[flatpepsi17]

Article starts mentioning 4GL's - a term I have not heard in a long, long time.

COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.

The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you become a programmer.

The main lesson of COBOL is that it isn't the computer interface/language that necessitates a programmer.

[vishnugupta]

I agree with you by and large except for this part.

> COBOL's promise was ... we wouldn't need programmers anymore..average person doesn't know how to explain & solve a problem

COBOL wasn't intended to be used by an "average" person but rather those with deep domain knowledge. They would know the business processes so well that they could transcribe it in COBOL with little or no need to learn how the computers worked. In some ways similar to analysts/data folks using SQL to communicate with databases.

While at it let me share a few more aspects of the top of my head.

COBOL and 4GLs in general were primarily intended to be used to build business applications; payroll, banking, HRMS, inventory management and so on. Even within that emphasis was more towards batch processing operations to reduce the burden on people doing routine bulk operations like reconciliation.

COBOL harks back to the times when there was no dedicated DBMS software. Which is why you see so much focus on how files are organised and the extensive verbs around files which somewhat resemble SQL today.

[moomin]

In my experience, often it’s hard to find that person with deep domain knowledge, and even when they do, it’s unstructured, they take things for granted they shouldn’t* and the have no appreciation of the demands of formalism.

Getting anything you can use to construct a work plan, never mind a detailed feature list, out of clients can be a dark art.

*To the point I have repeatedly experienced a point close to the end of the project where they go “What do you mean you don’t handle a case I have failed to mention for the entire duration of the project?”

[dcminter]

I recall a spec doc from a domain expert that said something like:

"The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B."

How to know what flavour the missing item was? Absolutely no mention of that...

[chii]

It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all.

The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X.

But that fact might not ever be recorded in the computer system, in a way that the old business process would've had a record of.

And this is just one small example - imagine something more complex!

So realistically, the job of a programmer is to force an expert to articulate all of their assumptions. IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.

[DebtDeflation]

My experience with "business domain experts" is that the majority of them are simply executing a process that someone else defined a long time ago. Their definition of "success" is usually that all steps within the process execute successfully without error and they can move on to the next transaction or activity. Very few of them are capable of taking a step back and considering what the process is actually trying to achieve and whether there might be a better way of accomplishing it. This leads to constant "paving of the cowpath" where archaic processes just get replicated in new technologies every so many years.

[chii]

That is a fair point. The programmer will have to learn the process, but also understand the process' goals and intentions.

If they do, then they by definition become a domain expert. It's just that this takes a while, and projects usually don't give enough time for such to take place unfortunately.

[Cthulhu_]

I work in the energy industry at the moment, we spend a lot of time looking for a stakeholder / domain expert, and they all seem to point at each other; nobody has the complete picture of one domain / feature, or nobody has the confidence to own and decide upon all aspects of it. That is, that "side" of the organization spends a lot of their time in meetings and writing emails to try and decide on things.

[dcminter]

> For example, they know if the submission was from party A, it must be type X.

Ha! As far as I remember it was almost exactly this when we interrogated them (but it's been a while).

[eru]

> IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.

Or you give them a prototype of the program, and see what they complain about?

[Seylox]

Oh, you're onto something. May I slap a sticker on it and call it "agile"?

[discretion22]

My experience is that invariably results in "development by veto". Each prototype they say that's not what I want, give me something else (that I'll fail to describe just like the last time) and I'll tell you that is wrong too after you've worked on it for a few weeks.

Occasionally, you'll randomly get something they accept - but only for a few weeks until they come across some missing capability for some other thing they never told you about.

[zknow]

you might say the domain expert expects the coputer to also already be a domain expert

[tannhaeuser]

> COBOL and 4GLs in general

COBOL dates back to 1959, much earlier than 4GLs, and the cited 1992/1999 articles make the point that 4GLs were poised to replace the likes of COBOL and FORTRAN when in fact those dinosaurs, or rather nautili since still living, turned out to outlive 4GLs except SQL (when counted as 4GL).

