Quote from dandl on February 5, 2021, 10:34 am

Quote from Dave Voorhis on February 5, 2021, 9:26 am

Quote from dandl on February 5, 2021, 8:18 am

... In the model I showed there is a Data/View separation for exactly that purpose. This kind of requirement has a regularity to it that can be captured. But I do not propose to include business rules: they are algorithmic in nature and best expressed in code. I do propose 3 sub-languages:

• Regex for validation
• Format strings for display
• Expression evaluation, both for validation and for calculated fields.

Looks more and more like MS Access, it does.

I imagine the Access folks must have reached a point in their "Expression evaluation, both for validation and for calculated fields" implementation where they said, "Screw it, this is turning into a full-fledged language. Let's just plug in Visual Basic."

Not even close. A programming language is Turing Complete: it has state and control flow, which are here specifically excluded. These are a close match to the features in SQL, but for use in the client data model.

Quote from Dave Voorhis on February 5, 2021, 12:03 pm

Quote from AntC on February 5, 2021, 1:01 am

Quote from Dave Voorhis on February 4, 2021, 6:47 pm

Quote from AntC on February 4, 2021, 9:59 am

Quote from Dave Voorhis on February 2, 2021, 10:11 am

Quote from dandl on February 2, 2021, 5:49 am

Quote from Dave Voorhis on February 1, 2021, 1:38 pm

Quote from dandl on February 1, 2021, 1:31 pm

 

SQL is not a programming language. It is arguably a specification for a data structure that will be interpreted by the RDBMS query optimiser and query executor. It has an embedded expression evaluator, but the rest is just data.

Xml, JSON and Yaml are not programming languages. Each is a language for specifying structured data.

Exactly the problem.

We've arbitrarily divided languages into "not programming language" / "data language" vs "programming language",

"We"? I think the division is in the nature of the subject: data is persistent, and has persistent structure, because it represents state/some facts in some mini-world. The data only maps to the state/facts on condition its content fits the structure. The program is ephemeral; it doesn't 'know' anything about the state except by reading the data. Separating the data with its structure has the side-benefit that different tools/different programming languages can all access it.

when we should have listened to the LISP (and Forth, and later, Haskell and other)

I'm confused why highlight those languages? (and which others?) Why not include other GP HLLs already mentioned like Java, or classic C, Fortran, COBOL (which was reasonably data-aware)? Where does Tutorial D go? Or Ds in general?

LISP is notable for homoiconicity. Forth is notable for extensibility (and being weird, but beside the point.) Haskell is notable for functional purity and type rigour.

All highlight how overarchingly powerful programming can be.

Hmm. Until I see a relational schema expressed in Haskell, I don't see enough power or the right sort of power. What could be simpler than set theory?

I think the discussion here may have deviated from the original topic, at least as I remember it.

My point was simply that if there is a compulsion to create a new sublanguage somewhere, for whatever purpose, don't. Don't create a new sublanguage!

Or, at least wait to create a new sublanguage. See if you can create an API for the host language instead.

In short, give me more APIs and fewer new sublanguages.

Otherwise, we likely go through an undesirable language evolution cycle -- from too simple, to too complex, to a simple scripting language, to a full programming language -- that we too often see.  A good example is the history of automating builds and resolving build dependencies for Java projects:

1. Java projects get big. Developers get frustrated as big project dependencies grow unmanageable.
2. Industry standardises on the Maven build automation tool, which uses XML configuration files to specify project dependencies.
3. Maven configurations get big. Developers get frustrated as Maven configuration files grow unmanageable.
4. Industry promotes Gradle build automation tool as a Maven alternative, because it uses Groovy files to specify project dependencies and build operations. Groovy is a Turing-Complete, dynamically typed scripting language for the JVM.
5. Gradle Groovy scripts get big. Developers get frustrated as Gradle Groovy scripts grow unmanageable.
6. Gradle introduces writing Kotlin programs as an alternative to using Groovy scripts. Kotlin provides static typing in a better-than-Java JVM language.

So we've gone from using non-programmable XML files to writing programs in something more powerful than Java, just to manage Java dependencies and builds. (Though to be fair, you can use Gradle to build Kotlin and Groovy and probably other JVM language projects too.)

