NoFlo has launched a kickstarter project to get 100.000 USD in funding for their Development and code-generation Environment.
Their motto is:
Software begins as boxes & arrows on a whiteboard, let’s keep it that way! Imagine, a platform that eliminates spaghetti code… With NoFlo, the diagram is the software!
NoFlow could be defined as a flow-based programming environment for NodeJS with plenty of predefined components so that these flow-based diagrams suffice to generate all code required for the modeled (web-based) application. As such, the diagrams are low-level models of the application (that’s why they talk about a programming environment and not a modeling one) but IMHO they will need to start going up in the abstraction level if they start supporting other technologies (they mention Android if they get enough funding).
All in all, an interesting initiative (more than the tool itself, what I find interesting is to follow what happens with the kickstarter project, so far they are on the right track to reach their funding goal; as far as I know this is the first project of this kind in Kickstarter).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
They actually address complexity: “with each new line your software accrues complexity debt”
However, they don’t understand that the complexity doesn’t come with the code, it comes from getting into details of the problem.
So long
|=
NoFlo is revolutionizing the Visual Programming space. We’ll be part of the revolution by building a Ruby port for NoFlo. AppStrom is a tool to build web applications without writing code. It allows non-tech people who have little or no knowledge on programming to kick start their Ruby On Rails app development with a cool set of visual tools. Along the way, AppStrom provides the flexibility to write code to the customize applications further.
I always find the juxtaposition of phrases like “build Web applications without writing code” and “using Ruby on Rails” funny: someone knowing what RoR is will probably _want_/like to write code, while someone wanting to do the former will not know the latter.
I agree with you. When creating a code-generation / model interpretation tool is key (but at the same time very difficult) to clearly delimit who are your target users. The goal of “I generate everything but you can still modify and optimize whatever you want” sounds nice in theory but it´s very difficult in practice.
In any case, note that in general they avoid using the word model and specially model execution, interpretation or anything like that. We already know that MDE is not cool: https://modeling-languages.com/mde-is-not-cool/ 🙂
Thanks for this article, I didn’t know about noflo before and it seems to be quite interesting.
Maybe it’s just a detail, but what confused me: From what I read about noflo, there is no code-generation at all. The modeled data flow is the executed directly as far as I understand.
I agree that I abused the word “code-generation” here and should be used instead the more generic term of model execution: https://modeling-languages.com/executable-models-vs-code-generation-vs-model-interpretation-2/