[fuzztester]

Informix 4GL is still alive and well (somewhat, anyway):

https://en.m.wikipedia.org/wiki/IBM_Informix-4GL.

[antonvs]

Arguably, Python is what 4GLs turned into or were supplanted by.

[nerdponx]

> In some ways similar to analysts/data folks using SQL to communicate with databases.

But SQL has the exact same problem. Except for very trivial scenarios, you can't just be an expert and plop your expertise into a SQL query. You have to learn how to use SQL to use SQL.

[vishnugupta]

> You have to learn how to use SQL to use SQL.

As with any other tool one has to learn it to effectively use it. Some find the learning curve not worth it and stick with Excel which is OK. But the thing is even Excel has to be learned to make full use of its potential.

[randomdata]

Keep in mind that the context is around domain experts being able to transcribe their domain knowledge into a machine-understandable language without concern for the intricacies of the machine it is executed on. That is where COBOL and SQL are said to have failed to live up to the hype, of which I'd agree. SQL is not a particularly good abstraction. Even for relatively trivial tasks, you still need to understand how computers work. EXPLAIN is the bread and butter of SQL users.

Ultimately every abstraction is leaky. There will never be a solution where you never need to understand how computers work under all circumstances. But my impression is that you can go a lot further in Excel before the stuff going on behind the scenes starts to get in your way? From what I have seen, Excel itself is more likely to get in your way before not knowing how computers work does.

[eternityforest]

It seems like Excel is an example of a successful app meant for a similar kind of audience

[froh]

> The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution.

I intuit this also is an intrinsic limit to LLM based approaches to "you don't need them expensive programmers no more"

with LLMs magically "generating the solution" you move the responsibility for concise expression of the problem up the ladder.

and then you "program" in prompts, reviewing the LLM-proposed formalization ("code").

I other words, the nature of "programming" changes to prompt engineering. alas you still have to understand formal languages (code)...

so there'll always be plenty to do for humans who can "math" :-)

[mmcdermott]

There is a disconnect somewhere. When I read online, I hear about how GenAI/LLMs replace programmers and office workers. When I go to work, I mostly hear the question of how we can apply GenAI/LLMs, apart from discussion of the general buzz.

Maybe this is a reflection of local conditions, I'm not sure, but it doesn't seem like the truly revolutionary changes require the solution to find a problem. It was immediately clear what you could do with assembly line automation, or the motor car, or the printing press.

[eru]

Electricity famously took perhaps twenty years for people to slowly figure out how to re-organise factories around it.. Hence the delayed impact on productivity figures.

To elaborate: in the bad old days of you had one big engine, eg a steam engine, that was driving shafts and belts all around the factory. There was a lot of friction, and this was dangerous. So you had to carefully design your factory around these constraints. That's the era of multi-story factories: you used the third dimension to cram more workstations closer to your prime mover.

With electricity, even if you have to make your own, you just need cables and you can install small electric motors for every task on every workstation. Now your factory layout becomes a lot more flexible, and you can optimise for eg material flow through your factory and for cost. That's when factories becomes mostly sprawling one-story buildings.

I simplify, but figuring all of that out took time.

[conradev]

a quote from Steve Jobs, explaining that the breakthrough invention was the fractional horsepower motor:

"Let’s look at the brief history of computers. Best way to understand it’s probably an analogy. Take the electric motor. The electric motor was first invented in the late 1800s. And when it was first invented, it was only possible to build a very, very large one, which meant that it could only be cost-justified for very large applications. And therefore electric motors did not proliferate very fast at all.

But the next breakthrough was when somebody took one of these large electric motors and they ran a shaft through the middle of a factory and, through a series of belts and pulleys, brought…shared the horsepower of this one large electric motor on 15 or 20 medium-size workstations, thereby allowing one electric motor to be cost-justified on some medium-scale tasks. And electric motors proliferated even further then.

