Mixing Visual and Textual Code
1–10 of 47 posts
Re: Mixing Visual and Textual Code
#2Oh dear. 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...
Re: Mixing Visual and Textual Code
#3Oh dear. 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...
Can you elaborate?
Re: Mixing Visual and Textual Code
#4Oh dear. 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...
Can you elaborate?
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.)
Re: Mixing Visual and Textual Code
#5Oh dear. 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...
Can you elaborate?
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.
Re: Mixing Visual and Textual Code
#6Earlier quoted context omitted.
Can you elaborate?
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…
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?
Re: Mixing Visual and Textual Code
#7Earlier quoted context omitted.
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…
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.
Re: Mixing Visual and Textual Code
#8Oh dear. 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...
I mean visual programming is standard in game development. Did not get traction in the rest of the dev community.
Now it does not matter anyways. We are not reading/ writing code anymore. Just specifying it and testing it.
Re: Mixing Visual and Textual Code
#9A very long time ago I wrote an Eclipse plug in that would read from source comments an ascii diagram describing the state/transition flow of a java class object, and generate/update the necessary state fields and transition methods.
It was pretty cool in principle but nearly unworkable in practice, purely because maintaining an ascii diagram in a text editor for anything more than "Hello world" is a massive PITA.
The simple text editor has a lot to answer for when it comes to how we think about programming, in a Sapir-Whorf kind of way. It's a shame there has been no cast iron standard for mixing live text and visuals. Our industry might look very different.
Re: Mixing Visual and Textual Code
#10Earlier quoted context omitted.
Can you elaborate?
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 :)