Node based programming.

What is node based programming?

I'm guessing it's not node.js?

No not node.js. Have a look here. I am more interested from the engineering and architecture of a node based system.

Are you developing a language, providing some utility to configure existing elements internally, want to understand workflow development? It's a pretty broad topic. I'd look into Visio clones perhaps; they're fairly well-known/standard. Making the diagrams functional would then flow from more traditional compiler theory.


I can't help but throw out the opinion that every 4 years or so someone gets the bright idea to make things 'so easy a non-programmer can do it!', and they never, ever work.

I am looking into node based programming and I would like to inquire whether you could suggest a book or link with information. If you could suggest a framework already available even better. Thank you.

Hi

I used BlueJ extensively whilst at uni a couple of years ago and it basically allows you to arrange your class hierarchy graphically then go in to the source code once your 'template' is laid out.

This area of programming theory is fascinating, sadly graphical programming languages never picked up; partly due to being snubbed by "real" programmers and partly because they are somewhat inefficient in terms of workflow. However, its quite simple to get non programmers to understand the basics of structured programming in this way, so its not a dead loss.

If you are hoping to go through your career programming this way, however, you should probably forget it.

Thank you for the replies :-) No no no not something that complicated. You were right I should have been more thorough in my question. I am already using an API which has everything I need. I just want to expose some classes in a visual way. For example if I have a class which gives the addition of two numbers (I would make a class for this :-)) I would like to visually represent that as a block with two inputs and one output. Since this code is already there how difficult would it be to make the node based system?

This area of programming theory is fascinating, sadly graphical programming languages never picked up; partly due to being snubbed by "real" programmers and partly because they are somewhat inefficient in terms of workflow.

LabView.

The reason these languages don't take off is practical. It works great for demos. It becomes a horrible mess on anything resembling real world.

Have you seen a 10 year old LabView codebase that was developed by 200 people from a pool of several thousand in several continents and having to deal with government regulation? With 640x480 screen containing thousands of nodes and tens of thousands of connections?

From SmallTalk to VisualAge and everything in between. The concept has failed in real world. But it's cool if making a little demo to impress non-technical people. But the horrors of developing in VisualAge with tens of thousands of classes, screens referencing each other, with more wires than a wire factory, it's just an exercise in futility.

Of course, nothing can be scripted either. So whenever you want to rename or move something, it's click, click, click for half an hour, rather than doing a s/old/new. Repeat for all past 4 revisions that need to be maintained.

The concept also fails with versioning. Merging two source files is well understood. Merging two graphs does not lead to intuitive results.

It simply doesn't work in real world.

However, its quite simple to get non programmers to understand the basics of structured programming in this way, so its not a dead loss.[/quote]Non-programmers are irrelevant. They don't work in industry, they don't contribute, they are hobbysts. That's fine.

But "real" programmers have deadlines to keep up, have to deal with moronic real world requirements and need to maintain even 20 year old codebases. In general, it's known as "works in real world".

If you are hoping to go through your career programming this way, however, you should probably forget it.[/quote]
3 years of VisualAge for Java here. That thing also made me become an alcoholic, the depression that comes over me from having to work that way still causes nightmares.

As soon as Eclipse and NetBeans became viable alternatives, the team switched to that. Many would prefer to check everything out, build it there and manually edit the files rather than come close to the disaster of "visual". Towards the end, support for VAJ became a punishment for people who screwed up and several people demanded to be moved off those projects out of sheer desperation. I'm dead serious about it, it was that bad.

It turned out that the time spent by "non-programmers" became so large, it became cheaper to hire top notch, codejam/topcoder winners to work the usual way. Spending a week rewiring things and guessing about bugs the visual way vs. 3 minute job via console.

[quote name='speciesUnknown' timestamp='1300463542' post='4787516']However, its quite simple to get non programmers to understand the basics of structured programming in this way, so its not a dead loss.

Non-programmers are irrelevant. They don't work in industry, they don't contribute, they are hobbysts. That's fine.

But "real" programmers have deadlines to keep up, have to deal with moronic real world requirements and need to maintain even 20 year old codebases. In general, it's known as "works in real world".
[/quote]

