Hacker News Reader

Comment by gregdoesit | Hacker News Reader

What a fun read! The one that ended up being the most off in the thread:

> I predict (and hope for) a major turn back to simplicity in technologies. Multimillion-line software will go extinct like dinosaurs. Existing programming languages and platforms will gradually be replaced with ones so simple and elegant that one software component will be written and maintained by one to three developers and art designers and not a whole software company packed with managers and other unnecessary staff. Oh, and managers along with poeple who "understand" "software business" but not software will hopefully go extinct too.

If I can predict anything for 2030 based on this, it will be software being even more complex, with even more frameworks and abstractions.

View on HN

I'd say that this prediction is describing current developments quite well. Newer programming languages (Go, Rust) and development tools are making the "software as lean independent components" vision more relevant than it ever was.

Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work.

Performance comes from optimizing the usage of state against hardware, modularity comes from code satisfying the properties of composition which is best left stateless (and high levels of modularity must come from abstraction and conventional practice, incurring further debts on the programmer and machine.)

It's a tension that I haven't seen fully resolved but I'm very very very open to being wrong. Many languages seem to be experimenting in this space with some preference for one side of the equation for another.

> Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work.

We know how this works, at least in broad theoretical terms. Zero-cost abstractions are quite feasible within a self-contained module/component, but their scope is ultimately limited by ease of building and deployment. Nevertheless the performance impact of having to support high levels of abstraction across modules/components is quite reasonable, even if not literally "zero" cost.

I'm thinking supercompilation might be another part of the equation as long as we're talking extended composition of modules and types whose behavior is totally closed. Having a pipeline that can supercompile when systems are pushed in production even if some compilation time is traded for performance at development (maybe "local" supercompilation for subsystems relevant to a development team?) would be an interesting thing. But I don't know.

Fwiw, I agree about supercompilation.

Some have noted that JIT systems perform many of the same things as supercompilation, and it seems reasonable to consider that JIT is part of the equation for optimising performance when systems are pushed to production. We've been doing that for decades now, with increasing sophistication in the details. Profile driven, multiple stages of specialisation and optimisation.

Not quite to the levels of proof systems (and therefore supercompilation as envisioned) yet - there's plenty of room to get better at it - and we need to go there if we want those "zero cost abstractions" across modules that aren't designed for it, often with significant impedance mismatches.

Do you have any resources on this you could recommend?

He is quoting from 2010 and predicts the very opposite and I fully support the claim. Reasons:

  * industry has either no interest or capacity in quality
  * software flaws may cause severe harm but will play no role for the majority of the industry. it is a gamble just like vc business.
  * pace of change/inonnovation will actually add even more harm
  * excellence in the field will decrease because the baseline compexity is already too high, people will specialize probably in ML/AI/fin.

One chance I see is that the industry runs into a major HR crisis and some smart players understand that the complexity cannot be maintained by "developers" or "software engineers" anymore and come up with solutions other than opening up more positions.

I think inherent complexity can only be fixed by better monitoring. Visual tools, monitoring, real time feedback are all things humans can use to get a better grasp of the innards of things.

We could use a lot more of it in software.

Nothing can fix unnecessary complexity. It will continue to affect every tool used to maintain it.

I don't know where you come from, but all I see in my bubble is immense growth in Java and massive Apache projects / ecosystems. Exactly the opposite.

Ditto for Javascript. When I first used React in 2015 I thought it might be a harbinger for unix philosophy tools in the web space. A lib with a simple API that solves a single hard problem with a good implementation under the hood.

What I never predicted was the sheer enormity of the useless cruft the community would build around it. I used to contribute to some of the React community places (particularly irc), and in the early days the discussion there was super interesting. Now it's just endless waves of "I'm building X and having Y problem with dependency Z" where Z is something I've never used because it looks shit, Y is something I haven't encountered in 3 years, and X is something I could build in my sleep with just plain old React.

I've always wondered if Java devs feel the same, or if they're happy drowning in whatever crap is in their ecosystem? Like, do they all love Java but hate every single code base they have to work on? Or is that a uniquely JS problem?

Framework and language complexity is just a cycle thing. Someone makes a new language/framework that's minimal, clean, and suited to what people need. Needs change, or people miss certain things, it gets bloated, and the cycle repeats.

Except for C and C++. C just gets better, C++ just keeps growing.

> Even more framework and abstractions.

npm and is_odd comes to mind.

There surely is a lot of frameworks, it almost make more sense to have less.

Reply on news.ycombinator.com