There's real value here. In a world being overrun with services what's desperately needed is an orchestration language. Such a language is severely focused on consuming services/messages, converting data, and then uploading data/messages. This is the next Unix shell; a tool whose only purpose would be to stitch together services, pipe data, schedule execution, and display results. An integration dsl.
But it's not clear ballerina that can really do that. Would love to see a more real world example that demonstrates it really solves the integration/scripting problem.
Ballerina is designed exactly for that; to be the Unix shell of the Internet basically. Deep understanding of JSON, XML, MIME, SQL etc., networked execution naturally, parallelism naturally, resiliency, etc..
Dealing with JSON objects in Java has been a pain which often caused me to pick Node.js. I always wanted another typed language that supports JSON literals...
There's looking to be a lot of value in visual languages - this isn't the first one to hit the FP in the last few weeks. We're probably beginning to appreciate the limits of text-based programming, and hopefully enough work goes into something different to create a tool with real productivity using visual code. The only trouble I can see is that there isn't a lot of speed at the moment in dragging and dropping to create graphs.
I'm leading the Ballerina language design. The team has about 15 engineers working on the runtime (and related tools) and about another 15 folks working on the browser-based composer and the IDE plugins.
Ballerina's design point is to be a language with semantically equivalent text and graphic syntaxes. Its not a "visual language" really .. its a language with alternative syntaxes, one text and one graphic.
That approach eliminates the "hit-the-wall" phenomenon of visual languages. And as other commenters have said, a lot of the graphical view is useful to understand overall structure and less to write lots of code. However, parallel code is much better visualized graphically as sequence diagrams are dead simple to grok.
In terms of speed of the current Composer .. still WIP. Help is welcome :).
I currently have the "pleasure" of building a SharePoint workflow, which is done by clicking together building blocks in a graphical builder (running as part of Visual Studio).
Maybe I am generalizing to hastily, but I absolutely despise the experience. In theory it sounds like a nice concept, in practice it tends to make trivial tasks exceedingly complicated[1]. And what would be a screen of code is several screens full of a block diagram. It is possible to zoom out, but text gets unreadable fairly quickly.
[1] To be fair, I think that is probably more of SharePoint problem, whose complexity would be hilarious if I did not have to deal with it.
I've been going back and forth on this for a while as I work on a product that allows users to build applications in a drag and drop visual manner.
What I've seen is that while novices fairly quickly ramp up and get productive generating basic CRUD apps rapidly, they also rapidly hit a wall in two ways:
1. It can be hard or cumbersome to express more complex logic
2. The drag and drop interface often leads people to -assume- what the runtime will do.
Right now, I'm leaning toward feeling that visualization should be a tool to understand the _behavior_ of what one has written, but not necessarily the thing one manipulates to express a program. Ballerina seems to be this, so I'm excited there!
It seems to me the next "graphical language" interface should be more like working in an IDE, but instead of entering the text directly and having the hints provided - we reverse the problem and only allow the user to enter what is allowed by the syntax of the language.
That would essentially generalise to "creating visual code", only now it would use the keyboard instead of the mouse.
It seems to be fairly mature for something I've just heard of. It's crazy how many languages we have now. It's mostly a good thing, but I always wonder how nice it would be to have these immensely talented designers focusing on libraries for existing languages...etc. What is ballerina's performance? I assume it is alright being on the JVM?
It is compiled and output is bytecode. Currently bytecode interpreter is in Java. In the future, it can run on other languages (go?) or using something like LLVM with we write an interpreter for the bytecode. However, to do that we need to port the connectors, which is some work.
Not yet .. but we have a design for tracing the execution flow of every run at near zero cost and then playing back the execution trace. That's not saving all intermediate state but if you save the input (usually an HTTP request; so its saved in the logs) then you can easily debug production issues with it.
If you meant debugging type stuff yes there's debugging already, including from the Idea plugin.
I missed replying to this .. yes one could easily.
Making that perform at the same level as a TCP driver written in C could be a bit challenging .. but not impossible.
In fact, expressing network interaction protocols is one motivation for the sequence diagram approach, but the expectation was higher level stuff like OpenID or SAML type interactions.
Pretty slow for me on Linux Chrome 59. I think there's some JS trying to "smooth" the scrolling (or at least that's how it looks) and/or handling those scroll animations at the top/bottom of the page, but affecting scrolling everywhere.
There's real value here. In a world being overrun with services what's desperately needed is an orchestration language. Such a language is severely focused on consuming services/messages, converting data, and then uploading data/messages. This is the next Unix shell; a tool whose only purpose would be to stitch together services, pipe data, schedule execution, and display results. An integration dsl.
But it's not clear ballerina that can really do that. Would love to see a more real world example that demonstrates it really solves the integration/scripting problem.