timroediger

Nice to see another cracking the 'nodes and strings' style of programming. However, as is I don't see a strong future for this one. It looks like it has replicated the ideas of many which have gone before without significant evolution. The long history of 'nodes and strings' for general programming shows that it isn't going to catch on in the current form.

Some problems in no particular order: * The presentation logic and execution logic of nodes are mixed together in the same python class. * Information density. Nodes and strings just can't fit enough on the screen. * Independent editor which doesn't integrate with other code editing tools. All the niceties of an established text editor or IDE have to be given up. * In my opinion 'get var' and 'set var' leak too much of the text based code paradigm into the flow paradigm. * It only outputs python, which already has a low barrier to entry. Outputting C or Rust or LLVM IR would make the product much more interesting.

However, after all the criticism, keep going. There is a future hidden somewhere inside this type of coding, it just hasn't been discovered yet.

I've been working on a more general framework. Its not public, but I'm happy to chat with anyone who has a specific interest. At present it consists of the following elements: * Language specification - code is stored as json. * Compiler with an interpreter, Javascript, Typescript and Rust backends. * Editor - not quite the classic style node editor. Our new design fixes a lot of the problems and complaints with the old style node editors, particularly information density and spaghetti layout. * Language Server - provides type hints, etc to the editor. * VSCode extension - integrates the editor and compilier into VSC.

Also of note, the language is statically typed, with generics. It handles loops, branches, and functions are first class. Recursion is not supported at present.

In time we also plan to build a LLVM backend, so an intermediate language won't be required. Currently the compiler is written in TS, but as it matures more we intend to make the language compile itself.

If you want to talk, seek me out (I work for Northrop Grumman Australia).

Designing a productive graphical programming environment is very challenging. I think it is probably at least as difficult as designing the underlying language mechanics. I'd love to see any experiments you might be able to share.

As someone who has been working in this area for a while, for a programing language to be embraced by non-programmers it has to not look like a programing language. That is, no matter how streamlined an simple it feels to us programmers, when you stand two meters back from the screen if it looks like c++ then it won't have any significant uptake. I scroll through the subtext page and just see code samples that look pretty much like any other language, and that's what the non-programmer target audience will notice.