But the real breakthrough was the invention of the fractional-horsepower electric motor. We could then bring the horsepower directly to where it was needed and cost-justified it on a totally individual application. And I think there’s about 55 or so fractional-horsepower motors now in every household."

[mmcdermott]

Adoption takes time, for sure, especially when dealing with fixed assets like a factory. The difference I'm poking at is that electricity had a clear value proposition and improved over time. I see people looking for the value proposition in GenAI/LLMs, which brings me to the original question.

If GenAI now was like early electricity, we would know what we wanted to use it for, even if we weren't there yet. That isn't what it looks like to me, but I'd be curious to know if that's just where I'm sitting, metaphorically speaking.

Every company I have worked for had more work than hands for programming and other knowledge work. Capacity is valuable. Does anyone here see GenAI teams being spun up for "management" by a human? Or do we see fancy Google search / code completion?

[eru]

> Adoption takes time, for sure, especially when dealing with fixed assets like a factory.

I was talking about the need to re-imagine and re-organise how factories work, not about the physical factories themselves. So it's more like a 'software' problem.

> Does anyone here see GenAI teams being spun up for "management" by a human? Or do we see fancy Google search / code completion?

How would the two cases look different? If you have a human worker that uses GenAI to help her complete tasks (via something like fancy auto-completion of text, code etc) that previously took a whole human team, that's exactly how you would 'spin up a team of GenAI for management by a human' would look like, wouldn't it?

It's just our framing that's different, and perhaps who that human is: you take someone who's familiar with the actual work and give her the tools to be faster, instead of taking someone who's more familiar with the meta-level work of managing humans.

I suspect that's because managing humans is a rather specialised skill in the grand scheme of things, and one that doesn't help much with telling GenAI what to do. (And, human managers are more expensive per hour than individual contributors.)

---

In any case, I agree that GenAI at the moment is still too immature to be trusted with much on its own. I hope more globally optimising AI like AlphaGo etc comes back in style, instead of essentially 'greedy' contemporary GenAI that just produces one token after another.

[mmcdermott]

What I'm picturing is two divergent paths with very different impacts on human interaction.

1) Every human programmer becomes the surgeon in Fred Brooks's surgical team model (https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...) and AI provides the rest. In effect, all working human programmers are software architects in the sense that they exist in large companies. The unstated assumption here is that going from vague user input to a solution is roughly equivalent to AGI, and so is further out than anything on the immediate horizon.

2) GenAI is used as a sort of advanced template/snippet/autocomplete system.

The first one is a fundamental paradigm shift. Professional programmers don't cease to exist, but the profession becomes inherently smaller and more elite. The bar is higher and there isn't room for many perfectly intelligent people who work in the field today.

The second one is a force multiplier and is helpful, but is also a much more banal economic question, namely whether the tool generates enough value to justify the cost.

I have no complaint either way and I'm definitely interested in the next step beyond what we've seen so far. The hype implies that the first branch above is where everything is headed, hence the "death of programming as a profession" type articles that seem to be making the rounds, but that isn't what I've seen day-to-day, which is what prompted the original thought.

[jerf]

I think it's a lot of little things. There's a lot of people very motivated to keep presenting not just AI in general, but the AI we have in hand right now as the next big thing. We've got literally trillions of dollars of wealth tied up in that being maintained right now. It's a great news article to get eyeballs in an attention economy. The prospect of the monetary savings has the asset-owning class salivating.

But I think a more subtle, harder-to-see aspect, that may well be bigger than all those forces, is a general underestimation of how often the problem is knowing what to do rather than how. "How" factors in, certainly, in various complicated ways. But "what" is the complicated thing.

And I suspect that's what will actually gas out this current AI binge. It isn't just that they don't know "what"... it's that they can in many cases make it harder to learn "what" because the user is so busy with "how". That classic movie quote "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" may take on a new dimension of meaning in an AI era. You were so concerned with how to do the task and letting the computer do all the thinking you didn't consider whether that's what you should be doing at all.

