There is a lot of overlap and while there are differences they are often small and hardly seem to justify the need for a new tool. I’m getting tired of looking at new platforms that seem like clones of what is already available. I’ve looked at most of those examples. Many of them are designed for younger students than I teach and so I haven’t gotten very deep into many of them.
Most of the ones for younger children are cute and fun but very limited. That’s probably fine for elementary school but I teach high school. Many people are having success with Alice, Scratch, App Inventor and Snap! at the high school level. And they are fine tools in their way.
I have chosen not to use them though for a number of reasons. I’ve been using TouchDevelop instead. One reason is that there is a clear path from block based languages to text based languages in TouchDevelop. In the same IDE one can move from colorful simple blocks to more traditional looking syntax. That can be helpful.
Moving on to phone apps. TouchDevelop lets users create apps for a variety of phones. Windows Phones, Android phones and even iPhones and iPads. That means that no matter what smart phone a student has they can run their apps on it. Or even develop their apps. I’ve had students all pull out their own devices to learn how to code when the computer lab systems were having issues.
It’s more than just phones though. TouchDevelop is one of the development platforms for the BBC MicroBit for example. TouchDevelop lets students write programs for embedded devices such as the Arduino, ARM embed boards, or node.js running on Raspberry Pi. That’s a lot of options with one simple programming language.
Last but not least I love being able to demonstrate my app and my development environment in random places. I’ve worked on my apps or showed them off on buses, in cars, on the train, sitting on line for various things and occasionally at a restaurant talking with friends. I think that is an advantage for students as well. I like that they can show off their apps on their phones or other devices.
Thanks for posting this, Alfred! I agree about TD being great because it's so ubiquitous. My only quibble is that the upgrade path you speak of (blocks to text) seems a bit more advanced than in Scratch, Blockly, or some others. The code you quote makes perfect sense to you, but I'm not sure it would (in either block or text form) to a beginning programmer.
ReplyDeleteHaving said that, I do want to play more with TouchDevelop. After school gets settled!
I should have used a loop example. I may update the images when I have a chance.
ReplyDeleteI'm not sure I agree with notion of grouping block-based languages together like this. After all, hardly anyone complains about the number text-based programming languages. "We already have Scratch! Why would we ever need Tynker?" sounds a lot to me like "We already have C++! Why would we ever need F#?".
ReplyDeleteAlso - Blockly is not a language at all. :)
Well leaving aside the face that C++ is procedural and F# is functional I do complain about the number of new text based languages. Swift? Really? Why? :-)
ReplyDeleteIf we don't have at least a bazillion almost identical drag and drop languages we'll be depriving the sector that likes and uses them of one CRITICAL part of CS....
ReplyDeletewait for it.....
Religious wars!!!!!!!!!
I mean, where would we be without:
GUI vs command line
Emacs vs Vi (and later Vim and Sublime text)
Mac vs Windows vs Linux
Now we can have:
Touch Develop vs Scratch
Scratch vs Itch
Itch vs Itchy
Itchy vs Scratchy.
But I digress.
And I almost forgot:
ReplyDeleteSpy vs Spy
Interesting post and comments for thought. I can't help but wonder, though, that we're not looking at a train in motion. Perhaps if we'd rolled back the clock and say "OK, let's develop one good block programming language" then we'd be concerned when the others came along. Had we only had one entry in this genre, we'd have Blockly or Scratch or one of the early languages and we'd be done.
ReplyDeleteWe'd have Sprint as our only word processor or Visicalc as our only spreadsheet. (I'm going off the top of my head here and will defer to anyone who can give us older titles.)
However, we all win when great programmers push the envelope and say "I think I've got a better idea" and run with it. Imagine a "one and done" scenario. Touch Develop would never have been developed and yet many people like it as their language of choice in this field.
Hats off to Emmanuel. I would never have thought of the counter argument about text languages.
The D&D field does seem a little strange. Scratch and Snap! look identical but are not. Confuses the heck out of me. I actually do like the array of choices though. Some languages seem to "fit" better than others. I like Scratch, I hate NXT-G but both have their applications. A good programming teacher needs to look around and see what fits best for them and their teaching goals. I like Alice but do not use it for teaching much, it does not fit where I want to go. I also do not spend a lot of time with D&D in my classes. Except for Touch Dev they are all pretty much dead ends as far as programming goes. I like the large number of choices, it give me options when I want kids to learn how to learn a new language. "Johnny, here is the name of a new D&D language. You have two weeks to write a program that does this and explain the basics of the language to the class." Besides, it is always fun to play with new toys.
ReplyDelete"C++ is procedural and F# is functional"
ReplyDeleteRight, but that's THE POINT. Block Language A is procedural and Block Language B is functional. Complaining about their coexistence is exactly as ridiculous as complaining about the coexistence of C# and F#.
I'm with you on the "omg too many of the same block language", but my comment was intended to remind us that block languages can have important semantic differences, and that those differences quite a bit more than the visual differences in the blocks themselves.
https://computinged.wordpress.com/2015/08/17/icer-2015-blocks-win-programming-language-design-ui-design/
ReplyDeleteInteresting read. I have not read the papers yet but they look worth while.
Garth I have downloaded and printed the papers referenced there but have not had a chance to do more than skim them so far. They bare serious reading.
ReplyDelete