Thanks :) This is basically Material Design / Flat design, and I consider it to be perfectly good-enough for an MVP, so yep, I'm keeping it :)
> To open or not to open is certainly not a decision that can be made lightly
Absolutely. Thank you for your write-up on open source models - you just saved me a lot of work. I'm bookmarking your comment for reference.
A concern I have about the entire open-source thing is that it will put a lot of maintenance burden on us, while not providing enough benefits in the 'breakthroughs departnemt'. For example, I'm sure the contributors can optimize performance or implement relatively minor inprovements, but I doubt that the community will be able to implement big systems (for example visual support for higher-kinded types). Is this generally the case, or I'm being too skeptical due to my lack of experience with open source?
> On top of that, visual languages are a very special case scenario. Considering there's so little out there in terms of visual languages, in a field where academics and tinkerers are constantly trying every possible combination, it's clear that for systems like this to make it, they must provide just the right amount of flexibility/functionality: too little and they'll be frustrating too use, too much and they'll lose design coherence. I suspect the sweet-spot for this level is less generalized than that of common programming languages.
These days, there are two kinds of visual functional languages in use by general (non-programmer) public:
1. Node-based image / video processing systems. Examples: material / shader editors in any modern 3D modeling app (3DS Max, Modo, Maya, Houdini etc.) and compositing apps (Shake, Nuke etc). Node-based (i.e. functional) workflow is nowadays a standard in these apps. Language-wise, these are simple funcional languages without higher-order functions, recursion and flexible type systems (they do offer strict typing, but you cannot construct custom types).
2. Excel. Yes, Excel. Basically, it's a tree of formulas, which are mostly pure (except for certain functions that access time, random numbers etc.). The evaluation order depends on the functional dependency, not row/column order, just like in a pure lazy functional language. No recursion, no reusable functions (though Simon Peyton-Jones proposed adding spreadsheet-defined reusable functions to Excel). Weak typing, no custom types, no recursion, no turing-completeness.
What I'm aiming for with my language is not full generality. It will be somewhere in between Haskell and Excel. It will be fully turing-complete like Haskell, but in terms of 'side-effectness' it will be more similar to Excel and Filter Forge: the program is entirely pure, and the only elements that access or produce side effects are the inputs and outputs of the program. The program is executed momentarily, just like in Excel and Filter Forge, and there's no notion of time or waiting.