If the question title was a little too vague or confusing, I'm talking about something reminiscent of the Mindstorms NXT/EV3 IDEs. But the code editor, instead of having prefabbed generic blocks to work with, would use just boxes with code inside of them that links to other code.I'm interested how this implementation might be accomplished because I don't know many languages that can be used like this.
Would an IDE with a flowchart view be practical?
ide;flowchart
This can work and this could be a terrible idea and it really depends on what you're trying to achieve. Positive example: Arena is a simulation software that uses predefined blocks to create new simulations. This works great since the constructs are similar between any two simulations and working with a graphical tool is beneficial for that kind of work. Negative example: I have developed software using a proprietary software created in an organization I worked at. You could write your on code, define it as a block, and then wire blocks together through a GUI. Although this sounds good in principle there were a lot of issues, I'll write some of them here to let you get the feeling of how something like this could go horribly wrong:You had to derive from a base class of the framework so the framework would recognize your class as a block. This created a dependency and made it such that you couldn't derive from any other class To control the data flow, the data passed between blocks had to be a wrapper of the framework. Meaning that you couldn't pass the objects themselves but their wrapper (we also had type safely issues since these were not considered in the framework design) The framework created the blocks using reflection (so it could wire the data and pass it around) , this meant that the ctor had to be default and there was no good way of creating a class. Data sent from a block went to all those blocks connected to it. This created a problem where you would like to send some data to some blocks, but not others. Testability became an issue, both integration tests (since creating the system is something that the framework has done) and since that blocks were isolated (the framework was the one did the wiring) It was difficult to navigate the code (since block wiring was done in the framework configuration) This made IOC and dependency injection a nightmare since an application built with an IOC has one composition root, meaning one block. Changing the system so that it would work after the framework lost support was a nightmare (due to the above reasons). 