This is the glaring fallacy! We are turning to unreliable stochastic agents to churn out boilerplate and do toil that should just be abstracted or automated away by fully deterministic, reliably correct programs. This is, prima facie, a degenerative and wasteful way to develop software.

My take: money. Years ago, when I was cutting my teeth in software, efficiency was a real concern. Not just efficiency for limited CPU, memory, and storage. But also how you could maximize the output of smaller head count of developers. There was a lot of debate over which methodologies, languages, etc, gave the biggest bang for buck.

And then… that just kind of dropped out of the discussion. Throw things at the wall as fast as possible and see what stuck, deal with the consequences later. And to be fair, there were studies showing that choice of language didn’t actually make as big of difference as found in the emotions behind the debates. And then the web… committee designed over years and years, with the neve the ability to start over. And lots of money meant that we needed lots of manager roles too. And managers elevate their status by having more people. And more people means more opportunity for specializations. It all becomes an unabated positive feedback loop.

I love that it’s meant my salary has steadily climbed over the years, but I’ve actually secretly thought it would be nice if there was bit of a collapse in the field, just so we could get back to solid basics again. But… not if I have to take a big pay cut. :)

We have been emphasizing on creating abstractions since forever. We now have several different hardware platforms, programming languages, OS's, a gazillion web frameworks, tons of databases, build tools, clustering frameworks and on and on and on. We havn't done so entirely collectively, but I don't think the amount of choice here reflects that we are stupid, but that rather that "one size doesn't fit all". Think about the endless debates and flame wars about the "best" of those abstractions. I'm sure that Skynet will end that discussion and come up with the one true and only abstraction needed ;)

I feel this some days, but honestly I’m not sure it’s the whole answer. Every piece of code has some purpose or expresses a decision point in a design, and when you “abstract” away those decisions, they don’t usually go away — often they’re just hidden in a library or base class, or become a matter of convention.

Python’s subprocess for example has a lot of args and that reflects the reality that creating processes is finicky and there a lot of subtly different ways to do it. Getting an llm to understand your use case and create a subprocess call for you is much more realistic than imagining some future version of subprocess where the options are just magically gone and it knows what to do or we’ve standardized on only one way to do it and one thing that happens with the pipes and one thing for the return code and all the rest of it.

I actually prefer the world with boilerplate connecting more important pieces of code together, over opinionated frameworks, because the boilerplate can evolve, charging the opinionated frameworks is much harder, and it's probably done by full rewrite. The thing is, the boilerplate needs to be kept to minimum, that's what I consider good API design. It allows you to do custom things, so you need some glue code, but not so much that you are writing a new framework each time you use it.

> Why hasn't there been a minimal-boilerplate language and framework and programming environment

Because everyone needs a boilerplate but it's a different boilerplate for everyone unless you're doing the most basic toy apps

> Why hasn't there been a minimal-boilerplate language and framework and programming environment?

Haskell mostly solves boilerplate in a typed way and Lisp mostly solves it in an untyped way (I know, I know, roughly speaking).

To put it bluntly, there's an intellectual difficulty barrier associated with understanding problems well enough to systematize away boilerplate and use these languages effectively.

The difficulty gap between writing a ton of boilerplate in Java and completely eliminating that boilerplate in Haskell is roughly analogous to the difficulty gap between bolting on the wheels at a car factory and programming a robot to bolt on the wheels for you. (The GHC compiler devs might be the robot manufacturers in this analogy.) The latter is obviously harder, and despite the labor savings, sometimes the economics of hiring a guy to sit there bolting on wheels still works out.

Because people think learning Haskell is too hard.

>Why haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

Lisp completely eliminates boilerplate and has been around for decades, but hardly anyone uses it because programs that use macros to eliminate boilerplate aren't easy to read.

It used to be. When I learned to program for windows, I will basically learn Delphi or Visual basic at the time. Maybe some database like paradox. But I was reading a website that lists the skills needed to write backend ant it was like 30 different things to learn.

> Why hasn't there been a minimal-boilerplate language and framework and programming environment?

There are? For example, rails has had boilerplate generation commands for a couple of decades.

> Why haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

i think it has. How much easier is it today than yester-decade to write, and deploy an application to multiple platforms (and have it look/run similarly)?

How little knowledge it requires now than before?

