JavaScript Gets Visual With Waterbear 220
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."
Programming in the future (Score:3, Insightful)
Actual programming will never be done in this ridiculously simplistic, underpowered manner.
snooze button (Score:5, Insightful)
wake me up when waterbear is implemented in waterbear.
...in the future (Score:5, Insightful)
"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
Can't help but think what now? (Score:5, Insightful)
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.
Re:Programming in the future (Score:5, Insightful)
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.