Very useful idea. In some instances the lack of semantic meaning from mutating the dimension, such as order, is "correct", if you want to visually communicate that order is irrelevant. So not using a dimension may be desirable. Making visual interconnections provide more information by providing shapes also runs into problems when using un-typed or dynamically typed language. Doing it in typed languages, you quickly run out of useful shapes. I've seen people try to use color to solve that problem, and it's visually jarring.

It does make me wonder whether it would be possible to eliminate fixed positions, which are meaningless in my tool, and have the pieces migrate visually to show their network of relationships.

Consider that for many box arrow tools, layout has about as much semantic content as whitespace in textual languages.

More completely, layout gives you more: layout also is like the order of things in a source file (often not semantically relevant to the computer but important to authors) and still more. I was going to say layout is like a comment, but the whitespace analogy felt too strong.

My problem with layout is that the default is messy and requires active work to make it "tidy", with white space the default/least effort option is the "tidy" one.

I say it because I built a box and arrows[1] tool and I saw how much time was spent rearranging the layout for no functional reason.

Same with the dashboard designer, it was free form, people spent ages aligning stuff (there layout had a meaning at least)

[1] https://www.event-fabric.com/

I think the main advantage of 2D in programming is not the ability to move or orient things, but the ability to zoom, which is way under-utilized. If I call a library function, I should be able to zoom in on the visual element for the call, and "inside it" see the code for the function. Zoom could make all kinds of nested graphs easier to navigate. Vlojure does a version of this.

I also think that semantically meaningless position and orientation can be helpful, if that fits the metaphor of the tool, and allows the user to transfer their instincts effectively. The left side of my desk is to do, the right side is done, not because of the semantics of desks, but because there isn't one, so I can invent one.

The challenge with orienting things in 2D space is real, though. In Blawx I'm actively trying to limit how much code would be all together in one place. But even still, I find myself having to shove things out of the way when they grow over each other, e.g. It remains awkward at times.

Jason Morris No reason that plain text programming couldn't do more to show items related to the focused part.

Using the Slack Pro trial to bump this thread which I think is interesting, and kind of relates to something I'm working on at the moment (a knowledge management system with tagging)

Register all automation with the community, which can inspect it, disable it and penalize its authors/distributors for misbehavior.

I'm not sure if MUDs and MOOs did that, though..

lobsters has this idea of invitation tree: https://lobste.rs/u

as Kartik says, the user that registers the automation is responsible for it and all the tree up to the root, people don't let other people affect their image in the community, if a bot misbehaves the bot register will be pressured to take action by people up his/her tree

Thank you for the lead. I hadn't heard of lobsters.

I think a good small example would be a tool that allowed you to define linear graphemes, which is ironically both above ("we don't process 2D images") and below ("we already have characters") the scope of parser generators. Imagine describing "two parallel straight lines of the same length connected at an obtuse angle by a constant radius curved line" for the uppercase U. Are there tools for that?

A large example would be something that detects and parses UML diagrams on a whiteboard. Which seems very promising.

Not sure it's what you are looking for but the cypher query language is kind of "ascii art graph pattern matching"

MATCH (nicole:Actor {name: 'Nicole Kidman'})-[:ACTED_IN]->(movie:Movie)

WHERE movie.year < $yearParameter

RETURN movie

• FYI - there are 2 kinds of parser generators

• parser generators based on language definitions (YACC, LR(k), etc.)

• parser generators based on DSLs for specifying parsers (PEG, Ohm-JS, etc.)

• DaS (Diagrams as Syntax) If you are interested in experiments, I would be glad to share

• I argue that graphics is not the problem, but ascribing meaning (semantics) to the diagrams is the problem, start small and build up, e.g.

  • what does a “box” compile to?

  • what do boxes-with-ports-and-arrows compile to?

  • what do concentric boxes compile to?

• “we already have characters”

  • we use characters for IDEs (aka programming languages) only because mid-1900s hardware made it easier to grok grids of non-overlapping, small bitmaps

I'm not clear what the difference is between a "language definition" and an expression in a "DSL for specifying parsers". But what I'd love to see is an example of 1 or 2 where the elements being parsed are graphical... lines, points, colours, shapes. Graphics is not a problem, agreed. And you can always roll-your-own in terms of parsing from some unusual user input. It's just a data tarnsformation. I'm just curious if the idea of parsing from graphical input has ever been abstracted in the way that is has for text.

like OCR but for symbols that aren’t necessarily characters 😉

I’ve drawn thousands of whiteboards over the years… transcribing them into diagram drawing software is usually an opportunity to revisit, clarify and edit. 😅

collecting dust on my shelf

• https://link.springer.com/book/10.1007/978-1-4612-1676-6

• (tc;dr)

• all you really need is SVG + contains () + intersects () + connectedTo ()

• see sections “Expressive Power” and “Ambiguity Detection” in https://en.wikipedia.org/wiki/Parsing_expression_grammar

  • PEG defines a parser in a top-down manner (TDPL), e.g. “if this matches, try to match this next”

  • LR(k) and LL(k) define languages in a bottom-up manner, e.g. “if this looks like a number, then bubble it upwards as a number” (regardless of the context) ; this is what is taught as “language theory”, and is commonly understood to form the basis of parser generators

  • TDPL is order-dependent, Lx(k) is not order-dependent (but more restricted)