@andrioid Or maybe we need a different timeline for copyrights and patents in software, like you only get 18 months before someone's allowed to copy your UI or API. It's fair to let people take advantage of their new ideas, but not to hold back everyone for years.

@EdwardTorvalds @jeremiah @InternetKevin Linux distros vs npm is a good question but with an easy answer: distros are typically actually vetted.

The culture around npm involves insane levels of trust and laziness. Not sure how fixable it is. It's like the crazy opposite of "not invented here" where it seems devs don't care about the reliability of sources.

Sometimes it really would be better to just write X yourself.

@InternetKevin @jeremiah @EdwardTorvalds "Drowning in complexity" -- I think that's a great succinct summary.

Too many technologies and platforms, everything over the network, a bunch of different languages just to do even the simplest things, and a lot of the time, the browser working against you, sometimes for good reasons (eg. security) and sometimes because of incompatibilities or outdated browsers.

@InternetKevin @jeremiah @EdwardTorvalds I'd guess JS is near its peak. Node helped a lot to make it "learn one language for server + client" and wasm could flip that around.

Wasm could be kind of invisible: you might just write code for the web and compile it without focusing on wasm any more than the jvm or native executables.

@InternetKevin @jeremiah @EdwardTorvalds I think wasm is the future but not present.

That's the web's big historical problem with new features: you have to wait for years before you can rely on enough users having browsers that support it.

Whereas on the desktop you just update your libraries on the dev side and compile. You can have platform issues, eg.if you want to use new OS features, but not nearly as much.

Wasm could change a lot of that.

@freemo @raichoo Still it can be a barrier, the difference between:

"I'll tinker with four new languages I've heard good things about for the next 3 months making toy programs in my spare time"


"I'll just sit down right now and start this new app."

It's tricky because every language exists for a reason and has its advocates. It's hard to know what you'll *actually* like using and find effective until you've written real programs in it.

And it's still about what *you* work best in.

@freemo @raichoo I agree learning new languages isn't a huge barrier.

When I was in CS, it was pretty normal to have brand new languages in each course, where the language wasn't the *topic*, just something we were supposed to learn on the side while doing course work.

I've even found I usually learned languages best by starting with a project and then learning the language people said was good for it. Way back I first learned Perl just to write a text processing script for a friend.

@InternetKevin @EdwardTorvalds @jeremiah
I'm really looking at the tech/culture issue of the web and seeing the relationship of factors influencing dev culture
* Tool availability
* Tool quality
* Platform popularity
* Platform homogeneity
* Customer goals
* Existing quality

The web's popularity combined with how awkward it is to develop simple things contributes to a culture where things are expected to suck a bit in quality but people want new, new.

But I also see some positive changes.

@InternetKevin @EdwardTorvalds @jeremiah Definitely it's *possible* to write robust software with minimal tools.

The funny thing is, the Apollo guys actually had a few advantages over modern web devs:
* They only had to build for a single well-known platform
* They were part of an organization that had full control over the whole system and how it would be deployed
* Their organizational goals absolutely favoured reliability and good engineering over speed to ship and number of features

@InternetKevin @EdwardTorvalds @jeremiah The JS/NPM culture makes me think of the idea of "tech debt" as an analogy to financial debt.

We get what I'd like to call a "tech bubble" but actual tech, not investment. Maybe "dev bubble"?

It's this mad rush to leverage tech; an overzealous "thou shalt not reinvent the wheel" and neophilia leading to infrastructure built on 3-month-old frameworks and at the bottom, tiny libraries like left-pad written by 14-yo's when they first discovered Javascript.

@EdwardTorvalds @InternetKevin @jeremiah I don't think dumbed down tools are to blame though. More like poor quality tools.

It's like JS culture which is all "let's scrap everything we've been using the last 3 months and try the NEW SHINY!"

Browser competition really screwed the web over for quality, but also drove change.

The web actually became a corrupted success of the Java vision: "write once, run everywhere." Except closer to writing viruses, making code to run on different platforms.

@EdwardTorvalds @InternetKevin @jeremiah The VB point definitely agrees with the premise that enabling fast development can lead to crappy stuff.

But a lot of it is also about *who* is doing the biz and dev. Eg. VB, PHP and now Node/JS/npm have at different times become favourite playgrounds for inexperienced programmers, where code quality sucks *but* there's always some half-assed library or tool that does what you want.

But it's also where the most buzz is.

@EdwardTorvalds @InternetKevin @jeremiah

Tools and better platforms are the other thing. When it was hard to code even HTML well, standards for web sites and web UI's were very low. They improve as better tools etc. make it possible to do a better job in less time.

When you make an app in C++, you can complain about platforms but it's so much easier than the HTML/CSS/Javascript shitshow, plus server side.

Things are changing: more reliable browser updating, standardization & eg. Web Assembly

@EdwardTorvalds @InternetKevin @jeremiah Have you ever heard of something called Visual Basic? 😂 It had a similar effect for desktop apps but was even easier.

Speed of development has always been a concern. I'd say that in terms of how markets work, you get lower quality in new categories where people are willing to sacrifice reliability for features they can't otherwise get. But as a product category matures, reliability matters more.

I'd say better tools will help to drive quality...

@Gargron In the ranking of statements that shouldn't be controversial, that should be up there, but then this is the internet...

They really do have a great opening sequence.

@EdwardTorvalds @InternetKevin That is, web developers discovered the joy of being able to "ship" buggy half-assed code today, see what goes wrong, and fix it tomorrow.

At that point in time you *couldn't* do that on the desktop. Today you more easily can because of internet updating, but it's not as built-in as for web apps.

I think it's a combination of both the web's hodgepodge tech mashup, and the historical culture of web dev.

@EdwardTorvalds @InternetKevin In web dev you definitely have a lot of constraints that don't exist when you're making a native app, and you typically have to work with multiple languages and a startling array of runtime platform inconsistencies.

I think some things are also easier, just based on what the platforms historically have been expected to offer.

But as web app use cases approach desktop apps, I think it's harder to achieve the same thing.

Still, you're not wrong about the culture.

@viTekiM It's counter-intuitive but probably the best option is to start with some kind of physical activity. When you wear out the body, pretty much everything feels more relaxing after.

Also yoga's good for that. Or walking in nature.

@sir @amiloradovsky So you're saying... DOS batch files were multitasking done right?

@raichoo @freemo ...BUT still, in most cases the first order differentiator between apps is whether you wrote it at all, or not.

Sounds simple but realistically the biggest hurdle tends to be "did I finish it in a meaningful way?"

So it can be about picking the language you enjoy using the most.

Of course it depends on use case too, and in a real sense languages aren't just syntax but libraries, tools and even supported platforms too.

As @freemo says, removing bug classes often adds others.

Show more

A Mastodon instance for Rubyists & friends