I'm not old enough to have gone through the revolution that was programming languages that got increasingly more abstract and decoupled from the metal, but surely there's a lesson that can be learned from that era?

▲

SoftTalker an hour ago | parent | next [-]

Yes. As machhine power and memory increased, and as as programming abstractions advanced, software grew larger and more bloated, therefore what used to run on a single core in KB of RAM now takes multiple cores and GB of ram.

The developers who knew how to write efficient low-level code found that there were no jobs for that anynmore, so today the developers who can work at that level are very few.

The same will happen with AI being the new abstraction. In another decade or two, very few people will be able to write code by hand. We'll need a rack of compute in a data center and multiple KW of power to do what we used to do on a desktop PC drawing a couple of hundred Watts.

▲

jdprgm 39 minutes ago | parent [-]

The funny thing is it appears we may see a return to the software output from AI being efficient low level code. So while the compute to actually write the software rockets upwards the software itself might broadly become dramatically more efficient again.

	▲	SoftTalker 10 minutes ago \| parent [-]
		I suppose that is possible, but I have not seen it yet. When I ask an LLM to write code for me, "dramatically efficient" are not the adjectives that come to mind to describe the results. Usually "well, it works" is about as good as I can hope for, and I often don't even get that at least on the first iteration.

▲

thayne 5 hours ago | parent | prev | next [-]

Those abstractions are deterministic. LLMs are not.

▲

tintor 4 hours ago | parent | next [-]

Human’s aren’t deterministic either.

▲

recursive 4 hours ago | parent [-]

We don't keep snapshots of humans in source control.

	▲	latentsea an hour ago \| parent [-]
		One time this codebase I worked on had an ASCII art image of one of the devs in it buried in a comment at the bottom of some random file. YMMV.

▲

isidor3 4 hours ago | parent | prev | next [-]

Garbage collection and what the JIT decides to do often isn't.

▲

jplusequalt 3 hours ago | parent [-]

I think the more salient point is that going from writing assembler to C still required you to understand a lot about your machine, algorithms, how to debug issues, and in general it demanded problem solving skills.

LLMs eat away at all of these requirements.

	▲	lanstin an hour ago \| parent \| next [-]
		Making things work demands problem solving skills. LLM or not. Perhaps one returns from the thoughtful debugging walk around the block knowing what question to pose to the LLM rather than what function to add logging to, but whatever. Everything is flux, this too shall end.
	▲	isidor3 3 hours ago \| parent \| prev [-]
		Perhaps, but as far as I've seen they don't make the requirement go away. They do make many types of development far more accessible, as an extension of how SQL or Excel make development far more accessible. Sure, people make messes with the tools available, and sometimes the tools can handle it and still give you something useful, many times it takes someone actually knowing what they're doing to clean it up though.

▲

convolvatron 5 hours ago | parent | prev [-]

more importantly those abstractions were designed to try to make it easier to reason about what was going on for the author, build additional internal abstractions and to allow a reader to follow along and gain an understand of the structure. unless we believe that we can completely punt on having agency over the codebase, then llm code is only as valuable as it is readable.

▲

brainwad 4 hours ago | parent [-]

The dream is that we keep agency, but also give up on reading code, by doing away with code as our level of abstraction and instead having humans edit human-readable spec files (including, say, depicting UIs directly with visual mocks). Like "no code" platforms, but for everything.

▲

thayne 4 hours ago | parent | next [-]

If by "human readable" you mean written in natural language, then those spec files will have ambiguities and imprecisions. If you make the spec precise and unambiguous enough, then it essentially just becomes a program written in code.

▲

jplusequalt 3 hours ago | parent | prev [-]

>The dream is that we keep agency, but also give up on reading code, by doing away with code as our level of abstraction and instead having humans edit human-readable spec files (including, say, depicting UIs directly with visual mocks). Like "no code" platforms, but for everything.

Human language is famously terrible at being unambiguous.

	▲	brainwad 2 hours ago \| parent [-]
		That's ok if you and the AI are on the same page. And it is possible to write more rigorous natural language, e.g. laws are written in human languages, and yet judges and lawyers agree on how to interpret most of them and there's a defined arbitration process to resolve any new ambiguities.

▲

5 hours ago | parent | prev [-]

[deleted]