But as someone who has had the luxury of taking time to do things the Right Way let me tell you from firsthand experience: doing things the Right Way is incredibly hard in no small measure because figuring out what you actually want to do is incredibly hard. There have been many times when I thought I was building something for the ages only to discover that I had made a bad assumption, or technology changed, or the market changed, or my own desires changed. The process of meeting human needs is messy because both human needs and the tools we have at our disposal are a constantly moving target.
Software development is inherently explorative. Finding the right solutions is exactly that: finding, discovery, learning and play. IMO This is best enabled by fast feedback loops and highly dynamic, interactive systems and visualization.
Sometimes it is possible/feasible to parametrize a tool beyond what it is supposed to be doing to enable this kind of play and discovery, but also to make the process of building data, plumbing and so on just a bit more efficient and fun.
Game programmers get that: At some point while developing a game, they create the tools that produce the data, or the parameters, typically controlled with a visual interface, a configuration language or a scripting language. Level editors, state machines, behavior trees, story boards, flow scripting etc.
Another field that does this well is scientific computing, they use Jupiter Notebooks etc. with integrated REPLs and graph visualization.
The whole "no-code" and "low-code" trend[0] also shows that people are willing to program with constrained, visual languages. It empowers them and connects their mental model more directly to a product (instead of having to go all the way through a team of implementers for every change that could be exposed as data).
[0] I personnally don't like the terms "no-code" and "low-code" at all, because they describe what it is not, instead of what it is: visual programming. It's like "no-sql": Could be anything from a configuration file, to a document db, to a key-value store or a ACID graph db.
Lisp is also widely perceived as an interpreted language. Willful ignorance does not make reality even if it is widespread.
Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again.
When teaching goes to shit, you’re breeding and propagating, institutionalizing horrible ways to do something - amplified 100x because YouTubers are chasing viewership. That code camp 8 hour course is better replaced by reading good books and docs. Actually build something by thoroughly reading the docs.
Now you got 100x more developers building foundational blocks that other developers blindly build atop.
Study what Unix did when they were building small composable highly quality building blocks. Still used today after 45 years!
This is largely a problem with people unable to shift practice according to the context, lazy developers and managers thinking "it works" means "ship it and never look back". Unfortunately, there is no cure perfect cure for lack of foresight and willingness to listen to the guy saying PoC code will cause problems at some point down the line.
Lol :-D. You haven’t worked in a shop, have you?
Don't worry, we're not offended because we know it's true.
I bet that pretty much most of NPM's package index consists only of weekend prototype projects that are abandoned afterwards. It's sad to see that there's literally no baseline of quality measurements on NPM, and people give them stars far too quickly, without realizing that it's literally a single line of code with megabytes of useless testing around it.
Most of the patterns in UI/UX frameworks that come and go all the time are actually very very old paradigms that have been known in Computer Science since the 60s-70s. I always feel like no one reads a book about Software Engineering or Software Patterns anymore, let alone tries to find patterns in alternatives and makes a pro/contra list of features to find out what they actually want.
All go hush hush and rush rush to put out their next starlet on GitHub, without actually thinking about a software architecture anymore. Those that do are somehow invisible to the masses; and can never gain really a traction behind their ideas, which leads to the abandoned code problem either way.
Don't worry, systemd has integrated building blocks that can replace all that. Those pesky reusable, composable modules won't hit their 50th birthday.
Many companies wouldn't have existed if they didn't move fast and tried to perfect everything instead of prioritising getting to market.
Don't put the same level of care into the weekend side web app you are creating for fun as to the rocket ship you are building.
Not really relevant.
At first I was inclined to comment "it doesn't" because I can easily build small but useful tools in a matter of days.
But your comment made me realize that maybe the reason is just that I keep using the same old C++ libraries to avoid surprises.
In my last Ruby project, critical APIs changed multiple times during development. But Boost / openssl / curl / TBB / MKL are surprisingly API stable, given how much is changed under the hood.
Maybe conservative languages attract conservative programmers who conserve time by conserving APIs.
All the easy problems are already solved and well-documented, and less likely to break my code with a new release.
I then try to write code in such a way that it would have worked 15 years ago and today both, working around platform changes.
My current stack is Perl, HTML, CSS, SSI, PHP, SQLite, PGP, txt, and JavaScript.
And yes, my sites do work in Netscape 2.0+, IE 3.0+, Lynx, Links, w3m, and with a few settings tweaks, also Mosaic.