3 ms·

I get that a submission like this is not intended as a suggestion for a practical tool, but as a curiosity and invitation to explore. It's great as a first att

I get that a submission like this is not intended as a suggestion for a practical tool, but as a curiosity and invitation to explore. It's great as a first attempt to delve into the strengths and shortcomings; you can't learn what won't work until you try. The author should explain the motivations after this design, and could get hints from other similar languages to improve the language. IMHO the notation has several shortcomings that would make it very hard to use in practice, and not the best strategy for working with functions. Maybe it's my fault for not seeing the purpose of this approach; but in my experience, free-form graph-based language work best when they emphasize working on collections and data streams, rather than on scalar function parameters. For the kind of example problems expressed in the article, a tree-based notation would work better.

minxomat 9y ago
Not really to explore, the intention is nothing but to be esoteric. Suggesting things to make this lang easier to use (i.e. less esoteric) is akin to suggesting adding names to brainfuck commands to make it more readable. Timwi does have some other useful projects though (take a look at his github), all of which are basically centered around parsing. (an IL debugger, a C# parser, generic regular expressions...)
- TuringTest 9y ago
  You're right, I didn't get that this is was intended as esoteric. Actually the parser for the language, if it works right from the Ascii art and not an intermediate representation, must be awesome. This also explains why the visual syntax is much better suited for a computer than human readers though. :-)