[noman-land]

As a practitioner I also inherently believe in well written software but as a lifelong learner, things change, and evolve. There is absolutely no reason why software today has to be written like software of yesterday.

There is no need to be so prescriptive about how software is made. In the end the best will win on the merits. The bad software will die under its own weight with no think pieces necessary.

On the other hand, code might be becoming more like clay than like LEGO bricks. The sculptor is not minding each granule.

We don't know yet if there's long term merit in this new way of crafting software and telling people not to try it both won't work, and honestly looks like old people yelling at clouds.

[smolder]

> There is absolutely no reason why software today has to be written like software of yesterday.

I get what you're saying, but the irony is that AI tools have sort of frozen the state of the art of software development in time. There is now less incentive to innovate on language design, code style, patterns, etc., when it goes outside the range of what an LLM has been trained on and will produce.

[ctoth]

> frozen the state of the art

Personally I am experimenting with a lot more data-driven, declarative, correct-by-construction work by default now.

AI handles the polyglot grunt work, which frees you to experiment above the language layer.

I have a dimensional analysis typing metacompiler that enforces physical unit coherence (length + time = compile error) across 25 languages. 23,000 lines of declarative test specs compile down to language-specific validation suites. The LLM shits out templates; it never touches the architecture.

We are still at very very early days.

Specs for my hobby physical types metacompiler tests:

https://gist.github.com/ctoth/c082981b2766e40ad7c8ad68261957...

[williamcotton]

I have been writing my own DSL (and LSP) for making web apps and LLMs can do a pretty decent job of writing this new language.

https://github.com/williamcotton/webpipe/tree/webpipe-2.0

https://github.com/williamcotton/webpipe-lsp/tree/webpipe-2....

[noman-land]

Citation needed. I see no reason at all why that's true any more than the screwdriver freezing the state of home design in time.

[smolder]

LLMs aren't like a screwdriver at all, the analogy doesn't work. I think I was clear. LLMs aren't useful outside the domain of what they were trained on. They are copycats. To really innovate on software design means going outside what has been done before, which an LLM won't help you do.

[mccoyb]

No, you weren't clear, nor are you correct: you shared FUD about something it seems you have not tried, because testing your claims with a recent agentic system would dispel them.

I've had great success teaching Claude Code use DSLs I've created in my research. Trivially, it has never seen exactly these DSLs before -- yet it has correctly created complex programs using those DSLs, and indeed -- they work!

Have you had frontier agents work on programs in "esoteric" (unpopular) languages (pick: Zig, Haskell, Lisp, Elixir, etc)?

I don't see clarity, and I'm not sure if you've tried any of your claims for real.

[smolder]

This is desperate rebuttal from ignorance.

My point stands. You haven't innovated, you've just leaned on an LLM to work with your unoriginal DSL. I'm sure it's worth 100 megawatt-hours.

[mccoyb]

I see -- unoriginal, but it was accepted for publication at a leading programming languages venue?

Do some experiments, stop speaking out of your ass.

[tikhonj]

> In the end the best will win on the merits.

The last six decades of commercial programming don't exactly bear this out...

The real lesson is that writing software is such a useful, high-leverage activity that even absolutely awful software can be immensely valuable. But that doesn't tell us that better software is useless, it just tells us it is not absolutely necessary.

[stuffn]

Software engineers are desperate to have their work be like machining aircraft parts.

It’s a tool. No one cares about code quality because the person using your code isn’t affected by it. There are better and worse tools. No one cares whether a car is made with SnapOn tools or milled on HAAS machines. Only that it functions.

We know there is no long term merit to this idea just looking back at the last 40 years of coding.