That's a typical progression: start with a light and non-programmable language; eventually wind up with a fully programmable language as powerful as (or more than!) the host language. Maybe we should have just created an API (for whatever task) in the host language and used it to begin with?

My examples of LISP, etc., were meant to allude to the fact that at least in the LISP world there's a tendency to avoid this cycle. When you feel the urge to create a non-LISP sublanguage for use by or with your LISP applications, you don't. You just write more LISP, thus gaining the capability you need without losing any of the capability of LISP, because sooner or later you're going to want it.

 Diminish programming and replace it with static configuration or single-purpose declaration, and you lose power.

C, Fortran, COBOL and their modern successors -- C++, Java, C#, Python, Ruby, PHP, etc. -- are fine for what they are, but none are particularly powerful, expressive, elegant, or extensible. Smalltalk simultaneously shows how that category of language should be handled (pure OO) and shouldn't be handled (dynamically typed and -- typically -- an isolated sandbox, and not in a good way.)

I like Tutorial D, of course, but I don't ascribe any special elegance or power to Tutorial D as a language. I like Java and C#, too, and they're not special either.

folks who went down this path before us and realised -- or knew to begin with -- that every non-programmable language is a lesser thing than an equivalent programming language. Thus, LISPers don't use (for example) a separate data or configuration language, they use LISP.

I wasn't aware LISP (or Scheme) is any sort of data language.

It is, but only rarely and usually within the LISP world itself. It's been pointed out (mainly among LISP fans, admittedly) that S-expressions are notionally isomorphic to XML, but completely and inherently potentially programmable (because LISP) out-of-the-box. Instead, we got XML and various XML languages, and we got... XML. Ugh.

I don't count XML as a data language, hence why I'm not seeing it in LISP either. XML is capable of expressing structured data; if some particular file/stream contains structured data, that only emerges when you've got to the end and haven't found anything that doesn't conform with the structure. But then HTML is capable of expressing structured data; ditto.

I think the issue here may be the definition of "data language."

I interpreted it as, to use your phrase, a language "capable of expressing structured data."

Haskell has extensive data-structuring declarations; but is just rubbish at accessing persistent/external data or transponding between its type-safe data structures and external media. Essentially everything has to be serialised as String. Type safety gone. Most applications' persistence layer is XML/JSON as a text file.

The two key features of The Relational Model: relations as sets; tuples as indexed sets (indexed by attribute names, which are metadata); and the key feature for data structuring viz. referential integrity -- just can't be represented in Haskell (nor LISP/Scheme/Forth AFAIA).

They extend the base language, rather than trying to generate it or replace it, which only creates a rigidity, inflexibility, and impedance mismatch between the host language and the sublanguage.

The Haskell base language is lambda calculus plus sum-of-product positionally-indexed data structures. The main resource for extending is powerful polymorphism and overloading. No amount of extending that gets you to those RM key features.

True, and I'm not trying to suggest they're an ideal, only that programmability is fundamental and essential. Further non-programmable configuration/exchange/markup/whatever non-Turing-Complete languages -- and their inevitable impedance mismatches -- are not a step in the right direction.

You haven't persuaded me I can do without a DDL -- by which I mean of course a Truly Relational ® DDL.

I wasn't intending to suggest not using a DDL. I was intending to suggest that any custom DDL must be fully programmable.

Ideally, yes, it would be a Truly Relational ® DDL, but in the absence of that let it be SQL if you're otherwise inclined to have it replace SQL or let it be Java/C#/whatever if you're otherwise inclined to have it replace Java/C#/whatever. Again, don't give me a new language and make me start at the beginning of that inevitable first too simple, then too complex, then simple scripting, then full programming language cycle.

Instead, empower the languages I've already got with APIs and (where possible and as appropriate) better integration with other languages.

And the industry appears not to have an abstraction in any GP HLLs that can grok relational DDL and the content that conforms to it. We can rearrange the deckchairs, but an impedance mismatch seems inevitable.

 

... Again, I mentioned Haskell as an example of programming goodness, not an ideal.

