[biddlesby]

I see this argument a lot: in the "good old days" there was Unix and apt and it was brilliant, now we have hundreds of toolsets and libraries that are flaky and need updating every year.

I think what these arguments miss is the upside of today. The "good old days" of brilliant developer experience was only brilliant for a small number of people. You had to learn right way of thinking, invest the right amount of time to learn good principles, how Linux was architectured, how not to re-invent the wheel, and so on.

This was a huge barrier to many people getting started with coding and the economics demanded getting more new developers ramped up faster. This pressure caused people to try to quickly develop little "get started quick" ecosystems.

Now we are in a situation where from a pure software engineering perspective we do have a complicated stack of teetering and shifting frameworks, I agree. But on the other hand this has come with enabling an awful lot more people to quickly get started toying with apps and coding.

What I'm trying to say is, these days its quicker to go from Level Zero to Level One, even if that means you've shot yourself in the foot going from Level One to Level Two.

[kingdomcome50]

I think you are misunderstanding the negative implications of “being easy to go from Zero to One”.

The problem with the above is that the easier it becomes to go from Zero to One, the more _replaceable_ One becomes. After all, you can learn it in no time!

Naturally this leads to more and more churn and every developer who is already _at_ One or above has to keep going back and re-learning it in order to “keep up with current trends”.

After a while it becomes tiresome to see yet another front-end state management library promising to fix all the problems caused by the previous iteration... Slowly you become jaded enough to find yourself subconsciously hoping these projects fail so you don’t have to waste your time learning their specific _dogma_ (because of course it can’t just be “entities”, “events”, and “handlers”. This new _snappier_ API uses “atoms”, “signals”, and “transducers”)

The reality is that most of the _real_ problems within a system (at least the interesting ones) are are at Two and above. So the constant churn at One just becomes an annoyance that takes focus away from the important bits.

I’d _gladly_ take some churn at the level of solving _my_ domain problems. Unfortunately, thus far, it seems I’m the only one writing anything that fits that bill...

[tekstar]

The good old days were terrible!

Uncompress tgz

./configure.sh

Missing dependencies

Find those tgzs

./configure.sh

Missing dependencies

Find those tgzs

One won't run on your system

Try to hack the dependency out

Give up, you didn't really need that anyways

[speedgoose]

The old joy of watching logs of a stupid GNU script checking basic features of the GNU C compiler. Just in case someone installed a compiler that had a different implementation.

[dTal]

And it checks them before checking for missing dependencies, so every time you fix a dependency, you have to do the whole rigamarole over again.

[m4r35n357]

Yeah hitting the up arrow a couple of times then return is a real pain.

[dTal]

I was referring to the tedious wait for the configure script. It might not seem so bad now, but what's a mild annoyance on modern computer with an SSD is quite the interruption on a few hundred MHz and spinning rust.

Another thing I wish it would do is give you all of the missing dependencies up front. Aain, not so bad now, but it was a major hassle for me when a missing dependency meant a long walk to the local library, 4gb flash drive in hand.

[Avamander]

Especially lovely now when one might want to use clang and some CFLAG you set breaks a bad check. It's also very annoying to correctly pass PIC and PIE flags when the makefile builds both libraries and executables. I loathe automake.

[lubesGordi]

Really not that bad. Almost always, configure make make install. And the main thing is the expectation. We always expect there to be dependencies and we expect to install them by hand and usually they were documented. Any errors would be easily understood (undefined reference or linker error). Now you have these systems that try to do things for you, you expect things to just work, when they don't your expectations are slighted and you get mad. The upside of all this tooling is the same joy you'd get in the 'bad/good old days.'

[lima]

Easy for a user, perhaps, but imagine maintaining it!

[RNCTX]

The FreeBSD or Debian port maintainer maintained it for you.

The seedy underbelly of all of this stuff is that most of the libraries and dependencies and pet projects that somehow became ubiquitous never worked outside of the lone developer's laptop, or the one compsci department's ancient from-scratch installation, etc.

And if you asked him why it didn't work he'd tell you to go fuck yourself.

[d0m]

I remember when I was a kid I tried for days to install gentoo and it just was not working. After so many hours of banging my head against the wall, I realized the CD was corrupted. Re-burning the iso fixed it

