I like parts of the transaction model. It’s how I would/do do it - the commit collection, batching and asynchronous reply model.

That said, why are we still using a decades old domain specific language from 1979 (SQL) to interact with databases.

A language that has an extremely low impedance match with “data”, when we have a perfectly good language from two decades earlier… 1958 (LISP) that does a better job, and doesn’t require an ad-hoc query planner that trys (and fails) to outsmart the person planning the query.

Not only that but clearly someone didn’t get the memo that relational database models are so “1995”.

I applaud the efforts, and cynicism aside it really looks like they are doing their best here, and appreciate there is still some time to go before SQL falls away.

Unfortunately I can’t really like the fact that the authors are working this hard on what really is a dead paradigm.

Very well made paper however.

Obviously this comment comes off as authoritative, snarky and denigrating to the people who did the work.

That’s really not my intention however; it’s more like

“just sayin…”

I think we should remember that the whole point is less about a particular language but rather about homoiconicity.

In systems where means for abstraction is the basis of themselves, abstraction becomes a no-op

My point is there is no need to stop with this at a mere computer language when we have every opportunity to go deeper

This seems like a hot topic, only the other day were we discussing AST editors, Intentional Programming and AOP.

I’d never heard the term “Design by Introspection” before, and that certainly may be a term that Andrei coined, but he certainly didn’t invent this, and he certainly didn’t invent static if, although he is owed much gratitude for taking it from its initial inception to the beautiful implementation in DLang. Nice to see C++ finally catching up btw, which is ironic because AFAIK Visual C++ 6.1 was the first compiler from a mainstream vendor to feature both static if and Design by Introspection, (well that and AspectJ).

As much as I love the meta-programming facilities in DLang, there is a difference to how Andrei approached it and a less tightly bound approach. In DLang, it’s hard for Design by Introspection to be done by someone other than the same programmer who wrote the regular code. That is to say there is a cross-cutting concern.

Another approach is that the allocator is chosen by external forces - enzymes that do deep introspection of the local or global AST.

What you do is open up the API to the compiler at the point just after the AST has been built and instead of hard-coding optimizer algorithms, you provide an open plug-in model where your “Intentional Programming” enzymes go and get busy on the code. These enzymes can be totally hidden and autonomous, or they can be exposed as optionally parameterized meta-tags that allow the application programmer to tweak the settings to guide the intentions.

In this way, things like optimizers are just a small class of things that can be written. You can just as easily have a rule that looks at your code in the middle of the compilation and sends a mail to your boss if you forgot to use Hungarian notation.

Now you have that, selecting allocators is left to people who know about selecting allocators, and you get to write

std::vector<SomeType> myBigFatVector;

or if you want to be explicit

[ fix_my_allocator ]
std::vector<SomeType> myBigFatVector;

or

[ meta::allocator::hint(meta::allocator::type::slab) ]
std::vector<SomeType> myBigFatVector;

… knowing that someone else, who knows a lot more about allocation strategies and the big picture has built something smart that does the right thing. these are examples not real code

More importantly, the policy that goes with the enzyme is not embedded in the code that rides with the implementation of either vector or a specific allocator, and that policy can be changed at the drop of a hat. Bye-bye cross-cutting concerns.

Anyway, there is a lot more to it than this, and I’ve barely touched on it here, but yes, “Design by Introspection” is extremely powerful and opens many doors where you only need provide your intention.

We had it to the point where I could mark up a class like so:

[ Window ]
class MyWindow
{
    onMouseDown(auto mouseEvent) { ... }
};

That thing would add you window creation code, message handler code, wire up the message handlers, tell the linker to add additional resources and a whole lot more, working not only inside the language, but across the entire tool-chain.

We even had Bjarne and a bunch of the committee bought in, but politics and time constraints led to a less than adequate solution, that’s not to say it still isn’t worth pushing for, and honestly this technique has nothing to do with C++ or any particular language of course.

Now, back to the title “Abstracting is NOT about names”, well abstracting is about elevating the communication and implementation of concepts (i’m not talking C++ concepts here). The names of the abstractions are important, and so is the implementation of how the concepts get manifested, and to me they kind of go hand in hand.

That said, concepts are generally not their own implementors, but for implementations to come-a-running, it’s necessary to fully convey the idea and that means the aspects of their identity.. to which you can give a name.

Sorry for the long post - just my 2c

I like the article by the way, and I’m very happy to see this stuff being explored.

This is so wonderful.

It got me thinking though, CGL can be time-stepped with a pretty simple GPU program. But now I’m thinking, why stop at the rules of CGL and go the whole hog representing actual transistors, gates and other higher level things while you are at it using different texel colors and even multiple-layers with through-hole interconnects. Maybe people do this already, I have no idea.

In any case, what a tour de force - wow!

Far as matching features to objectives, those I know that were designed for sure are Ada, Wirth’s stuff (esp Oberon’s language & system), and Noether. Ada was done by systematically analyzing the needs of programmers plus how they screwed up. The language’s features were there to solve problems from that analysis. The Wirth languages aimed at the minimal amount of language features that could express a program and compile fast. Cardelli et al did a nice balancing job in Modula-3 for a language easy to analyze, easier to compile than C++, handles small stuff, and large stuff. Noether addresses design constraints more than any I’ve seen so far by listing many of them then balancing among them.

