11 ms·

I hate almost all software (2011)

154 points by Decabytes 3y ago

auntienomen 3y ago
The thing is... I am the user.
bb88 3y ago
(2011) And not much has changed since then. Previous discussion: https://news.ycombinator.com/item?id=3055154 https://news.ycombinator.com/item?id=3055154
- dang 3y ago
  Thanks! Macroexpanded: I hate almost all software (2011) - https://news.ycombinator.com/item?id=28181632 https://news.ycombinator.com/item?id=28181632 - Aug 2021 (247 comments) I hate almost all software (2011) - https://news.ycombinator.com/item?id=15142316 https://news.ycombinator.com/item?id=15142316 - Aug 2017 (8 comments) I hate almost all software (2011) - https://news.ycombinator.com/item?id=13586596 https://news.ycombinator.com/item?id=13586596 - Feb 2017 (144 comments) I hate almost all software. (2011) - https://news.ycombinator.com/item?id=10553408 https://news.ycombinator.com/item?id=10553408 - Nov 2015 (2 comments) “I hate almost all software” — Ryan Dahl - https://news.ycombinator.com/item?id=3055154 https://news.ycombinator.com/item?id=3055154 - Sept 2011 (292 comments)
efields 3y ago
Absolutely one thousand million.
metadat 3y ago
Wow, this struck a nerve. https://www.linkedin.com/in/tinyclouds https://www.linkedin.com/in/tinyclouds Looks like he's still all in on Javascript with Deno? Interesting. I wonder what, if anything, has changed in his perspective.
deleted 3y ago
[deleted]
livinglist 3y ago
When I work on my own projects, I used to try to balance both worlds cuz I want these source code to be seen, but after some time observing GitHub insights on my repos I noticed barely any ppl even care to check out any sub directory like lib or src.. so I stopped caring about coding styles or formats, i do keep my repos zero warnings from linters though, for my own pleasure.
henning 3y ago
Then why build another incredibly slow dynamically typed monstrosity that breeds bugs and bad quality at industrial scale? Stop building JavaScript infrastructure.
- nforgerit 3y ago
  C'mon it wasn't that bad. npm was a fun experiment on what could possibly go wrong with putting leftpad into a single package. For me it's still by far the best runtime to do anything event-alike/http/json/web. It's quick to develop small things and quick to deploy (if you omit the whole transpilation shenanigans which of course help if you have dozens of engineers working together).
- rektide 3y ago
  He took one of the fastest & most successful & invested in existing JS engines & bolted on a pretty decent standard library. Great winning move, where a ton of the hard part of language optimization & growth is other people's problems, & Ryan could focus on making a great developer experience, which he and izs (npm author) did.
- richardjam73 3y ago
  They probably realised after that was done.
ChrisMarshallNY 3y ago
I remember a poster (but not the venue), who had a .sig that read “I hate code, and want as little as possible in my software.”
justin_oaks 3y ago
C'mon. I can't be the only one who is amazed at the things we've managed to build on top of a unnecessary complicated foundation. It's quite amazing that we've put layer after layer of leaky abstractions on top of each other and managed to make systems that mostly work. I don't hate all the software. I think it's awesome. It can be hell to develop, though.
- hejcloud 3y ago
  Reading your comment I can't help but think about that we're now starting to feed our layer lasagne that "mostly works" with code generated by a stochastic parrot which also only "mostly works" and turn the resulting products into some kind of fabric of the society. Ten years from now must be a fun time.
  - malikNF 3y ago
    "When I started, all I had was swamp! Other kings said I was daft to build a castle on a swamp, but I built it all the same, just to show 'em! It sank into the swamp, so I built a second one. That sank into the swamp. I built a third one. It burned down, fell over, and then it sank into the swamp. But the fourth one stayed up! And that's what you're going to get, lad--the strongest castle on these islands!"
    - RangerScience 3y ago
      Yep yep. Great way to solve a leak is shove enough stuff into it; it’ll stop leaking after enough!
      - MonaroVXR 3y ago
        Laughed way to hard about this.
      - bitwize 3y ago
        You laugh, but... AI only got real traction when we stopped teaching computers clever efficient ways to solve logic puzzles and started throwing massive amounts of data, memory, and compute at the problem.
mberning 3y ago
It would be nice if all software were simple, elegant, and minimal. But I don’t know why we should expect it to be. The hardware that runs the software is complicated on a whole other level. You want and simple, elegant and minimal cpu? Video card? Sound card? You better be ready to give up a LOT to get that. And giving up the current experience is something end users really don’t want to do.
- rektide 3y ago
  Simple elegant & minimal is subjective IMO. What absolutely shatters us is that we almost never have enduring & exposed bases. Software is endless layers of abstraction reaching upwards. Very few layers expose themselves at all. So we are all strangers to most software. For software to be simple elegant & minimal, we would have to be able to deploy existing knowledge, be able to leverage the fundamentals we know. But that's not where we are, but we are all adrift: > In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with.
- bb88 3y ago
  Back in the 1990's there were maybe 5 languages commonly used (C/C++/Assembler/Turbo Pascal/Visual Basic). Now there's 40. Each one needs it's own networking library. 8 different kinds of databases - with each language needing it's own adapter. 5 different web frameworks for each one. 3 different json libaries. It's a classic cartesian product. And instead of "I'll help fill in the gaps", its "I'll solve the problem by writing a new language!" -- which just makes the cartesian product bigger.
  - stefncb 3y ago
    And that's fine. Choice is good. IMO the problem isn't that there are a lot of things to choose from, it's that there are a lot of things on top of each other. Stuff on top of stuff on top of stuff. I personally wouldn't want to live in a world in which I could only use "one of these 5 languages", whatever those are. But I would love to live in a world where things weren't so deep in abstraction and complexity. These are two very different problems.
oofta-boofta 3y ago
All software, frameworks, etc is a reflection of the creature that created it: a Human, with all our faults, affectations, and prejudices. A lucky few have a come to Jesus moment and realize that nothing is perfect and that fighting the tide by swimming upstream is a fool's errand, they swim sideways to the shore.
- doitLP 3y ago
  I disagree, humans can create amazingly beautiful and simple things. All software reflects the environment in which it exists, including the time pressures involved in its creation and the complex, messy reality it is trying to model. We’re all familiar with a “90% MVP” that is small and elegant and solves the main use case sort of ok. Beyond that, reality has a lot of detail and edge cases and that’s when software gets nasty.
  - roeles 3y ago
    Then open source should be amazingly beautiful and simple?
- ssss11 3y ago
  But “upstream” is created by us, humans. All it takes is enough of us to change the direction of the current.
deleted 3y ago
[deleted]
gavinhoward 3y ago
Heh. I do too. In fact, I'm writing my own framework that replaces most of libc. It builds a better foundation, and I'm better off for it.
- Conscat 3y ago
  That's awesome! I'm working on something that sounds similar. https://github.com/cons-cat/libcat https://github.com/cons-cat/libcat I'd love to see your work if you're willing to share it here!
  - gavinhoward 3y ago
    Once I have an actual working piece of software, I will announce it on HN. This framework is not meant to be shared really; it's more building my own software stack from scratch, kind of like [1]. [1]: https://www.youtube.com/watch?v=443UNeGrFoM https://www.youtube.com/watch?v=443UNeGrFoM
