Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

JavaScript Gets Visual With Waterbear

timothy posted more than 3 years ago | from the click-and-drag-and-two-and-three dept.

Programming 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."

cancel ×

220 comments

CmdrTaco has a tiny penis (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#36036966)

Do you know how tiny CmdrTaco's dick is? It's so tiny that when sized up against a Japanese toddler, the Japanese toddler looks like Mandingo in comparison.

Programming in the future (3, Insightful)

ethan0 (746390) | more than 3 years ago | (#36036988)

You can't help but think that this is the way all programmng will be done in the future.

Actual programming will never be done in this ridiculously simplistic, underpowered manner.

Re:Programming in the future (1)

Securityemo (1407943) | more than 3 years ago | (#36037016)

It might make an awesome shellscripting interface combined with a touchscreen, though.

Re:Programming in the future (1)

$RANDOMLUSER (804576) | more than 3 years ago | (#36037056)

Because a CPU cycle is a terrible thing to waste.

Re:Programming in the future (1)

Securityemo (1407943) | more than 3 years ago | (#36037372)

I was thinking a multitouch screen. I have five fingers one one hand, so assuming a "palette" of "things to do"/basic operations (piping, flow control) on a panel at the edge of the screen I could put five things together at a time. Making simple array/list-like objects would also be intuitive using drag-and-drop. You could perhaps also pipe output to different widget-like objects (meters, graphs) for visualization.

You'd need/want to write shellscripts/wrappers for personalization though, but since that's something that I'd imagine most *nix users already do it wouldn't be that much of an inconvenience.

Re:Programming in the future (1)

h4rr4r (612664) | more than 3 years ago | (#36037416)

I bet I could still do whatever you were doing faster with a keyboard though.

Re:Programming in the future (1)

Securityemo (1407943) | more than 3 years ago | (#36037742)

I'm one of those people who mistype a lot. But still, I think having to type "names of things" is the part that itches for me. If i want to execute a desktop program I click on it's icon in my panel/dock. This is much faster and more convenient than opening a terminal and typing "programname & exit". But if I want to do a task like running a program and then open an instance of a program for every output file I have to open a terminal and type "program1 && for file in *.output123; do program2 $file; done". And one mistype means I have to break execution and fix the typo, sometimes far down the chain, which is annoying.

I suppose you could make a shell that syntax colored what you typed live, but still.

Re:Programming in the future (1)

h4rr4r (612664) | more than 3 years ago | (#36037804)

Not if you already have the terminal open. If I could totally get rid of the mouse I would have already.
Practice will help you far more than any tool like this.

So do your shell scripting in a tool meant for that, vim does text highlighting.

Re:Programming in the future (1)

Securityemo (1407943) | more than 3 years ago | (#36037472)

Oh, and obviously one of those widgets would open a terminal on my "main screen" and display output data in text form. If there was some possibility of rapidly constructing regular expressions visually for filtering that'd be nice, but it feels like that would be a task better done from the keyboard (and it's not like you could pre-construct regexps for every possible situation either.)

Re:Programming in the future (1)

Colonel Korn (1258968) | more than 3 years ago | (#36037760)

I was thinking a multitouch screen. I have five fingers one one hand, so assuming a "palette" of "things to do"/basic operations (piping, flow control) on a panel at the edge of the screen I could put five things together at a time. Making simple array/list-like objects would also be intuitive using drag-and-drop. You could perhaps also pipe output to different widget-like objects (meters, graphs) for visualization.

You'd need/want to write shellscripts/wrappers for personalization though, but since that's something that I'd imagine most *nix users already do it wouldn't be that much of an inconvenience.

A mouse will, of course, be much faster and less fatiguing. Why move your hand a foot across a screen when you can achieve the same thing without raising your entire arm (or if you keep your touchscreen in your lap, unhealthily lowering your neck) with a 1 cm mouse movement?

Re:Programming in the future (1)

Securityemo (1407943) | more than 3 years ago | (#36037866)

Because then you couldn't drag/drop several things at a time, or use multi-touch gestures to manipulate the "widget icons". It wouldn't really involve more movement than moving your right hand to the mouse and back.

Re:Programming in the future (1)

x*yy*x (2058140) | more than 3 years ago | (#36037032)

Personally I always found Delphi much more nicer to use because of the great visual designer. Since that is just replacing WinAPI (or equivalent) calls, why not use it for larger part of the project too?

If you really need to go deep down, then you do it. Use the correct tool for the job.

Re:Programming in the future (0)

Anonymous Coward | more than 3 years ago | (#36037140)

We should probably make it easy for any random person off the street to attempt an engine rebuild and transmission rebuild with their car.

Or, you can leave skilled tasks to skilled people. There's no visual do-it-yourself heart transplant tools either. For a reason

See GeoCities regarding websites.... or AOL regarding the internet, or VB for programming.

I don't know why every industry thinks it's better to put complete morons in charge of more and more complicated processes. The thing about aides are that they only help society if the person using the aid can do their job without it. Otherwise it becomes a crutch and another liability as well as failure point.

Re:Programming in the future (1)

x*yy*x (2058140) | more than 3 years ago | (#36037268)

See GeoCities regarding websites.... or AOL regarding the internet, or VB for programming.

Which all are old things from era when things were different. GeoCities is now replaced with Facebook and blogs, AOL is 20 years old and well, what's so truly terrible about VB? Yeah, lots of noobs used it back in the day. But you have to start somewhere. Besides, it's really powerful as Office macro language, when used correctly. There is no need for everyone to program in assembly, most of the things can be done in simpler languages.

And regarding GeoCities.. Aren't you actually trying to say there that people should be using HTML instead of the newer, easy-to-use interfaces like Facebook which aren't so ugly when created by casual people?

Re:Programming in the future (1)

h4rr4r (612664) | more than 3 years ago | (#36037312)

Facebook is only less ugly because it will not let you do those crazy things. This means it is not even a comparison. They made it easy to use by crippling it. Programming can't be crippled in the same way if you want to get anything done.

Re:Programming in the future (1)

Grishnakh (216268) | more than 3 years ago | (#36037968)

Facebook isn't even real competition for GeoCities. People who were not web designers used to have useful websites there, with stuff like information on their various hobbies, to help other people who have those same hobbies. It made it pretty easy for say, a ham radio buff, to post some documents and tips n' tricks for working with XYZ brand ham radio, and make this available to everyone for free.

Now, to do that, you have to buy a hosting account, and then create your own website, and hope that site's site-building tools are usable. There's still site-building tools out there, but it's not as centralized, easy, and free as GeoCities made it. Yeah, GC sites looked like crap, but it didn't matter and no one cared, because it was the information there that was important. It's a lot like Craigslist: CL looks like total shit too, and doesn't have all the refined tools that Ebay has, but that doesn't stop people from using it in droves.

Of course, the anonymous coward above probably thinks it's better that way, and that things should be left to "experts", so that if someone wants to post some information for fellow hobbyists, he needs to hire a professional web design firm to do it for him, as if some retired hobbyist on a pension is going to pay thousands of dollars to have a website made.

Re:Programming in the future (2)

kwoff (516741) | more than 3 years ago | (#36037534)

There's no visual do-it-yourself heart transplant tools either. For a reason

The primitive programming tools available make it too difficult to implement?

Re:Programming in the future (0)

Anonymous Coward | more than 3 years ago | (#36038022)

No, people at home shouldn't be doing heart transplants.

By making something easy, you permit people to go around an expert to get something done. The problem is that the expert was there for a reason. We go to doctors for a reason, we don't all build bridges, we have skilled people for that.

Programming poorly creates risk for the rest of us. Overflows, logic errors, vulnerabilities from poor coding, etc. The same kinds of disastrous risks you encounter doing your own surgeries.....

Re:Programming in the future (2)

binford2k (142561) | more than 3 years ago | (#36038050)

Just like there are no do it yourself books & tools & diagnostic equipment for casual drivers to work on their cars at home! Oh,... wait...

Ok, then. Just like there's no magic box in casual cooks kitchens to do things like cook bread or rice or whip up super quick meals! Oh,... wait...

I know. You want to feel special. But the natural progression of things is to put capabilities in more and more people's hands. You think you're a hotrod because you can fire up vim. 30 years ago, you would be considered the n00b and the old greybeards were decrying the modern babysitting tools like higher level languages and even compilers. Yes. A compiler was considered a crutch.

Time moves on. Hop on the wagon or be left behind.

Re:Programming in the future (0)

Anonymous Coward | more than 3 years ago | (#36037108)

You can't help but think that this is the way all programmng will be done in the future.

Actual programming will never be done in this ridiculously simplistic, underpowered manner.

What's so underpowered about it? We're programming computers not writing novels.

And that's what they said when they started programming computers with a human readable code and to that from plugging wires into a board.

It's ridiculous that we're still typing code to program computers after 50+ years. AND considering how symbolic mathematics is, a visual way of programming computers would be superior IF we get away from the verbal paradigm; which this programming method doesn't do. All they're doing in the article is a graphical way of manipulating computer code.

It does exist: many moons ago, NeXtStep had a really interesting GUI way of programming and I just wished Apple kept it.

Re:Programming in the future (2)

h4rr4r (612664) | more than 3 years ago | (#36037282)

Try it and you will find why they abandoned it. Any decent size application become incomprehensible.

Re:Programming in the future (1)

kestasjk (933987) | more than 3 years ago | (#36037334)

Yeah.. Apple threw away the next generation of programming (written using the "verbal paradigm"), before senselessly abandoning it for the "verbal paradigm". Why would every company across the globe make such a stupid mistake? Non-verbal was so interesting

Anyone remember "Click n' Play"? That was the future if you asked me, before those verbal assholes ruined it.. If they had just continued in that process I would be expressing the ideas in this post with the dragging and dropping of icons and pipes by now..

Re:Programming in the future (0)

Anonymous Coward | more than 3 years ago | (#36037526)

You're so stuck in the past.

See, this is where the bulk of technical people fail: they can't make the leap to something new. "Oh! It didn't work in the past so it can't work in the future!" Or they put a different face on old tech - like the product in the article.

Typing sucks. It's sooo 20th century and until we get away from it, computing will be stuck in the Dark Ages - where it is now.

BTW, you suck at satire.

Re:Programming in the future (1)

x*yy*x (2058140) | more than 3 years ago | (#36037666)

Klik & Play was awesome. Granted I was a kid then, but that along with SimCity and other great games got me interested in programming. The leap to start programming games with C/C++ and so on is huge, especially for a kid. But I guess these same people who used those tools to get interested in programming now want to remove it from new beginners, because they think everyone should immediately read several 1000's pages books about writing oh-so-perfectly optimized assembly and C/C++ code before they even get to see the fun in it.

Re:Programming in the future (1)

Grishnakh (216268) | more than 3 years ago | (#36038106)

If you look at hardware design, it's moved to verbal code from visual methods too. Way back in 1998, I was designing FPGAs using schematic-entry tools from Xilinx. Basically, you just plop down icons of AND and OR and XOR gates and inverters and such, and connect them by wires. Then you hit a button and the tool synthesizes the FPGA code to download to your device. 13 years later, how many companies are doing this for their ASICs? None. They're all using Verilog, a programming language (hardware description language actually) that looks a lot like C.

I got out of FPGAs years ago (I only did a little at that one job), but I imagine it's because these visual methods don't scale very well to very large and complex designs. Why? I'm not sure, but maybe it's because the visual tools are limited to 2D drawings, and anything complex looks really messy represented in 2 dimensions instead of 3.

Re:Programming in the future (0)

Anonymous Coward | more than 3 years ago | (#36037304)

I see your assertion and raise you a Simulink.

Re:Programming in the future (1)

cavreader (1903280) | more than 3 years ago | (#36037428)

It might serve as a quick way to develop and present new prototypes in the early stages of the development cycle. The actual tools used in the development would of course take over any functionality in the prototype.

Re:Programming in the future (2)

PJ6 (1151747) | more than 3 years ago | (#36037452)

I agree with you. I'd hate using this to code. Which is why all over-engineered projects will some day do it this way.

You know the ones I'm talking about - where you cross a Masters in CS with a jackass, subtract all common sense, give him the title of "Architect", and a budget roughly 20 times what the project should really cost.

Not only will all programming will be in diagram form, but the software will be shitty and nobody will like using it. But managers who don't code (but tell others how to) will love it because it "simplifies" programming, so much that they can sub almost everything out to India, even though it doesn't simplify it at all given the ugly, complicated, roundabout hacks required to accomplish nearly anything outside of a small, standard repertoire of patterns.

But on the bright side, it will actually provide a rather useful and appealing visual method of tacking unit tests onto the workflow.

Re:Programming in the future (1)

RyuuzakiTetsuya (195424) | more than 3 years ago | (#36037560)

What about prototyping?

Then again machine generated code generally sucks, necessitating a sane rewrite anyway.

Re:Programming in the future (1)

binford2k (142561) | more than 3 years ago | (#36038122)

30 years ago, the greybeards were saying that machine compiled code generally sucked and you had to write assembly by hand to get any decent performance. And before that ....

Re:Programming in the future (5, Insightful)

abucior (306728) | more than 3 years ago | (#36037652)

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.

Re:Programming in the future (1)

Sectoid_Dev (232963) | more than 3 years ago | (#36037864)

Back in high school, I remember very similar hoopla being bandied about fourth generation programming languages reducing the need for programmers. Fortunately I didn't listen to my guidance counselor or the crusty math comp-sci teacher who said I definitely wouldn't be a programmer.

Re:Programming in the future (2)

ObsessiveMathsFreak (773371) | more than 3 years ago | (#36037934)

Actual programming will never be done in this ridiculously simplistic, underpowered manner.

Clearly, someone's never worked on a Visual Basic project.

Um, no. (0)

Anonymous Coward | more than 3 years ago | (#36036992)

You can't help but think that this is the way all programmng will be done in the future.

By complete retards maybe. Finally, we'll have a language to replace VB and PHP in the "languages for people who'd drown in the rain without supervision" department!

Re:Um, no. (0)

Anonymous Coward | more than 3 years ago | (#36037514)

They probably said the same thing when the first higher programming languages emerged and also when computers became programmable without touching the hardware.

Re:Um, no. (1)

h4rr4r (612664) | more than 3 years ago | (#36037644)

No because those were usable. Try using this, go for it. Tell me what a 10k line application ends up looking like.

Typing is still used even for human to human communication, it is not going away anytime soon.

Tool Wanted (3, Funny)

Anne Thwacks (531696) | more than 3 years ago | (#36037010)

I am still waiting for a development tool that allows me to write PHP by throwing cowpats at the screen with my WiiMote. (It wont degrade the quality of my PHP code, I promise, but I cant speak fo others!).

Only sometimes... (4, Funny)

LighterShadeOfBlack (1011407) | more than 3 years ago | (#36037030)

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.

Riiiiight (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#36037038)

You can't help but think that this is the way all programmng will be done in the future.

Maybe if all you ever do is create are throw away toy applications. But all the low-level stuff that apps like this are built on are still going to have to be done by someone other than a mouth breather that can't do anything but put some blocks together.

Re:Riiiiight (2)

h4rr4r (612664) | more than 3 years ago | (#36037088)

This 100times this.

No serious software can be written this way. Hell, shell scripts should not be written this way.

Re:Riiiiight (2)

Maximum Prophet (716608) | more than 3 years ago | (#36037184)

Damn straight. I once saw a guy write a program composed of Z80 opcodes onto a legal sized note pad. He then hand assembled the code, copied the bytes into a hex editor, then sent the code to someone else to burn into a PROM. That's the way all coding should be done.

Oh, and Get Off My Lawn, ya lousy kids.

Re:Riiiiight (2)

h4rr4r (612664) | more than 3 years ago | (#36037346)

Pathetic, I once made a fully functioning system of street light controls out of nothing but logic gates, switches and wire.

That is not the point though, the point is visual programming is a total mess once you get to anything complicated. It is like voice input, it only sounds cool. In practice it is slower, less precise and a real pain for other people to deal with later.

Re:Riiiiight (1)

kestasjk (933987) | more than 3 years ago | (#36037436)

Easy to use is awesome, it's about being able to express very complex systems concisely. If that can be done graphically I would be stunned, but if it really can be done and is more efficient I learn it and use it with joy.

Re:Riiiiight (0)

Anonymous Coward | more than 3 years ago | (#36037176)

The problem is that JavaScript is just not performant enough, and it's restricted to browsers.

Once we get visual ASM and start writing operating systems using only touchscreens and goofy hand gestures (typing is for pussies), we'll enter a whole new world of... ugh... something.

The only good part I can think of is, depending on how well the visual design maps to the architecture of a program, maybe it would be easier to read other people's code. But I wouldn't want to write anything in a visual editor, because I did that with UDK, and it was a bitch. I had no idea when functions would execute, there wasn't any simple way to debug, and some things seemed to just not work right.

Re:Riiiiight (1)

Illicon (1588477) | more than 3 years ago | (#36037392)

Oh God, that WORD!

Re:Riiiiight (0)

Anonymous Coward | more than 3 years ago | (#36037906)

Not only that but it's friggin javascript and html5... are these difficult languages to master? The evolution of naff went from geocities to myspace to silly, bloated web sites that are needlessly reliant on scripting for half the stuff to work (I'm referring to what's possible with straight markup -- yes hello slashdot).

This is "javascript in the big" and the world needs it like an ebola outbreak!

Meh (0)

Anonymous Coward | more than 3 years ago | (#36037052)

Sounds like an "Illumination Software Creator" clone that only does javascript.

Nothing new here.. move on (1)

mswhippingboy (754599) | more than 3 years ago | (#36037094)

Reminds me of LEGO NXT-G

snooze button (4, Insightful)

fred fleenblat (463628) | more than 3 years ago | (#36037100)

wake me up when waterbear is implemented in waterbear.

Re:snooze button (1)

omfgnosis (963606) | more than 3 years ago | (#36037220)

Did you try it? It seems like it must have been implemented in waterbear, because everything feels like it was thrown together and nothing seems to work.

Re:snooze button (1)

justforgetme (1814588) | more than 3 years ago | (#36038074)

actually that might prove some point.

Idk which one but it would proove one. Definately not mine though

Graphical programming (1)

$RANDOMLUSER (804576) | more than 3 years ago | (#36037106)

Back in the early days of Java Beans, Sun had something similar that used this put-together-toys/plumbing&black-box model. It didn't last long. Anybody remember what it was called?

Re:Graphical programming (1)

LWATCDR (28044) | more than 3 years ago | (#36037166)

Hell AmigaVision and HyperCard did as wll. It is an old idea and works great for trivial programs. Get to a large program that is say over a thousand lines and then things get iffy.

Re:Graphical programming (1)

jandrese (485) | more than 3 years ago | (#36037900)

Hypercard is really not the same. I don't know about AmigaVision. When you got down to it, Hypercard still required you to enter text to get anything done.

The problem with these visual programming languages is that they make the easy stuff super easy, but never figure out a way to make the hard stuff possible, so you run into roadblocks almost immediately when you start trying to use it for real.

Re:Graphical programming (1)

Nursie (632944) | more than 3 years ago | (#36037680)

We had an assignment to use that back at university in... 97? It was already discontinued at that point.

It was called something like Java Cafe... there seems to have been a product called "Visual Cafe"... but I can't find any screenshots to confirm it.

I think whatever it was may have been lost in the mists of time!

...in the future (5, Insightful)

Ghostworks (991012) | more than 3 years ago | (#36037118)

"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

Re:...in the future (1)

hobb0001 (989441) | more than 3 years ago | (#36037430)

Agreed. The one thing I haven't seen visual languages address well is what happens when you have a program with several kilo-blocks. How do you find the block that you want to link to? Do you scroll through them all? Pick from a hierarchical menu? Zoom through a 3D representation?

Inevitably, you're forced to name the blocks, which means that you type the name of the block that want to link to. Tell me then, how is all that clicking and typing any easier than simply typing "foo = bar * baz" in a text editor?

Re:...in the future (1)

Mr. Underbridge (666784) | more than 3 years ago | (#36037754)

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)"

Labview is the most gawdawful scourge released upon the computing world. Once I installed Labview on a machine with the defective Pentium chip running Windows Me. It disappeared instantly in a puff of smoke and brimstone. 12 hours later, I got an email from Satan himself telling me that he just got his first computer. I can only draw conclusions.

Kinda Cool (1)

Ancantus (1926920) | more than 3 years ago | (#36037130)

I think I am with most slashdotters when I say this isn't for me. But its good to see people making these languages accessible for someone just starting out. My first programming language was a point-and-click drag-and-drop programming language, and I think they are really useful for teaching people the basics of computer programming. Now if someone is going to try and make their entire website like this...well good luck with that, I hope you like carpal-tunnel.

Oh good (0)

Anonymous Coward | more than 3 years ago | (#36037152)

Another layer of ab-fucking-straction

It pains me when I see these flash apps that would have run quite happily on my 7 Mhz amiga with 1 meg of ram struggling along on a modern multi-core - multi-Ghz computer with more ram than anyone back then would have dared dream of.

Re:Oh good (1)

SanityInAnarchy (655584) | more than 3 years ago | (#36037212)

That's not "ab-fucking-straction" causing that, it's shoddy programming, both on the part of Adobe in writing Flash, and on the part of most Flash developers.

The real problem here is enabling idiots to program without doing anything to make life easier on competent programmers.

The future! (1)

rgo (986711) | more than 3 years ago | (#36037158)

"You can't help but think that this is the way all programmng will be done in the future." mikejuk, are you trying to troll us? Visual programming tools have existed for years now, but they won't replace textual programming because they can't handle complex scenarios without making the interface uncomprehensible (check out Max MSP). Also visual tools are usually domain specific, while general purpose languages (like Java, Ruby, Python are not).

The website does not show right in FF. (1)

mapkinase (958129) | more than 3 years ago | (#36037178)

The website does not show right in FF.

The dream that will not die (4, Interesting)

not-my-real-name (193518) | more than 3 years ago | (#36037190)

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).

Re:The dream that will not die (1)

xMrFishx (1956084) | more than 3 years ago | (#36037354)

Visual programming is a dream that will not die.

Visual programming is to programming, what 3D is to displays. Hey maybe we can have 3D visual programming on a trusted platform touch screen desktop - in "HD". Yeah...No

Can't help but think what now? (4, Insightful)

SanityInAnarchy (655584) | more than 3 years ago | (#36037192)

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:Can't help but think what now? (1)

Svartalf (2997) | more than 3 years ago | (#36037532)

Heh... It's bad enough when someone goes and does a "program" with Mathcad and expects to have it gracefully and efficiently handle HUGE datasets and things like it. This tends to be even worse when someone doesn't see this for what it is- which is a learning aid. I've seen all sorts of train-wrecks where someone thought they could do without a Software Engineer or Programmer and tried to wing it with something like this tool. For over 25 years I've seen this sort of stuff. COBOL was the first attempt at this sort of thing, and while there seems to be no end to things- I'm amazed that people keep trying as hard as they have with it all.

Re:Can't help but think what now? (1)

kwoff (516741) | more than 3 years ago | (#36037918)

If you were solving a math problem, would you prefer to type it in, or to write it on a notepad? Do you think that a physicist would be more free to make abstractions by typing his solutions, or by scribbling on a chalkboard? Tapping 50 or so keys with 10 fingertips is surely not the most expressive interface there can be.

Enhanced interrogation methods (1)

$RANDOMLUSER (804576) | more than 3 years ago | (#36037216)

Oh boy, Javascript AND HTML5.
I can't wait for my CPU to get waterbearded, desperately gasping for air.

Re:Enhanced interrogation methods (1)

Securityemo (1407943) | more than 3 years ago | (#36037252)

can't wait for my CPU to get waterbearded

I believe they usually use a towel.

Not Yet (0)

Anonymous Coward | more than 3 years ago | (#36037240)

This will be relevant when code is more about visual structure and spatial relationships instead of abstract notions and correlations. Until then, coding will continue to require abstract thought, not square-peg-in-square-hole monkey operations.

I can't understand why this keeps popping up. If I were to try and teach programming to somebody who has never done it before, this would be the worst possible way to go about it. How do you teach the difference between colors with only a sense of touch?

Images are always better than language (2)

Homburg (213427) | more than 3 years ago | (#36037246)

You can't help but think that this is the way all programmng will be done in the future.

It's true. Just like how, after the invention of the comic book, no one writes prose any more.

Re:Images are always better than language (1)

Svartalf (2997) | more than 3 years ago | (#36037546)

That's far, far from true. And you know this to be the case. If it were so, Baen wouldn't be making money like they do.

Re:Images are always better than language (2)

h4rr4r (612664) | more than 3 years ago | (#36037764)

Baen must not have a book called "The idiot's guide to sarcasm".

Agreed (0)

Anonymous Coward | more than 3 years ago | (#36037294)

On tablets that track your every move!

You can't help but think.. (1)

Anonymous Coward | more than 3 years ago | (#36037380)

.. that graphic novels is the way all books will be written in the future.

Sounds silly? That's because it is.

Then again, i'd like to see a mod where the "boxes" are substituted with meatballs and the connections look like spaghetti. Finally we can have REAL spaghetti code!

Nope (1)

Lord Lode (1290856) | more than 3 years ago | (#36037390)

"You can't help but think that this is the way all programming will be done in the future."

No, I am very sure it will not be.

I once had to use a graphical system to create a build script for something. All the time during the time I used it, I was wishing it would be a normal, plain text, programming language instead. Working with the mouse does not allow those text operations you need like easily duplicating, search and replacing, etc...

Plain text will always be more powerful than mouse. Try doing a regexp on your graphical programming language...

So, nope.

Suuuure it's the way of the future... (1)

Svartalf (2997) | more than 3 years ago | (#36037418)

They've been saying "this is the way of the future" with this sort of stuff for DECADES. In the end, you still need to express things in a full-on programming language to make things perform well.

Programming in the past (0)

Anonymous Coward | more than 3 years ago | (#36037442)

a new 'Scratch- like' visual programming language ... You can't help but think that this is the way all programmng will be done in the future."

Where have you been living all these years mikejuk? The same stuff was said about Visual Basic 20 years ago dude!!!!

But thanks for the big laugh! hahahahaha

(wipes tears)

Looks a lot like (1)

drb226 (1938360) | more than 3 years ago | (#36037486)

Scratch [mit.edu]

What? (1)

NitroWolf (72977) | more than 3 years ago | (#36037512)

You can't help but think that this is the way all programmng will be done in the future.

Only an idiot would not be able to help themselves think that all programming will be done like this in the future. Even most programming would be an incredible leap of logic and faith.

Drag and drop programming is good for simplistic solutions to simplistic problems. It will never replace traditional programming for complex systems. I hate to say never, but when talking about a system like this, it just simply isn't designed for doing anything complex, because the moment a program gets complex to a system like this would be even more complex to use and maintain than a traditional programming language, making it a hindrance rather than an asset.

All programming done like this in the future indeed.

I can't help but think... (1)

QilessQi (2044624) | more than 3 years ago | (#36037518)

...that you're new to programming. Visual programming is fun to play with until you try to get a lot of interesting things done very quickly. Language (specifically, the non-graphical sort) still rules the world.

(Curiously, the link in my sig is strangely relevant today.)
 

No good. (1)

degeneratemonkey (1405019) | more than 3 years ago | (#36037622)

It would be grossly inefficient to describe large, complex systems with a visual grammar like this. If programming is done visually in the future, it will be because we have much broader abstractions built in to the grammar, and detailed control flow structures and micro-operations (such as drawing an arc from angle to angle with a given line width) will be well beneath the expressive range of the language (much in the same way that, as a general rule, the C++ programmer is not interested in writing to hardware registers but instead prefers complete machine abstraction).

Until the artifacts of language-oriented software development are eliminated, this is just regular old programming with a "user-friendly" feel that will allow unskilled workers to accomplish simple things, and impede skilled workers from doing anything useful. This is not ground-breaking, it's certainly not new (systems like this have existed for decades), and I can confirm that "this is how all programming will be done in the future" is a false statement.

Dykstra was right. (0)

Anonymous Coward | more than 3 years ago | (#36037648)

"You can't help but think that this is the way all programmng will be done in the future.".

really? and who will be programming the templates that fuel your pop-up book 'programming experience'., or the OS it sits on, or the drivers... Playing 'connect the dots' is not programming or Computer Science. Programming and computer science should be taught as a branch of mathematics. If you don't know big O notation, algorithms, sorting methods, tree traversal, discrete math... you're not a programmer, you're a fancier LOGO/TURTLE operator.

I'll never understand why people that have a hard time groking how to set up a mail filter even with visual aids, suddenly feel the world of programming opens to them because there are pretty pictures.

yeah, the future (5, Funny)

shadowrat (1069614) | more than 3 years ago | (#36037662)

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!

Efficiency (0)

Anonymous Coward | more than 3 years ago | (#36037698)

In the end it'll always boil down to efficiency. The size of the code vs the bandwidth speed of the server. The speed of the code's execution vs the browser's capability of executing it. And nothing will ever be able to match something hand-written to do the job. Just as there's a clear difference in program efficiency and size between something written in Assembly, C++, C#, Java, etc, there'll always be a difference between something hand-written for the task and something cobbled together by a visual tool incapable of automatically stripping out unneeded code.

oh no, not again (1)

joss (1346) | more than 3 years ago | (#36037744)

> You can't help but think that this is the way all programmng will be done in the future.

Well, I guess you might not be able to if you're retarded.

This visual programming crap crops up from time to time partly because so many people are brainwashed by that crap about a picture being worth a 1000 words. Draw me a picture of "misguided". We give children picture books while they are learning to read - they find them more intuitive than regular books, but that doesnt make them better.

Programming is done with languages because programming is communication. It's communication between programmer and computer.

The trouble with GUI interfaces is that they are predisposed towards the computer transfering information to the human. They are not an efficient mechanism for humans to transfer information to the computer. There is a good mechanism for this - one that has been used for millenia and which our brains have even evolved to use effectively.The power of language is that the range of choices grows exponentially with the length of the expression.

So if that's the future ... (1)

garry_g (106621) | more than 3 years ago | (#36037776)

... I wonder if programming will be as easy and done perfectly by everyone just as Windows is administered as easy and perfectly compared to command line on Unix systems ...

It doesnt work. (0)

Anonymous Coward | more than 3 years ago | (#36037786)

Uha? But even to demos don't work. "Even" in chrome. WTF?

visual programming languages (1)

heli_flyer (614850) | more than 3 years ago | (#36037834)

I've worked with (actually, had to replace) a visual programming language before. One huge problem with the language was printouts. It's very hard to print large programs. If you have a conventional text-based programming language, you can print out a 10000 line program on a printer, and it's comprehendable.Now try that with a visual program with 10000 interconnected blocks. You have to print it in sections on letter-sized paper, then tape it all together, and it becomes about 20 ft wide and 15 ft tall. In order to show someone a bug in the program, you needed to schedule a conference room so you have a large enough table to unfold the printout. Another huge problem was inserting new code. With a text-based programming language, you can just insert a new line. With this visual programming language, you had to move all the graphical elements out of the way to create space so you could plop down a new graphical element. It turned what should have been a single keypress operation into a five minute task for rearranging graphical elements. I could go on and on, but needless to say, managment thought the visual programming language was a "differentiating feature against our competitors". The people who actually used it hated it.

Programming the the future.... (1)

mark-t (151149) | more than 3 years ago | (#36037870)

... will generally involve the deployment of known design patterns, and then filling in the application-specific details for those patterns, combining them in innovative ways to create entire applications. It would not be entirely dissimilar from this. Programmers would have more fine tuned control by being able to expand the blocks that make up the pattern, but in general I'm pretty sure you can expect this sort of thing to become the norm, eventually.

Coding, as we typically do it today, would not generally be practiced by anyone other than system programmers and library developers, not application programmers.

I give it maybe 15 years or so.

I beg to differ (1)

binford2k (142561) | more than 3 years ago | (#36037890)

You can't help but think that this is the way all programming will be done in the future.

Actually, I can help but think that.

We have poor calling semantics in our code (1)

FranTaylor (164577) | more than 3 years ago | (#36037964)

Ask anyone who has ever tried to wire two programming languages together: the problem is that there is no coherence in the semantics of how we pass things around between modules.

Thanks to loose programming techniques with languages like C and C++, there is no way to determine the semantics of a function call by looking at its signature. 'const' is a lame half-hearted attempt to help but it's totally inadequate.

Until we solve this problem we will never have successful visual programming aids or even much in the way of automated code generation.

Long ago in MIT 6.170 they taught us the importance of writing formal function call signatures, but in our rush to implement everything ASAP these details are left aside.

Programming==Typing || Pointing_and_Clicking (0)

Anonymous Coward | more than 3 years ago | (#36038014)

So, Java has successfully de-skilled programming into "Pointing and Clicking" and simple Typing.

Don't worry about memory management, it's hard, let Java/X do it for you.

Don't worry about algorithms, it's hard, let Java/X do it for you.

Don't worry about Performance, CPU cycles are FREE!

Don't worry about Memory, it's FREE!

If I wanted pointers and clickers and typists, I would hire them. I want programmers that can think, select algorithms appropriate for the task, and can think ahead to create fast, optimized code.

Sorry.. (0)

Anonymous Coward | more than 3 years ago | (#36038024)

but the name 'Waterbear' brings to mind hairy homosexual men with urination fetishes.

Needs a better UI (1)

billcopc (196330) | more than 3 years ago | (#36038068)

The first thing I noticed upon loading the page, was that fuzzy turd thing that I can only guess is the Waterbear logo.

All in all, this looks interesting but the UI needs a serious makeover. I flipped through the element library and it was not quite obvious how things worked. Yeah, I get the puzzle piece concept, but it needs more visual feedback if this is truly to become an idiot-friendly scripting tool. If I'm dragging an object, show me right away which targets would be valid to plug it, instead of waiting until I'm hovering right over it. I don't really see myself using this for any serious work, but as a learning tool I think it could have tremendous value, since it shows you the resulting code.

For myself, I'll pass. JQuery is easy enough as it is, I rarely write more than a few lines of JS code per page.

We ARE just pushing around little blocks now (1)

FranTaylor (164577) | more than 3 years ago | (#36038110)

They are called ASCII characters and depending on what environment you are using, these little blocks have well-defined rules as to which blocks you can plug together and what the results will be if you make particular patterns out of the blocks.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...