The future of coding is LLMs coding, debugging, and refactoring in a loop. Our job will be mostly design, and intervening occasionally.

Sorta like how in the 90s UML & all the new modeling tools were going to replace the need for actual coding!

i’d rather be the detective of my own murder than another’s. i already struggle to figure out people’s thoughts from the strictures of whatever programming language they express it in. programming languages aren’t symbols of thought, neither do they enjoy the ubiquity of, for example, math notations, unfortunately.

New programmers who did not have chance to learn "properly" might not be able of "intervening".

That's probably what every generation of "older" programmers said - new programmers who did not do assembly will never be able to code etc.

> new programmers who did not do assembly will never be able to code etc

I see the results from programmers who never learned assembly.

Just like repairing and building cars from the ground up makes me a better driver. For example, the clutch in my car lasts a lot longer than it does for other drivers.

Then again, there is no clutch in an EV

I'm sure batteries and electric motors have their own quirks. For example, battery performance is dependent on temperature.

You are arguing against your point. Everything has its own quirks and no one has it easy or tough.

It doesn’t have it because it doesn’t need it, not because it somehow built abstraction around it. That’s not the case with modern computers, anything is built on top of everything.

1) false equivalence.

2) I am an old fart and had never said anything even remotely approaching "who did not do assembly will never be able to code". One can learn programming using any language. However some experience with the languages of multiple level definitely does not hurt.

In order to evaluate generated code you have to know how to program.

If you look at the mountains of crap that have been written in JS, for instance, those old programmers have been proven right.

Having no knowledge about assembly doesn’t stop me intervening with my JavaScript apps :)

Intervening can be done via LLM in some way I reckon

That’s not really a fair comparison here — A more fitting metaphor would be whether or not you could intervene on assembly code not knowing assembly.

Who said you need to know assembly.

>"Intervening can be done via LLM in some way I reckon"

This inspires much confidence

Thank you, you're the first person seeming to understand this in this whole darn section. Why does a human need a model of the program in their head when the LLM will be able to fire off 1500 test/debug/fix loops and wait for them to all resolve, then vote on the best answer?

For years we've been saying "computer time is cheaper than developer time."

Well, that's about to come back to bite us, in a big way.

Yes. Like it or not, the days of “typing code” is coming to an end. In fact, may be cheaper for companies to just nuke all existing software and start over

Test/debug/fix against what? Writing code is fundamentally not about tests or debugging, it's about formalising informal requirements into hard constraints. To do that, you need to understand business, human, and technical contexts. Without that understanding, you get over engineering, Google Cloud Console, and poor code lacking mechanical sympathy respectively. What's more, often those contexts have competing/incompatible requirements that you need to either evaluate using your idea of your team's values, or escalate, being aware of your own limitations.

None of those problems are amenable to modern LLMs. The moment you try to be formal enough to be unambiguous, you start writing code.

Speaking as someone who knows architects working with computers, architecture hasn’t achieved as much with computers as you think.

It goes beyond computing. The way that humans simplify systems is to treat components as black boxes, even though lots of internal details are actually coupled together. When you see a codebase that does this, you think "ewww separation of concerns".

But the real world violates this all the time. You want to buy a car. Some company you've never heard of in China makes the chips that detect whether or not your windshield wiper fluid reservoir has fluid. A shipment to the car manufacturer is ready to go out. But, there are no shipping containers. Until the windshield wiper sensor chips arrive, the car factory can't make any cars, and don't have room to unpack the shipping containers with unneeded parts that are piled up outside. So there is no container that can go back to China to bring the chips to the factory. While all that is worked out, SV venture capitalists print some money to give to a used car startup, making it super easy to get the best price on your used car. With no new cars available and flashy discounts to get the market kickstarted, the used car market shoots up, meaning that even though you want a new $60,000 electric car, all you can do is buy a used 1988 Yugo for $150,000. You walk to work, even though you have the money for the car you want.