TOGoS 3y ago
> The only thing that matters in software is the experience of the user. I mean, sometimes software development is enjoyable as an end in itself, otherwise Shenzhen I/O wouldn't be a thing. That said, it's a lot more enjoyable when the blocks you're building with are nice self-contained things that work well together like LEGO bricks. As opposed to a bunch of double-clawed hammers that are all invisibly connected with strings under the floor so that when you try to pick one up your drill automagically turns on as it falls off the shelf (I am borrowing some PHP-fractal-of-bad-design metaphor but it applies just as well to Spring Boot or whatever-the-f&^& somebody with too much time on their hands thinks is fun to inflict on me). Abstractions are great so long as they don't leak. But software development seems to have become the art of not going insane while trying to maintain castles in the sky that are oozing spaghetti sauce from every crack. So anyway, I agree with the author, but maybe for slightly different reasons.
taeric 3y ago
I urge the author to never look into building a physical building. The codes and amount of work you have to do to legally start are already complicated. But then you start buying screws and realize the entire screw isle at building supply store is bigger than many small grocers. And probably isn't complete. Heaven help you if you want to do something aesthetically pleasing like a pocket door. Or, far worse, heaven help you if you want to fix a pocket door. Finding a compatible wheel mechanism is usually most easily done with, "rip it out and use a new mechanism." Then there is car maintenance. Check engine light says something about the eco subsystem isn't working right? Here is a book mechanics use that list the common reasons for the code. Not standard across makes. Or models, even... I could probably go on. Point is nothing is greenfield lacking in complexity. I agree we probably could do better with software. But having done embedded work, I think it is easy to be ignorant of exactly how much has to coordinate in a computer system.
- gsatic 3y ago
  We can't do better with software Individually. But we can with groups. And most software ppl are quite useless at group formation and maintenance, hence the perpetual drama and tantrums.
- debacle 3y ago
  Cars are a fun one "Your emissions system is failing. It's probably because there's rust on the inside of your gas cap." That kind of troubleshooting is about as software as it gets.
  - el_benhameen 3y ago
    Hey, I just fixed that one. Turned out to be a mystery evap hose under the rear seat with no visible signs of wear or failure. Was it what any of the mechanics I talked to thought it was? Nope! Did anyone carry the part, or was anyone even able to identify the correct part number, even with a diagram? Nope! Did I have to hunt all over for some marine fuel line that happened to have the same inside diameter so that I could jury-rig a new part? Yep! Diagnosis and repair actually felt a bit like working with third party libraries: all the documentation is wrong, the problem is never your first guess, and you end up rolling your own solution in the end.
jabbany 3y ago
> The only thing that matters in software is the experience of the user. I have one disagreement with this... There is another thing that matters in software --- the experience of the developer making it. IMHO, I agree that libraries, languages, tooling,... etc. are not art whose complexity should be admired. But they are a necessary intermediate tool for _developers_ to make their work easier. We can apply the same logic to something like construction. You can build a house with hand tools and man power, just like you can write code in machine language. It's not enjoyable but you can do it. The work around developer tooling is like a builder working with scaffolding, an excavator, a crane, an electric drill... You spend effort to set it up, and before the final product is delivered, you have to tear it down. But it was still worth it because it serviced the developer in some transient way.
- cheeselip420 3y ago
  It only matters as far as the cost to the user (including any externalities due to poor construction). The software serves the user. Period.
  - BobbyJo 3y ago
    The software serves the business' bottom line period. The user only matters in so far as the keep coming back and paying money (or attention, which is also money). Developer experience only matters in so far as it keeps costs low, creating better margins. If that sounds kind of gross to hear, it's because it is. Businesses are made up of people. Customers are people. Every interaction on both sides of the equation should take that into account. If you ruthlessly maximize like the human part doesn't exist, your optimization strategy will fail.
    - Tehdasi 3y ago
      "The software serves the business' bottom line period." Making big assumptions about what the software project here. Given the article was mostly complaining about software developed for developers by developers, I don't think we can blame the suits for this one.
adamnemecek 3y ago
Let's be real the languages and operating systems are not good.
slt2021 3y ago
software is like prose. Writing software - is an act of self-expression like it is for an artist or writer. Everybody wants to write his/her masterpiece in his/her own way, and not always agree with the way others do it. same with scientific community - two scientists cant agree on two ways to conduct scientific experiment, because they want to express themselves in this act
- Solvency 3y ago
  Actually, some people want to write his/her own masterpiece in their own way. Others just want to write literally anything to get the job done and be on with it. Others resent the fact they're being forced to write it in the first place. There are likely many other archetypes I'm ignoring too. But even reconciling these 3 together is what leads to everything regressing to the mean amount of suckiness.
  - slt2021 3y ago
    > Others just want to write literally anything to get the job done and be on with it. this is not compatible in team-based software development. Once you want to collaborate with others, the #1 priority becomes not "anything that gets job done", but "anything that team can read, maintain, support, and continue developing" if you are solo dev or writing bash scripts for your own workflow - then of course you can use anything literally, as long as it is on your computer and nobody sees it
lmm 3y ago
We rarely replace the foundations, we just paper over them. I don't think this actually matters, except when it breaks? I'm all for building a clean, simple system, but for me Unix would actually be the main part I would rip out (my preferred architecture would look something like unikernels on the server and a qubes-style cluster-of-communicating-unikernels on the desktop). If you're against adding complexity and memorizing trivia, Unix and C create more of those than the rest of the stack put together.
- Kamq 3y ago
  > qubes-style cluster-of-communicating-unikernels on the desktop Oh hey, yeah. A bunch of small utilities that communicate and interoperate. I can see it working out. You could even have them communicate with each other via some sort of universal interface.
  - bb88 3y ago
    So Java -> C is terrible but workable. C -> Java is terrible. Java <-> C++ is worse. C++ -> C is great. C -> C++ is terrible.
  - lmm 3y ago
    > Oh hey, yeah. A bunch of small utilities that communicate and interoperate. I can see it working out. You could even have them communicate with each other via some sort of universal interface. The key is to have that interface be narrow and well defined - something like gRPC. Allowing them to communicate via a huge, poorly specified, non-concurrency-safe swathe of shared state (filesystems with all their ad-hoc semantics, shared memory, signals, pipes, KAME sockets, namespaces, goodness knows what else two processes on a Unix system can do to fuck with each other) is a recipe for disaster.
    - Kamq 3y ago
      > The key is to have that interface be narrow and well defined - something like gRPC. You really can't use a mesh of unikernels for this then. You need an external system to enforce the types (like a compiler does for a single program). At runtime, so far as the computer cares, there's really just arrays of bytes (or machine words depending on if your system is really byte-addressable or just faking it). You can do input validation, but unix cli utilities can already do that. You'd need, rather than a bunch of unikernel utilities, an all encompassing environment that the utilities can register their constraints with, and the system would prevent them from being called if the constraints were not met. Main contender is probably emacs, just because it's already ahead on the "all encompassing environment" part of this.
StillBored 3y ago
The other times this appeared on HN are informative. But to be the devils advocate here, the unix abstraction is only beautiful if your living in a single process, single user, teletype environment. Add multiple users, network programming, multiple processes/threads, async IO, etc, etc, etc. and the whole thing starts to look like the layered monstrosity full of edge states, and broken promises the author is arguing against. Although frankly, there aren't many better choices. NT being nearly 3 decades newer and with the forethought of VMS is actually much better at a systems programming level but you have to be willing to dedicate significantly more effort upfront to understand the more complex task/io/user/permissions model. In the end there is probably less of a learning curve on windows, but its steeper because you end up having to learn how to do all this stuff on the various *nix clones as well, just using bolt on interfaces that frequently vary slightly between the different flavors. In a way this applies to much of the windows ecosystem now that vb6/delphi aren't popular and the similar attempts at web co-design utilities have largely died.
userbinator 3y ago
I suspect at least part of it is due to the dogmatic worshipping of abstraction and the period in the late 80s-early 2000s where performance was still growing exponentially. Then there's the common notion that "more is better" when it comes to complexity, and along with that the idea that "growth" is somehow a good thing. The vast majority of software simply does not need constant growth nor change. Look at the demoscene for an example of the exact opposite culture.
- rramadass 3y ago
  Amen! With the rise of the Web/Mobile computing things have gotten exponentially worse. And i don't even want to think about where we are headed with AI/ML.
