You are viewing archived messages.
Go here to search the history.

Paul Tarvydas 2023-12-08 09:59:26

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. (discussion of 1D, 2D, 3D, 4D program syntax)

📝 Code layout for programming

Code Layout for Programming

Jack Rusher 2023-12-08 10:47:35

There are no pictures or diagrams!

Alex McLean 2023-12-08 10:57:05

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

Alex McLean 2023-12-08 11:01:24

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.

Alex McLean 2023-12-08 11:04:27

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

Alex McLean 2023-12-08 11:06:55

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.

Paul Tarvydas 2023-12-08 11:47:20

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): Jack Rusher

Dan Swirsky 2023-12-08 11:51:33

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

Paul Tarvydas 2023-12-08 11:57:41

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

Paul Tarvydas 2023-12-08 12:10:35
  • 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

Paul Tarvydas 2023-12-08 12:31:31

“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 (Hilltop looks less scary)

Dan Swirsky

Paul Tarvydas 2023-12-08 12:51:50

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

Paul Tarvydas 2023-12-08 12:56:41

Kagi Universal Summarizer summary of

  • 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

Paul Tarvydas 2023-12-08 12:58:55

neuron fired: as a collection of useful data types Dan Swirsky

Jason Morris 2023-12-08 14:26:11

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.

Konrad Hinsen 2023-12-08 14:42:12

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.

Dan Swirsky 2023-12-09 17:20:03

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.

Paul Tarvydas 2023-12-10 20:38:56

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