https://futureofcoding.org/ logo
#thinking-together
Title
# thinking-together
g

guitarvydas

12/08/2023, 9:59 AM
I believe that VPLs are better than TPLs. I include some observations that led me to that conclusion. meta: I choose to believe that this channel “thinking together” means that half-baked ideas are to be tossed out for brainstorming, pushback, discussion and revision. https://guitarvydas.github.io/2023/12/04/Code-Layout-for-Programming.html (discussion of 1D, 2D, 3D, 4D program syntax)
j

Jack Rusher

12/08/2023, 10:47 AM
There are no pictures or diagrams!
a

Alex McLean

12/08/2023, 10:57 AM
Python has 2d layout. 'Visual' programming languages very rarely have spatial syntax - position/proximity is secondary notation ignored by the interpreter. So I don't think it makes that much sense to say they are 2D or 3D..
My hunch is that it's better to think about how text can be better supported with visual features, rather than think about how to replace text with something visual. The latter approach seems to either end up with inventing a new alphabet when we already have plenty of those, or making a way to describe geometry using geometry.
That's on the pushback side! On the other side I do like the idea of visuaspatial locations meaning you don't necessarily have to name things.. also thinking about units in terms of glyphs/words rather than characters
While doing a few of the advent of code puzzles which included some 2D parsing, it made me think about how strong the affordance is towards 1D representations in 'general purpose' programming languages. Breaking out of that is super tricky and must really limit the programming UIs we have ended up with.
g

guitarvydas

12/08/2023, 11:47 AM
Sigh, you would think that a post about VPLs and DPLs would contain lots of pictures. As penance, I refer you to the following for some possible ideas (different agenda, but contains pictures if you scroll down): https://github.com/guitarvydas/0d @Jack Rusher
d

Dan Swirsky

12/08/2023, 11:51 AM
I'm working on a hierarchical approach with optional table-based code representations. I'd love to know what you think. https://github.com/Danskydan/Hilltop
g

guitarvydas

12/08/2023, 11:57 AM
fact: our quiver is full of text-processing tools, text parsing technologies fact: Ohm (OhmJS/PEG) raises the bar for writing parsers (PEG specifies Parsers, while CFGs specify Languages, PEG parses a construct that can’t be parsed with CFGs or stock REGEX (matched, recursive pairs of “???“)) revelation: some diagram editors save-out diagrams as XML (i.e. parseable text) revelation: “connection” and “containment” relationships go beyond traditional TPL (a long way) revelation: I thought that I would want “beside”, “above”, etc. relationships, but, I haven’t needed them yet. If I end up needing them, I would reach for PROLOG to infer such relationships (N.B. SWIPL can read/write JSON) revelation: backtracking makes parsing much easier (enter: PROLOG, OhmJS, PEG, (miniKanren?)) revelation: 0D adds a new dimension to think-ability fooling with: • using markdown as a programming language (parse things like “`<mark>...</mark>`” as if they were atomic characters) • parsing draw.io files (.drawio) (let someone else build the diagram editor, I build the transpiler) • examples/POCs on request (gladly, but, this reply is too long already) @Alex McLean
• I like it a lot. Thanks for sharing! • I love “num”. No need for further detail (int8, int64, float, double, ...) unless you’re a Production Engineer • Tables: my knee-jerk reaction is to think of Harel’s Scenario-based stuff • I need to re-read this a few more times and give myself some shower-time. @Dan Swirsky
“There is currently no implementation of Hilltop.” : For starters, use OhmJS and RWR (my invention for expressing semantics) (I’ve come down the learning curve on OhmJS, feel free to ask me for summary and help) Tables: Use markup, parse with OhmJS in general: Use OhmJS for syntax, use Lisp/Scheme/Racket for operations (define a “bag” of operations that would be needed, then implement each operation, glue the operations together using syntax (OhmJS)) Flappy Bird: ... reading ... as it happens, I’m watching / learning how to implement this in Lua

https://www.youtube.com/watch?v=rBHusPevM5k

(Hilltop looks less scary) @Dan Swirsky
neurons fired: @jonathoda’s Subtext stuff, 0D, Kenny Tilton’s “cells” (sequential, synchronous PLs oppose reactive solutions, 0D ideas encourage such thinking) @Dan Swirsky
Kagi Universal Summarizer summary of README.md: • Hilltop is a proposed general-purpose programming language that borrows concepts from spreadsheet programming, with cells and their attributes described textually rather than through a graphical interface. • Cell attributes like values, positions, fonts can depend on other cell attributes, allowing for reactive updates when dependencies change. • Cells are organized hierarchically under a root application cell rather than in rows and columns. Attributes use prefixes to indicate their type. • A temperature conversion application is presented to illustrate core Hilltop concepts like cells, attributes, and reactive updates based on dependencies. • Conditional logic can be expressed through if-then tables or statements to control program flow and updates. • Data types like numeric, text, and boolean are distinguished through prefixes and constrain valid attribute values. • Functions can be used to calculate attribute values, with return types automatically inferred. • A guessing game example demonstrates using instructions stored in an attribute to dynamically set other attribute values. • Flappy Bird is proposed as an example of what could be built with under 80 lines of Hilltop code. • Multiple instances of cells can be created at runtime to support more complex programs. @Dan Swirsky
neuron fired: https://altscript.com as a collection of useful data types @Dan Swirsky
j