What became of languages based on D.L.Childs' framework? Or perhaps we embed something Childs-like as a Domain-Specific Language inside a GP language? But still there's the impedance mismatch.

As I understand it, D L Childs's own implementations were Fortran APIs and later C APIs. I have only heard tell of standalone languages based on D L Childs's ideas; I have not seen them.

Of course, this brings us back to the inevitable issues with host languages and their inadequate type systems. My current approach is to work strictly within the constraints of the type system.

In other words, I will accept giving up the TTM notion of TUPLE {x INT, y CHAR} being the same type as TUPLE {y CHAR, x INT} -- and accept working with the host language forcing me to treat them (or their host language equivalents) as different types -- before I will give up strong static typing guarantees enforced by the host language.

Of course, that doesn't preclude using some host code generation to get back some good things, so I am using a wee bit of code generation. The trick, so far, seems to be making it into a friendly workflow.

Quote from Dave Voorhis on February 5, 2021, 12:26 pm

Quote from dandl on February 5, 2021, 10:30 am

Just a quick side note: it seems I am not alone. A quick web search for NoCode turned up heaps of products with the single claim: create apps without code. Maybe Dave is right and they're all wrong, but then they sure are burning heaps of money on finding out!

The predominant themes are: database, workflow, web sites and I'm sure some of them have point-and-click code-that-isn't-really code, but at least the demand and willingness to pay for product seem to be there. It's a good start.

Here is a selection (sorry about the formatting):

Name

Adalo

Airslate

Airtable

AllcountJS

Appsheet

Appy Pie

Betty Blocks

Bubble

Caspio

Clay

DronaHQ

FileMaker

Glide

Gumroad

IFTTT

Kintone

Knack

Mailer

Memberspace

Microsoft Flow

Nintex

Node-red

Outgrow

Parabola

Podio

Quickbase

Quixy

Retool

Stackby

Skyve

TrackVia

Transpose

Universe

Webflow

Zap with Zapier

Zengine

Zenkit

Zoho

Zudy

Yes, in fact these things lead to common questions about them -- and the category in general -- on Quora. See https://www.quora.com/Is-low-code-no-code-the-future-of-software-development/answer/Dave-Voorhis

I am sceptical, as they're been around for years making boasts, but not much impact. I first remember seeing their claims in a package for the Apple II in the late 1970s; they probably pre-date that with mainframe and mini products. They're been churning away in the background ever since. I used to occasionally run into them in the field, when in-house users had found insurmountable limitations and needed their no-code or low-code app rewritten in code.

I think it was yesterday that I mentioned Microsoft's foray into this -- PowerApps.

Quote from Dave Voorhis on February 5, 2021, 12:49 pm

Quote from dandl on February 5, 2021, 10:34 am

Quote from Dave Voorhis on February 5, 2021, 9:26 am

Quote from dandl on February 5, 2021, 8:18 am

... In the model I showed there is a Data/View separation for exactly that purpose. This kind of requirement has a regularity to it that can be captured. But I do not propose to include business rules: they are algorithmic in nature and best expressed in code. I do propose 3 sub-languages:

• Regex for validation
• Format strings for display
• Expression evaluation, both for validation and for calculated fields.

Looks more and more like MS Access, it does.

I imagine the Access folks must have reached a point in their "Expression evaluation, both for validation and for calculated fields" implementation where they said, "Screw it, this is turning into a full-fledged language. Let's just plug in Visual Basic."

Not even close. A programming language is Turing Complete: it has state and control flow, which are here specifically excluded. These are a close match to the features in SQL, but for use in the client data model.

Yes, I imagine that's what the Access 1.0 developers said too, shortly before they decided to integrate Visual Basic. ;-)

Quote from dandl on February 5, 2021, 1:26 pm

Quote from Dave Voorhis on February 5, 2021, 12:26 pm

Quote from dandl on February 5, 2021, 10:30 am

Just a quick side note: it seems I am not alone. A quick web search for NoCode turned up heaps of products with the single claim: create apps without code. Maybe Dave is right and they're all wrong, but then they sure are burning heaps of money on finding out!