Also, I'm sure a lot of people will read this as me claiming AI can't learn what to do. Actually, no, I don't claim that. I'm talking about the humans here. Even if AI can get better at "what", if humans get too used to not thinking about it and don't even use the AI tool properly, AI is a long way from being able to fill in that deficit.

[adamc]

Not to mention someone would need to evaluate and test the proposed solution... which with today's LLMs I would not bet heavily on its correctness.

This is some years ago, but a friend of mine, trained in a 4GL that was still a procedural programming language, went somewhere that was using a higher level, model-based generation of code based on that language. It turned out they still needed a few people who understood how things worked beneath the hood.

I am deeply skeptical that human-language level specifications will ever capture all the things that really need to be said for programming, any more than they do for mathematics. There are reasons for formalisms. English is slippery.

[devjab]

This is only true to an extend. We have a lot of digitally inclined workers who’re developing programs or scripts to handle a lot of things for them. It’s imperfect and often wildly insecure and inefficient, but unlike any previous no-code or “standard” solution it actually works. Often in conjunction with “standard” solutions.

On one hand you’re correct in that there will always be a need for programmers. I really doubt there will be a great need for generalist programmers though. The one area that may survive is the people who’re capable of transforming business needs and rules into code. Which requires a social and analytical skillset for cooperating with non tech people. You’ll also see a demand for skilled programmers at scale and for embedded programming, but the giant work force of generalist developers (and probably web developers once Figma and similar lets designers generate better code) is likely going to become much smaller in the coming decades.

Then is basically what the entire office workforce is facing. AI believers have been saying AI would do to the office what robots did to the assembly line for years, but now it actually seems like they’re going to be correct.

[stroupwaffle]

Another parallel is type foundries and printing presses. At one point people operated these linotype machines which used molten lead. Of course this transitioned to photo typesetting which, to the dismay of everyone had poor results. Along came Donald Knuth and TeX to fix those deficiencies. NOTE: mechanical printing has a profoundly better result no matter what. It is the ink and the impression in paper that makes it superior (for letterforms and such).

So, if AI follows suit, we will witness the dumb (but very knowledgeable) AI start to supplant workers with questionable results; and then someone (or a team) will make a discovery to take it to the limit and it’ll be game over for large swaths of jobs.

https://en.m.wikipedia.org/wiki/Hot_metal_typesetting

[Animats]

TeX was predated by a family of macro-based document languages that began with RUNOFF and continued through roff, nroff, troff, ditroff, and groff. Plus tbl, eqn, and mm*. Some manual pages still use that stuff. Most Linux systems still install it by default. TeX has roughly the same concept, a macro-based layout language, but a better design with far less cruft.

[jasfi]

A lot of business people want to get something functional that they can sell, and hire a programmer if/when they can afford one. That niche is seeing a lot of uptake with regards to LLM based approaches.

This works for them because an MVP typically isn't a lot of code for what they need, and LLMs have a limited scope within which they can generate something that works.

[immibis]

In fact we've been using programming LLMs for a long time, which we call compilers.

[mannykannot]

The acronym LLM stands for what is now a term of art for a class of information- processing systems which are produced by, and themselves produce their output by, methods very unlike those for compilers. This is just as well, considering the consequences that would follow from compilers routinely hallucinating.

[unscaled]

4GL were supposed to be even more of that, with more "human-language-like" constructs added to the language to deal with things besides general logic, simple data structures and arithmetic.

The author mentions "4GLs" were all the rage in the early 1990s, but I doubt that that was true outside of the mainframe world. The 4GL movement, as a conscious movement, seems to have always been highly mainframe oriented (the Wikipedia article mentions reducing the amount of punched cards necessary for a program as initial goals). By the 1990s you could categorize many languages as 4GL, but I doubt this term was used with any enthusiasm outside of the mainframe world. It was the opposite of a buzzword.