- deleted 3y ago
  [deleted]
evelynsalt 3y ago
https://suckless.org/ https://suckless.org/ https://nixos.org/ https://nixos.org/ You only have to configure this once. Don't install too many things. Just what you need. This level of complexity is needed because this is not TempleOS in which all software is made by one person. Most software exists to bridge the Tower of Babel lost in translation scenario.
- madwebness 3y ago
  Suckless.org is merely a subjective catalog. Not a bad one, but for a tiling Window Manager, which I have to recompile every time I want to change its settings and need to somewhat know C for that - because what if I don't - that hardly sucks less. NixOS is also a subjective take on packaging, heavily luring people into a functional programming world, where one set of problems is merely replaced by another set of problems. I tried NixOS, so no, thank you. There are better ways to isolate packages and have multiple versions of libraries. The simplest of which that come to mind are things like Flatpak and containers. There's almost 0 usecase for NixOS - it merely replaces one set of problems with another. And forces you to learn something, that does not justify the time it'd take to learn it. I feel like people who built it just wanted to be smart, not create things that are seemingly simple and beautiful (which is what true artists strive for, I think). I learned Vim in two weeks. I gave NixOS the same time and it was almost a waste of it. Not a complete waste, however, because, I recall, I discovered an extremely useful, but unrelated thing (zfs), but I don't remember how come it worked out this way.
xwdv 3y ago
I can’t help but wonder if right now, we are unwittingly building software in such a way, that in 100 years from now, our decisions will result in some kind of crisis, that the generations to come will wonder why we didn’t take more care with what we were doing.
jupp0r 3y ago
Operating systems are great abstractions. If the author ever wanted to build an actual application on top of kernel APIs they would appreciate things like boost or libc more. While not always perfect, the alternative of implementing purpose built abstractions is not worth it for 99% of projects long term. The author should look into golang which amazingly gives you one fully static binary (without dynamic linking glibc) and builds directly on top of kernel APIs. They will find reasons to rant about go itself though, I'm sure.
monero-xmr 3y ago
One of the constant lessons I preach to my engineers is to make everything as simple as possible. You can always complicate it later if absolutely needed. Once you make 20 simple things and start to mix them together, you are already in a combinatorial explosion beyond man’s comprehension. The good old devs know this instinctively. The young ones haven’t learned the hard way. The old ones who never learned the lesson must be avoided at all costs.
- nunez 3y ago
  Simple is in the eye of the beholder IMO
  - sureglymop 3y ago
    That's true. I think that in reality, the complex has to "live" somewhere.. It is inherently present in the world. If the engineer simplifies their solution by relying on a dependency that abstracts away all of the complexity that doesn't mean the complexity is just gone. Should the engineer ever have to deal with that complexity, should that dependency break, they might be screwed. On the other hand, if they over engineered a more complex solution themselves, the engineer would at least know how to deal with it and fix it if it breaks. I would say usually the issue is lack of time to generate quality work (even if complex) and lack of time to adequately document it, mainly due to the "agile engineering" trend. It amounts to this: if there exists complexity, there must exist responsibility for that complexity (in my example in the form of the one engineer who created the complex component).
- jxramos 3y ago
  I also like language constructs which have constrained definitions, eg in python list and other comprehensions vs for loops. The comprehensions are very limited in their side effect outcomes and intent, the for loops are much more open ended. Don't use a more open ended construct when a more narrow one can be used. This is sort of analogous to the using narrowest scope possible rule of thumb, use the narrowest conceptual space when authoring software.
maerF0x0 3y ago
Ultimately I think a lot of the human condition boils down to being stuck in a local maxima and deciding if you want to go through the valley for the potential of higher heights.
deleted 3y ago
[deleted]
evelynsalt 3y ago
Anything I can understand is simple. Anything I cannot understand is complicated. Therefore the whole world should revolve around me.
BoppreH 3y ago
I feel like this got better for developers, and much worse for end users. Containers and Infrastructure as Code brought quite some sanity for myself, and even the beast that is Kubernetes is optional and has alternatives. Clouds are complicated but mostly work, and are certainly more reliable than most in-house solutions. Language safety is now a big talking point. But the end users got screwed. We forgot about consent, from "yes/maybe later" options, to obligatory apps, and shrinking features. Then offline applications became unfashionable, and now every action takes two seconds. The final nail is suicidal monetization, like seemingly every game publisher, Google Maps, Twitter, and recently Reddit. I found https://handmade.network/ https://handmade.network/ a breath of fresh air, but so far it's been too little, too late. Here's to the next 12 years.
carabiner 3y ago
I'm the same, except replace software with people/entities/objects.
madwebness 3y ago
Since the author mentioned webpages/webapps, to that I'd like to add that the insanity of both backend, but especially frontend frameworks has gotten out of hand. Forget it that I literally hate React more than I hate any other framework I came across, but even if I did like it - not only React, but even JavaScript is entirely unnecessary on 95% of pages, on any given website. SPAs have a place with things like maps or Crypto Exchanges, fine. Are you building one of them? No? Break down your site into pages with normal URLs, learn yourself some CSS (without css frameworks! I'd only argue SCSS is better because of nesting) and learn about HTML tags, which are plenty and can do awesome things out of the box. Some pages may require a bit of Javascript. Maybe a bit more. But don't be buying into this bullshit of React or other frameworks. If it need be so, maybe write your own? For your purposes? And for the love of god, don't be sharing it. Who cares. Be an artist for the user. Make your code work 10 years from now without making any changes to it, even. In any code, in any language. Can you do it? Today I had to use Node.js and grunt (first time I hear about it) which installed npm packages and "compiled" it all into the Chromium extension I needed. The extension's actually good, but it itself uses Angular and ton of other packages, 50 or 70 maybe. What in the actual...? On the backend side... Why do you need a framework? Learn yourself some CGI, write small programs. Sure, use libraries, but also maybe try a compiled language, so it runs faster, isn't as simple to hack if someone breaks in. Besides, Cloudflare and the likes of them (also hated by me and many) protects from most attacks anyway (and that would be one single positive aspect of the existence of these captcha racket-companies). So you won't need to learn much at first. You don't want spam? Maybe ask your users to pay first. Then it's much harder to perform a DDoS if most of your website is behind a paywall. Nothing is free. Everyone complained about how Bitcoin mining is bad for the environment etc... yea yeah. Next time don't use React and Ruby On Rails for your Blog with two and a half articles in it. P.S. My sincere recommendation for anyone: find and listen to Jonathan Blow's interviews and talks (not the twitch streams - they're too long and boring). This man understands many important things, not the least of which is that game devs, somehow, manage to waste less resources while people are playing their pretty demanding games, less than certain websites do. Or that Twitter's engineers being let go is because you don't need that many engineers to build a micro-blogging platform that hasn't even changed all that much over the years. It appears to me there's a lot of scamming going on in the startup/VC industry. You get a $2mil check and hire expensive devs - also pay yourself nicely, of course - to build something I can probably build in 3 months for $15k and it'd be better. I had founded and financed a company myself. And even when we finally got external funding (not much) we never paid ourselves as founders, not the once. VCs in the US don't care (not their money and the inflation forces them to just stuff it into whatever comes their way) and founders are happy to be sort of "working for themselves". No wonder the success rate is low.
kovac 3y ago
> The only thing that matters in software is the experience of the user. Isn't the user experience subjective though? For example, to solve the problem of sending an email, all one needs is a set of commands on a terminal. I love this approach, but would this qualify as solving the problem in a way that meets the user experience criterion? I agree with the thesis of the post, though.
- bb88 3y ago
  Yes! A lot of things could be strung together though a shell and was "good enough". No need to fire up the compiler if all one needed was a shell script with the common set of utilities. (grep/cut/head/tail/paste/wc etc.)
