Hacker News Reader

Comment by throwaway984393 | Hacker News Reader

When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy, because they just like doing new things in newly complicated ways. It's like changing how we build houses every few years just for fun, with no benefit to the people eventually living in that home. We're definitely not saving them money or building them any faster.

View on HN

After having been in this industry for 20+ years, I can pretty confidently say the world of software will never wake up. It's just been an endless cycle of adding abstractions, removing them again, using back end languages on the front end, using front end languages on the back end, using relational databases instead of a key value store, using key value stores instead of a relational database, unit tests over integration tests, integration tests over unit tests, silver bullet framework after silver bullet framework.

My feeling now is that in the greater scheme of things none of the technology choices really matter all that much, the main thing is if the software is written in a clear, documented and maintainable fashion. Unfortunately people will still throw that away and pointlessly rewrite it in a few years, so making the choice to contribute in that fashion is more a matter of professional pride than practical utility. Arguably it's better for your career to let go of that pride and just embrace the constant unnecessary rewrite process.

I do wonder if there are still some corners of software development which aren't like this. Perhaps in public universities or government?

Agree. Specifically on the point of "clear, documented and maintainable" I think this is where languages such as Ruby (and therefore Rails) shines.

Since it was "optimized for developer happiness" (https://news.learnenough.com/ruby-optimized-for-programmer-h...) it's more likely to be easier to understand, document and maintain.

Unfortunately in practice, there is so much ruby/rails magic going on that most Rails projects end up in terrible shape.

It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams

This was my experience with rails (to be fair, some years ago). Each new version reinvented some huge chunk of the previous version with magic all the way down. Basically why I stopped using it despite having invested lots of time.

> there is so much ruby/rails magic going on that most Rails projects end up in terrible shape

Should check out Java Spring (and for a bonus round, Lombak). So much magic pixie dust spewed around to get around not being able to monkey patch.

This I think shows how "clear, documented, and maintainable" can mean different things to different people.

I specifically left Rails and Ruby because I failed to see any production Rails code actually meet any of those criteria. All of the metaprogramming, OOP, inheritance, and DSLs just made the code more confusing than it needs to be. Ruby is a cult of "the code documents itself", but code can never document itself, because good documentation includes the how and the why and some examples. Code is a horrible at describing how it exists, and no, unit tests are often not sufficient examples. And then there's the issue of Rails apps taking way too long to boot up despite their only job being to serve webpages. Debugging serious issues is a pain when the Ruby code takes minutes to actually run, and having neither clear nor documented code doesn't help. It's always abstractions upon abstractions upon abstractions.

But some people like Ruby because it's a beautiful language and Rails gives them an opinionated structure, and maybe that matters more to them.

I'll take simple functions and primitive data structures with detailed comments any day over design patterns with a bunch of classes to describe abstract ideas that inherit from one another and fail to self-describe.

> I do wonder if there are still some corners of software development which aren't like this. Perhaps in public universities or government?

Try aerospace, defense, critical infrastructure. They tend to move much slower and methodically about their stacks.

I think it's a maturity thing. I've found myself going from wanting to use cool technology to build whatever to wanting to use boring technology to build cool software.

A few decades of programming has taught me that cool technology inevitably turns out to be janky and annoying and half-finished.

I agree it's a maturity thing, but I wouldn't say the cool technology 'inevitably turns out to be janky and annoying and half-finished.' I think it's more that the cool technology is developed for a certain use-case and, developers being the way we are, we pick up our new hammer and proceed to test if every object around us is a nail.

We also won't accept other people's test results. Sure, 80 other devs have said this isn't a nail, but are they SURE?

It's not the technology's fault.

Maybe not inevitably, but the vast majority of of yesteryear's cool technology is obsolete and forgotten today. The remaining became mature "old" technology.

There was a time Java used to be cool new technology.

20+ years here too, and I agree to a large extent.

The conclusion I've come to is that we're making expensive sandcastles. I don't know when I start a project how big the sandcastle will need to get, or exactly what it will end up looking like. I also don't know when the tide is coming in. Some of them were pretty good, others were disasters, but they've all washed away now.

I do quite like building sandcastles though, so I don't worry too much about it.

Same here.

I think the fashion industry is a consequence that a big subset of the industry lives from selling services, books, trainings, conference talks,....

So the need for something new needs to be constantly generated so that the crowds feel the need for new content and buying services.

Then on top of that, most people new to the industry tend not to learn the past, so they keep re-discovering stuff as the "new coolness".

I think no one is going to necessarily disagree with what you’re saying, but I’d also ask what is the point? It’s almost tautological.

Of course this is the case, so does that mean new things shouldn’t be made because it’s been pre-decided it would be a waste? I can’t say I agree with that, even though I agree with the premise that all PLs suck.

Maybe this stuff is just hard, and also maybe part of that is because as humans we’re pretty limited. So I think we just have to deal with it and try. I don’t love front end stuff, for example, and it kind of annoys me at times that everything gets reinvented over and over, to great fanfare no less. However at the end of the day, I realize it’s because we’re limited and one of those limitations is not being smart enough to do everything right the first time. That makes sense and isn’t like a knock on people, just the truth.

And these new frameworks and paradigms that keep getting made indicate to me that things are reaching some stability, but aren’t there yet. Like, a lot of native stuff has been literally miles ahead for years, which is why you don’t really see a ton of innovation in that spaces, aside from adding new frameworks to support new sensors. But you still see stuff getting made to support more privacy aware stuff, which is a shame because it could have been that way from the beginning.

Anyway, I think it’s fine for both to be true: PLs suck because tech is hard and people are limited, and we keep trying new stuff because it’s just both there yet.

(Note: wrote this on my phone so maybe it rambles and is incoherent or has mistakes)

Maybe once we lift the abstractions from the clutches of the Von Neumann architecture and reintroduce spatial and sensory mechanisms to our programming environments? Especially with server-client applications, the underlying topologies are often ad-hoc and brittle, which contributes to the complexity in sneaky ways. Jaron Lanier, a pioneer of VR, has a concept of "phenotropic programming" which is almost like OOP taken to the extreme - objects can only sense and act on each other in a virtual world akin to the real one [0].

If you want to really fall down a rabbit hole, Alan Kay has been espousing similar themes for years. He of course was the driving force behind Smalltalk, which did things in the 70s that still seem hard to do. Look at the examples built by middle schoolers in [1] - super impressive stuff! I personally believe OOP got a really bad rap by the bastardizations of C++ and Java, and a principled reframing of it may be what takes us to the next level of programming.

[0] https://www.edge.org/conversation/jaron_lanier-why-gordian-s...

[1] https://www.dgsiegel.net/files/refs/Kay,%20Goldberg%20-%20Pe...

If you can only see the churn and froth, that doesn't mean there aren't great waves to surf; you might just need to paddle out to a better spot.

https://remix.run is a prime example. It's new, and better, and simpler.

It's better for new people joining, each cycle brings some improvement over the last typically.

It also equalizes the playing field every few years, you become an expert in the latest new thing as there isn't an old guard. Some new web framework comes along, you can invest in that and become leet, where its very difficult to start new in react today and achieve that.

This isn't to say past experience isn't valuable or helps you adopt things more quickly, can make you cynical about the new shiny and sometimes miss out on the actual improvements, even if small. I

laugh

1. software is a VERY new discipline. its also one of the most malleable. I doubt we'll ever stop seeing churn in this space.

2. we don't reinvent the how we build houses each year. you can safely ignore all this new fangled web things if you want.

3. churn is also domain specific. we've more or less stopped inventing drastically new APIs at the OS/system level.

4. software for UIs have never been great. we are still learning how to build them. most of the major players in UI software still exist, windows, java, macosx (cocoa?), QT, GTK, Enlightment, and HTML/CSS/javascript.

finally software will continue to evolve as base layers add the ability for higher layers to do things differently. for example as CPU get more and more vector operations that can dramatically change how we write code.

this churn is a positive not a negative on the industry.

The churn keeps me employed :)

