Live data from Hacker News

The Software Crisis

wryl.tech

111–120 of 201 posts

Re: The Software Crisis

#111
> It is no longer easy to build software

It is very easy if you know the right tools for the right job, but information about these are suppressed so you never hear about them.

What the vast majority of people think the tech tooling landscape looks like and what it actually looks like are very different. The tools we know about are mostly horrible. They try to be silver bullets but they're really not good for anything... Yet they're the most popular tools. I think it's about capital influence, as hinted by the article.

For example, with the tool I'm using now, I made a video showing how to build a relatively complex marketplace app (5+ pages) in 3 hours with login, access control, schema validation, complex filtered views from scratch using only a browser and without downloading any software (serverless). The whole app is less than 700 lines of HTML markup and 12 lines of JavaScript code. The video got like 10 views.

Re: The Software Crisis

#112

> It is no longer easy to build software It is very easy if you know the right tools for the right job, but information about these are suppressed so you never hear about them. What the vast majority of people think the tech tooling landscape looks like and what it actually looks like are very different. The tools we know about are mostly horrible. They try to be silver bullets but they're really not good for anythin…

Link it!

Re: The Software Crisis

#113
post #101

Earlier quoted context omitted.

Yes to this. Lately I feel like we have built a society with expansive software infrastructure, where that software is doomed to be crappy and inhumane because our society actually couldn't afford to build this quantity of software well. So another hypothetical fantasy solution would be a lot less software, like being careful about where we used software, using it in fewer places, so that we could collectively afford…

Our society / societies may well be able to afford to build this quantity of software well. We choose not to.

I don't know how/haven't seen an attempt to approach this question by a method other than "my hunch", but as a software engineer "my hunch" is it would cost at least 10-50x as much human labor (not just engineers but designer and UX researchers as well as all the other support roles like project managers etc) to build the software "well" (including more customization for individual enterprises or uses), and that it would become an unsustainable portion of the GDP.

Just "my hunch", but one I reflect on a lot these days.

Re: The Software Crisis

#114
post #16

Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…

It's important to remember "Clarke's three laws"[0]:

  The laws are:

    1. When a distinguished but elderly scientist states that
       something is possible, he is almost certainly right. When
       he states that something is impossible, he is very
       probably wrong.
    2. The only way of discovering the limits of the possible is
       to venture a little way past them into the impossible.
    3. Any sufficiently advanced technology is indistinguishable
       from magic.
Depending on one's background and when they entered this field, there exists a non-trivial probability that previous abstractions have become incorporated into accepted/expected practices. For example, at one point in computing history, it became expected that an Operating System with a general purpose file system is assumed to be in use.

The problem I think you are describing is the difficulty one experiences when entering the field now. The prerequisites in order to contribute are significant, if one assumes the need to intricately understand all abstractions in use.

While this situation can easily be overwhelming, I suggest an alternate path; embrace the abstractions until deeper understanding can be had.

0 - https://en.wikipedia.org/wiki/Clarke's_three_laws

Re: The Software Crisis

#115
post #101

Earlier quoted context omitted.

Yes to this. Lately I feel like we have built a society with expansive software infrastructure, where that software is doomed to be crappy and inhumane because our society actually couldn't afford to build this quantity of software well. So another hypothetical fantasy solution would be a lot less software, like being careful about where we used software, using it in fewer places, so that we could collectively afford…

Our society / societies may well be able to afford to build this quantity of software well. We choose not to.

What doesn't get spent on quality goes down as profit. This is why we have fake mobile games. Vaporware is the real software crisis.

Re: The Software Crisis

#116

Shallow and composable is something we all experience when using UNIX tooling. GUIs are where this all falls apart as they are literal islands that don’t communicate with each other in a composable manner. I’ve been experimenting with some GUI-meets-shell-pipeline ideas with a tool I’ve been working on call guish. https://github.com/williamcotton/guish I’m curious to know if anyone knows of any similar tools or appro…

This looks pretty cool!

I agree -- a big reason I like Unix, and find it productive, is that it's "shallow and composable".

But GUIs have long been a weakness. I guess because there are many "global" concerns -- whether a UI is nice isn't a "modular" property.

Personally I would more of a UI, but still retain automation

That is, the property of shell where I can just saved what I typed in a file, and then run it later

