https://futureofcoding.org/ logo
Join Slack
Powered by
Vector-graphics used for design is stored in files...
# thinking-together
j
Vector-graphics used for design is stored in files and cloud databases, but that doesn't mean designers write text or SQL to interact with it. Code needs to be no different. It needs a UI.
t
We can never perceive the inside of a system without an environment that presents it to us. That makes the environment essential. And so, the environment’s properties must be a core focus in software development, too.
g
The way I see it, Code is a UI. It’s the 1950s solution to the problem of “how to replace this bank of toggle switches by something more flexible”. IMO, we need a new UI for programming, devised for computers and problems of 2022 (which, unlike computers of the 1950s, are distributed and no longer memory-constrained, etc.). I favour the idea of using SVG Elements, instead of Characters, in the design of 2022+ programming UXs.
j
@guitarvydas Fully agree that we need more modern UIs for code! SVG sounds interesting as a UI for code. Any links/projects you can share?
g
… yes … later today …
k
SplootCode is SVG-based 🙂 http://splootcode.io/
j
@Katie Bell Ah, nice, didn't catch that detail when I saw your talk a while back. Looks like you've pivoted away from JavaScript towards Python?
k
Yes that’s right
j
What were the main reasons? Interested because we're going for TypeScript and React 😁
Lovely "What we believe" page 👍
g
My idea of a programming language is:
which I dumb down to:
I slapped together a Makefile that demonstrates a draw.io to .JSON transpiler. Draw.io is a lot like SVG - it’s a better technical diagram editor than anything I know of (suggestions welcome). Clone https://github.com/guitarvydas/eh and type ‘make’. This stuff is WIP and contains a bunch of other issues that interest me (0D, transpiling the generated .JSON to Python and to CL, incremental transpilation, synonyms, etc., etc.). ATM, only the build of helloworld.json works, and the rest of the build process breaks. Maybe I’ll fix the build script in the morning... ATM, the code drops into PROLOG to infer semantic information about the diagram. I think that this can be done more simply, e.g. using Ohm-JS, but I haven’t done it (yet). I wrote a bunch of point-form notes regarding AHAs w.r.t. DaS (Diagrams as Syntax) using SVG. If you find this interesting, the notes are at: https://publish.obsidian.md/programmingsimplicity/2022-11-24-Parsing+SVG+Languages
k
@Jim Meyer When I was doing TypeScript/React there was a ton more syntax that I had to support, including HTML/CSS. Since I’m basically building each node of the AST, more syntax meant I couldn’t focus on the usability and editing experience. The plan is to go revisit TS/JS and HTML/CSS at a future date.
j
@Katie Bell Got it 🙂 That makes a lot of sense for a structural editor, and for proving/refining the core editing experience. We're a visual editor with a canvas, so we're more at the "use React components like visual Lego blocks" at this stage, without us having gone into low-level/raw CSS.
g
Trimming most of the detail, here is a trivial example of an SVG file:
Copy code
<svg version="1.1" width="300" height="300" xmlns="<http://www.w3.org/2000/svg>">
  <rect fill="gray" stroke="black"/>
</svg>
I’ve written a trivial parser in Ohm-JS:
Copy code
SVG {
  Blueprint =  "<svg" stuff ">" GraphicObject+ "</svg>"
  GraphicObject =
    | Rect
  Rect = "<rect" stuff "/>"
  stuff = (~">" ~"/>" any)+
}
The code is in my github svg In my mind, SVG Elements are Atoms, and characters are but Quarks. Ohm-JS insists on having me deal with Quarks. I use Ohm-JS to describe Atoms and to build Molecules out of Atoms. Molecules can then be used to define new programming languages.
A screenshot of the parse, in Ohm-Editor, is:
10 Views
Open in Slack
PreviousNext
Powered by