This. So much this. Futhermore - does it all really matter that much when most of us are stuck with delivery managers screaming: FEATURE, FEATURE, FEATURE in our faces, such that there is never enough time to use any toolset in an optimal way.

At this point learning C++ standards is like learning new frameworks. There is no escape other than reclusing to C (maybe not so bad!)

No offense, but that’s sort of a bitter take on software development and reads like a middle manager who has contempt for software engineers.

I don't think this is the case at all, maaaaybe it's a tad cynical in tone, but I think overall it's a pragmatic and realistic view of software engineering, ESPECIALLY web development.

I say that as someone who is been in the industry since just before the first .com bust, and have seen a lot of this cycle.

No offense, but you have probably not been in software development for 25+ years.

I've been doing web dev for 30 yrs and it's kind of funny to see everyone inventing server side rendering, plain old html and php again. It's a spiral, not a circle and we're a bit wiser and performant this time, but much of it has been done and gone in some way or another.

If you think this is the same as "old html and php again" then you haven't understood the article.

> No offense, but you have probably not been in software development for 25+ years.

You're wrong about this.

You and I see things differently.

You see things as never being new and "plain old X and Y again".

I try to see things with fresh eyes, yet still with the benefit of my 25+ years in the industry. I try not to make assumptions that limit my thinking about something. Some might call it a beginner's mindset, and it has served me well.

> I've been doing web dev for 30 yrs

That would be impressive, since Mosaic is only 29 years old at this point :)

I don't thinking people are reinventing server side rendering. Rediscovering it, perhaps. It has always been here, along with plain old HTML and PHP. The modern toolbox of JS-based toolboxes exists for a reason: all the things that you can't do (or can only do very clunkily) with server-side implementations. That hasn't changed.

What people wanted from a web page in 1994 is so utterly different than what many web pages are expected to do now. If it's a spiral, it's one that is spiralling out, not in, as the scope expands significantly.

Reply on news.ycombinator.com