I've always found these "lego" languages cumbersome to use, even as a novice. I think a nicer alternative would be to use a (simplified) IDE with good code completion, error highlighting as-you-type, edit-and-continue etc..
Funnily, one of my first languages (after Basic and Pascal) was VB6, which had for that time an excellent IDE.
If I had back then something for C/C++ as good as XCode / Vim YouCompleteMe / ReSharper C++, I would have been much less scared by pointers. Just write `myvar.` and if it doesn't complete, try `->`. If you forget an address-taking & or a dereferencing *, you'll likely get a red wavy underline and correct it easily without compiling.
Maybe combine that with a snippet palette, and a good help function, and you have someting that is both great for learners and for advanced users.
I teach high school students introductory HTML, CSS, & JS on behalf of a non-profit so I'm somewhat familiar with the problem space.
What makes languages such as these and Scratch beneficial is that they decouple logic from the syntax. I can't tell you how frustrating it is for high schoolers to hit the syntax wall and lose interest altogether. At this age (14-18) when you haven't necessarily built up the grit and persistence you have as an adult, tools such as these keep the student progressing and motivated.
Eventually you take the training wheels off and have them engage in real coding. Languages such as these and tools such as Scratch serve as a crucial bridge to that end state.
On the other hand you have an enormous amount of people who grew up in the 80s/early 90s who were pretty fluent in assembly by that age.
Something made it fun for them, so fun they persisted and learned it. There are many other very hard things, such as swimming or riding a bike, which most children learn.
I'm not advocating that things should be boring, just that it's also important to discuss what makes things fun and rewarding, not only on removing hurdles.
I think you're right, but you're talking about a different case than 'dopeboy is. With no offense to him, it's a school setting, which means making kids code on your own terms and schedule, whether they like it or not. It's a different case than intrinsically motivated kid, who will have more than enough persistence to master even C.
I think what's fun and rewarding varies person to person. I'm happy for the people you cite figuring out their way (I count myself as one of them - having an organic interest in programming). But not everyone has that desire and coming up / experimenting with ways to reach those people should be celebrated and critiqued. That way, we can expand the pie and ultimately produce more creators of technology.
It's worth noting that those languages, like 6502 assembly language and early BASIC, had very little in the way of syntax, and particularly, no block structures. I remember finding details of syntax in Pascal and C incredibly cumbersome, learning them as a kid after a considerable amount of time with BASIC and assembly.
Echo that. I recall programming up a ASCII "game" of sorts using basic on a school computer years ago. Whole lot of those infamous gotos etc. But i don't know if i could produce anything even close in C or similar unless it wrote it all as one big hairball inside main().
Edit: Frankly i think we humans are inherently sequential thinkers. Especially when trying to describe how to do something in detail. So when trying to deal with non-sequential systems we sooner or later make a mess of things.
I've sometimes toyed with the idea that users of SQL would benefit from having a block-like representation of the language: there are big multi-clause statements (particularly "SELECT ...", with lots of different places where values need to be plugged in, and a classic source of difficulty for novice/intermediate users is to know what kind of values can be used where, e.g. if you produce a value in the SELECT clause, you can't refer to it by name in a WHERE clause, but you can refer to it by name in ORDER BY. Another is that there's a less than obvious relationship between the GROUP BY clause and the SELECT clause.
A well-designed block language could offer a lot of guidance on these sort of points, perhaps by having a context-dependent pool of available blocks to drag into the body of the query.
At least, doing that would make more sense to me than any graphical query builder I've ever seen, with the bonus that it might lead to users who are more capable of writing SQL directly. (Not that I'm holding up SQL as a paragon of language design - but it is ubiquitous, and very useful in a wide range of situations.)
Sadly, knowledge of CTEs seems to be poorly disseminated. I suspect it's because, at least as of last time I bothered to check, they still aren't supported in MySQL.
Come to it, I've got similar suspicions around overcomplicated query structures and MySQL's lack of hash joins.
I once saw block languages described as "What I could have typed out in twenty characters takes me 100 meters of dragging and dropping instead." Pretty much sums up the one major issue with them, doesn't it?
Having said that, I'm convinced there's a way to design an interface around it that creates an acceptable compromise with (most of) the best of both worlds, although I don't know what that interface would look like. Perhaps introducing a cursor and treating the blocks as we would normally treat glyphs in typed languages[0], using keyboard shortcuts to quickly insert and manipulate blocks.
EDIT: Also, what's notable about all these block lanuages is that they're essentially taking writing, and turning the words into things that can be dragged around and manipulated as objects. Although we do to some degree process language in that way, I wonder if it isn't doing things backwards.
If you look at Bret Victor's recent work you can see interesting alternative takes on this where the problem is approached from a concrete example first and then generalised into abstractions[1][2][3].
[0] Err... not as in typed languages, obviously, but as in languages that we type out.
Right, what you want is a seamless view that shows the block diagram while you type, perhaps by "dissolving" a single block while you type in a way that transiently corrupts the block, and condenses the block when the incremental compile notices that there is once again a valid block.
Right, but in that case the IDE evolved around the existing character-based programming language. What if we try it the other way around? Start by designing an elegant block language and then create a keyboard interface around it.
> And I'd argue that some languages (lisp?) already fit this.
Yup. And with proper editing help like Paredit, you start to actually think in terms of moving tree nodes ("blocks") around instead of typing in text. With that, all you'd have to do is to start drawing colored boxes around the code instead of parens, and you'd have a decent, keyboard-operated "block language".
In my experience, syntax error is a huge barrier to entry to programming. Block removes syntax error by making syntactically erroneous program impossible by construction, so it is of great help.
It is a necessary evil in my opinion. Typing code perfectly without the aid of code completion reinforces the idea that attention to detail in coding is extremely important. Furthermore, it forces the user to read every letter which is very important when first starting out.
"Texting while driving reinforces the idea that you need to pay attention to many different things while driving, which is extremely important. Every new driver should text constantly while driving, or else they will never become good drivers."
I'm a fan of teaching programming using block languages, but scratch has some serious issues. The runtime model of scratch is so much more complicated and divorced from the hardware that it can be hard to really understand what is going to happen when, and why.
Also, once you get past toy programs on scratch, there's not really anywhere to go. Building large programs in scratch is cumbersome and error-prone, and methods of transitioning from scratch to a text-based language are pretty iffy.
This approach of starting with a block representation of a common, practical language makes a lot of sense to me.
I am a fan of simplified syntax as a way to facilitate learning basic computing concepts. Maybe we could use '(' to start a block and ')' to end the block and skip the dragging and dropping?
The PLT group with its {BSL, ISL...} series addresses the issue of "What's next?" in a way that bespoke environments can't. Legos are a useful abstraction all the way up the CS track. But training wheels made of Legos don't roll very long. Alice pushed gamification to the point it could engage a wide audience. Logo has a track record.
> I am a fan of simplified syntax as a way to facilitate learning basic computing concepts. Maybe we could use '(' to start a block and ')' to end the block and skip the dragging and dropping?
Congratulations, you've just created Lisp :). Really, one can't get any simpler than that, syntax-wise. I don't understand the assumption that kids will be too scared to type and have to do everything with a mouse.
Thirty years ago, when computers were not part of so many people's lives, it made sense. I remember what a big deal the graphic tree was in MS DOS 5.0. More recently, it has been hard to overcome 20+ years of GUI habits. WYSWG hampers our conceptual models.
A while back I attempted a Common Lisp version of visual programming, drawing heavily on the syntax innovations of Jens Monig's "Smalltalk Elements", which was a research language attempting to simplify Scratch syntax and move it closer to a pure smalltalk-like metaphor.
I'm not terribly confident that visual programming will ever really come into its own. But I think the combination with Lisp could be really useful, and I'm still doing some work in this area.
EDIT: Just looked around for Jens Monig's "Smalltalk Elements" but it seems the original page is gone...
i have played around with Scratch (trying to teach my daughter how to program)
The issue with blocks is that it gets really hard to handle once it gets a little bit complicated.
- the display becomes cluttered
- A few level of if nestings, and it gets hard to drag around the statements. at least for me: a simple change forces me to mess up the whole structure.
the idea looks nice but it gets messy once you start using
it for real.
Of course for a teaching language it has a big advantage: you don't have to bother about syntax errors. Now maybe its too good to be true, right now i don't know how to get past that stage in my teaching efforts.
Our startup Scirra makes Construct 2, a game creator that uses an interesting kind of block language called "events": https://www.scirra.com/construct2
It's accessible to non-programmers but also is sophisticated enough to cover things like loops, functions, recursion, local/global/member variables, and more.
Friends of mine chose to use it in the most recent Global Game Jame[0]. Remembering how disappointed I was in Klik and Play as a kid, it was a pleasant surprise. We managed to tease out a lot more functionality than I expected.
Aside from the "lots of mouse dragging when a bit of typing would be faster" that I mentioned elsewhere, the only issue I remember having with it, was that it wasn't always really clear which object was being referred to. (Sorry if this is useless vague feedback, but this is from memory and the event being a 48 hour game jam with little sleep doesn't help in that department).
Firefox? Didn't work here either so i grabbed the zip from the download section and had a look. The UI loaded fine, but i could not work out how go get any code to run.
I believe the biggest problem with introductory programming courses is that students are taught two things at once; programming logic and syntax.
To a newbie, rules like ending statements in a semi-colon, wrapping strings in quotes and remembering the casing of a function name can be difficult. Ask them to produce a program with branching and looping with proper syntax and things get needlessly difficult.
I tried teaching a programming class with pseudo code and I found the class seem easier for most than those that had to learn the same material in an actual programming language.
If you could relieve the burden of syntax initially, that's great. But they'll have to learn to carry that burden eventually like the rest of us if they ever want to produce anything of value.
Yeah, i recall poking at basic back in the day and getting that every puzzling "syntax error" back.
Also, there is a mass of bugs out there that come from someone misplacing or forgetting a " or similar.
One thing that is likely needed though is some way to rapidly insert blocks via keyboard, as right now most of these interfaces are overly mouse driven when you want to modify a bunch of blocks quickly.
When I tutored/taught I always found that logic was the root cause of a student's struggle. If you can't understand the logic, there's absolutely no way to understand implementation.
The most unusual situation I've seen when teaching (shit-tier university) was that some students couldn't look at a single ASM instruction and understand what it's doing after being explained the syntax:
ADD R1, R2, R3 ; R2 + R3 --> Store sum in R1
It's almost like some students aren't even ready to learn...o_O
I tend to agree with this. Whenever I'm tutoring and students are having trouble with some piece of syntax, that's almost always the most trivial problem.
I've often encountered students who think they need help with syntax, but in actuality have no understanding of how they're going to actually solve the problem. Conversely, I've never encountered a student who has a good idea of how to solve the problem but just has a syntax error.
This whole "syntax errors cause problems in teaching" thing is something students shouldn't be told. Both because it's pretty untrue on balance, and also because it allows them to blame "syntax" when they write down some copy pasta nonsense and it doesn't work due to compiler errors (completely glossing over the fact that even if there were no compilation errors, the code would still be absurd nonsense.)
With syntac out of the way, they could experiment and iterate with the logic to learn faster. Imagine of legos melted every time you put two together in a way that didn't math the model you were building, and you had to go out and buy a new set.
Funnily, one of my first languages (after Basic and Pascal) was VB6, which had for that time an excellent IDE.
If I had back then something for C/C++ as good as XCode / Vim YouCompleteMe / ReSharper C++, I would have been much less scared by pointers. Just write `myvar.` and if it doesn't complete, try `->`. If you forget an address-taking & or a dereferencing *, you'll likely get a red wavy underline and correct it easily without compiling.
Maybe combine that with a snippet palette, and a good help function, and you have someting that is both great for learners and for advanced users.