1992 wasn't too long ago. Linus Torvalds has already released Linux, and Guido van Rossum was already working on Python. Perl was already gaining popularity, and Haskell also saw it first versions released. The forefront of technology was already shifting from expensive workstations to consumer-grade PCs and language designers gave little thought to 4GL concepts, even when they happened to design something that could qualify as a 4GL for personal computers (e.g. dBase, HyperTalk, AppleScript).

I agree that human-like text is a bad idea for most use cases of programming, but I think this is not why the 4GL movement failed, and in fact most 4GLs weren't more "natural language-like" than the 3GL COBOL. I think the main problem was that the 4GL movement has never really defined a new generation or anything useful at all. The previously defined generations of language introduced revolutionary changes: translation from friendlier assembly language to machine code (2GL) and compilation (3GL). The only change we can properly define from the loose definition of 4GL is "put more features that used to be external routines or library directly into the language".

This approach worked out relatively well when the language was domain-specific. This is how we got some of the most successful 4GLs like SQL, R and MATLAB. These languages have syntax that deals directly with data tables, statistics and linear algebra directly into the language and became very useful in their own niche. The concept of a general-purpose 4GL, on the other hand, was always destined to boil down to an overly bloated language.

[int_19h]

dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here.

But, yes, I agree that aside from the generally more verbose and sometimes unwieldy syntax, there wasn't really that much to it in practice. I did work with FoxPro, and the reason why it was popular was not because you had to write things like "ACTIVATE WINDOW", but because it had many things baked directly into the language that nicely covered all the common tasks a pre-SQL data-centric app would need - e.g. a loop that could iterate directly over a table.

[Delphiza]