Jason Morris

12/08/2023, 2:26 PM
It rings false to me to say Blockly is fundamentally sequential. The units of code are hierarchical, with two kinds of children. And I use it to generate logical code, not imperative. But maybe you mean something else.
k

Konrad Hinsen

12/08/2023, 2:42 PM
Maybe I have spent too much time in Lisp Land and Smalltalk Playgrounds, but I think of code as expressed in terms of data structures that can in principle have multiple visual representations, even if there seems to be a preference for something textual outside of Smalltalk.
d

Dan Swirsky

12/09/2023, 5:20 PM
Thanks for the deep dive, @guitarvydas. I have a lot more design to go. Ideally, I'd like to team up with someone who is much more capable than me to take on its implementation.
g

guitarvydas

12/10/2023, 8:38 PM
@Jason Morris I would be interested in seeing examples of how you use Blockly...
j

Jason Morris

12/10/2023, 11:27 PM
If you go to dev.blawx.com there is a demo video linked from the front page!
c

Christopher Shank

12/11/2023, 7:35 AM
I agree with @Alex McLean that most VPLs don't use a "spatial syntax". So what are these VPLs visualizing then? They are visually representing the topological relationships between different parts of a program. Those relationships include containment, connection, adjacency, overlap, order, etc. Most node and wire VPLs make use of connection and possibly containment (e.g. a node can itself contain a set of nodes and wires). Scratch makes frequent use of adjacency, order, and containment. There is nothing inherently visual or spatial about these relationships, they are multi-modal and lossless to transform. A textual syntax that describes these relationships has tradeoffs when compared to a visual syntax, but I wouldn't say that either is inherently better. For example, connection in textual languages has to be a symbolic reference. There is no way to directly point to a function or variable besides referencing it's name. Symbolic references are genuinely helpful when it's easy to name the intent of a piece of memory or a set of instructions. The name becomes a bookmark that is easy to remember and others to learn. But naming can be overbearing at times, and describing connection/reference in a visually direct manner removes that need in until I have to repeatedly layout and organize these connections as a program grows. To Alex's point, spatial position in most VPLs doesn't have much importance to the computer executing the program, only of those authoring the program. I'm excited to see more spatial canvases like excalidraw and tldraw start capturing these topological relationships in there underlying data structures as well as image recognition being able to do the same. It means that the ability to transfer a notation through different modalities or even bridging the physical to digital world is becoming easier. It also brings up the questions of what a VPL looks like that requires spatiality? A language that depends on location and proximity and other geometric relationships that cant easily be represented in other modalities if at all. Much of my framing is based around David Harel's paper "On Visual Formalisms" for anyone interested! https://dl.acm.org/doi/pdf/10.1145/42411.42414
a

Alex McLean

12/13/2023, 3:59 PM
Scratches use of adjacency, order and containment seem wholly textual to me. There's no real visual difference between jigsaw-piecing something inside something else to specify containment and using parenthesis ()
In 'textual' languages you can point to a function or variable without naming them, just by using adjacency
The difference between visual and textual programming languages breaks down further with things like befunge, which inspired the popular real world language orca
Basically all textual languages have visual properties, and almost all visual languages make heavy use of text. So I think the distinction only confuses matters and limits possibilities
j

Jason Morris

12/13/2023, 4:14 PM
If there was no real difference, making languages visual wouldn't do anything. They would be adopted at the same rate, by the same people, with the same amount of success. Evidence categorically shows otherwise. Visual language seem pointless only to people suffering the curse of expertise. They are not FOR people who have already struggled through learning how to use parenthesis for containment. They are for people for whom that struggle and others like it are not obviously worth going through. They are curb cuts to allow people in wheelchairs to cross roads, and people who can walk saying they are pointless is distasteful.
a

Alex McLean

12/13/2023, 4:25 PM
I'm not saying there's no difference between languages, I'm just pointing out that 'textual' programming languages have visual features, and vice-versa. My argument is essentially "why not both"? Also I do think almost no-one will have any problem understanding the use of parenthesis for containment (partly because it's really visual)
j

Jack Rusher

12/13/2023, 4:42 PM
The entire discipline of graphic design, which PLT mostly ignores, is concerned with visual properties applicable to text. I only know of two papers that try to codify those aspects in a programming context: https://hal.inria.fr/hal-00737414 https://dl.acm.org/citation.cfm?id=2661138
a

Alex McLean

12/13/2023, 4:46 PM
Those look great thanks will read! Here's a PDF for the second (paywalled) one
d

David Alan Hjelle

12/13/2023, 5:51 PM
Speaking of graphic design and programming, also see Human Factors and Typography for More Readable Programs by Backer and Marcus. (I first learned about it in this FoC thread.)
5 Views