The predominant themes are: database, workflow, web sites and I'm sure some of them have point-and-click code-that-isn't-really code, but at least the demand and willingness to pay for product seem to be there. It's a good start.

Here is a selection (sorry about the formatting):

Yes, in fact these things lead to common questions about them -- and the category in general -- on Quora. See https://www.quora.com/Is-low-code-no-code-the-future-of-software-development/answer/Dave-Voorhis

I am sceptical, as they're been around for years making boasts, but not much impact. I first remember seeing their claims in a package for the Apple II in the late 1970s; they probably pre-date that with mainframe and mini products. They're been churning away in the background ever since. I used to occasionally run into them in the field, when in-house users had found insurmountable limitations and needed their no-code or low-code app rewritten in code.

I think it was yesterday that I mentioned Microsoft's foray into this -- PowerApps.

Of course, and we all do. But the point is the need has been there since the earliest days, but the products have been getting steadily better and now they're getting serious traction and making serious money. There really are people out there who want to make simple applications without writing code. They don't want to acquire the programming skills or pay others, they want to do it on their own at the same skill level as spreadsheets. And they are. [Even if it turns out to be just a prototype for a real dev project down the line.]

So I'm not interested in debating whether there is a need or whether it's possible. I'm interested in finding out how to do it, and where the limitations of this approach really are.

 

Quote from Dave Voorhis on February 5, 2021, 1:33 pm

Quote from dandl on February 5, 2021, 1:26 pm

Quote from Dave Voorhis on February 5, 2021, 12:26 pm

Quote from dandl on February 5, 2021, 10:30 am

Just a quick side note: it seems I am not alone. A quick web search for NoCode turned up heaps of products with the single claim: create apps without code. Maybe Dave is right and they're all wrong, but then they sure are burning heaps of money on finding out!

The predominant themes are: database, workflow, web sites and I'm sure some of them have point-and-click code-that-isn't-really code, but at least the demand and willingness to pay for product seem to be there. It's a good start.

Here is a selection (sorry about the formatting):

Yes, in fact these things lead to common questions about them -- and the category in general -- on Quora. See https://www.quora.com/Is-low-code-no-code-the-future-of-software-development/answer/Dave-Voorhis

I am sceptical, as they're been around for years making boasts, but not much impact. I first remember seeing their claims in a package for the Apple II in the late 1970s; they probably pre-date that with mainframe and mini products. They're been churning away in the background ever since. I used to occasionally run into them in the field, when in-house users had found insurmountable limitations and needed their no-code or low-code app rewritten in code.

I think it was yesterday that I mentioned Microsoft's foray into this -- PowerApps.

Of course, and we all do. But the point is the need has been there since the earliest days, but the products have been getting steadily better and now they're getting serious traction and making serious money. There really are people out there who want to make simple applications without writing code. They don't want to acquire the programming skills or pay others, they want to do it on their own at the same skill level as spreadsheets. And they are. [Even if it turns out to be just a prototype for a real dev project down the line.]

So I'm not interested in debating whether there is a need or whether it's possible. I'm interested in finding out how to do it, and where the limitations of this approach really are.

Again, in this area, it's really worth looking at MS Access. Outside of MS Excel, it's unquestionably the most successful product in this field.

The general category, as I've mentioned, has been around for decades. The products don't seem to be getting better, their claims are always the same, they do manage to get seed funding -- or are self-funded -- on the same misunderstandings and poor assumptions as their predecessors, and companies in this area go up and down like the toilet seat at a mixed party.

Outside of the specialist successes like spreadsheets and Access, they're a cesspit of fail.

Quote from dandl on February 5, 2021, 1:35 pm

Quote from Dave Voorhis on February 5, 2021, 12:49 pm

Quote from dandl on February 5, 2021, 10:34 am

Quote from Dave Voorhis on February 5, 2021, 9:26 am

Quote from dandl on February 5, 2021, 8:18 am

... In the model I showed there is a Data/View separation for exactly that purpose. This kind of requirement has a regularity to it that can be captured. But I do not propose to include business rules: they are algorithmic in nature and best expressed in code. I do propose 3 sub-languages:

• Regex for validation
• Format strings for display
• Expression evaluation, both for validation and for calculated fields.

Looks more and more like MS Access, it does.

I imagine the Access folks must have reached a point in their "Expression evaluation, both for validation and for calculated fields" implementation where they said, "Screw it, this is turning into a full-fledged language. Let's just plug in Visual Basic."

Not even close. A programming language is Turing Complete: it has state and control flow, which are here specifically excluded. These are a close match to the features in SQL, but for use in the client data model.

Yes, I imagine that's what the Access 1.0 developers said too, shortly before they decided to integrate Visual Basic. ;-)

Not a chance. This is 1992 and Bill Loves Basic. The dialect changed over the years, but it was always Basic.

Quote from Dave Voorhis on February 5, 2021, 1:45 pm

Quote from dandl on February 5, 2021, 1:35 pm

Quote from Dave Voorhis on February 5, 2021, 12:49 pm

Quote from dandl on February 5, 2021, 10:34 am

Quote from Dave Voorhis on February 5, 2021, 9:26 am

Quote from dandl on February 5, 2021, 8:18 am

... In the model I showed there is a Data/View separation for exactly that purpose. This kind of requirement has a regularity to it that can be captured. But I do not propose to include business rules: they are algorithmic in nature and best expressed in code. I do propose 3 sub-languages:

• Regex for validation
• Format strings for display
• Expression evaluation, both for validation and for calculated fields.

Looks more and more like MS Access, it does.

I imagine the Access folks must have reached a point in their "Expression evaluation, both for validation and for calculated fields" implementation where they said, "Screw it, this is turning into a full-fledged language. Let's just plug in Visual Basic."

Not even close. A programming language is Turing Complete: it has state and control flow, which are here specifically excluded. These are a close match to the features in SQL, but for use in the client data model.

Yes, I imagine that's what the Access 1.0 developers said too, shortly before they decided to integrate Visual Basic. ;-)

Not a chance. This is 1992 and Bill Loves Basic. The dialect changed over the years, but it was always Basic.

Of course. But my point is not about the choice of which programming language they used, but the fact that they obviously decided they needed one.

Quote from dandl on February 5, 2021, 11:16 pm

Quote from Dave Voorhis on February 5, 2021, 1:45 pm

Quote from dandl on February 5, 2021, 1:35 pm

Quote from Dave Voorhis on February 5, 2021, 12:49 pm

Quote from dandl on February 5, 2021, 10:34 am

Quote from Dave Voorhis on February 5, 2021, 9:26 am

Quote from dandl on February 5, 2021, 8:18 am

... In the model I showed there is a Data/View separation for exactly that purpose. This kind of requirement has a regularity to it that can be captured. But I do not propose to include business rules: they are algorithmic in nature and best expressed in code. I do propose 3 sub-languages:

• Regex for validation
• Format strings for display
• Expression evaluation, both for validation and for calculated fields.

Looks more and more like MS Access, it does.

I imagine the Access folks must have reached a point in their "Expression evaluation, both for validation and for calculated fields" implementation where they said, "Screw it, this is turning into a full-fledged language. Let's just plug in Visual Basic."

Not even close. A programming language is Turing Complete: it has state and control flow, which are here specifically excluded. These are a close match to the features in SQL, but for use in the client data model.

Yes, I imagine that's what the Access 1.0 developers said too, shortly before they decided to integrate Visual Basic. ;-)

Not a chance. This is 1992 and Bill Loves Basic. The dialect changed over the years, but it was always Basic.

Of course. But my point is not about the choice of which programming language they used, but the fact that they obviously decided they needed one.

And in the context of 1992 and earlier this was the right decision. It drove dBase, FoxPro, Powerflex and many others. There was no Java or C# or indeed any other usable language for business applications. VB was state of the art and every Office product followed down that path, whether users wanted it or not.

But that was then and this is now, 30 years later. Those are tired old arguments that no longer apply. Those products always targeted programmers, or people who were prepared to learn how to write programs. There is a big market now for nocode products and they make money. If you don't want to engage with that, it's your choice. Stay with what you know. I see new horizons.