Theres a million different million environments. This includes, OS, languages, frameworks and setups within those frameworks. Spring, java or kotlin, rest or grpc, mysql or postgres or, okhhtp or ktor, etc etc.

There is no software you could possibly write that works for everything thatd be as good as "Give me an internal dashboard with these features"

> collectively emphasized the creation of new tools

In fact, collectively created 1000s of them and all of them a various flavor of mid.

I think this one way of looking at what your parent was describing.

They weren’t just saying ‘AI writes the boilerplate for me.’ They were saying: once you’ve written the same glue the 3rd, 4th, 5th time, you can start folding that pattern into your own custom dev tooling.

AI not as a boilerplate writer but as an assistant to build out personal scaffolding toolset quickly and organically. Or maybe you think that should be more systemized and less personal?

Because no one wants to develop and use Lisp macros.

Why haven't we collectively emphasized the creation of new tools to reduce boilerplate and grunt work?

You dont understand how things evolve.

There have been plenty of platforms that got rid of boilerplate - e.g. ruby on rails about 20 years ago

But once they become the mainstream, people can get a competitive edge by re-adding loads of complexity and boilerplate again. E.g. complex front end frameworks like react.

If you want your startup to look good you've got to use the latest trendy front end thingummy

Also to be fair, its not just fashion. Features that would have been advanced 20 years ago become taken for granted as time goes on, hence we are always working at the current limit of complexity (and thats why we're always overrun with bugs and always coming up with new platforms to solve all the problems and get rid of all thr boilerplate so that we can invent new boilerplate)

Because of the obsession with backwards compatibility and not breaking code. The web development industry is the prime example. HTML, Javascript, CSS, a backend frontend architecture - absolutely terrible stack.

Because the set of problems we make to be solvable with code is huge and the world is messy. Many of these things really are at a very high level of abstraction and the boiler plate feels boilerplatey but is actually slightly different in a way not automatable. Or it is but the configuration for that automation becomes the new bit you look at and see as grunt work.

Now we have a way we can get computers to do it!

You have to keep guard at each step to notice the inconsistencies and call your tutor's mistakes out though, or you'll inevitably learn some garbage. This is a use case that certainly "feels" like it's boosting your learning (it sure does to me), but I'd like to read an actual study on whether it really does before reaching any conclusions.

It seems to me that LLMs help the most at the initial step of getting into some rabbit hole - when you're getting familiar with the jargon, so you can start reading some proper resources without being confused too much. The sooner you manage to move there, the better.

ChatGPT even has a specific "Study mode" where it refrains from telling you the answer directly and kinda guides you to figure it out yourself.

It'll be interesting if tools like Claude will end up being used to highlight the people who have no clue what they are doing.

Everytime I have to mentor juniors, it’s more productive to get them to articulate the problem and their initial solution. It’s often sufficient to highlight (mostly for them) how little they actually know about the problem itself to actually rush to solve it.

But the moment I got the idea in my head, is the moment I got the code for it. The time spent is moslty checking the library semantics, or if there’s not some function already written for a specific bit. There’s also checking if you’re not violating some contract somewhere.

A lot of people have the try and see if it works approach. That can be insanely wasteful in any moderately complex system. The scientist way is to have a model that reduce the system to a few parameters. Then you’ll see that a lot of libraries are mostly surface works and slighlty modified version of the same thing.

In a startup, especially early, the only thing that isn't optional is shipping. You can fix any and all issues later, first you have to ensure there is a 'later'. (That's not to say you shouldn't do it at all, but definitely focus on the business before the tech.)

> Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail.

I lead the engineering team at my org and we hire almost exclusively for c++ engineers (we make games). Our build system by happenstance is written in c#, as are all the automation scripts. Out of our control to change. Should we require every engineer to be competent and write fluent c# or should we let them just get on with their value adds?

> If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself?

Reading code doesn't mean you can write it, as any programmer will tell you.

If I want to know if a string in ruby begins with another string, is the method starts_with or start_with or startwith like python or is it like perl where I have to use some completely different method? I don't know, better google it.

But if I'm reading and see `str.start_with?("https://")` I know instantly what it's doing.

That is what I observe at work: people who heavily use LLM in their coding don't read, review and test their code, pushing this work to teammates and testers.

Great skill multiplier, right?

are you advocating for not having code reviews...? Just straight force push to main?