@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.
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.
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.
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.
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.
"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.
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.
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
We get what I'd like to call a "tech bubble" but actual tech, not investment. Maybe "dev bubble"?
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.
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.
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.
Things are changing: more reliable browser updating, standardization & eg. Web Assembly
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.
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.
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.
I mostly use this account when I want to talk about #webdev.
A Mastodon instance for Rubyists & friends