Quote from Dave Voorhis on March 13, 2021, 11:53 am

Quote from dandl on March 13, 2021, 12:18 am

Let us assume that (as I assert) the D problem is solved. There are 'good enough' type systems right now, and if we really wanted full TTM we could tweak an existing language to make it so. Let's call it E.

I have personally written programs at just about every level there is: plug-boards, machine code, assembler, early 3GL (fixed types), C/Pascal, OO (also several 4GLs, including our very own Powerflex). The biggest steps were:

• symbolic macro assembler
• HLL (Cobol, Fortran, Algol, Basic)
• Type definitions (Pascal, C)
• OO, encapsulation, leak-proof memory (C++, Java, C#)
• Generics, lambdas (C++, C#, Java ?)

Why the question mark after Java?

It has generics and lambdas.

I do wish C# fans (it's always C# fans) -- and I'm not singling you out here; I see this elsewhere -- would stop comparing a 2002 release of Java (deprecatory claims are usually based on Java 1.4; we're on Java 15 now with version 16 out in a week or two) to current C#.

If there are comparisons and criticisms to be made, let them be around current features, like whether or not C# properties are a benefit or a code smell or not, or a comparison of Java records to C# tuples, or the whether Java's type erasure semantics are an obstacle or not, etc.

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

Brief aside: Powerflex is our very own 4GL. It has meta-programming (type-aware macros), built-in forms and data records (ISAM with FK) and a good-enough HLL. Most of our development effort went into making the HLL better, and doing ports/interfaces (Windows, Unix, Btrieve, SQL). We were too early: the 3GL and SQL turned out to be more important than the 4GL bits.

But here is a complete data entry program in Powerflex, so you get an idea of what I mean.

// MEMBER.PFX - sample entry program for the members database

/S_1
MEMBER.PFX Page 1 of 1
Maintain Members of Club


NO <____.>
SURNAME <____________>
GIVEN NAMES <________________>
DOB [__/__/____]
SEX [_]
RATING <____.>
JOINED [__/__/____]
MAILCODE [____]
PLAYED [___.]
WINNINGS [_____.__]
/*

//[]------------------------------------------------------------------[]
//[] File Opens
//[]------------------------------------------------------------------[]
open "member" as MEMBER


//[]------------------------------------------------------------------[]
//[] Program Start
//[]------------------------------------------------------------------[]
enter MEMBER
autopage S_1
entry MEMBER.NO
entry MEMBER.SURNAME {capslock}
entry MEMBER.GIVEN_NAMES
entry MEMBER.DOB
entry MEMBER.SEX {capslock}
entry MEMBER.RATING
entry MEMBER.JOINED
entry MEMBER.MAILCODE {capslock}
entry MEMBER.PLAYED
entry MEMBER.WINNINGS
return

enterend

Heavens. 1987 called and wants its UI definition language back.

I suppose you can flip a switch to emit Web and mobile front-ends, in addition to desktop?

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

I work in this business area, and I'm watching as UI forms in application code are becoming almost extinct. There are still some forms at point-of-sale/point-of-business and for entering options, but everything else is moving to automated data pipelines. I've written code that directly interacted with a form once in the past year, and that was to pick a report and its options for a purely admin-side gadget. All the front-end stuff was typical front-end: heavily designed by dedicated UX people, implemented by UI people, interfaced by front-end programmers. The business logic / back-end programmers don't even see that stuff.

I'm not convinced we want to revisit 4GL, which was epically flawed and still is.

I think we want more powerful 3GL. We're doing an awful lot of building houses out of toothpicks, but that doesn't mean we need prefab 4GL walls. It maybe means we need 3GL 2x4s and breezeblocks.

Quote from dandl on March 13, 2021, 1:35 pm

Why the question mark after Java?

It has generics and lambdas.

I do wish C# fans (it's always C# fans) -- and I'm not singling you out here; I see this elsewhere -- would stop comparing a 2002 release of Java (deprecatory claims are usually based on Java 1.4; we're on Java 15 now with version 16 out in a week or two) to current C#.

If there are comparisons and criticisms to be made, let them be around current features, like whether or not C# properties are a benefit or a code smell or not, or a comparison of Java records to C# tuples, or the whether Java's type erasure semantics are an obstacle or not, etc.

The simple reason is that C# programmers know C# is better, but Java programmers think Java is just as good. My experience with Java is around 2 years old, so 12 or 13, plus a peek at 14. I've been using it since 1995 or so, but C# has always been ahead since 2.0 or so. IMO the language suffered badly at the hands of Sun through that period, and while C# has plenty of cruft from the pre 3.0 days, Java has way more cruft. The main things that irritated me (still) were int/Integer, array/list and not-quite-generics, but there were others. Enums are bad in both, so not really a contest there. But that really isn't the point...

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

<snip>

Heavens. 1987 called and wants its UI definition language back.

Certainly not. The point of this is to illustrate those 3 features: shorter, safer, higher.

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

Why ever would that be a good idea? Those are the assembly languages of the modern browser, not even one step up from rock bottom. Horrible.

I work in this business area, and I'm watching as UI forms in application code are becoming almost extinct. There are still some forms at point-of-sale/point-of-business and for entering options, but everything else is moving to automated data pipelines. I've written code that directly interacted with a form once in the past year, and that was to pick a report and its options for a purely admin-side gadget. All the front-end stuff was typical front-end: heavily designed by dedicated UX people, implemented by UI people, interfaced by front-end programmers. The business logic / back-end programmers don't even see that stuff.

I'm not convinced we want to revisit 4GL, which was epically flawed and still is.

I think we want more powerful 3GL. We're doing an awful lot of building houses out of toothpicks, but that doesn't mean we need prefab 4GL walls. It maybe means we need 3GL 2x4s and breezeblocks.

The GP languages we have can't do that, they weren't designed for it. I quoted 4GL not as an end in itself, but as an example of shorter, safer, higher. I have no particular interest in generating forms (although I think your experience is probably not typical). I care about languages that are tools for others to use to create programs. We have precious few of those.

 

Quote from Dave Voorhis on March 13, 2021, 4:53 pm

Quote from dandl on March 13, 2021, 1:35 pm

Why the question mark after Java?

It has generics and lambdas.

I do wish C# fans (it's always C# fans) -- and I'm not singling you out here; I see this elsewhere -- would stop comparing a 2002 release of Java (deprecatory claims are usually based on Java 1.4; we're on Java 15 now with version 16 out in a week or two) to current C#.

If there are comparisons and criticisms to be made, let them be around current features, like whether or not C# properties are a benefit or a code smell or not, or a comparison of Java records to C# tuples, or the whether Java's type erasure semantics are an obstacle or not, etc.

The simple reason is that C# programmers know C# is better, but Java programmers think Java is just as good. My experience with Java is around 2 years old, so 12 or 13, plus a peek at 14. I've been using it since 1995 or so, but C# has always been ahead since 2.0 or so. IMO the language suffered badly at the hands of Sun through that period, and while C# has plenty of cruft from the pre 3.0 days, Java has way more cruft. The main things that irritated me (still) were int/Integer, array/list and not-quite-generics, but there were others. Enums are bad in both, so not really a contest there. But that really isn't the point...

Compared to higher level languages, C# and Java are indistinguishable -- effectively varying only in syntactic sugar.

Compared to each other, there are unquestionably some useful features in C# that aren't found in Java. But for whatever reason, C# seems to attract marginal programmers to a far greater degree than Java. The result is that typical production Java code is readable and maintainable whilst typical production C# code is abominable, usually a mix of developers attempting to demonstrate capability in every C# feature plus forced adherence to what I can only assume are C# / .NET / Microsoft "best practices" (because I've seen them appear identically in multiple, unrelated places -- and by the way, I use the term "best" very loosely here) that result in unreadable, un-maintainably labyrinthine complexity, brittleness, awkwardness, and sometimes operational slowness.

I've found that rewriting such ghastliness to make it simple, straightforward, readable and maintainable is almost always beneficial. Notably, the resulting code is invariably almost indistinguishable from Java code to accomplish the same thing. It seems the useful features found in C# but not in Java don't add much in (good) practice.

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

<snip>

Heavens. 1987 called and wants its UI definition language back.

Certainly not. The point of this is to illustrate those 3 features: shorter, safer, higher.

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

Why ever would that be a good idea? Those are the assembly languages of the modern browser, not even one step up from rock bottom. Horrible.

I've seen it done effectively. The UX/UI people produce the front-end using the tools they know (HTML/CSS or whatever design tool emits it) to produce the look-and-feel they want, and the coding tool slurps up all the form field definitions and fill-in-able HTML elements (of some class, I guess? I didn't look) and makes them available to the code.

The UX/UI folks aren't forced to learn new stuff to implement designs or be relegated to using wireframes or creating non-production HTML/CSS, and the programmers aren't forced to laboriously re-implement designs in HTML/CSS/code provided by UX/UI folks who have been relegated to using wireframe tools because they can't write production HTML/CSS.

Of course, it presumes the goal is custom UI/UX designs for end-user Web sites. If it's only manual data entry that matters and look-and-feel isn't a concern, then any form painting / coding tool will do.

I work in this business area, and I'm watching as UI forms in application code are becoming almost extinct. There are still some forms at point-of-sale/point-of-business and for entering options, but everything else is moving to automated data pipelines. I've written code that directly interacted with a form once in the past year, and that was to pick a report and its options for a purely admin-side gadget. All the front-end stuff was typical front-end: heavily designed by dedicated UX people, implemented by UI people, interfaced by front-end programmers. The business logic / back-end programmers don't even see that stuff.

I'm not convinced we want to revisit 4GL, which was epically flawed and still is.

I think we want more powerful 3GL. We're doing an awful lot of building houses out of toothpicks, but that doesn't mean we need prefab 4GL walls. It maybe means we need 3GL 2x4s and breezeblocks.

The GP languages we have can't do that, they weren't designed for it. I quoted 4GL not as an end in itself, but as an example of shorter, safer, higher. I have no particular interest in generating forms (although I think your experience is probably not typical). I care about languages that are tools for others to use to create programs. We have precious few of those.

We have a lot of those. Perhaps what you mean is you care about languages that are tools for non programmers to create programs?

From a programmer point of view, I find your interpretation of "shorter, safer, and higher abstraction" rather curious, particularly using a 4GL to illustrate it.

"Shorter" seems least controversial, but it won't be shorter once your requirements deviate from the limited things the 4GL (or whatever) is pre-specified to do and you have to integrate some 3GL or otherwise work around the inevitable limitations of the 4GL. (And you will.)

It's only "safer" in the sense that it's not really a programming language (even if it's inside one); it's (invoking) predefined functionality that is effectively checkboxed from the available choices by being written down in a text file. That's safety by restriction rather than safety by nature. And, again, it's only "safer" until you starting writing the inevitable workarounds to achieve required functionality that hasn't been pre-specified, and then it's typically less safe than if you had done it all in a strong 3GL.

Finally, your interpretation of "abstraction" is odd. Compared to the current popular programming languages, higher levels of abstraction are (for example) declarative programming, pattern-matching (-based dispatch), meta-programming, generative programming, inferential systems, constraint-based programming, etc., and are always in comparison to lower levels. Prewritten libraries for specific uses such as forms are typically not abstractions in the programming sense, they're simply someone else writing some non-abstract code for you.

Notably, levels of abstraction are hierarchical, the way "shape" is an abstraction of "cube", "cube" is an abstraction of "building", "building" is an abstraction of "house", etc. What you're describing is not higher level abstraction but predefinition. E.g., what is "form" an abstraction of? (If you're thinking "a bunch of fields", that's composition rather than abstraction.)

That said, I agree wholeheartedly that shorter, safer, and higher abstraction are laudable goals.

Only, they need to be entirely in the 3GL domain. Thus:

"Safer" means as much possible checked before execution and/or handled at runtime via inescapably obligatory code.

"Higher abstraction" and "shorter" together mean expressive, powerful, reusable constructs that can be composed to form new constructs, and those constructs composed to form new constructs, and so on ad infinitum.

The value of such a language would be demonstrated by its universality. It should be equally good at constructing a DBMS or a new end-user business application, though it might mean you need to create the DBMS functionality first. You shouldn't need (or want!) to change language to do it, though.

If the language can only effectively specify some subset of possible end-user business applications, then it's certainly a valid domain-specific language, but to me that seems like more of a tickbox exercise in feature inclusion than an interesting pursuit of new and perhaps innovative general-purpose language design.

But maybe that should be a different thread?

Quote from dandl on March 14, 2021, 9:56 am

Quote from Dave Voorhis on March 13, 2021, 4:53 pm

Quote from dandl on March 13, 2021, 1:35 pm

Why the question mark after Java?

It has generics and lambdas.

I do wish C# fans (it's always C# fans) -- and I'm not singling you out here; I see this elsewhere -- would stop comparing a 2002 release of Java (deprecatory claims are usually based on Java 1.4; we're on Java 15 now with version 16 out in a week or two) to current C#.

If there are comparisons and criticisms to be made, let them be around current features, like whether or not C# properties are a benefit or a code smell or not, or a comparison of Java records to C# tuples, or the whether Java's type erasure semantics are an obstacle or not, etc.

The simple reason is that C# programmers know C# is better, but Java programmers think Java is just as good. My experience with Java is around 2 years old, so 12 or 13, plus a peek at 14. I've been using it since 1995 or so, but C# has always been ahead since 2.0 or so. IMO the language suffered badly at the hands of Sun through that period, and while C# has plenty of cruft from the pre 3.0 days, Java has way more cruft. The main things that irritated me (still) were int/Integer, array/list and not-quite-generics, but there were others. Enums are bad in both, so not really a contest there. But that really isn't the point...

Compared to higher level languages, C# and Java are indistinguishable -- effectively varying only in syntactic sugar.

They're close, but I would argue the C# program is likely to be shorter, so C# is higher level on that metric.

Compared to each other, there are unquestionably some useful features in C# that aren't found in Java. But for whatever reason, C# seems to attract marginal programmers to a far greater degree than Java. The result is that typical production Java code is readable and maintainable whilst typical production C# code is abominable, usually a mix of developers attempting to demonstrate capability in every C# feature plus forced adherence to what I can only assume are C# / .NET / Microsoft "best practices" (because I've seen them appear identically in multiple, unrelated places -- and by the way, I use the term "best" very loosely here) that result in unreadable, un-maintainably labyrinthine complexity, brittleness, awkwardness, and sometimes operational slowness.

I've found that rewriting such ghastliness to make it simple, straightforward, readable and maintainable is almost always beneficial. Notably, the resulting code is invariably almost indistinguishable from Java code to accomplish the same thing. It seems the useful features found in C# but not in Java don't add much in (good) practice.

Not my experience at all. Must be the company you keep.

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

<snip>

Heavens. 1987 called and wants its UI definition language back.

Certainly not. The point of this is to illustrate those 3 features: shorter, safer, higher.

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

Why ever would that be a good idea? Those are the assembly languages of the modern browser, not even one step up from rock bottom. Horrible.

I've seen it done effectively. The UX/UI people produce the front-end using the tools they know (HTML/CSS or whatever design tool emits it) to produce the look-and-feel they want, and the coding tool slurps up all the form field definitions and fill-in-able HTML elements (of some class, I guess? I didn't look) and makes them available to the code.

The UX/UI folks aren't forced to learn new stuff to implement designs or be relegated to using wireframes or creating non-production HTML/CSS, and the programmers aren't forced to laboriously re-implement designs in HTML/CSS/code provided by UX/UI folks who have been relegated to using wireframe tools because they can't write production HTML/CSS.

Of course, it presumes the goal is custom UI/UX designs for end-user Web sites. If it's only manual data entry that matters and look-and-feel isn't a concern, then any form painting / coding tool will do.

None of this has anything whatever to do with the issue of 'Life after D'. The mere fact that you even raise those as issues of concern says we're a long way off a solution.

Yes, use tools to make visual imagery that looks as desired, but no, never look at the save file format. Do you routinely read the SVG emitted by Inkscape or the FBX emitted by Autodesk tools or the PS emitted by Adobe? Of course not!We assume a save file form for UI/UX tools and a save file format for data model design, and we don't poke around inside: those are just UI objects and dataset objects. The question is what language we use to manipulate those objects. And the aim is: sweet spot at 100 lines of code, but absolutely no program over 300 LOC.

I work in this business area, and I'm watching as UI forms in application code are becoming almost extinct. There are still some forms at point-of-sale/point-of-business and for entering options, but everything else is moving to automated data pipelines. I've written code that directly interacted with a form once in the past year, and that was to pick a report and its options for a purely admin-side gadget. All the front-end stuff was typical front-end: heavily designed by dedicated UX people, implemented by UI people, interfaced by front-end programmers. The business logic / back-end programmers don't even see that stuff.

I'm not convinced we want to revisit 4GL, which was epically flawed and still is.

I think we want more powerful 3GL. We're doing an awful lot of building houses out of toothpicks, but that doesn't mean we need prefab 4GL walls. It maybe means we need 3GL 2x4s and breezeblocks.

The GP languages we have can't do that, they weren't designed for it. I quoted 4GL not as an end in itself, but as an example of shorter, safer, higher. I have no particular interest in generating forms (although I think your experience is probably not typical). I care about languages that are tools for others to use to create programs. We have precious few of those.

We have a lot of those. Perhaps what you mean is you care about languages that are tools for non programmers to create programs?

Not at this point. I care about tools created by tool creators to be used by tool users. A lumberjack is an expert in felling trees, but someone has to make axes. I am a tool maker, my customers are programmers who use my tools. What language tool should I make for them to achieve shorter, safer, higher?

From a programmer point of view, I find your interpretation of "shorter, safer, and higher abstraction" rather curious, particularly using a 4GL to illustrate it.

"Shorter" seems least controversial, but it won't be shorter once your requirements deviate from the limited things the 4GL (or whatever) is pre-specified to do and you have to integrate some 3GL or otherwise work around the inevitable limitations of the 4GL. (And you will.)

Why? Because we don't know how to build tools to solve that problem.

It's only "safer" in the sense that it's not really a programming language (even if it's inside one); it's (invoking) predefined functionality that is effectively checkboxed from the available choices by being written down in a text file. That's safety by restriction rather than safety by nature. And, again, it's only "safer" until you starting writing the inevitable workarounds to achieve required functionality that hasn't been pre-specified, and then it's typically less safe than if you had done it all in a strong 3GL.

Again why? Every language creates data structures and every data structure is filling in checkboxes. How do we add new checkboxes as the need arises?

Finally, your interpretation of "abstraction" is odd. Compared to the current popular programming languages, higher levels of abstraction are (for example) declarative programming, pattern-matching (-based dispatch), meta-programming, generative programming, inferential systems, constraint-based programming, etc., and are always in comparison to lower levels. Prewritten libraries for specific uses such as forms are typically not abstractions in the programming sense, they're simply someone else writing some non-abstract code for you.

Notably, levels of abstraction are hierarchical, the way "shape" is an abstraction of "cube", "cube" is an abstraction of "building", "building" is an abstraction of "house", etc. What you're describing is not higher level abstraction but predefinition. E.g., what is "form" an abstraction of? (If you're thinking "a bunch of fields", that's composition rather than abstraction.)

I think you're quibbling over a choice of words. An older 3GL language let me think about strings, a newer one lets me think about collections of strings, now I want to think about documents or pages or forms. I know there will be bits and bytes all the way down to the metal, but I want languages that aim 'higher', however you define it. I know exactly what a regex can do, and I hate deeply the mental gymnastics I have go through to do it. I routinely do simple file system tasks well within the capabilities of Windows cmd, Powershell or bash and I routinely fail to get them right first time. I have a bunch of CSV files that comprise a data model, and there is hours of work before I can get the data to the point I can do SQL queries on it. None of these problems are handled by 3GLs per se, but all of them could be handled by tools implemented in a 3GL. We're not good enough at crating those tools.

That said, I agree wholeheartedly that shorter, safer, and higher abstraction are laudable goals.

Only, they need to be entirely in the 3GL domain. Thus:

"Safer" means as much possible checked before execution and/or handled at runtime via inescapably obligatory code.

"Higher abstraction" and "shorter" together mean expressive, powerful, reusable constructs that can be composed to form new constructs, and those constructs composed to form new constructs, and so on ad infinitum.

The value of such a language would be demonstrated by its universality. It should be equally good at constructing a DBMS or a new end-user business application, though it might mean you need to create the DBMS functionality first. You shouldn't need (or want!) to change language to do it, though.

If the language can only effectively specify some subset of possible end-user business applications, then it's certainly a valid domain-specific language, but to me that seems like more of a tickbox exercise in feature inclusion than an interesting pursuit of new and perhaps innovative general-purpose language design.

Again, this completes misses the key distinction between the roles of tool creator and tool user. The 4GL is a tool created for people with business needs who think they're programmers by people who really are programmers but find business stuff boring. You are an oddity: academic, compiler writer, but also application programmer, so perhaps you don't see this. In my experience only 1 in 10 programmers can write tools, and the other 9 really don't want to. The 1 in 10 really want all the stuff you've been banging on about, but the other 9 just want to churn out working code with the least possible effort. You won't solve this problem by designing esoteric languages exclusively for the high fliers: you need ways to let them efficiently build tools for everyone else. That's what a 4GL really is (or might have been): a way to divide tool builders from tool users.

But maybe that should be a different thread?

 

Quote from Dave Voorhis on March 14, 2021, 2:56 pm

Quote from dandl on March 14, 2021, 9:56 am

Quote from Dave Voorhis on March 13, 2021, 4:53 pm

Quote from dandl on March 13, 2021, 1:35 pm

Why the question mark after Java?

It has generics and lambdas.

I do wish C# fans (it's always C# fans) -- and I'm not singling you out here; I see this elsewhere -- would stop comparing a 2002 release of Java (deprecatory claims are usually based on Java 1.4; we're on Java 15 now with version 16 out in a week or two) to current C#.

If there are comparisons and criticisms to be made, let them be around current features, like whether or not C# properties are a benefit or a code smell or not, or a comparison of Java records to C# tuples, or the whether Java's type erasure semantics are an obstacle or not, etc.

The simple reason is that C# programmers know C# is better, but Java programmers think Java is just as good. My experience with Java is around 2 years old, so 12 or 13, plus a peek at 14. I've been using it since 1995 or so, but C# has always been ahead since 2.0 or so. IMO the language suffered badly at the hands of Sun through that period, and while C# has plenty of cruft from the pre 3.0 days, Java has way more cruft. The main things that irritated me (still) were int/Integer, array/list and not-quite-generics, but there were others. Enums are bad in both, so not really a contest there. But that really isn't the point...

Compared to higher level languages, C# and Java are indistinguishable -- effectively varying only in syntactic sugar.

They're close, but I would argue the C# program is likely to be shorter, so C# is higher level on that metric.

APL is highest of all, so I'm not sure that metric means much.

Compared to each other, there are unquestionably some useful features in C# that aren't found in Java. But for whatever reason, C# seems to attract marginal programmers to a far greater degree than Java. The result is that typical production Java code is readable and maintainable whilst typical production C# code is abominable, usually a mix of developers attempting to demonstrate capability in every C# feature plus forced adherence to what I can only assume are C# / .NET / Microsoft "best practices" (because I've seen them appear identically in multiple, unrelated places -- and by the way, I use the term "best" very loosely here) that result in unreadable, un-maintainably labyrinthine complexity, brittleness, awkwardness, and sometimes operational slowness.

I've found that rewriting such ghastliness to make it simple, straightforward, readable and maintainable is almost always beneficial. Notably, the resulting code is invariably almost indistinguishable from Java code to accomplish the same thing. It seems the useful features found in C# but not in Java don't add much in (good) practice.

Not my experience at all. Must be the company you keep.

Perhaps. But it does seem to be the case in far too many unrelated circumstances. The only commonality is C#.

Back in the VB heydey, it used to be notable the degree to which MSDN VB examples would be awful. I think that's carried over to .NET and is having an unpleasant influence.

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

<snip>

Heavens. 1987 called and wants its UI definition language back.

Certainly not. The point of this is to illustrate those 3 features: shorter, safer, higher.

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

Why ever would that be a good idea? Those are the assembly languages of the modern browser, not even one step up from rock bottom. Horrible.

I've seen it done effectively. The UX/UI people produce the front-end using the tools they know (HTML/CSS or whatever design tool emits it) to produce the look-and-feel they want, and the coding tool slurps up all the form field definitions and fill-in-able HTML elements (of some class, I guess? I didn't look) and makes them available to the code.

The UX/UI folks aren't forced to learn new stuff to implement designs or be relegated to using wireframes or creating non-production HTML/CSS, and the programmers aren't forced to laboriously re-implement designs in HTML/CSS/code provided by UX/UI folks who have been relegated to using wireframe tools because they can't write production HTML/CSS.

Of course, it presumes the goal is custom UI/UX designs for end-user Web sites. If it's only manual data entry that matters and look-and-feel isn't a concern, then any form painting / coding tool will do.

None of this has anything whatever to do with the issue of 'Life after D'. The mere fact that you even raise those as issues of concern says we're a long way off a solution.

Yes, use tools to make visual imagery that looks as desired, but no, never look at the save file format. Do you routinely read the SVG emitted by Inkscape or the FBX emitted by Autodesk tools or the PS emitted by Adobe? Of course not!We assume a save file form for UI/UX tools and a save file format for data model design, and we don't poke around inside: those are just UI objects and dataset objects. The question is what language we use to manipulate those objects. And the aim is: sweet spot at 100 lines of code, but absolutely no program over 300 LOC.

Sorry, you've lost me here. We must be talking past each other.

I work in this business area, and I'm watching as UI forms in application code are becoming almost extinct. There are still some forms at point-of-sale/point-of-business and for entering options, but everything else is moving to automated data pipelines. I've written code that directly interacted with a form once in the past year, and that was to pick a report and its options for a purely admin-side gadget. All the front-end stuff was typical front-end: heavily designed by dedicated UX people, implemented by UI people, interfaced by front-end programmers. The business logic / back-end programmers don't even see that stuff.

I'm not convinced we want to revisit 4GL, which was epically flawed and still is.

I think we want more powerful 3GL. We're doing an awful lot of building houses out of toothpicks, but that doesn't mean we need prefab 4GL walls. It maybe means we need 3GL 2x4s and breezeblocks.

The GP languages we have can't do that, they weren't designed for it. I quoted 4GL not as an end in itself, but as an example of shorter, safer, higher. I have no particular interest in generating forms (although I think your experience is probably not typical). I care about languages that are tools for others to use to create programs. We have precious few of those.

We have a lot of those. Perhaps what you mean is you care about languages that are tools for non programmers to create programs?

Not at this point. I care about tools created by tool creators to be used by tool users. A lumberjack is an expert in felling trees, but someone has to make axes. I am a tool maker, my customers are programmers who use my tools. What language tool should I make for them to achieve shorter, safer, higher?

If it's the pseudo-technical programmers I work with, it's probably a nice library -- or set of libraries -- for Python.

Of course, there's a possibility here that your pseudo-technical programmers are very different from mine. I am reminded of the parable of the blind men and an elephant here, and I'm aware that despite working in notionally the same field, our experience of it could be almost completely different. It only takes a few distinct client niches to create a wholly different experience of what typical IT is, and what its developers do, expect, want, need, or use.

From a programmer point of view, I find your interpretation of "shorter, safer, and higher abstraction" rather curious, particularly using a 4GL to illustrate it.

"Shorter" seems least controversial, but it won't be shorter once your requirements deviate from the limited things the 4GL (or whatever) is pre-specified to do and you have to integrate some 3GL or otherwise work around the inevitable limitations of the 4GL. (And you will.)

Why? Because we don't know how to build tools to solve that problem.

It's only "safer" in the sense that it's not really a programming language (even if it's inside one); it's (invoking) predefined functionality that is effectively checkboxed from the available choices by being written down in a text file. That's safety by restriction rather than safety by nature. And, again, it's only "safer" until you starting writing the inevitable workarounds to achieve required functionality that hasn't been pre-specified, and then it's typically less safe than if you had done it all in a strong 3GL.

Again why? Every language creates data structures and every data structure is filling in checkboxes. How do we add new checkboxes as the need arises?

That's where the strong 3GL comes in.

Finally, your interpretation of "abstraction" is odd. Compared to the current popular programming languages, higher levels of abstraction are (for example) declarative programming, pattern-matching (-based dispatch), meta-programming, generative programming, inferential systems, constraint-based programming, etc., and are always in comparison to lower levels. Prewritten libraries for specific uses such as forms are typically not abstractions in the programming sense, they're simply someone else writing some non-abstract code for you.

Notably, levels of abstraction are hierarchical, the way "shape" is an abstraction of "cube", "cube" is an abstraction of "building", "building" is an abstraction of "house", etc. What you're describing is not higher level abstraction but predefinition. E.g., what is "form" an abstraction of? (If you're thinking "a bunch of fields", that's composition rather than abstraction.)

I think you're quibbling over a choice of words. An older 3GL language let me think about strings, a newer one lets me think about collections of strings, now I want to think about documents or pages or forms. I know there will be bits and bytes all the way down to the metal, but I want languages that aim 'higher', however you define it.

Is it really a language you want?

Or better/suitable pre-built libraries for the languages you've got?

I know exactly what a regex can do, and I hate deeply the mental gymnastics I have go through to do it. I routinely do simple file system tasks well within the capabilities of Windows cmd, Powershell or bash and I routinely fail to get them right first time. I have a bunch of CSV files that comprise a data model, and there is hours of work before I can get the data to the point I can do SQL queries on it. None of these problems are handled by 3GLs per se, but all of them could be handled by tools implemented in a 3GL. We're not good enough at crating those tools.

Are you sure it's not simply that you are slow at using the tools we already have?

I don't mean that as an insult or deprecation, simply that your strengths -- and experience, and practice -- lie elsewhere. Nikki, my other half, can wire up Excel spreadsheets to do complex data crunching things in seconds and has whole infrastructure built in minutes and connected to external data stores whilst I'm still trying to figure out how to format a number in cell A1.

I watched a demo a month ago by a colleague using Python and Pandas and Jupyter, and in four minutes (time-constrained demo sessions) he shlorped up data from some a weather Web site, did some nifty stats on it, and created a dynamic graph of the data.

Of course, they do that sort of thing all day, so they're quick at it. I can do something distantly similar with Rel for crunching through tabular data in CSV files and spreadsheets, but I wouldn't expect anyone else to do it (except Hugh.)

Likewise for other people and other tools.

But the key ingredient in every case is a lot of practice. If you're expecting some tool to suit your preconceptions so you can be immediately not just productive, but fast, with no prior practice, you may be looking for a chimera unless you create it all (perhaps including the underlying language) yourself.

That said, I agree wholeheartedly that shorter, safer, and higher abstraction are laudable goals.

Only, they need to be entirely in the 3GL domain. Thus:

"Safer" means as much possible checked before execution and/or handled at runtime via inescapably obligatory code.

"Higher abstraction" and "shorter" together mean expressive, powerful, reusable constructs that can be composed to form new constructs, and those constructs composed to form new constructs, and so on ad infinitum.

The value of such a language would be demonstrated by its universality. It should be equally good at constructing a DBMS or a new end-user business application, though it might mean you need to create the DBMS functionality first. You shouldn't need (or want!) to change language to do it, though.

If the language can only effectively specify some subset of possible end-user business applications, then it's certainly a valid domain-specific language, but to me that seems like more of a tickbox exercise in feature inclusion than an interesting pursuit of new and perhaps innovative general-purpose language design.

Again, this completes misses the key distinction between the roles of tool creator and tool user. The 4GL is a tool created for people with business needs who think they're programmers by people who really are programmers but find business stuff boring. You are an oddity: academic, compiler writer, but also application programmer, so perhaps you don't see this. In my experience only 1 in 10 programmers can write tools, and the other 9 really don't want to. The 1 in 10 really want all the stuff you've been banging on about, but the other 9 just want to churn out working code with the least possible effort. You won't solve this problem by designing esoteric languages exclusively for the high fliers: you need ways to let them efficiently build tools for everyone else. That's what a 4GL really is (or might have been): a way to divide tool builders from tool users.

I don't think I'm describing anything esoteric. I was actually thinking more along the lines of a better Python (in concept, not necessarily in syntax), but with greater ease and safety, and friendly access to higher-order capability and abstraction. If we were just going for esoteric, high-flying purity, we'd just pick Haskell or OCaml or whatever and be done with it.

But I'm thinking general-purpose abstraction rather than domain-specific predefinition. Specificity should be a feature of libraries written using the language, not features wired into the language.

Wiring features into languages is where 4GLs went wrong, and where they are still wrong. 4GLs invariably reflect a certain arrogance on the part of the 4GL vendor, that its users will only ever want to do things the way the 4GL wants them done. In reality, that almost invariably flies against what the developer wants to do -- even for developers who have not the slightest interest in anything but solving business problems.

That's why 4GLs are all but gone, 3GLs are pervasive, and everyone and their dog thinks learning Python is worthwhile.

Quote from tobega on March 15, 2021, 4:20 pm

How is html even remotely like being "the assembly language of the web"? It's a declarative description of a web page (and increasingly even desktop and mobile app user interfaces). If you want the dumbest data app possible, you could use the html form as a specification and generate everything else.

<form>

<label for="No">No</label><input type="number" name="No" required>

<label for="Surname">Surname</label><input name="Surname" required>

<label for="Given names">Given names</label><input name="Given names" required>

<label for="Dob">Date of birth</label><input type="date" name="Dob" required>

<label for="Sex">Sex</label><input name="Sex" pattern="[FMO]" required>

<label for="Rating">Rating</label><input type="number" name="Rating" min="1000" max="3000" value="1300" required>

<label for="Joined">Joined</label><input type="date" required>

<label for="Email">Email</label><input type="email">

<label for="Tel">Telephone</label><input type="tel" pattern="0\d{1,3}-(\d|\s){5,8}">

</form>

Even non-coders tend to enjoy playing a little with html as they can see the results immediately and it is very forgiving. I'm not even sure a GUI editor would be much simpler. Added bonus of having accessibility pretty much built in if you stick to semantic elements and don't try to pixel-adjust things.

I believe anybody doing any kind of coding would never want to learn yet another language instead of just doing html.

So that's that squared away, now about the post-SQL, post-D way of querying, aggregating and analyzing data:

• Obviously it will be coupled to some html templating mechanism to present the output, with a sensible default if no template is given.
• The results should be possible to process by general programming constructs, as needed, both during and after the query.
• Let's also say that simple queries should be dead simple and declarative.

But what would the language look like? Can we integrate something Datalog-like to produce streams of values without turning the whole language into Datalog?

Quote from dandl on March 16, 2021, 12:20 am

APL is highest of all, so I'm not sure that metric means much.

I subscribe to the principle: that every major programming project generates its own language, usually a bad one. Otherwise known as LYHINLYN: the language you have is not the language you need (to solve this problem). So first design the TLYN, implement that using TLYH, then solve the problem in your new language. I read that somewhere, but I have no idea where and I can't find it.

Lisp subscribes heavily to that principle. Alan Kay said: "Lisp is a building material, not a programming language".

What I'm on about is separating tool building from tool use: making it way easier to create, maintain and extend the LYN. APL is a super example of the LYN for writing certain kinds of mathematical expressions, hampered by some awkward choices of symbols. We should be able to create a 'New APL' easily to replace it, but we can't. Ditto for 4GLs, like dBase and Powerflex.

IMO 4GL was too early, it was solving the wrong problem for the time, the priority was 3GL. But the whole 3GL thing is now good enough, there is nothing important to do, just tweaks. It's time to go back and do 4GL again: less is more.

• shorter: less lines of code (to do common repetitive programming)
• safer: less room for bugs
• higher abstraction: higher level programmable objects (forms, datasets, collections, not glorified machine words, values, pointers)

<snip>

Heavens. 1987 called and wants its UI definition language back.

Certainly not. The point of this is to illustrate those 3 features: shorter, safer, higher.

I think a more modern approach would be to define the interface in HTML/CSS, and have a tool that parses out the forms so you can use them from code.

Why ever would that be a good idea? Those are the assembly languages of the modern browser, not even one step up from rock bottom. Horrible.

I've seen it done effectively. The UX/UI people produce the front-end using the tools they know (HTML/CSS or whatever design tool emits it) to produce the look-and-feel they want, and the coding tool slurps up all the form field definitions and fill-in-able HTML elements (of some class, I guess? I didn't look) and makes them available to the code.

The UX/UI folks aren't forced to learn new stuff to implement designs or be relegated to using wireframes or creating non-production HTML/CSS, and the programmers aren't forced to laboriously re-implement designs in HTML/CSS/code provided by UX/UI folks who have been relegated to using wireframe tools because they can't write production HTML/CSS.

Of course, it presumes the goal is custom UI/UX designs for end-user Web sites. If it's only manual data entry that matters and look-and-feel isn't a concern, then any form painting / coding tool will do.

None of this has anything whatever to do with the issue of 'Life after D'. The mere fact that you even raise those as issues of concern says we're a long way off a solution.

Yes, use tools to make visual imagery that looks as desired, but no, never look at the save file format. Do you routinely read the SVG emitted by Inkscape or the FBX emitted by Autodesk tools or the PS emitted by Adobe? Of course not!We assume a save file form for UI/UX tools and a save file format for data model design, and we don't poke around inside: those are just UI objects and dataset objects. The question is what language we use to manipulate those objects. And the aim is: sweet spot at 100 lines of code, but absolutely no program over 300 LOC.

Sorry, you've lost me here. We must be talking past each other.

I mean:

• Use visual tools to create visual imagery (the saved file format is something standardised and interoperable)
• Use programming languages to manipulate those visual images as opaque objects.

Not at this point. I care about tools created by tool creators to be used by tool users. A lumberjack is an expert in felling trees, but someone has to make axes. I am a tool maker, my customers are programmers who use my tools. What language tool should I make for them to achieve shorter, safer, higher?

If it's the pseudo-technical programmers I work with, it's probably a nice library -- or set of libraries -- for Python.

Of course, there's a possibility here that your pseudo-technical programmers are very different from mine. I am reminded of the parable of the blind men and an elephant here, and I'm aware that despite working in notionally the same field, our experience of it could be almost completely different. It only takes a few distinct client niches to create a wholly different experience of what typical IT is, and what its developers do, expect, want, need, or use.

Yes, the main (if not the only) 'shorter-safer-higher' we have right now is the library of classes and functions, but that still leaves the accidental complexity of the programming task fully exposed. Have you written any C++ lately? We talk about code reuse, components and modules but that's really hard to do with the tools we have. But that still leaves the use of the tool in the same language used to create the tool, and that's a mistake: the language is complex, powerful and unsafe in the wrong hands. That's taking the fully-equipped machine shop everywhere when all you want to do is change a light bulb or hand a picture.

So I'm advocating languages that can expose a controlled subset as a new LYN. If you take my 4GL as an example, you can expose a LYN that does that data entry task in the same few lines of code. Once you discover a need for a feature not included, the LYN manager extends the language by exposing features as needed.

Again why? Every language creates data structures and every data structure is filling in checkboxes. How do we add new checkboxes as the need arises?

That's where the strong 3GL comes in.

Only if it's used to build the LYN.

Finally, your interpretation of "abstraction" is odd. Compared to the current popular programming languages, higher levels of abstraction are (for example) declarative programming, pattern-matching (-based dispatch), meta-programming, generative programming, inferential systems, constraint-based programming, etc., and are always in comparison to lower levels. Prewritten libraries for specific uses such as forms are typically not abstractions in the programming sense, they're simply someone else writing some non-abstract code for you.

Notably, levels of abstraction are hierarchical, the way "shape" is an abstraction of "cube", "cube" is an abstraction of "building", "building" is an abstraction of "house", etc. What you're describing is not higher level abstraction but predefinition. E.g., what is "form" an abstraction of? (If you're thinking "a bunch of fields", that's composition rather than abstraction.)

I think you're quibbling over a choice of words. An older 3GL language let me think about strings, a newer one lets me think about collections of strings, now I want to think about documents or pages or forms. I know there will be bits and bytes all the way down to the metal, but I want languages that aim 'higher', however you define it.

Is it really a language you want?

Or better/suitable pre-built libraries for the languages you've got?

No, not libraries as now. The LYN has no accidental complexity: every line of code is there to do a job that is part of the end result, not dictated by the programming environment.

I know exactly what a regex can do, and I hate deeply the mental gymnastics I have go through to do it. I routinely do simple file system tasks well within the capabilities of Windows cmd, Powershell or bash and I routinely fail to get them right first time. I have a bunch of CSV files that comprise a data model, and there is hours of work before I can get the data to the point I can do SQL queries on it. None of these problems are handled by 3GLs per se, but all of them could be handled by tools implemented in a 3GL. We're not good enough at crating those tools.

Are you sure it's not simply that you are slow at using the tools we already have?

Of course I am, because the tools are crap: the knowledge load is too high, I can't know everything. The LYN I need is one to solve basic regex but I have to use the whole machine shop to do the job.

I don't mean that as an insult or deprecation, simply that your strengths -- and experience, and practice -- lie elsewhere. Nikki, my other half, can wire up Excel spreadsheets to do complex data crunching things in seconds and has whole infrastructure built in minutes and connected to external data stores whilst I'm still trying to figure out how to format a number in cell A1.

So the LYN for that job would capture her knowledge and let you (and me) perform at that same level.

I watched a demo a month ago by a colleague using Python and Pandas and Jupyter, and in four minutes (time-constrained demo sessions) he shlorped up data from some a weather Web site, did some nifty stats on it, and created a dynamic graph of the data.

I've done all those things and yes, that's a perfectly credible start of a LYN (although I did resent how long it took to install Jupyter).

Of course, they do that sort of thing all day, so they're quick at it. I can do something distantly similar with Rel for crunching through tabular data in CSV files and spreadsheets, but I wouldn't expect anyone else to do it (except Hugh.)

Likewise for other people and other tools.

But the key ingredient in every case is a lot of practice. If you're expecting some tool to suit your preconceptions so you can be immediately not just productive, but fast, with no prior practice, you may be looking for a chimera unless you create it all (perhaps including the underlying language) yourself.

No, I specifically want language tools that allow expert knowledge to be captured and exposed as the LYN for simpler folk to use. The 3GLs we have are enough (give or take a few tweaks), for the users who put in the 10,000 hours of practice, but the tools we have for creating a new LYN are poor. That's where I think the focus should be.

Again, this completes misses the key distinction between the roles of tool creator and tool user. The 4GL is a tool created for people with business needs who think they're programmers by people who really are programmers but find business stuff boring. You are an oddity: academic, compiler writer, but also application programmer, so perhaps you don't see this. In my experience only 1 in 10 programmers can write tools, and the other 9 really don't want to. The 1 in 10 really want all the stuff you've been banging on about, but the other 9 just want to churn out working code with the least possible effort. You won't solve this problem by designing esoteric languages exclusively for the high fliers: you need ways to let them efficiently build tools for everyone else. That's what a 4GL really is (or might have been): a way to divide tool builders from tool users.

I don't think I'm describing anything esoteric. I was actually thinking more along the lines of a better Python (in concept, not necessarily in syntax), but with greater ease and safety, and friendly access to higher-order capability and abstraction. If we were just going for esoteric, high-flying purity, we'd just pick Haskell or OCaml or whatever and be done with it.

But I'm thinking general-purpose abstraction rather than domain-specific predefinition. Specificity should be a feature of libraries written using the language, not features wired into the language.

Wiring features into languages is where 4GLs went wrong, and where they are still wrong. 4GLs invariably reflect a certain arrogance on the part of the 4GL vendor, that its users will only ever want to do things the way the 4GL wants them done. In reality, that almost invariably flies against what the developer wants to do -- even for developers who have not the slightest interest in anything but solving business problems.

That's why 4GLs are all but gone, 3GLs are pervasive, and everyone and their dog thinks learning Python is worthwhile.

You're getting closer. Python is still a crap language, but it makes great glue. Still way too much accidental complexity, but it's a step in the right direction.

Yes, 4GLs phase 1 are gone, but that was just a warmup. My LYN:

• has zero accidental complexity
• fully expresses the things that need to be done for business purpose
• is maintainable and extensible as needed
• maps readily unto the underlying 3GL(s)
• achieves shorter, safer, higher.

Isn't that just a 'new' 4GL by another name?

 

Quote from dandl on March 16, 2021, 9:59 am

Quote from tobega on March 15, 2021, 4:20 pm

How is html even remotely like being "the assembly language of the web"? It's a declarative description of a web page (and increasingly even desktop and mobile app user interfaces). If you want the dumbest data app possible, you could use the html form as a specification and generate everything else.

I know what it is: the lowest possible level description of a browser page, in a form directly interpreted by the browser and from which the DOM is built. Likewise, CSS is the lowest possible description of choices the browser can make in rendering HTML pages, and JS is the lowest possible level description of logic the browser can execute to manipulate the DOM.

These are like protocols or serialisation formats: designed to be rigorously specified for communicating between programs running in different locations or at different times. By contrast a programming language is one designed for the convenience of programmers, in the expectation of an intermediate step (compilation) before being used by the machine. HTML was never designed to be written by humans, and the sooner we hide it inside something else the better.

Even non-coders tend to enjoy playing a little with html as they can see the results immediately and it is very forgiving. I'm not even sure a GUI editor would be much simpler. Added bonus of having accessibility pretty much built in if you stick to semantic elements and don't try to pixel-adjust things.

Indeed. But hopefully they get over it.

I believe anybody doing any kind of coding would never want to learn yet another language instead of just doing html.

You just met one. I have written many things for the Web, but I haven't written HTML for many years and hopefully never will again. Fragments of JSX if I have to, but this too shall pass.

So that's that squared away, now about the post-SQL, post-D way of querying, aggregating and analyzing data:

• Obviously it will be coupled to some html templating mechanism to present the output, with a sensible default if no template is given.

No, it won't.

• The results should be possible to process by general programming constructs, as needed, both during and after the query.

This is too vague to comment on.

• Let's also say that simple queries should be dead simple and declarative.

Of course: shorter, safer, higher.

But what would the language look like? Can we integrate something Datalog-like to produce streams of values without turning the whole language into Datalog?

Best not. Datalog is chock full of accidental complexity, and desperately in need of the same approach I outline elsewhere.

 

Quote from tobega on March 16, 2021, 12:27 pm

Quote from dandl on March 16, 2021, 9:59 am

Quote from tobega on March 15, 2021, 4:20 pm

How is html even remotely like being "the assembly language of the web"? It's a declarative description of a web page (and increasingly even desktop and mobile app user interfaces). If you want the dumbest data app possible, you could use the html form as a specification and generate everything else.

I know what it is: the lowest possible level description of a browser page, in a form directly interpreted by the browser and from which the DOM is built. Likewise, CSS is the lowest possible description of choices the browser can make in rendering HTML pages, and JS is the lowest possible level description of logic the browser can execute to manipulate the DOM.

These are like protocols or serialisation formats: designed to be rigorously specified for communicating between programs running in different locations or at different times. By contrast a programming language is one designed for the convenience of programmers, in the expectation of an intermediate step (compilation) before being used by the machine. HTML was never designed to be written by humans, and the sooner we hide it inside something else the better.

Twaddle. You will be hard pressed to express this clearer and more compactly.

Even non-coders tend to enjoy playing a little with html as they can see the results immediately and it is very forgiving. I'm not even sure a GUI editor would be much simpler. Added bonus of having accessibility pretty much built in if you stick to semantic elements and don't try to pixel-adjust things.

Indeed. But hopefully they get over it.

I believe anybody doing any kind of coding would never want to learn yet another language instead of just doing html.

You just met one. I have written many things for the Web, but I haven't written HTML for many years and hopefully never will again. Fragments of JSX if I have to, but this too shall pass.

Edited (misread first): For some strange reason many devs seem to incorrectly prefer javascript over html. Just write the html and don't write so much code. Interestingly you are now advocating a strictly inferior and more low-level approach entrenched in a 3G language, contrary to what you seem to be doing otherwise.

Anyway, I thought the premise was to provide for non-programmers? They actually like html.

So that's that squared away, now about the post-SQL, post-D way of querying, aggregating and analyzing data:

• Obviously it will be coupled to some html templating mechanism to present the output, with a sensible default if no template is given.

No, it won't.

• The results should be possible to process by general programming constructs, as needed, both during and after the query.

This is too vague to comment on.

• Let's also say that simple queries should be dead simple and declarative.

Of course: shorter, safer, higher.

But what would the language look like? Can we integrate something Datalog-like to produce streams of values without turning the whole language into Datalog?

Best not. Datalog is chock full of accidental complexity, and desperately in need of the same approach I outline elsewhere.

 

Query by example is perhaps more what I was aiming for. Pretty much the same as "calling" a datalog rule. (Addendum: Come to think of it, defining a Datalog rule is pretty much like defining your "while" thing. Datalog is not Turing complete, so it is more of a "safe" language as you were aspiring to. Still might be designed differently, perhaps)

Go ahead, build your approach, then we may be struck by your genius. So far I can't follow.