bitwize 3y ago
> The only thing that matters in software is the experience of the user. The problem is, for most users, to have a decent experience you need... COMPLEXITY. See, there are roughly two groups of people when it comes to computers: * Real Human Beings. Your mom. Your sister. The CEO of the company you work for. People who have real needs that computers might help with, but don't want to futz with them to get them working. * Lizard People. People who love programming and don't mind futzing with a computer or its software. It's an open secret that they're not really human because it's all over the marketing. When Ubuntu called itself "Linux for humans" they were a) trying to assure their customer base that theirs was not a scary product intended for Lizard People; b) lying. Unix is a Lizard Person OS. Apple, who had already invented and perfected[0] the Real Human OS, did more or less the same to Unix by adding layers of complexity, but even then some of the ancient Lizard Person tech shows through. If you like building pipelines to process data, you are a Lizard Person. If you are concerned about how much resources a program is taking, you are a Lizard Person. If you hate that all this memory and CPU time is being WASTED to do something you could do with a couple of Unix commands, you are a Lizard Person. Real Humans may notice when their computer is slow; if it's a persistent problem they throw it away and go down to Best Buy to buy a new one. Do you see what I'm getting at? Most users are not computer literate, don't value becoming so, and get scared when they see the ancient underpinnings of Lizard Person technology. So in order for them to have a good experience, hiding the details, automating pain points like configuration, and putting a nice friendly face and good presentation on everything is an absolute MUST. That requires engineering complexity and layers of software working together. They are TABLE STAKES for a good experience. So while I find myself quoting Ryan Dahl an awful lot about the experience of users, I think 99% of the time I mean the exact opposite of what he means. [0] No, shut up. The Xerox Star sucked, and Smalltalk was a propaganda tool for indoctrination into the Lizard Person way of life. Inasmuch as computers are usable by Real Humans, the fact that they are so is an Apple invention entirely.
tayistay 3y ago
I liked a much of classic macOS and the software. Maybe it's just childhood nostalgia, and perhaps it's also because I never had to really develop for it. When you installed an app, it usually just went in a folder. Sometimes it was just one file. There wasn't a mass of dependencies and complex systems to manage them. Just some libraries built into the system. Modern macOS is a bit like that too, except it has all the unix under there too, so there's a mess of files all over the place. There are many files hidden from the user (which the user wouldn't understand anyway). Whereas classic macOS had a beautiful simplicity where you clicked on the system folder and there was Finder and other things which were at least somewhat understandable to me as a kid. I had Strata 3D, which I got with an educational discount. That was the software used to make Myst. Our Quadra 700 only had 8mb of RAM and I was trying to render a spaceship flying through mountains on a distant planet. I managed to replace the Finder with Strata (using RezEdit) and boot into Strata. The machine would crash if I clicked on the apple menu, but this got me a bit more RAM. Anyway, something like NixOS addresses the flaws of Unix package management, but it requires quite some complex machinery to do so. AFAIK, we didn't have the versionitis issues on classic macOS, but again, I was just a kid. It was a simpler time.
- cortesoft 3y ago
  Yeah, except those simple 'apps' that went into a folder had a resource fork that was hidden away from users, and could be accidentally lost if you copied it to a disk formatted for windows and suddenly your application wouldn't work anymore and you had no idea why.
  - tayistay 3y ago
    I didn't say it was perfect :)
  - itwillnotbeasy 3y ago
    This, and also when you delete an "application", all its remnants clutter up the disk space.
- ndiddy 3y ago
  Classic Mac OS had multitasking shoehorned into an operating system originally designed for single-tasking. This meant that if one program locked up, it would never give up the processor and your whole system would lock up. The only way to recover was to hard power off the computer. It also meant that you couldn't do things as basic as listening to MP3s while web browsing, because whenever you loaded a new webpage your browser would hog the CPU to render the page so your MP3 player would skip.
madwebness 3y ago
ALSO: how convenient that a submission with > 100 upvotes appeared at the very top and merely a few minutes later was not even on the frontpage (I have nothing to do with the original post, nor this submission of it). You know guys, you should really tone down your censorship, or this site too will finally perish from everyone's radar.
nunez 3y ago
...and that's BEFORE you throw systemd into the mix! I agree. Though to be fair software is doing more these days. Or at least it feels that way!
fargle 3y ago
I wholeheartedly agree, but will add the further complication: who is the user anyhow? Is it the downstream packager, or the importer of your library, or the end user of the distro that includes your thing, the unfortunate sysadmin who needs to glue it together, or his boss, or the "luser" trying to use the tool containing your thing, or his boss, or their shareholders? What if all these "users" do not agree on some point or other? It seems like a conundrum with a likely non-ideal outcome.
eternityforest 3y ago
The average user doesn't need to understand software. The average programmer doesn't either, unless they're developing it. That's kind of the point, software encapsulates a process so you don't have to do it. In 2011, we didn't have SSDs(Or at least I sure didn't) compilers were not as good, and people said "Premature optimization is the root of all evil" way too much. I'm willing to tolerate just about any amount of complexity if it's well factored, reliable, performance, and the abstractions aren't leaky. Even for very small tasks... Because chances are, if I'm bothering to use software for a small task, it's because it's something I do every day and it's fairly important. If it drags in 10 million lines of code from 1000 devs to make sure my notes app syncs reliably without manual intervention.... then that's fine. Almost all hardware still in use seems to be fast enough. We have built amazing things with software. The only thing I don't like is that the FOSS scence has a tendancy to be less innovative and more Kackzynki, and all the cool stuff is proprietary cloudware. That, and that things are getting harder and harder to develop. Not even because the languages or APIs are hard, those are amazing these days, it's that you have 50 layers of DevOps nightmare time with Docker to get a hello world running because everything is microservicy, and developers have a high amount of tolerance for manual setup, and programmers really think it's worth breaking a whole ecosystem just to rename a function. "Getting started with X" used to be a half a page, now it's 5 pages. I have a lot more complaints about hardware than software. Almost everything has a few missing things that would only cost a few dollars to add. Limiting charging to 80% to save battery, reporting status on Bluetooth, a tiny metal ring to protect the plastic bit that wears, a cheap molded case instead of sharp sheet metal that collects dents...
deleted 3y ago
[deleted]
JohnFen 3y ago
I don't hate all software. Just most of it, for many of the reasons this article states. At some point, our industry took a very wrong turn and we keep going down the mistaken road.
jxramos 3y ago
Seeing and reading this this morning finally made me want to go chase down an old contemporaneous reaction blog post to this Ryan Dahl rant that I used to enjoy referring to Too Much Stupid Software https://web.archive.org/web/20160906072516/http://www.lovettsoftware.com/LovettSoftware/post/2011/10/02/Too-Much-Stupid-Software.aspx https://web.archive.org/web/20160906072516/http://www.lovett...

154 points by Decabytes 3y ago

The thing is... I am the user.

bb88 3y ago

(2011) And not much has changed since then. Previous discussion: https://news.ycombinator.com/item?id=3055154 https://news.ycombinator.com/item?id=3055154

dang 3y ago
Thanks! Macroexpanded: I hate almost all software (2011) - https://news.ycombinator.com/item?id=28181632 https://news.ycombinator.com/item?id=28181632 - Aug 2021 (247 comments) I hate almost all software (2011) - https://news.ycombinator.com/item?id=15142316 https://news.ycombinator.com/item?id=15142316 - Aug 2017 (8 comments) I hate almost all software (2011) - https://news.ycombinator.com/item?id=13586596 https://news.ycombinator.com/item?id=13586596 - Feb 2017 (144 comments) I hate almost all software. (2011) - https://news.ycombinator.com/item?id=10553408 https://news.ycombinator.com/item?id=10553408 - Nov 2015 (2 comments) “I hate almost all software” — Ryan Dahl - https://news.ycombinator.com/item?id=3055154 https://news.ycombinator.com/item?id=3055154 - Sept 2011 (292 comments)

efields 3y ago

Absolutely one thousand million.

metadat 3y ago

Wow, this struck a nerve. https://www.linkedin.com/in/tinyclouds https://www.linkedin.com/in/tinyclouds Looks like he's still all in on Javascript with Deno? Interesting. I wonder what, if anything, has changed in his perspective.

deleted 3y ago

[deleted]

livinglist 3y ago

When I work on my own projects, I used to try to balance both worlds cuz I want these source code to be seen, but after some time observing GitHub insights on my repos I noticed barely any ppl even care to check out any sub directory like lib or src.. so I stopped caring about coding styles or formats, i do keep my repos zero warnings from linters though, for my own pleasure.

henning 3y ago

Then why build another incredibly slow dynamically typed monstrosity that breeds bugs and bad quality at industrial scale? Stop building JavaScript infrastructure.

nforgerit 3y ago
C'mon it wasn't that bad. npm was a fun experiment on what could possibly go wrong with putting leftpad into a single package. For me it's still by far the best runtime to do anything event-alike/http/json/web. It's quick to develop small things and quick to deploy (if you omit the whole transpilation shenanigans which of course help if you have dozens of engineers working together).
rektide 3y ago
He took one of the fastest & most successful & invested in existing JS engines & bolted on a pretty decent standard library. Great winning move, where a ton of the hard part of language optimization & growth is other people's problems, & Ryan could focus on making a great developer experience, which he and izs (npm author) did.
richardjam73 3y ago
They probably realised after that was done.

ChrisMarshallNY 3y ago

I remember a poster (but not the venue), who had a .sig that read “I hate code, and want as little as possible in my software.”

justin_oaks 3y ago

C'mon. I can't be the only one who is amazed at the things we've managed to build on top of a unnecessary complicated foundation. It's quite amazing that we've put layer after layer of leaky abstractions on top of each other and managed to make systems that mostly work. I don't hate all the software. I think it's awesome. It can be hell to develop, though.

hejcloud 3y ago
Reading your comment I can't help but think about that we're now starting to feed our layer lasagne that "mostly works" with code generated by a stochastic parrot which also only "mostly works" and turn the resulting products into some kind of fabric of the society. Ten years from now must be a fun time.
- malikNF 3y ago
  "When I started, all I had was swamp! Other kings said I was daft to build a castle on a swamp, but I built it all the same, just to show 'em! It sank into the swamp, so I built a second one. That sank into the swamp. I built a third one. It burned down, fell over, and then it sank into the swamp. But the fourth one stayed up! And that's what you're going to get, lad--the strongest castle on these islands!"
  - RangerScience 3y ago
    Yep yep. Great way to solve a leak is shove enough stuff into it; it’ll stop leaking after enough!
    - MonaroVXR 3y ago
      Laughed way to hard about this.
    - bitwize 3y ago
      You laugh, but... AI only got real traction when we stopped teaching computers clever efficient ways to solve logic puzzles and started throwing massive amounts of data, memory, and compute at the problem.

mberning 3y ago

It would be nice if all software were simple, elegant, and minimal. But I don’t know why we should expect it to be. The hardware that runs the software is complicated on a whole other level. You want and simple, elegant and minimal cpu? Video card? Sound card? You better be ready to give up a LOT to get that. And giving up the current experience is something end users really don’t want to do.

rektide 3y ago
Simple elegant & minimal is subjective IMO. What absolutely shatters us is that we almost never have enduring & exposed bases. Software is endless layers of abstraction reaching upwards. Very few layers expose themselves at all. So we are all strangers to most software. For software to be simple elegant & minimal, we would have to be able to deploy existing knowledge, be able to leverage the fundamentals we know. But that's not where we are, but we are all adrift: > In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with.
bb88 3y ago
Back in the 1990's there were maybe 5 languages commonly used (C/C++/Assembler/Turbo Pascal/Visual Basic). Now there's 40. Each one needs it's own networking library. 8 different kinds of databases - with each language needing it's own adapter. 5 different web frameworks for each one. 3 different json libaries. It's a classic cartesian product. And instead of "I'll help fill in the gaps", its "I'll solve the problem by writing a new language!" -- which just makes the cartesian product bigger.
- stefncb 3y ago
  And that's fine. Choice is good. IMO the problem isn't that there are a lot of things to choose from, it's that there are a lot of things on top of each other. Stuff on top of stuff on top of stuff. I personally wouldn't want to live in a world in which I could only use "one of these 5 languages", whatever those are. But I would love to live in a world where things weren't so deep in abstraction and complexity. These are two very different problems.

oofta-boofta 3y ago

All software, frameworks, etc is a reflection of the creature that created it: a Human, with all our faults, affectations, and prejudices. A lucky few have a come to Jesus moment and realize that nothing is perfect and that fighting the tide by swimming upstream is a fool's errand, they swim sideways to the shore.

doitLP 3y ago
I disagree, humans can create amazingly beautiful and simple things. All software reflects the environment in which it exists, including the time pressures involved in its creation and the complex, messy reality it is trying to model. We’re all familiar with a “90% MVP” that is small and elegant and solves the main use case sort of ok. Beyond that, reality has a lot of detail and edge cases and that’s when software gets nasty.
- roeles 3y ago
  Then open source should be amazingly beautiful and simple?
ssss11 3y ago
But “upstream” is created by us, humans. All it takes is enough of us to change the direction of the current.

deleted 3y ago

[deleted]

gavinhoward 3y ago

Heh. I do too. In fact, I'm writing my own framework that replaces most of libc. It builds a better foundation, and I'm better off for it.

Conscat 3y ago
That's awesome! I'm working on something that sounds similar. https://github.com/cons-cat/libcat https://github.com/cons-cat/libcat I'd love to see your work if you're willing to share it here!
- gavinhoward 3y ago
  Once I have an actual working piece of software, I will announce it on HN. This framework is not meant to be shared really; it's more building my own software stack from scratch, kind of like [1]. [1]: https://www.youtube.com/watch?v=443UNeGrFoM https://www.youtube.com/watch?v=443UNeGrFoM

TOGoS 3y ago

> The only thing that matters in software is the experience of the user. I mean, sometimes software development is enjoyable as an end in itself, otherwise Shenzhen I/O wouldn't be a thing. That said, it's a lot more enjoyable when the blocks you're building with are nice self-contained things that work well together like LEGO bricks. As opposed to a bunch of double-clawed hammers that are all invisibly connected with strings under the floor so that when you try to pick one up your drill automagically turns on as it falls off the shelf (I am borrowing some PHP-fractal-of-bad-design metaphor but it applies just as well to Spring Boot or whatever-the-f&^& somebody with too much time on their hands thinks is fun to inflict on me). Abstractions are great so long as they don't leak. But software development seems to have become the art of not going insane while trying to maintain castles in the sky that are oozing spaghetti sauce from every crack. So anyway, I agree with the author, but maybe for slightly different reasons.

taeric 3y ago

I urge the author to never look into building a physical building. The codes and amount of work you have to do to legally start are already complicated. But then you start buying screws and realize the entire screw isle at building supply store is bigger than many small grocers. And probably isn't complete. Heaven help you if you want to do something aesthetically pleasing like a pocket door. Or, far worse, heaven help you if you want to fix a pocket door. Finding a compatible wheel mechanism is usually most easily done with, "rip it out and use a new mechanism." Then there is car maintenance. Check engine light says something about the eco subsystem isn't working right? Here is a book mechanics use that list the common reasons for the code. Not standard across makes. Or models, even... I could probably go on. Point is nothing is greenfield lacking in complexity. I agree we probably could do better with software. But having done embedded work, I think it is easy to be ignorant of exactly how much has to coordinate in a computer system.

gsatic 3y ago
We can't do better with software Individually. But we can with groups. And most software ppl are quite useless at group formation and maintenance, hence the perpetual drama and tantrums.
debacle 3y ago
Cars are a fun one "Your emissions system is failing. It's probably because there's rust on the inside of your gas cap." That kind of troubleshooting is about as software as it gets.
- el_benhameen 3y ago
  Hey, I just fixed that one. Turned out to be a mystery evap hose under the rear seat with no visible signs of wear or failure. Was it what any of the mechanics I talked to thought it was? Nope! Did anyone carry the part, or was anyone even able to identify the correct part number, even with a diagram? Nope! Did I have to hunt all over for some marine fuel line that happened to have the same inside diameter so that I could jury-rig a new part? Yep! Diagnosis and repair actually felt a bit like working with third party libraries: all the documentation is wrong, the problem is never your first guess, and you end up rolling your own solution in the end.

jabbany 3y ago

> The only thing that matters in software is the experience of the user. I have one disagreement with this... There is another thing that matters in software --- the experience of the developer making it. IMHO, I agree that libraries, languages, tooling,... etc. are not art whose complexity should be admired. But they are a necessary intermediate tool for _developers_ to make their work easier. We can apply the same logic to something like construction. You can build a house with hand tools and man power, just like you can write code in machine language. It's not enjoyable but you can do it. The work around developer tooling is like a builder working with scaffolding, an excavator, a crane, an electric drill... You spend effort to set it up, and before the final product is delivered, you have to tear it down. But it was still worth it because it serviced the developer in some transient way.

cheeselip420 3y ago
It only matters as far as the cost to the user (including any externalities due to poor construction). The software serves the user. Period.
- BobbyJo 3y ago
  The software serves the business' bottom line period. The user only matters in so far as the keep coming back and paying money (or attention, which is also money). Developer experience only matters in so far as it keeps costs low, creating better margins. If that sounds kind of gross to hear, it's because it is. Businesses are made up of people. Customers are people. Every interaction on both sides of the equation should take that into account. If you ruthlessly maximize like the human part doesn't exist, your optimization strategy will fail.
  - Tehdasi 3y ago
    "The software serves the business' bottom line period." Making big assumptions about what the software project here. Given the article was mostly complaining about software developed for developers by developers, I don't think we can blame the suits for this one.

adamnemecek 3y ago

Let's be real the languages and operating systems are not good.

slt2021 3y ago

software is like prose. Writing software - is an act of self-expression like it is for an artist or writer. Everybody wants to write his/her masterpiece in his/her own way, and not always agree with the way others do it. same with scientific community - two scientists cant agree on two ways to conduct scientific experiment, because they want to express themselves in this act

Solvency 3y ago
Actually, some people want to write his/her own masterpiece in their own way. Others just want to write literally anything to get the job done and be on with it. Others resent the fact they're being forced to write it in the first place. There are likely many other archetypes I'm ignoring too. But even reconciling these 3 together is what leads to everything regressing to the mean amount of suckiness.
- slt2021 3y ago
  > Others just want to write literally anything to get the job done and be on with it. this is not compatible in team-based software development. Once you want to collaborate with others, the #1 priority becomes not "anything that gets job done", but "anything that team can read, maintain, support, and continue developing" if you are solo dev or writing bash scripts for your own workflow - then of course you can use anything literally, as long as it is on your computer and nobody sees it

lmm 3y ago

We rarely replace the foundations, we just paper over them. I don't think this actually matters, except when it breaks? I'm all for building a clean, simple system, but for me Unix would actually be the main part I would rip out (my preferred architecture would look something like unikernels on the server and a qubes-style cluster-of-communicating-unikernels on the desktop). If you're against adding complexity and memorizing trivia, Unix and C create more of those than the rest of the stack put together.

Kamq 3y ago
> qubes-style cluster-of-communicating-unikernels on the desktop Oh hey, yeah. A bunch of small utilities that communicate and interoperate. I can see it working out. You could even have them communicate with each other via some sort of universal interface.
- bb88 3y ago
  So Java -> C is terrible but workable. C -> Java is terrible. Java <-> C++ is worse. C++ -> C is great. C -> C++ is terrible.
- lmm 3y ago
  > Oh hey, yeah. A bunch of small utilities that communicate and interoperate. I can see it working out. You could even have them communicate with each other via some sort of universal interface. The key is to have that interface be narrow and well defined - something like gRPC. Allowing them to communicate via a huge, poorly specified, non-concurrency-safe swathe of shared state (filesystems with all their ad-hoc semantics, shared memory, signals, pipes, KAME sockets, namespaces, goodness knows what else two processes on a Unix system can do to fuck with each other) is a recipe for disaster.
  - Kamq 3y ago
    > The key is to have that interface be narrow and well defined - something like gRPC. You really can't use a mesh of unikernels for this then. You need an external system to enforce the types (like a compiler does for a single program). At runtime, so far as the computer cares, there's really just arrays of bytes (or machine words depending on if your system is really byte-addressable or just faking it). You can do input validation, but unix cli utilities can already do that. You'd need, rather than a bunch of unikernel utilities, an all encompassing environment that the utilities can register their constraints with, and the system would prevent them from being called if the constraints were not met. Main contender is probably emacs, just because it's already ahead on the "all encompassing environment" part of this.

StillBored 3y ago

The other times this appeared on HN are informative. But to be the devils advocate here, the unix abstraction is only beautiful if your living in a single process, single user, teletype environment. Add multiple users, network programming, multiple processes/threads, async IO, etc, etc, etc. and the whole thing starts to look like the layered monstrosity full of edge states, and broken promises the author is arguing against. Although frankly, there aren't many better choices. NT being nearly 3 decades newer and with the forethought of VMS is actually much better at a systems programming level but you have to be willing to dedicate significantly more effort upfront to understand the more complex task/io/user/permissions model. In the end there is probably less of a learning curve on windows, but its steeper because you end up having to learn how to do all this stuff on the various *nix clones as well, just using bolt on interfaces that frequently vary slightly between the different flavors. In a way this applies to much of the windows ecosystem now that vb6/delphi aren't popular and the similar attempts at web co-design utilities have largely died.

userbinator 3y ago

I suspect at least part of it is due to the dogmatic worshipping of abstraction and the period in the late 80s-early 2000s where performance was still growing exponentially. Then there's the common notion that "more is better" when it comes to complexity, and along with that the idea that "growth" is somehow a good thing. The vast majority of software simply does not need constant growth nor change. Look at the demoscene for an example of the exact opposite culture.

rramadass 3y ago
Amen! With the rise of the Web/Mobile computing things have gotten exponentially worse. And i don't even want to think about where we are headed with AI/ML.
deleted 3y ago
[deleted]

evelynsalt 3y ago

https://suckless.org/ https://suckless.org/ https://nixos.org/ https://nixos.org/ You only have to configure this once. Don't install too many things. Just what you need. This level of complexity is needed because this is not TempleOS in which all software is made by one person. Most software exists to bridge the Tower of Babel lost in translation scenario.

madwebness 3y ago
Suckless.org is merely a subjective catalog. Not a bad one, but for a tiling Window Manager, which I have to recompile every time I want to change its settings and need to somewhat know C for that - because what if I don't - that hardly sucks less. NixOS is also a subjective take on packaging, heavily luring people into a functional programming world, where one set of problems is merely replaced by another set of problems. I tried NixOS, so no, thank you. There are better ways to isolate packages and have multiple versions of libraries. The simplest of which that come to mind are things like Flatpak and containers. There's almost 0 usecase for NixOS - it merely replaces one set of problems with another. And forces you to learn something, that does not justify the time it'd take to learn it. I feel like people who built it just wanted to be smart, not create things that are seemingly simple and beautiful (which is what true artists strive for, I think). I learned Vim in two weeks. I gave NixOS the same time and it was almost a waste of it. Not a complete waste, however, because, I recall, I discovered an extremely useful, but unrelated thing (zfs), but I don't remember how come it worked out this way.

xwdv 3y ago

I can’t help but wonder if right now, we are unwittingly building software in such a way, that in 100 years from now, our decisions will result in some kind of crisis, that the generations to come will wonder why we didn’t take more care with what we were doing.

jupp0r 3y ago

Operating systems are great abstractions. If the author ever wanted to build an actual application on top of kernel APIs they would appreciate things like boost or libc more. While not always perfect, the alternative of implementing purpose built abstractions is not worth it for 99% of projects long term. The author should look into golang which amazingly gives you one fully static binary (without dynamic linking glibc) and builds directly on top of kernel APIs. They will find reasons to rant about go itself though, I'm sure.

monero-xmr 3y ago

One of the constant lessons I preach to my engineers is to make everything as simple as possible. You can always complicate it later if absolutely needed. Once you make 20 simple things and start to mix them together, you are already in a combinatorial explosion beyond man’s comprehension. The good old devs know this instinctively. The young ones haven’t learned the hard way. The old ones who never learned the lesson must be avoided at all costs.

nunez 3y ago
Simple is in the eye of the beholder IMO
- sureglymop 3y ago
  That's true. I think that in reality, the complex has to "live" somewhere.. It is inherently present in the world. If the engineer simplifies their solution by relying on a dependency that abstracts away all of the complexity that doesn't mean the complexity is just gone. Should the engineer ever have to deal with that complexity, should that dependency break, they might be screwed. On the other hand, if they over engineered a more complex solution themselves, the engineer would at least know how to deal with it and fix it if it breaks. I would say usually the issue is lack of time to generate quality work (even if complex) and lack of time to adequately document it, mainly due to the "agile engineering" trend. It amounts to this: if there exists complexity, there must exist responsibility for that complexity (in my example in the form of the one engineer who created the complex component).
jxramos 3y ago
I also like language constructs which have constrained definitions, eg in python list and other comprehensions vs for loops. The comprehensions are very limited in their side effect outcomes and intent, the for loops are much more open ended. Don't use a more open ended construct when a more narrow one can be used. This is sort of analogous to the using narrowest scope possible rule of thumb, use the narrowest conceptual space when authoring software.

maerF0x0 3y ago

Ultimately I think a lot of the human condition boils down to being stuck in a local maxima and deciding if you want to go through the valley for the potential of higher heights.

deleted 3y ago

[deleted]

evelynsalt 3y ago

Anything I can understand is simple. Anything I cannot understand is complicated. Therefore the whole world should revolve around me.

BoppreH 3y ago

I feel like this got better for developers, and much worse for end users. Containers and Infrastructure as Code brought quite some sanity for myself, and even the beast that is Kubernetes is optional and has alternatives. Clouds are complicated but mostly work, and are certainly more reliable than most in-house solutions. Language safety is now a big talking point. But the end users got screwed. We forgot about consent, from "yes/maybe later" options, to obligatory apps, and shrinking features. Then offline applications became unfashionable, and now every action takes two seconds. The final nail is suicidal monetization, like seemingly every game publisher, Google Maps, Twitter, and recently Reddit. I found https://handmade.network/ https://handmade.network/ a breath of fresh air, but so far it's been too little, too late. Here's to the next 12 years.

carabiner 3y ago

I'm the same, except replace software with people/entities/objects.

madwebness 3y ago

Since the author mentioned webpages/webapps, to that I'd like to add that the insanity of both backend, but especially frontend frameworks has gotten out of hand. Forget it that I literally hate React more than I hate any other framework I came across, but even if I did like it - not only React, but even JavaScript is entirely unnecessary on 95% of pages, on any given website. SPAs have a place with things like maps or Crypto Exchanges, fine. Are you building one of them? No? Break down your site into pages with normal URLs, learn yourself some CSS (without css frameworks! I'd only argue SCSS is better because of nesting) and learn about HTML tags, which are plenty and can do awesome things out of the box. Some pages may require a bit of Javascript. Maybe a bit more. But don't be buying into this bullshit of React or other frameworks. If it need be so, maybe write your own? For your purposes? And for the love of god, don't be sharing it. Who cares. Be an artist for the user. Make your code work 10 years from now without making any changes to it, even. In any code, in any language. Can you do it? Today I had to use Node.js and grunt (first time I hear about it) which installed npm packages and "compiled" it all into the Chromium extension I needed. The extension's actually good, but it itself uses Angular and ton of other packages, 50 or 70 maybe. What in the actual...? On the backend side... Why do you need a framework? Learn yourself some CGI, write small programs. Sure, use libraries, but also maybe try a compiled language, so it runs faster, isn't as simple to hack if someone breaks in. Besides, Cloudflare and the likes of them (also hated by me and many) protects from most attacks anyway (and that would be one single positive aspect of the existence of these captcha racket-companies). So you won't need to learn much at first. You don't want spam? Maybe ask your users to pay first. Then it's much harder to perform a DDoS if most of your website is behind a paywall. Nothing is free. Everyone complained about how Bitcoin mining is bad for the environment etc... yea yeah. Next time don't use React and Ruby On Rails for your Blog with two and a half articles in it. P.S. My sincere recommendation for anyone: find and listen to Jonathan Blow's interviews and talks (not the twitch streams - they're too long and boring). This man understands many important things, not the least of which is that game devs, somehow, manage to waste less resources while people are playing their pretty demanding games, less than certain websites do. Or that Twitter's engineers being let go is because you don't need that many engineers to build a micro-blogging platform that hasn't even changed all that much over the years. It appears to me there's a lot of scamming going on in the startup/VC industry. You get a $2mil check and hire expensive devs - also pay yourself nicely, of course - to build something I can probably build in 3 months for $15k and it'd be better. I had founded and financed a company myself. And even when we finally got external funding (not much) we never paid ourselves as founders, not the once. VCs in the US don't care (not their money and the inflation forces them to just stuff it into whatever comes their way) and founders are happy to be sort of "working for themselves". No wonder the success rate is low.