That class of software also allowed for very efficient data capture against normalised tables. A recall as early as Paradox for DOS (something I haven't thought of for a while) in about 1990 being really simple tools for creating one-to-many database capture 'forms' (with selection boxes, date drop downs, the lot). The richness of form design and tight coupling to the database meant that the language did not need to be very powerful and could just run as a script on top of a rich database environment. The PC-based successor to mainframe 4GL concepts was late-nineties RAD (Rapid Application Development) of Delphi and VB. MS Access was the Windows successor to those tools and was wildly successful as a way for 'business people' to build apps. It took many years for windows low-level app development or the web to catch up to the richness, but they have never really achieved the same level of non-programmer usability.

[int_19h]

Yep, and C# (or VB.NET) + WinForms sort of carried that torch well into the aughts. You can still see traces of that all over classic .NET - stuff like DataSet and stock widgets designed specifically for those kinds of CRUD apps such as BindingNavigator.

It's interesting that we have largely abandoned this approach to software development despite its amazing productivity in that niche. I guess a large part of it is because custom-made software is much less common in general than it used to be.

[gopher_space]

In my mind ‘low-code’ was perfected in FileMaker Pro and then quietly abandoned because you still needed an interest in the subject to use it.

[farrelle25]

Gosh it's a long time since I heard 'Clipper' mentioned. I used to do 'PC' apps for Banks in the early 90s. Turbo Pascal and Clipper were popular with us. (We used PL/1 rather than COBOL for batch processing)

Then VB 4.0 started to get popular around 1996 and ruled the roost...

So many technologies... does anyone remember 'SUPRA' from that era! (think it was supposed to be a 4GL language/interface for mainframe databases)

[El_RIDO]

Sigh I work at a company that not long ago added support for applications written to use SUPRA to their portfolio. It's not dead yet, there are companies out there still running it in production and willing to spend money to replace it, while keeping their business logic.

[adamc]

Where I work we still use Software AG's Natural for mainframe programming. It's not really a bad language for what it is (very much focused on database programming). The main limitation is that they never created or provided great mechanisms for something like a standard library, so we do a lot in Python now, and occasionally other languages.

From my perspective, the standard libraries of languages like Python and Java, as well as effective package managers such as pip or npm or cargo, have raised the bar so high that it is difficult for old, specialist languages to compete in most cases. Although the security problems of the package managers give me some pause.

[cmiles74]

I have to disagree that 4GL languages being aimed at the big iron, mainframe world. After browsing the Wikipedia page, there seems to be some confusion around what a 4GL would actually be... For instance, RPG is lumped into this category despite it functioning at a pretty low level and predating the idea by about 30 years. When I first started working with RPG we had worksheets from IBM that felt reminiscent of punch cards.

In my experience, most 4GL languages were aimed at microcomputers and did reasonably well. Others have mention FoxPro and dBase, 4D and FileMaker also slot nicely into this category. IMHO, they had great success in the back office of small businesses.

I have seen some effort to force SQL into this category, perhaps with the idea that a SQL database with stored procedures technically meets the 4GL definition.

[AdieuToLogic]

> COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.

The more things change, the more they are the same.

[_yb2s]

> we wouldn't need programmers anymore

This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.

But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper, and have it work - something few people can or need to do nowadays

[AdieuToLogic]

> This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.

I have heard others and myself describe COBOL in many ways, most involving creative expletive phraseology which would make a sailor blush, but "low level/terse language" is a new one to me.

> But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper ...

LISP and Fortran predate COBOL IIRC.

[_yb2s]

> LISP and Fortran predate COBOL IIRC

I didn't mean to imply COBOL was anything close to the first programming language, only that I was speculating what 'programming' generally meant within computer culture at the time. I was not around at that time- but I strongly suspect that directly writing machine code and/or assembly was still common practice throughout the entire 1950s, whereas it is far less common nowadays.

I wonder what year Fortran overtook assembly and became the most popular programming language during that era? I suspect it was well after COBOL came out. Surely there is a lag time for any new programming language to become commonplace.

I couldn't find any data on that, but I was able to find that C was released in 1972, but took until 1982 to overtake Fortran, and until 1985 to overtake Pascal. I often forget how slow new things propagated through the culture in pre-internet times.

[AdieuToLogic]

> ... I strongly suspect that directly writing machine code and/or assembly was still common practice throughout the entire 1950s ...

It depends on what type of programming was being done. What we now call "kernels" and "device drivers" were largely authored in assembly languages well into the 80's (depending on the machine).

> I wonder what year Fortran overtook assembly and became the most popular programming language during that era?

Fortran got its name from "formula translator" (or equivalent, depending the source), so it quickly gained traction in the scientific/mathematics domain. As an aside, there are variants of BASIC which have much of the semantic mathematical capabilities of Fortran yet with better I/O support IMHO. None come close in performance AFAIK.

> I suspect it was well after COBOL came out.

COBOL took off in the business world, as it was intended to do, and remains prevalent in at least the insurance and banking industries to this day.

> ... I was able to find that C was released in 1972, but took until 1982 to overtake Fortran, and until 1985 to overtake Pascal.

K&R C was viewed by many as "portable assembly code", with Unix helping it to gain acceptance. ANSII C largely replaced use of K&R C in the late 80's.

Depending on the OS, a small amount of "shim code" remained in assembly (such as interrupt handlers and MMU interaction) up to most of the OS being written in assembly well into the late 80's.

This is all to say that:

> ... directly writing machine code and/or assembly was still common practice throughout the entire 1950s

Is still common practice in OS development, albeit to a lesser degree, if directly writing machine code is omitted.

HTH

[andsoitis]

> LISP and Fortran predate COBOL IIRC.

Correct. Fortran, LISP, and COBOL were invented in ‘57, ‘58, and ‘59, respectively.

[jll29]

> Yes, but the ideas behind COBOL were older still. Flowmatic, COBOL’s predecessor, dates back to 1955, so it really just depends how you count.

Yes. but the ideas behind LISP were older still: Church's typed lambda calulus was conceived in 1936.

[moomin]

Yes, but the ideas behind COBOL were older still. Flowmatic, COBOL’s predecessor, dates back to 1955, so it really just depends how you count.

[thorin]

Saying we don't need "programmers" any more was true when a programmer was someone who used very low level languages such as Assembly and probably had used punched cards in the past etc. Languages like cobol / fortran / plsql gave analysts a chance of designing things on paper and handing off to developers or even doing the development themselves which couldn't have happened in the past. Using something like python these days feels like the kind of thing that would have been thought of as a 4gl in those days for some use cases. However, python also works as a general purpose programming language.

[_yb2s]

That was exactly my point

[electroly]

Do you mean something other than "terse" here? Or are you perhaps thinking of a different language? I cannot possibly imagine that adjective being used to describe COBOL. It is the #1 textbook example of a verbose language--the opposite of terse.

[_yb2s]

What I mean is that it is an attempt to make a high level domain specific language, but is not my modern standards

[bloppe]

Even LLMs have not realized the dream of a natural language computer interface. Everyone who uses them significantly has to read up on prompt engineering and add little things like "explain your steps" or "describe it like I'm 5" or other oddly specific sequences of characters to get the results they want. That's not natural language. It's a DSL.

[rbanffy]

Worse. It’s a DSL without a formal specification. You are writing prompts blindly in hopes they trigger the desired behaviour from the LLM.

A bit like writing enchantments to force demons to do your bidding.

[namaria]

Worse. You're just providing tokens which will get values you don't know or can predict attached to them and trying to influence values which will produce tokens based on rules you don't know, which change all the time for reasons you also don't know. Hopefully the tokens you get are the ones you're hoping for, and if you don't have complete mastery of the subject you won't know if they are the tokens you need or can even trust their meaning.

[anthk]

Z Machine text adventures are far more predictable...

[ykonstant]

>A bit like writing enchantments to force demons to do your bidding.

But without the cool chanting and poetic language; just like cyberpunk was realized without the vivid imagery and neon lights :(

[rbanffy]

> just like cyberpunk was realized without the vivid imagery and neon lights :(

The 21st century never ceases to disappoint. It’s a cheap, low budget and dystopian version of what we imagined.

[NoGravitas]

To be fair, what we imagined was dystopian, too. It's just that some people with a lot of ambition and not much media literacy didn't realize it was dystopian, and set about to build that future.

[rbanffy]

I am from the Thunderbirds generation. It wasn't a perfect 21st century, but at least it was cool. And the sound track was excellent.

[zknow]

could have been high budget dystopian at least!

[systems_glitch]

This is often the exact reason I give to people when they don't understand why Amy and I don't think "everyone should be a 'coder!'" should be pushed in schools, heh.

When you're graduating students from high school who go into college as engineering hopefuls who can't solve X - 2 = 0 for X, what hopes does the average individual have for solving programming problems?

[wvenable]

My company is finally upgrading away from a product that is written in a 4GL language. This product probably started out on a Unix but was ported to Windows decades ago. It has both a web and classic VB front ends.

All the source code is available and theoretically I could make changes and compile it up. The language itself is basically just plain procedural code but with SQL mixed right in -- somewhat like DBase or Foxpro but worse. I think the compiler produces C code and is then compiled with C compiler but it's been a while since I looked into it. Requires a version of Kornshell for Windows as well.

[agumonkey]

I spent very little time in the cobol world but what I got is that its use outgrew many times its original design (batch processing not too complex tables/rows). Whenever you start to need complicated state machines and abstractions the language will implode.

[cwbriscoe]

4GL's were a mistake. We have 4gl code that was compiled into COBOL. Nice. Except, nobody still around knows the 4gl language and the generated COBOL is completely unreadable.

[actionfromafar]

Vision 4GL. Like VB but cross platform and with a horribly unstable IDE which would corrupt the source code. (Which was in some kind of binary format not amenable to source control.)