@sophieschmieg @david_chisnall And before that - COBOL

"COBOL is a language intended for use by non-programmers and, by extension, for non-programs"

@sophieschmieg I think a lot of the low-code or no-code things were better because they didn't claim to be general solutions. They were good at creating business apps that worked like ten thousand other in-house business apps but with the small tweak specific to your requirements. Effectively, they factored out the common code and made it easy to create something that was the common bit plus a tiny extra bit.

In contrast, LLMs let you automatically generate a private local copy of all of that shared code, which is a maintenance nightmare and is completely unapproachable to non-programmer users because they can't tell the difference between the thousand lines of code that are copied and pasted and the dozen that are actually related to their requirements.

@sophieschmieg @david_chisnall I question your premise that it's easy to see what and why Excel is doing something. From personal experience, it's often not even clear, why it stores certain fields as a specific type. Slight version difference, language settings, and the phase of the moon might influence it or not.

But yes, writing code is always the smallest part. You always read and try to understand code (even your own code) much more often. With debugging or not in mind. 1/2

@sophieschmieg The labor angle is a good one -- focus on the linguistic details over the underlying intellectual work has been a part of how some insecure people in this industry have been trying to keep out people who don't look like or think like them for years.

I think a lot of the "thought leadership" about who can be a programmer is based on observed differences (and thus downstream of all kinds of differences in privilege - education, non-disability, being included by default, etc.). I think alternate tooling (that works consistently!) with enough equitable treatment would make a lot of actual programmers who today don't think of themselves as such.

What non-programmers who opine on AI don't seem to appreciate is that programmers mostly end up preferring the ability to precisely specify behavior of a program

@david_chisnall

@androcat Python is basically Smalltalk with ugly syntax and better FFI, so a starting point would be something like a Smalltalk debugger: everything is inspectable, you can create inspector windows for any object and directly manipulate it. Oh, and the code in Smalltalk (and Excel) is just a pile of objects (cells) and so you can dynamically modify any of it while the program runs.

Some of the more interesting work I've seen on debuggers for this kind of environment works by realising that reactive programming and watchpoints are basically the same concept: run some code when some variable changes. This lets you write arbitrary code in the language being debugged that runs when a particular variable changes (including things referenced by complex path expressions, so you can express things like 'starting from this root node of a tree, run this code any time a leaf node changes'. That lets you build live inspectors of program state and arbitrary traces for later inspection (and for turning into breaks on the next run).

@mhd Access got a lot of flak because it did one thing very well and another very badly, and it was marketed as a tool for doing the latter.

I worked with a bunch of companies that had used Access to build UIs to things like stock-management systems. The GUI builder was drag and drop and each form was backed by an SQL query that you could create mostly visually.

The built-in DB's complete lack of most features of a DB was painful, but it was quite easy to migrate these things to using SQL Server.

With the rise of things like Ruby on Rails, it was easier to build more complex, more maintainable equivalents if you had an in-house Ruby programmer, the nice thing about Access was that a non-programmer could build a working GUI front end to a DB and a part-time DBA could make it something that could work long term.

Several of the companies I saw doing this had written their UI bits on Windows 3.11 and not really modified them up to Windows XP. They'd been solving real business problems for a decade with minor tweaks. Good luck doing that with a 'vibe coding' solution.

@Liamo Fully agree. I do data analysis not real "programming". Having a LLM write the python code for me is a god send, as I cannot ever seem to remember the plotting commands just right. Through the LLM I get those right.

As you mention, my prompting ends up being a reasonable fraction of the code, but at least I get a graph quickly.

@cosmic @david_chisnall I am not sure what you are referring to with that.

It has been vigourously touted that the verboseness of COBOL would make it easier to learn. This is of course mostly bullshit, but no worse than the bullshit accompanying promotions of other languages.

One advantage was however that it could thus lure non-programmers to get started, for purely psychological reasons, something needed because there was much too few programmers around in the 60s.