Live data from Hacker News

The Eternal Promise: A History of Attempts to Eliminate Programmers

ivanturkovic.com

191–200 of 246 posts

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#191

Earlier quoted context omitted.

Programming is probably the most democratized profession ever. The problem was never access barriers, but the fact that people are too lazy to study even a 200-300 pages on something as simple as ruby on rails.

I think there’s an actual barrier. I’ve seen it, especially since the (until recently) brisk market for programmers was sucking people out of traditional engineering. It’s puzzling because programming seems so easy and fun. And even before LLM’s, we had StackOverflow after all. But for some reason a lot of people just hit a wall when they try to learn programming, and we don’t know why. The “CS 101” course at college…

This is literally the same for all professions, only in CS/SE it is for some unknown fucking reason considered “a problem”. Why isn’t there “replace extremely expensive doctors/lawyers with AI” movement?

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#192
post #76

LLMs seem quite successful when considered something like a natural langiage interface, but expecting intelligence seems a step too far. For one they do not learn, at least not online, and that is a somewhat important requirement for truly intelligent behaviour. Arguably programming is as much learning as it is writing code. This is part of the reason some people copy an entire API and don't realise they're not so mu…

In some sense, programming is about figuring out which algorithms are a fitting metaphor for business problems. By programming, you are building a model of the business problem and a model of its solution. Most of the non-programmers who are in positions of authority (managers, CEOs, even some CTOs), do not understand that this is what programmers do. From their point of view, the authorities come up with a "strategy…

> and programmers turn those instructions into code that does something somewhere, usually after finding ways to avoid bad or unfeasible ideas, while still complying with the instructions.

Some do, but not all did that. With work-from-home I was staying at a friend of a friend that was a programmer and had a meeting. I was amazed about the level of simple things he was discussing, like "please add an error check, now you made a form where you can insert wrong data; make sure form is visible on a small screen, now it is not; etc.". And they talked ~2 hours about each, with the other person showing the guy exactly what it was not working. I do not know the history (maybe he was reconverting or something), but if this was what was he was doing usually, it was very inefficient and quite simple.

Most of my work was more similar to what you describe (fighting vague instructions and push back unfeasible ideas), but I wonder how much of "the industry" does this.

On the management I worked with all kinds, the employees have a small part of responsibility to look and select good organizations, otherwise power-hungry idiots arrive on top and start dictate and nothing crumbles because everybody just stays.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#193

Earlier quoted context omitted.

The actual work happens in the head. I suspect you know this. Now, there is a clear benefit to being able to flatten some of the issues related to coding, but do you really think, any of it can be done without those meetings and muddling through those requirements? At the very least, there needs to be one person that understands what is actually needed. I mean.. I am ok with you saying saying yes. In a sense, I half…

I spend an unusually small proportion of my life in meetings, probably an idiosyncratic feature of my job. My impression is that the main reason most people have so many meetings is because meetings are equated to work. If you are in a meeting, you are at work and you need to work. This is because, in a meeting, everyone is looking at everyone else with the expectation that they are working. But if you are not in a m…

I have seen people that cannot focus or are not confident enough about their ideas unless they are with someone. Yes, for me meetings are annoying, but for those people they reduces their anxiety (and tbh sometimes they do have bad ideas that are better shutdown).

On remote work, I do see an advantage of having people interact occasionally (I agree daily is probably too much) on work topics, besides the meeting. Spontaneous "can you have a look at" or "oh what is that program that you use". This will help much less the best performers (they know how to solve things, they look actively for new tools, etc.), but most companies have lots of profiles.

Someone in this thread was also complaining "management does not get engineering", which I feel is also made worse by working fully remotely - they will not get all topics in a meeting and if you have more informal talks, if they hear the discussions they might get (a bit) better.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#194

I'd say that the article left out Software Reuse - talked a lot more about in the late 90's early 00's than now. You could argue that coding with LLM's is a form of software reuse, that removes some of its disadvantages.

