4 ms·

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

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.

tannhaeuser 2y ago
> 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 2y ago
  Informix 4GL is still alive and well (somewhat, anyway): https://en.m.wikipedia.org/wiki/IBM_Informix-4GL https://en.m.wikipedia.org/wiki/IBM_Informix-4GL.
- antonvs 2y ago
  Arguably, Python is what 4GLs turned into or were supplanted by.
moomin 2y ago
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 2y ago
  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 2y ago
    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.
    - zknow 2y ago
      you might say the domain expert expects the coputer to also already be a domain expert
    - eru 2y ago
nerdponx 2y ago
> 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 2y ago
  > 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 2y ago
    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 2y ago
It seems like Excel is an example of a successful app meant for a similar kind of audience

tannhaeuser 2y ago

> 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 2y ago
Informix 4GL is still alive and well (somewhat, anyway): https://en.m.wikipedia.org/wiki/IBM_Informix-4GL https://en.m.wikipedia.org/wiki/IBM_Informix-4GL.
antonvs 2y ago
Arguably, Python is what 4GLs turned into or were supplanted by.

moomin 2y ago

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 2y ago
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 2y ago
  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.
  - zknow 2y ago
    you might say the domain expert expects the coputer to also already be a domain expert
  - eru 2y ago

nerdponx 2y ago

> 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 2y ago
> 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 2y ago
  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 2y ago

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