There are no pictures or diagrams!

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.

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): github.com/guitarvydas/0d Jack Rusher

I'm working on a hierarchical approach with optional table-based code representations. I'd love to know what you think. github.com/Danskydan/Hilltop

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 youtube.com/watch?v=rBHusPevM5k (Hilltop looks less scary)

Dan Swirsky

neurons fired: Jonathan Edwards’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: altscript.com as a collection of useful data types Dan Swirsky

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.

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.

Thanks for the deep dive, Paul Tarvydas. 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.

Jason Morris I would be interested in seeing examples of how you use Blockly...