If you have been in the industry for a few decades you will be able to think of several hundred "silver bullets" that made great promises - some even turned out to be great ideas, but none where the 10x revolution that they promised. The article is a good summary of major movements through the decades without so much that whole point is lost in the details. I would have put in a slightly different set of things if I…

Maybe that's due to Amdahl's law applied to software. Everybody imagines that task X which is improved by 10x is 100% of the total work, so you will get 10x overall benefit, when in fact might be something like 20% of the work, so your overall benefit is only 1.21x .

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#195
One other thing that is often ignored: Most of the business class, executive class, ... even working class, DON'T want to write code.

The reasons vary, but in general, just as some people don't want to touch maths (even if they might be good at it if they tried), some people loathe the very idea of being technical, either because they think it is beneath them, or they just don't see themselves that way.

And like the article explains, even when "programming" tools seem to become simpler to use, they still require technical specification, and once people feel like they are getting close to "programming" they check out.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#196
post #195

One other thing that is often ignored: Most of the business class, executive class, ... even working class, DON'T want to write code. The reasons vary, but in general, just as some people don't want to touch maths (even if they might be good at it if they tried), some people loathe the very idea of being technical, either because they think it is beneath them, or they just don't see themselves that way. And like the…

Most people don’t avoid programming because it’s too hard. They avoid it because they don’t identify as technical. Just like math many people who could be decent at it still recoil from it. It’s not capability, it’s identity and preference. Humans aren’t fundamentally logical thinkers, we’re storytelling creatures who occasionally use logic to justify what we already feel.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#197

One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more. I see an analog with AI-generated code: the disciplined among us know we are programm…

A particularly alarming case: https://www.bbc.com/news/technology-54423988

And then of course there's this: https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt#Metho...

> Or will people realize they are programming and discipline up?

Well, they apparently haven't with spreadsheets, 50 years on, so I wouldn't be optimistic.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#198
post #64

One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more. I see an analog with AI-generated code: the disciplined among us know we are programm…

I often think about how the modern world genuinely does run on Excel formulas, many written by amateurs, most without automated tests and with version control based on final_final_v2 suffixes. Somehow civilization continues to function! Makes me a bit less terrified that untested vibe coded slop will sink the economy. It's not that different from how things work already.

In which spreadsheet slop arguably sinks the economy: https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt#Metho...

(This paper was extremely influential in pushing austerity policies of questionable efficacy during the financial crisis.)

We don't want _more_ of this.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#199

Earlier quoted context omitted.

I attended a CASE tools conference in the 1990s, which of course included a vendor exhibition. The vendors all had demos of creating an application using their tool. At multiple vendor stands I asked to see the code generated by their CASE tool. Invariably, the salespeople would start waffling about how the code was no longer important (sound familiar?), how you didn't need to examine the engine of a car while drivin…

Was a "to do" list the example they used at that time also?

Nah, that came later as the canonical example, with Ruby on Rails (which also somewhat suffered from a "programmers are irrelevant now" meme). Rails would make todo apps and twitter clones too cheap to meter (pretty much all Rails tutorials involved making one or the other in like an hour, pretty much entirely in the DSL).

In practice, Rails, while quite nice, was not the productivity revolution that it was originally touted as. These things never are.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#200
post #26

Until a year ago I believed as the author did. Then LLMs got to the point where they sit in meetings like I do, make notes like I do, have a memory like I do, and their context window is expanding. Only issue I saw after a month of building something complex from scratch with Opus 4.6 is poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe. It won’t be l…

The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything. In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages. From my experience, those developers that believe LLMs are good enough for production…

> The closer you get to releasing software, the less useful LLMs become.

Which is _always_ the case with these things, honestly. Remember Ruby on Rails? Make a Twitter clone in half an hour by just writing some DSL! Of course, in reality Rails was _not_ a productivity revolution, and making _real_ software which had to be operated at scale and maintained, and work properly, in it wasn't much easier than it had been previously.

Post reply on HN