While I highly respect antirez, I think this post is full of good sounding, short statements, that wouldn't hold in a discussion.
One example: Newbies shouldn't reinvent the wheel. I think they should use the tools, that are available and common in the given context. When they want to tinker, they should write their own compiler. But they shouldn't use that in production.
Another: Backward API compatibility is a business decision in most cases.
Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.
I strongly disagree. They should, and fail and try again and fail. The aim is not to reinvent the wheel, but to understand why the wheel they're trying to reinvent is so complex and why the way it is. This is how I learnt to understand and appreciate the machine, and gave me great insight.
Maybe not in production at first, but they don't reinvent the wheel in their spare time either. They cobble up 200 package dependency chains to make something simple, because that’s what they see and taught. I can write what many people write with 10 libraries by just using the standard library. My code will become a bit longer, but not much. It'll be faster, more robust, easier to build, smaller, and overall better.
I can do this because I know how to invent the wheel when necessary. They should, too.
> Another: Backward API compatibility is a business decision in most cases.
Yes, business decision of time and money. When everybody says that you're losing money and time by providing better service, and lower quality is OK, management will jump on it, because, monies.
> Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.
I think Antirez is spot on. We're destroying software. Converting it to something muddy and something for the ends of business, and just for it.
I'm all with Antirez here. Software came here, because we developed the software just for the sake of it, and evolved it to production ready where needed. Not the other way around (Case in point: Linux).
> Yes, business decision of time and money. When everybody says that you're losing money and time by providing better service, and lower quality is OK, management will jump on it, because, monies.
Often that "saving money" is just externalizing the cost onto your users. Especially in mobile development. Instead of putting in the tiny amount of effort it takes to continue support for older devices, developers just increase the minimum required OS version, telling users with older hardware to fuck off or buy a new phone.
Another example is when you don't take the time to properly optimize your code, you're offloading that cost onto the user in the form of unnecessarily higher system requirements.
> I'm all with Antirez here. Software came here, because we developed the software just for the sake of it, and evolved it to production ready where needed. Not the other way around (Case in point: Linux).
Growing up in the 80s and 90s I understand viscerally how you feel, but this take strikes me as willfully ignorant of the history of computers, and the capitalist incentives that were necessary for their creation. The first computer and the internet itself were funded by the military. The PC wouldn't have existed if mainframes hadn't proved the business value in order to drive costs down to the point the PC was viable. Even the foundational ideas that led to computers couldn't exist with funding—Charles Babbage's father was a London banker.
I think a lot of what you are reacting to is the failed promise of free software and the rise of the internet, when the culture was still heavily rooted in 60s counter-culture, but it hadn't crossed the chasm to being mainstream, so it was still possible to envision a utopian future based on the best hopes of a young, humanitarian core of early software pioneers operating largely from the sheltered space of academia.
Of course no such utopian visions ever survive contact with reality. Once the internet was a thing everyone had in their pocket, it was inevitable that software would bend to capitalist forces in ways that directly oppose the vision of the early creators. As evil as we thought Microsoft was in the early 90s, in retrospect this was the calm before the storm for the worst effects of tech. I hear Oppenheimer also had some regrets about his work. On the plus side though, I am happy that I can earn enough of a living working with computers that I have time to ponder these larger questions, and perhaps use a bit of my spare time to contribute something of worth back to the world. Complaining about the big picture of software is a fruitless and frustrating endeavour, instead I am interested in how we can use our expertise and experience to support those ideals that we still believe in.
I think what he is trying to say is that the value or focus was better when it was placed on the endeavors, not the means behind the endeavors. I don't think anything has to be inevitable. What matters is what we decide to do when challenges like these present themselves and how can we have more of a positive impact on the world when things go awry.
I take issue with your use of the word "utopian" being used in this context. Its not a lost cause to see the world from the perspective of making the world better, by finding our way though this with a better mindset on the future.
And while you are taking the time to ponder these questions because you earn enough to take the time, the world is burning around you. Sorry if my tone is harsh, but these kinds of statements really rub me the wrong way. It feels like you are saying everything that is happening is how its suppose to be and I am strongly against that. We have enough of that perspective, we really don't need it, IMHO.
Fair criticism, but saying "we are destroying software" is not actionable. I want us to do better, but I also want to be effective, and not just sit around impotently wringing our hands about how bad everything is.
I'll kindly disagree. For me, seeing or accepting where we are currently is enough to gently motivate me to do whatever I can do to change the current state.
This gentle motivation is good, because it allows me to look inside and be rational about my ambitions. I won't go to a blind crusade, but try to change myself for the better.
Because, I believe in changing myself to see that change in the world.
Fair point. I agree with you. Some times it just takes one person to say whats wrong with the world, to make people realize something can/has to be changed.
I actually don’t agree. Maintaining or not maintaining backwards compatibility is often a decision made on the technical level, e.g. by a tech lead, or at least heavily based on the advice from technical people, who tend to prefer not being restricted by backwards compatibility over not breaking things for relying parties.
> Newbies shouldn't reinvent the wheel. I think they should use the tools, that are available and common in the given context. When they want to tinker, they should write their own compiler. But they shouldn't use that in production.
So basically they shouldn’t learn the prod systems beyond a shallow understanding?
They absolutely should, or they will never even get to understand why they are using these wheels.
Fun fact, try to question modern web developers to write a form, a simple form, without a library.
They can barely use html and the Dom, they have no clue about built-in validation, they have no clue about accessibility but they can make arguments about useMemo or useWhatever in some ridiculous library they use to build...ecommerces and idiotic crud apps.
These systems also came from tinkering. Most programming languages even are really the investment of one person for a long time, doing apparently what you aren't supposed to do.
When it comes down to it, whatever works best and is usually the most simple, non-breaking, used to win out. That decision has been disconnected from the value creators to the value extractors. It is impossible to extract value before value is created.
Additionally, programming is a creative skill no matter how hard they try to make it not one. Creativity means trying new things and new takes on things. People not doing that will harm us long term.
>> But they shouldn’t use that in production.
> Why?
Generally speaking, because that’s very likely to end up being “pushing for rewrites of things that work”, and also a case of not “taking complexity into account when adding features”, and perhaps in some cases “jumping on a new language”, too.
This is an imagined scenario, but the likelihood of someone easily replacing a working compiler in production with something better is pretty low, especially if they’re not a compiler engineer. I’ve watched compiler engineers replace compilers in production and it takes years to get the new one to parity. One person tinkering and learning how to write a compiler almost for sure does not belong in production.
"parity" is the keyword here. Most of the time, the problem doesn't come from sloppy execution, but ever widening scope of the software.
For example, my own "Almost C" compiler[1] is 1137 lines of code. 1137! Can it ever reach "parity" with gcc or even tcc? No! That's specifically not the goal.
Do I benefit strongly for having a otherworldly simpler toolchain? hell yeah.
The key is scope, as always. Established projects have, by virtue of being community projects, too wide a scope.
Agreed, parity is a strong constraint. Since the premise under discussion was “production” environments where some kind of parity is presumably required, I think it’s a reasonable assumption. If there is no baseline and it’s not a production situation where parity is needed, then yeah scope can and should be constrained as much as possible. I like the phrase “otherworldly simple”, I might borrow that!
I don't think that people deciding what goes in "production" are immune to scope inflation. Thinking that we need parity with another software without realizing the cost in terms of complexity of that parity requirement is, I think, a big driver of complexity.
Those who do not know history are doomed to repeat it. Or re-re-reinvent Lisp.
There was this anecdote about storm lamp or something. New recruit comes to a camp and sees old guard lighting lamps are turned upside down and lit sideways with a long stick. But he knows better, he tells them and they smirk. First day he lights them the optimal way with a lighter. He's feeling super smug.
But next day he finds the fuse is too short to reach so he takes the long stick...
Few months later, he's a veteran, he's turning lamp upside down using lighter sideways, with a long stick.
And the fresh recruit says he can do it better. And the now old guard smirks.
I'm sure I'm misremembering parts, but can't find the original for the life of me.
If someone would hand me a project, that is full of self invented stuff, for example a PHP project, that invented its own templating or has it's own ORM, I would run. There is laravel, slim or symfony, those are well established and it makes sense to use them.
There are so much resources around those frameworks, people who posted about useful things, or packages that add functionality to those.
It just doesn't make sense to reinvent the wheel for web frameworks and thousands of packages around those.
Writing software is standing on the shoulders of giants. We should embrace that, and yes one should learn the basics, the underlying mechanisms. But one should make a difference between tinkering around and writing software, that will be in production for years and therefore worked on by different developers.
The JavaScript world shows how to not do things. Every two years I have to learn the new way of building my stuff. It is annoying and a massive waste of resources. Everyone is always reinventing the wheel and it is exhausting. I understand why it is like this, but we as developers could have made it less painful, if we would embrace existing code instead of wanting to write our own.
the shitstorms usually have a community behind it. Even if it sucks, it's supported and will be maintained to a point of it "working." If someone writes their own thing, chances are they won't go the extra mile and build a community for it. Then, when it comes to maintaining it later, it might grow untenable, especially if the original "tinkerer" has moved on.
This would be great if things like open source were more supported in the "real" world. Unfortunately, you're describing exactly why a community means nothing in this situation unless the community is giving back to the project. When the "original tinkerer" moves on, everything depending on that project breaks when everything else changes around it.
One example: Newbies shouldn't reinvent the wheel. I think they should use the tools, that are available and common in the given context. When they want to tinker, they should write their own compiler. But they shouldn't use that in production.
Another: Backward API compatibility is a business decision in most cases.
Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.