[rgoulter]

Yes, the increase in accessibility seems much nicer now than waves hand before GitHub and Arch Linux Wiki.

But I found the examples given in this blogpost striking: https://tonsky.me/blog/good-times-weak-men/ One of the most prominent tech companies (Apple) released a new music program to replace their older music program. The replacement program included several easy-to-notice UX bugs.

The bugs surely aren't from a lack of attention, expertise, or resources. And while obviously it's not easy to write a program like that, I think the best explanation would sound something like "towering pile of shit".

[joefourier]

I would disagree strenuously with the fact that it's easier to get started now than in the past, unless you're talking about the early 90s when the World Wide Web was still nascent.

10+ years ago, you could just install a server-side rendered web framework on a VPS or dedicated server you rented from a hosting site, and you'd experience a far smoother developing experience compared to today's Javascript churn. I'll take Django over React+Node.js+Docker+etc. any day.

And compare modern devops to ye olde webmaster ways. It's much easier to get started by writing a few bash scripts and customizing Nginx configs than to learn how to use Kubernetes, Docker, Terraform, etc.

[pas]

Nah, you can still do that.

Nowadays you can get cheap internet access, and you can buy a used okay-level laptop, get a free domain (like .tk, just a bit better from Google, the .dev), get a free VPS from AWS, and you can run whatever you want on it.

PHP has a built in web server, you can start developing with Laravel/Symfony easier than ever.

You find DigitalOcean tutorials for basic things easily, and you don't have to try to make stuff work on shady adware shared hosting portals.

The old webmaster days. Uh those were horrible. People tried to do blue-green deployments with Capistrano and PHP cache invalidation with atomic rename. And then folks spent years hacking RoR stuff to make it scale.

Yeah, Django is nice, but Python is a mess. Now with mypy finally there's some light at the end of the tunnel.

[leadingthenet]

So what’s stopping you from using Django?

[drewcoo]

If you see that argument, you're making it.

The author is not pining for the good old days. In fact, he specifically says that when he was starting out, the tooling was terrible.

[quantummkv]

> What I'm trying to say is, these days its quicker to go from Level Zero to Level One, even if that means you've shot yourself in the foot going from Level One to Level Two.

I see this a lot as well. And frankly it scares me. It should not be very easy or quicker to go from Zero to One at the expense of footgunning One to Two and beyond.

Practices and culture are easily learned when you are just starting. And those practices stay with you till the end. It is very difficult to unlearn something, especially when you learned it while starting out as it becomes a kind of second nature.

Those practices might not harm when you are making basic sites or demo apps in your spare time. But when an engineer with these practices goes to work on something like the software for controlling Teslas, it suddenly becomes a big problem.

In my view, it is better to take some time to make a solid foundation than to quickly make a leaning tower of software that could, in these days of software in everything, lead to catastrophe.

[ascar]

> Those practices might not harm when you are making basic sites or demo apps in your spare time. But when an engineer with these practices goes to work on something like the software for controlling Teslas, it suddenly becomes a big problem.

Well, the reality is that most businesses only need basic sites and you don't need trained engineers to build them. Basic developers can do it as well and giving them the tooling to do so helps.

There is a lot of value in making programming for "basic" stuff like a CRUD web/mobile app about learning to use tools rather than learning to understand the whole system (i.e. programmer vs engineer).

A comparison I really like: To build a house, you need one engineer for statics, but a lot of construction workers actually putting it together. And even that one engineer for the statics is more for safety than actually necessary, if you build some basic house with the basic default material. Because it's proven over and over again that it holds and the margin for errors is quite large before there is any risk of collapse.

[wolco]

Your time invested paid off for years. Now it is throwaway knowledge that won't be valuable in a month. The churn is increasing.

[pas]

The concepts are the relevant knowledge pieces. Those change/evolve slowly.

[StillBored]

See arguments against excel/vba...

Nothing has changed, today's web frameworks are pretty much worse on all fronts than the mess of excel, access, vb apps written by people without any formal training. At least many of those utilities worked for years after being created, unlike this mess which requires constant reworking just to continue working.

[eeZah7Ux]

> "good old days" there was Unix and apt and it was brilliant

Apt is still here.