Currently I am preparing video demo for my generic tree editor. I would like to mention interesting programming languages/environments that store code as structure, not as text. For now I have Dark Language, Subtext and Lamdu in mind. What are other programming environments that are worth mentioning?

unison

The Luna language project out of Poland has a dual-mode approach, where you can see it as wire and node or in textual form. They favor graphical of course.

Thank you

Isomorf

You made a nice start on your editor. However, you haven't considered one of the crucial problems that will come up, which is what happens when the width of your display is wider than the screen, and the content is taller. At that point you are now looking through a porthole into misc. data, and the user will be completely lost. Spreadsheets alleviate this through a split screen approach, and supporting fixing in place header rows so context isn't lost. There is a lot of ergonomics in doing this kind of graphical approach properly, and if you haven't addressed the core problems, your prototype is like putting frosting without the cake. So my suggestion is to take a much larger example and see how you would edit that. This loss of context problem is what is killing the node-and-wire projects like Luna. It immediately turns into pure wires once you hit a complex enough problem. I'm not saying it isn't solvable, but that the reason so many people fail is they pick their own examples to build around. Take my chess program; that will not fit under any circumstances on a single screen, and one will have to navigate around. If you are interested in the theory behind this, i can recommend "Platform for change" by Stafford Beer, who was invited by Salvador Allende to automate chile, and is one of the pioneers of systems theory. Really brilliant man, and in that book he talks about Ashby's law of requisite variety. If more people were familiar with that law they wouldn't be so gung ho on no code approaches which usually try to break this law of information theory.

@Edward de Jong / Beads Project

There is a lot of ergonomics in doing this kind of graphical approach properly, and if you haven't addressed the core problems, your prototype is like putting frosting without the cake.

Oh, absolutely. Current UI is certainly not final. It would require a lot of work. Probably I am not even qualified to fix all these problems.

So my suggestion is to take a much larger example and see how you would edit that.

I will. My idea is to start using this editor early, document what is inconvenient and fix that. Working with a tree that represents a database is one of the key use cases.

If you are interested in the theory behind this, i can recommend "Platform for change" by Stafford Beer

Thank you for this reference, I will certainly take a look on it.

Well, my LES/Loyc tree project standardizes (to some extent) the structure of code independent from its syntax. You can take a Loyc tree (an in-memory language-independent syntax tree) and serialize it in a textual syntax (LES2, LES3, EC#) or in a binary format (Jonathan Van der Cruysse invented one). It's not a programming language nor an environment; it's intended as a foundation for others to build languages and environments on.

@David Piepgrass Hey! I've seen your project when I was searching for existing solutions, it is indeed interesting. It is great that you are here also. There are some things that I didn't like in loyc trees. Specifically use of literals. I wanted this tree data structure to be used by as many parties as possible. I expected it to be easily stored as JSON in text file, stored as file tree in Git or tree in IPFS. Use of literals like uint64 goes against that, since Git files are not typed and JSON numbers are expected to be numbers of JavaScript, which are doubles internally and cannot denote max value of uint64. Thus, allowing different kinds of literals might create a lot of friction, many little hacks how to denote this of that kind of literals in this or that storage. My solution to that is to have only one kind of literal: binary blob. Other kinds of values can be denoted with a wrap that will be represented equally on all storage systems:

{"uint32": "\0x00000001"}

Vladimir, LES2 is intended to be used instead of JSON and is backward-compatible with it, although I guess a JSON encoding would be... possible. Now, for LES3 I decided that in order to achieve better cross-language compatibility, it was necessary to not require all implementations to support data types like int64, so I introduced Custom Literals. I think I'll be changing the implementation of this at some point, but conceptually my new approach is that everything is a string, but could, incidentally, also be a number, a Regex, a boolean, or whatever. For example, a literal like

1234f

(single-precision float 1234) would be equivalent to

_f"1234"

in LES3 which is a character sequence

['1','2','3','4']

and a type marker

_f

in which the leading underscore means "formatted as a number literal, if possible". So you can treat all literals as pairs of two strings. Related comment on my repo: https://github.com/qwertie/ecsharp/issues/52#issuecomment-331034896

There is also BSON created by MongoDB team. There is also CBOR, which is kinda similar