kovac 3y ago

> The only thing that matters in software is the experience of the user. Isn't the user experience subjective though? For example, to solve the problem of sending an email, all one needs is a set of commands on a terminal. I love this approach, but would this qualify as solving the problem in a way that meets the user experience criterion? I agree with the thesis of the post, though.

bb88 3y ago
Yes! A lot of things could be strung together though a shell and was "good enough". No need to fire up the compiler if all one needed was a shell script with the common set of utilities. (grep/cut/head/tail/paste/wc etc.)

bitwize 3y ago

> The only thing that matters in software is the experience of the user. The problem is, for most users, to have a decent experience you need... COMPLEXITY. See, there are roughly two groups of people when it comes to computers: * Real Human Beings. Your mom. Your sister. The CEO of the company you work for. People who have real needs that computers might help with, but don't want to futz with them to get them working. * Lizard People. People who love programming and don't mind futzing with a computer or its software. It's an open secret that they're not really human because it's all over the marketing. When Ubuntu called itself "Linux for humans" they were a) trying to assure their customer base that theirs was not a scary product intended for Lizard People; b) lying. Unix is a Lizard Person OS. Apple, who had already invented and perfected[0] the Real Human OS, did more or less the same to Unix by adding layers of complexity, but even then some of the ancient Lizard Person tech shows through. If you like building pipelines to process data, you are a Lizard Person. If you are concerned about how much resources a program is taking, you are a Lizard Person. If you hate that all this memory and CPU time is being WASTED to do something you could do with a couple of Unix commands, you are a Lizard Person. Real Humans may notice when their computer is slow; if it's a persistent problem they throw it away and go down to Best Buy to buy a new one. Do you see what I'm getting at? Most users are not computer literate, don't value becoming so, and get scared when they see the ancient underpinnings of Lizard Person technology. So in order for them to have a good experience, hiding the details, automating pain points like configuration, and putting a nice friendly face and good presentation on everything is an absolute MUST. That requires engineering complexity and layers of software working together. They are TABLE STAKES for a good experience. So while I find myself quoting Ryan Dahl an awful lot about the experience of users, I think 99% of the time I mean the exact opposite of what he means. [0] No, shut up. The Xerox Star sucked, and Smalltalk was a propaganda tool for indoctrination into the Lizard Person way of life. Inasmuch as computers are usable by Real Humans, the fact that they are so is an Apple invention entirely.