Except every programmer was at one point a non-programmer. Failing to contribute immediately to precious business deadlines does not by any stretch of the imagination make something totally worthless. Of course using the wrong tool for the job will always cause problems, but that doesn't mean that the tool itself is the problem.

[quote name='speciesUnknown' timestamp='1300463542' post='4787516']
This area of programming theory is fascinating, sadly graphical programming languages never picked up; partly due to being snubbed by "real" programmers and partly because they are somewhat inefficient in terms of workflow.

LabView.

The reason these languages don't take off is practical. It works great for demos. It becomes a horrible mess on anything resembling real world.

Have you seen a 10 year old LabView codebase that was developed by 200 people from a pool of several thousand in several continents and having to deal with government regulation? With 640x480 screen containing thousands of nodes and tens of thousands of connections?

From SmallTalk to VisualAge and everything in between. The concept has failed in real world. But it's cool if making a little demo to impress non-technical people. But the horrors of developing in VisualAge with tens of thousands of classes, screens referencing each other, with more wires than a wire factory, it's just an exercise in futility.

Of course, nothing can be scripted either. So whenever you want to rename or move something, it's click, click, click for half an hour, rather than doing a s/old/new. Repeat for all past 4 revisions that need to be maintained.

The concept also fails with versioning. Merging two source files is well understood. Merging two graphs does not lead to intuitive results.

It simply doesn't work in real world.

However, its quite simple to get non programmers to understand the basics of structured programming in this way, so its not a dead loss.[/quote]Non-programmers are irrelevant. They don't work in industry, they don't contribute, they are hobbysts. That's fine.

But "real" programmers have deadlines to keep up, have to deal with moronic real world requirements and need to maintain even 20 year old codebases. In general, it's known as "works in real world".

If you are hoping to go through your career programming this way, however, you should probably forget it.[/quote]
3 years of VisualAge for Java here. That thing also made me become an alcoholic, the depression that comes over me from having to work that way still causes nightmares.

As soon as Eclipse and NetBeans became viable alternatives, the team switched to that. Many would prefer to check everything out, build it there and manually edit the files rather than come close to the disaster of "visual". Towards the end, support for VAJ became a punishment for people who screwed up and several people demanded to be moved off those projects out of sheer desperation. I'm dead serious about it, it was that bad.

It turned out that the time spent by "non-programmers" became so large, it became cheaper to hire top notch, codejam/topcoder winners to work the usual way. Spending a week rewiring things and guessing about bugs the visual way vs. 3 minute job via console.
[/quote]

Man, thats a terrible story... i guess "somewhat inefficient in terms of workflow" barely sums it up O_o.

[quote name='Antheus' timestamp='1300465020' post='4787529']
[quote name='speciesUnknown' timestamp='1300463542' post='4787516']However, its quite simple to get non programmers to understand the basics of structured programming in this way, so its not a dead loss.

Non-programmers are irrelevant. They don't work in industry, they don't contribute, they are hobbysts. That's fine.

But "real" programmers have deadlines to keep up, have to deal with moronic real world requirements and need to maintain even 20 year old codebases. In general, it's known as "works in real world".
[/quote]

Except every programmer was at one point a non-programmer. Failing to contribute immediately to precious business deadlines does not by any stretch of the imagination make something totally worthless. Of course using the wrong tool for the job will always cause problems, but that doesn't mean that the tool itself is the problem.
[/quote]

But that's the point; by the time you're getting paid for a living there's people who are skilled programmers. The difference in salary between a skilled programmer and a non-programmer isn't so much to make up for the vast deficiencies that these sort of systems entail for pretty much every real world scenario. They often times require skilled programmers to do scripting to fill in the blanks, or circumvent the inevitable limitations of the UI. They're barely maintainable (which adds cost to business). They're hard to debug (which adds cost to business). They add on-boarding time compared to a programmer using a mainstream language (which adds cost to business). And they very often take longer to actually do things in, which offsets the salary difference anyways.

For all practical purposes, the tool is the problem; or at least this tool has no job. Maybe something that is throw-away-ish code that has limited operations, and follows that nice workflow pattern, but needs non-technical specialists like an art pipeline or sound effect mixer or something might be suited to this, but...