Live data from Hacker News

Mixing Visual and Textual Code

arxiv.org

21–30 of 47 posts

Re: Mixing Visual and Textual Code

#22

Earlier 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…

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

Re: Mixing Visual and Textual Code

#23

Earlier quoted context omitted.

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?

Re: Mixing Visual and Textual Code

#24

Oh 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.

Grasshopper is massively successful in the CAD space. If you’ve looked at a building and thought “that doesn’t seem possible”, it’s probably grasshopper. See: https://www.grasshopper3d.com/page/architecture-projects

But I drive grasshopper with Claude code, so still 100% agree with your last graf.

Re: Mixing Visual and Textual Code

#25

Earlier quoted context omitted.

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.

Re: Mixing Visual and Textual Code

#26

Oh 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.

Yeah but that's pure visual programming, not a hybridization of the best parts of visual and textual programming.

Anyone who thinks code doesn't matter anymore is selling something. Trying saying "math won't matter anymore" while clicking your heels three times

Re: Mixing Visual and Textual Code

#27
post #4
post #3

Earlier 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.)

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)

Re: Mixing Visual and Textual Code

#28

Earlier quoted context omitted.

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?

...Their name might be descriptive...

Re: Mixing Visual and Textual Code

#29
post #4

Earlier quoted context omitted.

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.)

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.

Re: Mixing Visual and Textual Code

#30
Every to often a project will come along which reminds me of the visions which Hermann Hesse's _The Glass Bead Game_ (originally published as _Magister Ludi_) inspired in me --- this looks to be the latest.

Looking forward to reading the paper and hope that it is widely read/discussed, and that it influences projects/developers such as: https://www.inkandswitch.com/

I'd dearly love to see a 3D CAD program which used this methodology.

Post reply on HN