The Bug-Free Lie of Visual Programming – InApps Technology 2022

Flashback time: it’s 1984 and you’ve just dutifully spent a solid 45 minutes typing in the BASIC source code from the back pages of Discovery Magazine in breathless anticipation of the game that is promised to appear before your eyes as soon as you type RUN… and all you get is a syntax error.

This was your red pill or blue pill moment. You decided to plod onward, find the error, and get that game working or you said “to hell with this” and did something, anything else with your life other than programming computers.

As computer pioneer Maurice Wilkes is quoted as saying, “As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.”

Now, we are light years ahead of that, with IDEs that can help highlight our syntax errors and forewarn us of any compile-time bugs, even suggesting code as we type, but still our acceptance that debugging is and always will be part of the programming profession is an essential aspect of the job.

This week, “itinerant developer” Mike Hadlow takes issue with visual programming — offering to explain why it’s a bad idea — focusing on a few “misconceptions about programming.” On first publication, Hadlow cited MIT’s Scratch as his primary example, with that as the feature image, and many readers took issue with this fact arguing that Scratch is “enormously useful in teaching programming, especially to children.”

“Anything that introduces more people to the wonderful and exciting world of programming is only to be celebrated,” Hadlow offered in an edit to ease readers’ ire, but I would offer instead that Scratch lacks the one thing you have to know about leading a life as a programmer — you have to deal with bugs. Heck, you should possibly even enjoy dealing with bugs. You should get a rush from figuring out where you went wrong. I feel like, if a few bugs deterred you from staying the course, then it was the wrong course anyways.

At the same time, it’s hard to disagree with one Reddit comment that argues that “you want beginning programmers think about the structure of the algorithm, not where to place the semicolon.”

Nonetheless, it seems disingenuous to let someone endeavor to learn programming without knowing that this is what they’re getting into — a field where misplaced semicolons and mistyped words can be the cause of bigger problems; where attention to even the details you think you need pay no mind can be of the utmost consequence.

Or heck maybe AI will take care of all those mistakes and bug-free visual programming tools like Scratch are perfectly appropriate for the new batch of up and coming developers. Syntax and compile errors will be a thing of the past and AI the wave of the easily programmed future.

Fine. Have your visual programming teaching tool. Enjoy life with the training wheels on and the bowling bumpers shielding you against that gutterball. Perhaps you’ll learn to like programming and then, when the wheels are pulled off and the bumpers removed, you won’t run screaming in terror.

With that in mind, take a look (if you somehow haven’t seen it already) at this absolutely ridiculous bit of “visual programming” that is the creation of a fully playable version of Pokémon Red inside Minecraft. (For the impatient, I’d say skip ahead to about the 10-minute mark to see a bit of the playable game before they dive, in-game-literally, into the rabbit hole that is the programming of the game inside a game.)

This Week in Programming

• KotlinConf 2018 In Summary: First up, KotlinConf 2018 came and went this week with a series of announcements, which are neatly summarized in a blog post by Jet Brains. Among those announcements were a Kotlin 1.3 release candidate, which the company says “brings a ton of new features and functionality,” including coroutines and multiplatform projects. Also, JetBrains and Google have made official the previously announced Kotlin Foundation, which looks to “protect, promote and advance the development of the Kotlin programming language” and “secures Kotlin’s development and distribution as Free Software.” And if you really feel like you missed out, make sure to check out the nine and a half hour YouTube video of the conference – coffee and lunch not included.
• PyTorch Developer Preview: As SDTimes puts it, the PyTorch community is inching closer to a 1.0 release with this week’s announcement by Facebook of new partners and production capabilities for PyTorch 1.0. The “deep learning platform for everything from research prototyping to production deployment” is seeing industry-wide support from not only Facebook, but Microsoft, Google, and hardware makers ARM, IBM, Intel, NVIDIA and Qualcomm. The developer preview of PyTorch 1.0 is now available for download and PacktPub offers a deeper dive into not only what’s new, but where the project has struggled.

• The Muddled Mess of Language Rankings: And in a post that is close to my heart, TechCrunch asks what the heck is going on with programming language popularity? Taking a look at two of the most popular programming language rankings — the TIOBE index and the PYPL index — they find that the rankings seem oddly incongruous. “What’s going on is that the two indexes have very different methodologies,” they explain. “TIOBE measures the sheer quantity of search engine hits. PYPL measures how often language tutorials are Googled. Both are bad measures. We can expect the availability of online resources to be an extremely lagging indicator; a once-dominant dead language would probably still have millions of relict web pages devoted to it, zombie sites and blog posts unread for years. And the frequency of tutorial searches will be very heavily biased towards languages taught en masse to students. That’s not a meaningful measure of which languages are actually in use by practitioners.” Something to keep in mind as we look at language rankings in the future, it would seem.
• GitHub’s Tail of Upgrading Rails: GitHub brings us its story of upgrading GitHub from Rails 3.2 to 5.2, which took a total of a year and a half and afforded them a number of lessons learned along the way, which they happily share. Among these lessons are: upgrade early and often, address technical debt often, upgrade incrementally if you can, and avoid roll-your-own tooling as well as private APIs. Read on for further lessons and specifics on updating a 10-year-old code base.
• MS-DOS Goes to GitHub: And finally for this week, a bit of news that doesn’t really change anything, but is fun to look at: Microsoft has re-open-sourced MS-DOS 1.25 and 2.0 by adding them to GitHub. “Why? Because it’s much easier to find, read, and refer to MS-DOS source files if they’re in a GitHub repo than in the original downloadable compressed archive file.” According to the blog post, the source for both was written entirely in 8086 assembly code back in 1983 and while DOS 1.25 was just seven files, DOS 2.0 exploded to 100 files. Imagine!

Feature image by Alyssa Stevenson via Unsplash.