And modify it and run it again

Or I can copy and paste a command, send it to my friend in an e-mail, etc.

---

As context, I've been working on a from-scratch shell for many years, and it has a "headless mode" meant for GUIs. There are real demos that other people have written, but nobody's working on it at the moment.

Screenshots:

https://www.oilshell.org/blog/2023/12/screencasts.html#headl...

https://www.oilshell.org/blog/tags.html?tag=headless#headles...

More links here - https://github.com/oilshell/oil/wiki/Interactive-Shell - some interesting (inactive) projects like Xiki

If you find the need for a compatible shell that's divorced from the terminal, or a NEW shell that is, feel free to let me know (by e-mail or https://oilshell.zulipchat.com )

Basically we need to people to test out the headless protocol and tell us how it can be improved. I think we should make a shell GUI that HAS a terminal, but IS NOT a terminal -- which looks like it has some relation to what you're building

Right now we're working mostly on the new YSH language, but I'd like to revive the GUI work too ... I'm not an experienced UI programmer, so it would be nice to have some different viewpoints :)

---

Also, I'm a big fan of ggplot, so I'm glad you included it there.

Actually ggplot is exactly where I miss having graphics in shell!

Re: The Software Crisis

#117
post #24

Earlier quoted context omitted.

It's hard to get past the hubris wrapped up in the statement "I'll show you how"... as if the tens of thousands of bright engineer's whose shoulders you stand on were incapable and you're the savior... maybe you are! (But just adding the word "try" in that sentence would reduce the perceived arrogance by orders of magnitude.)

Well, that certainly wasn't my intention, but in an environment of "I have a silver bullet and it'll cost you $X", I can understand the sentiment. At the same time, I do want to show that I have confidence in my ideas. Hubris and confidence must be applied in equal parts.

Hubris and confidence are two sides of the same coin. Did you maybe mean to say that one should balance hubris with humility to avoid coming across as arrogant?

Re: The Software Crisis

#118

Earlier quoted context omitted.

The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality. With a bridge, for example, at some level it must meet a minimum bar of structural integrity, quality of materials, etc. or it will fall over from its own weight. As a cook, there is a bare minimum I have to hit with the quality of my ingredients and skill of preparation in order…

> The thing that is unique about software is the lack of physical constraints which serve as a natural forcing function or filter on quality. Completely agree with this. The number of good+reasonable solutions is almost infinite, and the number of bad solutions is also almost infinite. What makes it even worse is that we really don't have a good method of communicating the design+structure of our models to others (te…

The number of bad solutions is not just almost infinite. It is definitely infinite. Because, by induction, you can always make another bad solution from a bad solution by adding something unnecessary to it. Hence infinity. QED

Re: The Software Crisis

#119

Earlier quoted context omitted.

> But yes, sometimes the phone doesn't stop vibrating. I failed to communicate clearly. Yes, I agree, the scope of human achievement is amazing, software included. However, the issues with software go far deeper than just the trivial example I gave of the phone. It's pervasive and pernicious. I assume most software developers understand this as lived experience, but I'll elaborate more. Almost every single person I k…

I think I agree with you but disagree with the article. > But because of the things called out in this article, these magical tools and technologies are plagued by endless amounts of things that just don't work right, break randomly, and fail in unexpected ways. There is way more software out there than one can even imagine responsible for literally every aspect of human society. There is an insatiable need for more…

I just wanted to thank you two here. Your dialog is so insightful. I think the original article was bad. It's biggest merit is that it got you two together here in the comments!

Re: The Software Crisis

#120

If you look at the resumes of engineering or automotive company leadership, you'll see people going through stages of ever expanding responsibilities of part, component and product design, or management of production facilities of increasing size and importance. The CEO will still emphasize their technical knowledge, non-technical staff will at least try and fake it. In agile software development on the other hand, t…

> I partly blame Hollywood and their incessant humiliation of software/IT people, while creating endless leading roles for doctors and lawyers, effortlessly weaving their complicated terminologies into fascinating storylines, which is aparently not possible to do for us? Doctors and lawyers deal with people and everyday problems that are easy to turn into a interesting story. I don't see many contract lawyers or radi…

Bugs can make great stories. But only for a niche audience. Not Hollywood.
Post reply on HN