When I first started my project Ephestos, I imagined a software enviroment that would give the power of the programming language yet it would feel like using a simple application. One of the first people I talked with was sjoerd , at the #blenderpython channel. His first reaction when I mentioned visual coding was "aha you make a node system like me!" my reaction was "Hell no!". 

I am not new to node systems, or flow graphs as they are also known. When I introduced myself to software audio synthesis back in 1997 , node systems were kinda popular for modular sound synthesis environments. Synthesizer are complex machines, a average powerful synth can have up to 1000 modulation sources offering hundreds of modulation options, and that does not apply only to modern digital synths , it also applies to old analogue synths even those that date back to 1970. The most successful example of such an environment is Reaktor by Native Instruments 

http://www.native-instruments.com/en/products/komplete/synths-samplers/reaktor-5/

Reaktor is NOT a toy, as its name implies its a MONSTER. Dont take my word just taking a look at the module manual alone you come against 900 juicy pages. To this date is the most successful node system I have used. What makes Reaktor special, is not only the fact that it has nodes for even low level stuff like completely custom math computations etc , but also extremely high level stuff, individual components and huge assembles that cab from entire synthesizer , mixing consoles and even entire studios. Reaktor ties everything to fully customized GUI components so the end results is a fully bllow personalised GUI app.

Seeing at Reaktor's rather huge sucess story for over 17 years now its easy to praise the flow graph model but thats far from the truth. Reaktor was made successful because of its ability to tie its flow based interface to its GUI interface. What that means is that the users is not forced into flow based mode immediately, he can "frankestein" existing ensembles just reassembling gui elements, like panels of filters , or use group smaller ensembles together to wrapped up to a single custom GUI. In short, a clear case of "drag n drop". You can easily avoid the flow based mode altogether. And why not use the flow based mode ? Well simple . Its INSANELY complex. A simple nice sounding synth can have internally hundreds of nodes, connected to each other what can only resemble a web of a spider. Sure you can use node groups and such, but its does not make things less complex when you want to understand what the hell is going on. Ironically enough if it was not for the flexible GUI and the already available top notch ensembles built by the company and offered as ready to use examples, Reaktor would be as popular as any flow based solution. 

The problem with flow graphs is that they solve one problem and create another. The problem they solve is to give an overall idea to what is connected to what, which is easier to view than it would in text as normal programming language do. But in the end of the day they clutter screen estate, and nodes are not as expressive as are objects in smalltalk so in the end of the day the more complex the flow graph gets the more difficult it becomes to manage. 

For me text based coding is perfectly fine, its more expensive, its very easy to understand and it is user friendly. The problem with coding is understanding the why. Even when I look at smalltalk code I lose myself because I have no clue why the code behaves the way it behaves, and the idea to jump through methods or nodes like super mario on steroids is far from appealing for me when it comes to achieving understanding. 

With Ephestos I have this idea that I call "proton" , for me a proton is not just an object, is not just a visual element, its also fragment of documentation. I imagine a system that is not only self documented, heavily documented, but modularly documented. Meaning each entity carries its own documentation. 

In the age of modern computing coders try to find solutions in the programming language , in GUI, in IDE , external tools or just new ways of intefacing with the user. For me the future is modular documentation. If the user can learn the how in an instant , without the pain of reading hundrends of pages, if the user can ask the system and the system can reply back with the answer that the user needs then I can see the user fiddling with software generation. 

And if "Proteas" is one part of my project , "Morpheas" is another. We already have morphic , we have guis but if you look really closely you will see that when it comes to the text itself the gui does not appear there , with the exception of code completion and syntax highlighting. The question I am asking with "Morpheas" is why ? Why cant we popup tiny graphical elements while we type the text of the language, why get stuck on code completition while we can go much futher and offer tiny gui widget per request, with no extra fat. I am willing to do the unthinkable and erase the smalltalk GUI of the IDE and stuck it inside those tiny widget , leaving the user with a huge text area that at the same time its also its gui canvas. I am trying to imagine Smalltalk making love to Emacs and giving birthing to a child.

Is this possible ? Is this the future ?

No clue , but I am willing to try. 

I forked amber and right now working on code completion, next is documentation and implementation of "Proteas" and then the tiny widgets.

So even If I disagree with the article you linked, I do completely agree with the summary you posted. Luring the user inside coding is the future , so coders can free themselves to work on really complex problems and leave the simple ones on the users. Who knows like Reaktor we may see users implementing things that we never imagined they could do. Why give people fish when you can teach them fishing ?   

On Sat, Aug 24, 2013 at 5:45 PM, sebastian <[hidden email]> wrote:

Hi guys,

I hope this inspires you to keep making Amber cooler and cooler.

How An Arcane Coding Method From 1970s Banking Software Could Save The Sanity Of Web Developers Everywhere

“What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,” says Kenneth Kan, CTO of a company called Pixbi and a recent convert to flow-based programming. “Rather than making us humans think like machines, it's time to make machines to be able to think more like us.”

http://www.fastcolabs.com/3016289/how-an-arcane-coding-method-from-1970s-banking-software-could-save-the-sanity-of-web-develop

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.