Live data from Hacker News

Mixing Visual and Textual Code

arxiv.org

11–20 of 47 posts

Re: Mixing Visual and Textual Code

#11
post #9

A 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. Th…

> The simple text editor has a lot to answer for when it comes to how we think about programming

I wonder whether those that used punch cards said the same about those punch cards?

It’s weird how our mobile devices aren’t programmed using keyboards/text as input devices. Or our microwaves. Or refrigerators.

Programmers are stuck with text because their programming paradigms are stuck in a text-based paradigm, hence AIs spew out reams and reams of simple to understand text.

There is definite room for improvements and room for keyboards. However the focus should move on from keyboard to mouse to XR environments using 3D glasses. Our programming paradigms have to move aswell.

Using a visual first paradigm means using higher level constructs, things such as Blockly from Google isn’t a good example of visual programming. For music, things such as noisecraft are. For more general programming approach, Node-RED is a good example of visual programming based on flow based programming paradigm which is well suited to visual programming.

Re: Mixing Visual and Textual Code

#12
post #9

A 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. Th…

> The simple text editor has a lot to answer for when it comes to how we think about programming I wonder whether those that used punch cards said the same about those punch cards? It’s weird how our mobile devices aren’t programmed using keyboards/text as input devices. Or our microwaves. Or refrigerators. Programmers are stuck with text because their programming paradigms are stuck in a text-based paradigm, hence A…

I can assure that mobile devices and embedded systems are programmed with text and keyboards as well.

As a small challenge you could try expressing the contents of your comment using visuals only.

Re: Mixing Visual and Textual Code

#13
Hm...the screenshots don't really sell it;

Maybe the authors should just vibe code a cljs port and put it in a browser?

And showcase some program written in this language that sells it better?

Re: Mixing Visual and Textual Code

#14
post #12

Earlier quoted context omitted.

> The simple text editor has a lot to answer for when it comes to how we think about programming I wonder whether those that used punch cards said the same about those punch cards? It’s weird how our mobile devices aren’t programmed using keyboards/text as input devices. Or our microwaves. Or refrigerators. Programmers are stuck with text because their programming paradigms are stuck in a text-based paradigm, hence A…

I can assure that mobile devices and embedded systems are programmed with text and keyboards as well. As a small challenge you could try expressing the contents of your comment using visuals only.

> As a small challenge you could try expressing the contents of your comment using visuals only.

Hah! That's a trick question, isn't it, because HN filters out emojis?

Re: Mixing Visual and Textual Code

#15
post #9

A 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. Th…

> The simple text editor has a lot to answer for when it comes to how we think about programming I wonder whether those that used punch cards said the same about those punch cards? It’s weird how our mobile devices aren’t programmed using keyboards/text as input devices. Or our microwaves. Or refrigerators. Programmers are stuck with text because their programming paradigms are stuck in a text-based paradigm, hence A…

> I wonder whether those that used punch cards said the same about those punch cards?

Oh, absolutely. One statement/line per card, the first 5 columns reserved for labels (how's that for significant whitespace?), the 6th to signal line continuation, the last eight for arbitrary comments/line numbers? People loathed it.

Re: Mixing Visual and Textual Code

#16
post #12

Earlier quoted context omitted.

I can assure that mobile devices and embedded systems are programmed with text and keyboards as well. As a small challenge you could try expressing the contents of your comment using visuals only.

> As a small challenge you could try expressing the contents of your comment using visuals only. Hah! That's a trick question, isn't it, because HN filters out emojis?

I mean just as an exercise. Also, emojis (as well as hieroglyphics ) are still text.

Re: Mixing Visual and Textual Code

#17
post #3

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

That does not look like a visual programming language?

Re: Mixing Visual and Textual Code

#18
Visual languages often fail when it comes to concurrent development where the state of the art is textual diff and merge. The IBM Rational suite attempted visual model diff/merge but I recall it being unworkable in practice.

Modern collaborative visual tools like Miro sidestep the concurrent development problem by being live multiplayer and by essentially having no version management at all.

Most visual BPM tools that I'm aware of try to mix flowchart style programming with e.g. Javascript on activity nodes, but they fail provide any developer-time syntax checking or completion. They also tend to serialise to XML which is unworkable in practice for diff/merge of the visual logic.

In a previous job we developed an in-house flowchart based language that embedded Javascript. We put the effort into writing a first-class Eclipse plugin that had syntax checking and completion across all graphical and Javascript constructs. It even had interactive debugging that interleaved graphical and textual single-stepping. We never solved the diff/merge problem in a satisfactory way.

Re: Mixing Visual and Textual Code

#19
post #13

Hm...the screenshots don't really sell it; Maybe the authors should just vibe code a cljs port and put it in a browser? And showcase some program written in this language that sells it better?

Yes, I think the best avenue for exploration in this space would be to start with literate programming tools like Jupyter notebooks or Observable.

https://new.observablehq.com/@observablehq/notebooks-2-0-sys...

Re: Mixing Visual and Textual Code

#20

Visual languages often fail when it comes to concurrent development where the state of the art is textual diff and merge. The IBM Rational suite attempted visual model diff/merge but I recall it being unworkable in practice. Modern collaborative visual tools like Miro sidestep the concurrent development problem by being live multiplayer and by essentially having no version management at all. Most visual BPM tools tha…

for a long time I've believed that the way to bridge the visual and the textual worlds is to generate the visuals from a plain text source of truth. I've never gone so far as to make a visually editable programming language, but I have done multiple projects where, for example, process diagrams in an IDEF0 style were generated from human readable text propositions of the form:

Prepare Meal is a Process Oven enables Prepare Meal Utensils enable Prepare Meal Prepare Meal transforms Raw Ingredients Prepare Meal produces Finished Meal Menu governs Prepare Meal Customer Order governs Prepare Meal

You can map out a business process using a very simple (and XML-free, and diffable) plain text DSL and generate interactive diagrams from it. My most recent example is for concept maps along similar lines.

Post reply on HN