If it's software, this is what we call a pageable event and the postmortem whines about "separation of concerns". But in the real world... well, we don't have those. We LOVE thinking we do, but when shit blows up, it's clear that we don't. So are we really surprised that software works the same way? It's how the Universe works, not bad architecture. The Universe has terrible architecture. Adjust some of those constants and try again!

architecture has a long history, of course. even if we start from since drafting became standard practice, recent advances like 3d modeling (due to computers) and analyses (satisfying/resolving building code constraints, structural forces, etc) are quantum leaps. in programming, perhaps the type systems (static) and debugger (post-production) gives a similar feeling but not quite. these two aside, the concerns of a c programmer today largely overlaps with those of dennis ritchie & brian kernighan.

We are still going to evaluate code in our heads. If anything, we need to enhance our capacity to do so. That is where AI can assist. A simple overview or graphical representation of a codebase will be a good start.

UML is dead! Long live UML!

Reminds me of other tools from the past that "allow development with out a developer". With fancy drag and drop UIs that look like circuit diagrams. In trying one you very quickly find out that you still need a developer. Because the easy happy path that the biz analyst thinks of is like 1-10% of what we do. 90% of our job is the plethora of edge cases and sad paths. The retrying. The when not to retry case within the retry case.

Does these language model bots help a little? Sure! But my worry of being replaced is currently sitting at like a 3% out of 100%. I expect to still have a job right up until we have AGIs, and quite probably for long after, as not everyone will be able to afford them. That is assuming we have any meaningful control over them.

I think this is more of a developer productivity tool than a replacement. Like an IDE.

Are there IDEs that can display compile-run-observe results in real time? A feature where you can set the inputs for a certain function and view the result of each statement in-line as you edit the function?

it's a normal way to develop in clojure. The primitive no-IDE support needed trick is to just define variables with the names of your function inputs, as in: https://blog.michielborkent.nl/inline-def-debugging.html

and then you can just evaluate expressions within the function. The fancy way with editor support is: https://github.com/vvvvalvalval/scope-capture-nrepl

you make snapshots of the local variables at any point, and later evaluate code in the context of that snapshot. So you do some action in your program that results in that function being called, it'll save the input, you select that snapshot, and now you evaluate in the context of those function arguments as you edit and eval expressions in the function. And while clojure supports interactive development at a level beyond other mainstream languages, Smalltalk and Common Lisp have support for it on another level, for example: https://malisper.me/category/debugging-common-lisp/

There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun. Why it went out of style I don't know

> There's some study where Smalltalk came out as the most productive language, I don't know whether it's more productive but that kind of interactive development where you build up your program evaluating it the whole time, without ever restarting, is a lot of fun.

I think it's this paper: https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirt...

Which seems to be a proprietary venture without any transparency into the kinds of task that were undertaken or the software development tools chosen. For example, what were the comparable tasks undertaken with "HTML" and "Machine language"?

Presumably the differences between "GW Basic", "Basic (interpreted)", "Quick Basic", "Visual Basic" ("Excel" Visual Basic for Applications?) follow from differences between the software development tools provided with the different language implementations.

So shouldn't we expect wildly different results between Java + plain text editor and Java + IntelliJ IDEA?

But there's only some kind-of generic place-holder "Java".

> you build up your program evaluating it the whole time, without ever restarting

Maybe that description is incomplete.

Maybe there's a stack of mundane activities that are needed for that style to be effective.

----

"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.

…

The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."

1984 Smalltalk-80 The Interactive Programming Environment page 46

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

----

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)

1984 "Smalltalk-80 The Interactive Programming Environment"

Light Table, which I presume to be defunct, comes to mind. (http://lighttable.com/#features)

But if you're willing to do without the "as you edit" requirement, then what you're left with is a plain old breakpoint debugger. Certainly, there are many IDEs that have those builtin.

If you use JavaScript or Typescript, check out Wallaby and Quokka.

My experience with this type of tool is it does help south some types of very repetitive code (wordy idioms, test code, etc.) or with using unfamiliar libraries. But yeah it's limited in other contexts.