Slashdot Mirror
Google Blockly — a Language With a Difference
mikejuk writes "There are aspects of Google that increasingly don't make sense. First they dump App Inventor — a graphical language for Android apps — in a fit of spring cleaning and closures — and now they have launched another Scratch-like graphical language, Blockly. However Blockly is different. It works like Scratch or App inventor but it is written in JavaScript. This means it can be included in any web page or web app very easily. This, in turn, means that it can be used for education, getting people to learn to program, or as an easy-to-use script generator for the app. The FAQ gives the example of automating GMail filters and management. The additional difference is that Blockly can compile its programs to JavaScript, Dart or Python so you can take the script and develop it further. This is a really good idea. As long as Google doesn't throw this one out in a fit of reorganization and spring cleaning, it's a welcome new language."
I thought Minecraft had comprehensively solved the problem of creating a Turing-complete graphical programming language. It's redstone all the way down.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
When you bring a product to market, your users just don't expect it to suddenly go away and be replaced by something else a year down the road.
If you violate this expectation too many times, people will stop paying attention. For this reason, "maintenance mode" is one of the most overlooked -- yet most important -- parts of the product lifecycle.
Look Google, yeah, we get it: you like inventing stuff. Great. But here's the thing -- people want to use the products you've invented. We'd rather have you support your existing products than throw them away and spend a year or two developing a replacement. Yes, there's a cost to doing this. But if you care about the long term, you'll put in the extra effort.
There's no -1 for "I don't get it."
As long as Google doesn't throw this one out in a fit of reorganization and spring cleaning, it's a welcome new language.
If the sun doesn't come up in the morning, I can sleep all day!
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Yet Another Google Language.
I'm seeing no evidence this is a Google-backed project, at least in the links provided - it's a project from a guy who works at Google, that's all. So expecting Google to guarantee this exists in perpetuity is not particularly realistic. Realistically, you should have the same expectations you'd have on a project from, say, SourceForge.
Basically this looks like a Javascript re-envisioning of Apple's Automator. Might be a fun toy, but not much more than that.
#DeleteChrome
Says the elitist. The demo of a maze solver is a perfect example of teaching logic programming.
Do not look at laser with remaining good eye.
Is this really a language as much as it is an IDE that saves to Javascript, Dart, or Python? It's not like they took the new language all the way down, they just wrote a nice Javascript based way to make more Javascript, or Dart, or Python. I suppose in the sense of "knowing how to use it" it then becomes a language since it completely obfuscates the layer below it, but there are plenty of people who make their way through C# with nothing more than the help of Visual Studio. So, is Visual Studio a language too?
While I've never made time to go do the experiments, I've often wondered why someone hasn't done a Python IDE that provides a Scratch-like UI, but manipulates the Python AST directly. Seems like that should be doable.
Anyway, I believe Scratch-like interfaces are the future of programming languages. Much as when Backus discovered Noam Chomsky's formal grammars and compilers development as it was done in FORTRAN and COBOL was replaced by a grammar-driven parser in the development of Algol, and pretty much all languages since, eventually, the Scratch-ification of the IDE will become the "obvious" replacement for linear streams of ASCII character codes.
So how fluent exactly are you in machine language these days? Wouldn't want to rely on assembler or anything...
Analogies don't equal equalities, they are merely somewhat analogous.
I've taught quite a few courses ranging from traditional programming to tools such as Adobe Flash (which allows you to use any combination of the graphical tools and ActionScript, the latter being a full-fledged object-oriented programming language, with GC and all the other modern niceties). I've drawn boxes around variables to symbolize how they contain the values, I've given assignments to write pseudo-code, I've demonstrated the concept of algorithms by asking students to give me clear instructions on how to order a stack of documents alphabetically, when I only know how to access them by index and compare two documents... and I'm not sure if any of that has been worth the time.
I don't think I've ever run into a student, who would have been able to actually grasp the concept but would then have stumbled because the code part is difficult. There are people who can grasp the concepts and who then have no real trouble with the code and then there are people who don't really understand having one loop inside another, no matter whether you allow them to write down code, draw flowcharts or whatever.
Also, is there any evidence whatsoever that these "graphical" languages are easier for people to learn?
My kid is 5, and he spends hours writing little programs in Scratch. The click and drag aspect of the graphical language makes it much easier for him. If he had to rely on his nascent typing skills to write code, he'd be stuck in the frustration of Syntax Error Hell, as I was for years when I first started pounding out Basic code on the Apple II.
SpyDock: Scientific Python in a Docker container
If you can accomplish what you need to, there is absolutely no point in having an understanding of the underlying process
*shudders* I hate to actually have to watch as civilization collapses...
You're quibbling over symbology, while missing the important distinctions.
At the most trivial level, just about all programming is "graphical". Characters are symbols. A two-dimensional array of symbols is a graphic. You don't think of it as a graphic, but there it is, right there on your display.
If you've got a graphical language that lets you drag colorful boxes around, snap them together, and watch them twinkle contentedly as the program executes, how exactly is that different from using text? If it's "less rich" -- if there are constructs available in a "conventional language" that aren't available in the graphical language -- then we can discuss the graphical language's particular deficits, and perhaps correct them.
Model-Ts were "any color you like, as long as it's black". It was General Motors that started coloring things up and I think they also invented model years. The model year is a not so subtle suggestion that you are driving an "old" car even though it still runs fine.
As people "acquire" technology like search and programming languages, the people who made their scratch creating these things are left with nothing to do. You might think they'd move on to create something entirely different, or that they'd move into maintenance mode as you suggest. However, they have special expertise in creating not maintaining, and moreover they have special exerptise in creating particular kinds of things. The easiest thing for them to do is fool people into believing that thing A is obsolete so they can create thing B which is fundamentally the same. They maximize their profit that way. It's not so much malice as it is simple laziness. It's economics 101, really.
People want recurring revenue. It's the next best thing to economic rent. Or as I like to say, "everybody wants to be a subsidized farmer".
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
That is actually how civilization advances. People specialize. I drive to work every day. I use a car (a tool) that was created by people who have spent most of their career becoming better, through education and experience, at making that tool (the car) better. It makes me A LOT more efficient at my job because I can drive 20min each way instead of walking for 3 hours each way. I, on the other hand, make other tools (computer programs) that they can use in their everyday life to be more efficient. An example of this analogy is g-code. The car specialist can quickly mill out a part to test on a CNC machine without having to do it by hand and without worrying about how the processor interprets the code, or how the mechanical linkages of the mill work, or the energy characteristics of the milling motors. Because he is using a tool, not trying to understand the underlying process.
Its released under an Apache license. Anyone can run with it if they want to.
I got a version that looks like this
when (aProblem.comes(along)){
you.whip(it,must);
}
before(cream.sitsOut(tooLong)){
you.whip(it,must);
}
go(forward);
move(ahead);
try(detect(it));
if(it != too late) {
you.whip(it,good)
}
blog