JavaScript Gets Visual With Waterbear
mikejuk writes "Waterbear, a new 'Scratch-like' visual programming language, made its debut at a JavaScript conference this week. Basically you can put together a JavaScript program by putting blocks together and entering some parameters. The output is JavaScript that you can use in other web pages. The Waterbear system runs in a browser, it's HTML5 based, and needs no installation. You can't help but think that this is the way all programming will be done in the future."
You can't help but think that this is the way all programmng will be done in the future.
Yes, occasionally, when I'm at my most cynical.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
wake me up when waterbear is implemented in waterbear.
"You can't help but think that this is the way all programming will be done in the future."
I've heard this before about visual languages, in a couple of different field, but it never pans out. National Instruments tries it with LabVIEW, for example. Unfortunately, dragging around boxes and drawing wire is an even clunkier substitute for odd-looking but simple code like "x=power(10,2)". And as soon as it comes time to inspect code someone else has done, branches, loops, and all? It becomes a monstrous game of "Where's Waldo?".
It's an entertaining idea, but in the end when a written language becomes two cumbersome, one of two approaches are taken: you either come up with a framework of code that generates other code to make the writing easier, or the come up with a new language to handle the most common abstractions and make everything easier
Visual programming is a dream that will not die. Those of us who've been around for a while remember flowcharts. Everybody was suppose to use flowcharts. I think that there were even programs that would turn flowcharts into code (and vice versa). How many people do you know who do much flowcharting now? Years ago, Fred Brooks addressed this issue and pointed out that software is very difficult to visualize.
The latest iteration of the idea is "Model Driven Architecture" which is suppose to turn UML (or BPMN) diagrams for a system into code. There are some people who claim some success with this is limited areas. The truth is somewhere between the unbridled optimism and luddite pessimism.
The thing is that programming is hard work and while these tools are helpful, you still need to think about programming. There is no magic bullet (to quote Brooks again).
un-ALTERED reproduction and dissimination of this IMPORTANT information is ENCOURAGED
Visual programming has been done before, and it's never really caught on. Visualizations can help, but the advantages of working with raw text as a native format are too many. Just off the top of my head:
Comments? On the off-chance that I look at one of these visual charts and can't figure out WTF it's trying to do, or why this particular block is wired where it makes no sense for it to go, how might the original programmer tell me? Maybe it's a browser-specific hack, maybe it's legacy cruft that we mean to get rid of eventually... And how do I connect to some existing code someone wrote?
Speed? If I can't do this with a keyboard, it probably already loses. Even in JavaScript, is this going to be quicker than a decently capable typist hacking it together by hand?
Version control? Even something as simple as a diff -- how does that work in this system? Decades of research have gone into tools to work with text -- Git is awesome -- can I bring any of that stuff to bear with this system? If not, what do you have to replace it, and how does it measure up? This was my biggest complaint against systems like Squeak -- I think the idea of changing code live in the system and taking snapshots is awesome, but how do I wire it up to something like Git?
Expressiveness? Are there limits to what I can build with this and have it look sane? With text, I can come up with whole new domain-specific languages to suit the task at hand -- there are all kinds of ways of abstracting away complexity. What does this give me?
I could go on, and these same observations have been made before. It really seems like the attempts to make programming more visual are aimed less at making experienced programmers more productive, and more at making things easier on beginners, or worse, non-programmers. I'm all for making things easy on beginners, so long as they eventually outgrow this sort of crutch, but enabling non-programmers to write programs seems to always end in tears, in entire businesses run on Excel + VBA written by a business type. Understand, I'm not trying to build an ivory tower here, ensure job security, or anything of the sort -- by all means, if businesspeople want to learn to program, go ahead -- but attempting to dumb things down to where they can write programs without really understanding fundamental things about programming is giving us the worst of both worlds.
Regardless, no, I can't help but think that most programming will never be done this way.
Don't thank God, thank a doctor!
I'm not a Javascript developer, but working in the game industry, I've been involved in the development of mission scripting technology for a number of different games. In some ways the problem is the same: The people you need to write the code aren't necessarily comp-sci grads. It needs to be simple, yet powerful. I've seen multiple variations of both visual and textual languages used to represent mission flow, and the big problem I've seen with visual programming is that once a particular scripting problem becomes even mildly complicated in terms of requirements, the resulting visual script becomes a spaghetti mess which is far harder to understand than the lines of equivalent textual code. There's certainly a place for visual programming, but it's generally limited to fairly simple problems.
Basically, visual programming doesn't scale well with the complexity of the problem it's trying to solve.
What if there was a language where each block was a character? then you could string them together to form more complex commands, variable names, and flow control! If you wanted to add the values in the A and B blocks, you would just put a + block between them. you could then use the assignment block to put the resulting value into the C block! you'd probably never need to learn more than 50 or so blocks and you could do just about ANYTHING with that!