tayistay 3y ago

I liked a much of classic macOS and the software. Maybe it's just childhood nostalgia, and perhaps it's also because I never had to really develop for it. When you installed an app, it usually just went in a folder. Sometimes it was just one file. There wasn't a mass of dependencies and complex systems to manage them. Just some libraries built into the system. Modern macOS is a bit like that too, except it has all the unix under there too, so there's a mess of files all over the place. There are many files hidden from the user (which the user wouldn't understand anyway). Whereas classic macOS had a beautiful simplicity where you clicked on the system folder and there was Finder and other things which were at least somewhat understandable to me as a kid. I had Strata 3D, which I got with an educational discount. That was the software used to make Myst. Our Quadra 700 only had 8mb of RAM and I was trying to render a spaceship flying through mountains on a distant planet. I managed to replace the Finder with Strata (using RezEdit) and boot into Strata. The machine would crash if I clicked on the apple menu, but this got me a bit more RAM. Anyway, something like NixOS addresses the flaws of Unix package management, but it requires quite some complex machinery to do so. AFAIK, we didn't have the versionitis issues on classic macOS, but again, I was just a kid. It was a simpler time.

cortesoft 3y ago
Yeah, except those simple 'apps' that went into a folder had a resource fork that was hidden away from users, and could be accidentally lost if you copied it to a disk formatted for windows and suddenly your application wouldn't work anymore and you had no idea why.
- tayistay 3y ago
  I didn't say it was perfect :)
- itwillnotbeasy 3y ago
  This, and also when you delete an "application", all its remnants clutter up the disk space.
ndiddy 3y ago
Classic Mac OS had multitasking shoehorned into an operating system originally designed for single-tasking. This meant that if one program locked up, it would never give up the processor and your whole system would lock up. The only way to recover was to hard power off the computer. It also meant that you couldn't do things as basic as listening to MP3s while web browsing, because whenever you loaded a new webpage your browser would hog the CPU to render the page so your MP3 player would skip.

madwebness 3y ago

ALSO: how convenient that a submission with > 100 upvotes appeared at the very top and merely a few minutes later was not even on the frontpage (I have nothing to do with the original post, nor this submission of it). You know guys, you should really tone down your censorship, or this site too will finally perish from everyone's radar.

nunez 3y ago

...and that's BEFORE you throw systemd into the mix! I agree. Though to be fair software is doing more these days. Or at least it feels that way!

fargle 3y ago

I wholeheartedly agree, but will add the further complication: who is the user anyhow? Is it the downstream packager, or the importer of your library, or the end user of the distro that includes your thing, the unfortunate sysadmin who needs to glue it together, or his boss, or the "luser" trying to use the tool containing your thing, or his boss, or their shareholders? What if all these "users" do not agree on some point or other? It seems like a conundrum with a likely non-ideal outcome.

eternityforest 3y ago

The average user doesn't need to understand software. The average programmer doesn't either, unless they're developing it. That's kind of the point, software encapsulates a process so you don't have to do it. In 2011, we didn't have SSDs(Or at least I sure didn't) compilers were not as good, and people said "Premature optimization is the root of all evil" way too much. I'm willing to tolerate just about any amount of complexity if it's well factored, reliable, performance, and the abstractions aren't leaky. Even for very small tasks... Because chances are, if I'm bothering to use software for a small task, it's because it's something I do every day and it's fairly important. If it drags in 10 million lines of code from 1000 devs to make sure my notes app syncs reliably without manual intervention.... then that's fine. Almost all hardware still in use seems to be fast enough. We have built amazing things with software. The only thing I don't like is that the FOSS scence has a tendancy to be less innovative and more Kackzynki, and all the cool stuff is proprietary cloudware. That, and that things are getting harder and harder to develop. Not even because the languages or APIs are hard, those are amazing these days, it's that you have 50 layers of DevOps nightmare time with Docker to get a hello world running because everything is microservicy, and developers have a high amount of tolerance for manual setup, and programmers really think it's worth breaking a whole ecosystem just to rename a function. "Getting started with X" used to be a half a page, now it's 5 pages. I have a lot more complaints about hardware than software. Almost everything has a few missing things that would only cost a few dollars to add. Limiting charging to 80% to save battery, reporting status on Bluetooth, a tiny metal ring to protect the plastic bit that wears, a cheap molded case instead of sharp sheet metal that collects dents...

deleted 3y ago

[deleted]

JohnFen 3y ago

I don't hate all software. Just most of it, for many of the reasons this article states. At some point, our industry took a very wrong turn and we keep going down the mistaken road.

jxramos 3y ago

Seeing and reading this this morning finally made me want to go chase down an old contemporaneous reaction blog post to this Ryan Dahl rant that I used to enjoy referring to Too Much Stupid Software https://web.archive.org/web/20160906072516/http://www.lovettsoftware.com/LovettSoftware/post/2011/10/02/Too-Much-Stupid-Software.aspx https://web.archive.org/web/20160906072516/http://www.lovett...