http://www.adacore.com/knowledge/technical-papers/safe-and-secure-software-an-invitation-to-ada-2012/

https://cr.yp.to/bib/1995/wirth.pdf

https://en.wikipedia.org/wiki/Modula-3

https://tahoe-lafs.org/~davidsarah/noether-friam4.pdf

I don’t know about Smalltalk. It had a nice design from what I’ve seen but I don’t know about the process that went into it. It could’ve been cleverly hacked together for all I know. Scheme’s and Standard ML’s languages seem to lean toward clean designs that try to balance underlying principles/foundations against practicality with some arbitrary stuff thrown in there. There’s also variants of imperative and functional languages designed specifically for easy verification in a theorem prover. They have to subset and/or superset them to achieve that.

We are excited to continue experimenting with this new editing paradigm.

That’s fine, but this is not new.

Structured editors (also known as syntax-directed editors) have been around since at least the early 80s. I remember thinking in undergrad (nearly 20 years ago now) that structured editing would be awesome. When I got to grad school I started to poke around in the literature and there is a wealth of it. It didn’t catch on. So much so that by 1986 there were papers reviewing why they didn’t: On the Usefulness of Syntax Directed Editors (Lang, 1986).

By the 90s they were all but dead, except maybe in niche areas.

I have no problem with someone trying their hand at making such an editor. By all means, go ahead. Maybe it was a case of poor hardware or cultural issues. Who knows. But don’t tell me it’s new because it isn’t. And do yourself a favour and study why it failed before, lest you make the same mistakes.

Addendum: here’s something from 1971 describing such a system. User engineering principles for interactive systems (Hansen, 1971). I didn’t know about this one until today!

Ummm, I’m old and crotchety, and one of my cats is sick, so take this with pinch of salt.

“SRE, Go Programmer, Mathematician.”

I beg of you, Software Engineers, Computer Scientists or anyone in the field, pleeeease don’t self-identify with one language. It breaks my heart. There are vast tracts of land to explore!

As far as the post though, it’s weird though, although I enjoy programming in loosely typed or dynamically typed languages occasionally, I’ve generally had just as much, if not more productivity in statically typed environments. Especially in these days of editors that fully understand the AST and type flow.

So, as far as increasing compile times… I don’t even need to compile very often these days - well not until I can already see that the thing compiles - the tools are that good.

Even without the fancy editors though, seeing really strong concrete types explicitly in the code is a wonderful form of documentation that is really beneficial to others that have to maintain things years down the line. Personally I only begrudgingly accepted auto’s and var’s in the last five years although I do have to concede they do make refactoring more convenient and save key presses.

All in all, it seems like he is really torn up and like he’s trying to convince himself or his boss one way or the other. I kind of feel for the guy actually :/

This is an excellent writeup on the benefits you see from having the application language be the application.

I’d also like to add a little to this. For some time, I have been working on a multi-user version of LISP scalable to tens of thousands of concurrent sessions on a single machine.

In this system, given sufficient privilege, any user or agent in the system may inspect, reflect or inject definitions in one, any or all of the other environments, whether they are connected and running or not.

As you can imagine, being able to do this from a simple REPL provides amazing power to you the application developer, but certainly comes with huge responsibility. When you push a definition out, it really is live in that moment.

The nice thing is, as this author says, you can play in your sandbox and keep micro-testing until you feel comfortable, then try giving the new definition to one user agent to see how it works before finally committing it to everyone.

That is the beauty of the REPL.

It still scares the pants off me though!

Immutability. (…) This means you’ll tend to program with values, not side-effects. As such, programming languages which make it practical to program with immutable data structures are more REPL-friendly.

Top-level definitions. Working at the REPL consists of (re-)defining data and behaviour globally.

These two points are in furious contradiction, since redefining top-level definitions is pretty much the ultimate side effect. Every other top-level function can see this “action at a distance”.

Let me be perfectly clear: ML and Haskell allow you to program using Lisp’s “every definition is subject to revision” style. Just stuff all your top-level definitions into mutable cells. The reason why it’s not done as frequently as in Lisp-land is because, perhaps, perhaps, this is actually a bad idea.

It’s a very worthy goal, and my hat is off to you and really anyone who gets into this area of research, personally I do think it is the future.

I’ve run similar experiments using the AST as the primary editing medium and there is so much to like about it.

We were trying it once back at Microsoft on the C++ AST, it was pretty neat… zero time compiles at least for debug builds since we could simply execute the AST itself. Pretty fun.

Charles Simonyi even left Microsoft to work on just this and created Intentional Software. He had a nifty editor that could render in a number of languages, buf it certainly wasnt cloud based or modern, but then it goes back a long time.

Another friend of mine, is making a project called MakePad. That is an absolutely gorgeous editor that works at the AST level aimed at teaching kids WebGl. Definitely worth checking out.

Personally I’m doing a lot of research in the area of extensible meta-circular semantic protocols and object models. This work ties in very nicely as well with these kinds of ideas.

I’m very interested and impressed with your project and look forward to seeing your progress.

Very nice work!