You won't find it in any of the academic literature because it's not an academic project: https://bablr.org/

BABLR is just the extensible streaming parser framework, but it has a few key things going for it: 1. Gap support like Hazel has, but for any language it can parse 2. Streaming parse results, which make multi-pass stream transformation easy 3. The ability to consolidate and take over the work currently done by Treesitter, LSP, Git, and the IDE itself.

So bablr is from you?

"BABLR is a parser framework roughly comparable to Tree-sitter, but built from the ground up for the web"

I have to admit, I don't know why I would stop using my wasm build of treesitter that works amazing on the web for something that is "conditionally production ready". Also I don't see where your project mixed visual and textual code like this paper here explores?

Yeah it's by me. It isn't the purpose of the project to be able to make visual widgets, just an ability that arises naturally when your state layer holds both structure and text.

That does not look like a visual programming language?

It isn't! It's a version control system and IDE state layer that can make EVERY programming language visual at the same time

So, where is this commercially viable visual programming language you claimed exists?

You are bringing the idea that a specific programming language must be made to do visual programming, not me. That is the opposite of what I think!!

If your solution to global problems is for everyone in the world to adopt Hybrid Clojure Script as their programming language, you don't really have an economically viable solution.

Your original comment was:

> I think they may fall over in surprise when they realize that this technology become commercially viable while they were busy writing this academic paper...

"this technology" is an actual concrete language that mixes text and graphics. Not a version control system or an extensible parser framework or whatever it is that you have.

Maybe one day you will build an actual language that mixes text and graphics but unless you can show me a screenshot of that it seems like a dick move to say that they've wasted their time because you've already got a commercially viable version, when actually you haven't at all.

...Their name might be descriptive...

I certainly invite people to disrespect me for superficial reasons, and that is on purpose. The people who actually judge me on my merit I find to be much more worth my time.

My judgment is that you were lying in your original comment, to draw attention to one of your unrelated projects. Then I noticed your name.

I assume he's referring to the massive commercial success of Holy-C and TempleOS.

(It's the only programming language with inline graphics I can think of, at least, your average esoteric visual language tend to not mix with normal code.)

You can use images inline in Racket. Decidedly less esoteric :)

I was going to mention holyC here, but I don't think it is the same thing. holyC lets you embed images etc in the code, but those images don't become part of the logic. This paper is talking about mixing graphical programming languages with textual ones (like a file with both scratch blocks and c code in)

Yeah I'm not talking about that. I'm thinking more like "a C program is just a parse tree, so why couldn't a visual tool help you visualize or rearrange the parse tree?"

This academic paper assumes two largely unmixed disciplines just barely kissing each other. I see a complete blending coming that will melt the boundaries between textual and visual programming.

Once you start thinking like this, you stop seeing semantic editing as a feature of a particular language: it should just be a native ability to have on any parseable code: the ability to reassemble the parse tree nodes like lego bricks.

I entirely agree with you, and I'll raise you one -- coding via AST's lets you formally note and track the boundary/linking facts and concepts via comments. That might finally get us out of the stone-age!