[ping_pong]

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now.

There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very quickly and then people will "graduate" from it and go to something more convenient.

My kid is learning Scratch right now, and it's taught him a lot of great stuff. But after about a year, he's ready to move onto Python. Scratch has taught him some very valuable concepts and he was able to jump into some Python concepts with ease (others still escape him). But you can only go so far with Scratch vs other programming languages.

The same goes for other visual tools. In the end, people graduate from the visual style because it ironically becomes too complex because they want to keep things simple, and then you've lost a customer.

[lliamander]

In my experience, there are three things that visual programming tools make difficult:

* abstraction

* version control

* test automation

Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects.

The one asterisk I would put on that is tools in which the visualization is based upon an actual, human readable, programming language. I did some work with XSLT back in the day using a visual programming tool, and it worked reasonably well.

[analog31]

An interesting thing about things like version control and test automation is that they are almost like "meta interpreters" that interpret your code, but do so for purposes other than executing it. Syntax checking and linting come to mind too. Those things are possible, not so much because the program is in text format, but because it's in an open format that anybody can parse.

If a visual programming language stored its programs in a human readable or at least open format, then it would be possible for people to create those tools for it. But then, people would start writing and editing the program directly in its storage format, and it would cease to be visual programming.

[SAI_Peregrinus]

The really funny bit is that the classic visual programming tool LabView is designed mostly for test automation. But it ends up practically requiring the creation of unmaintainable spaghetti (this[1] being a classic example) and there's no test automation possible for it. It's a test automation platform so complex it needs (but doesn't have) test automation for its automation of your tests.

[1] https://thedailywtf.com/articles/Labview-Spaghetti

[bmitc]

No one should ever write code like that and no experienced LabVIEW developer would find that anywhere close to acceptable. And there are no doubt analogs in the text-based world, except you may not even know it because the structure isn’t as visible.

Also, there are certainly test frameworks for testing LabVIEW code. NI has a few but then JKI, a third party company, has multiple testing frameworks including Caraya, which is similar in philosophy to something like FsUnit for F# or Elixir’s ExUnit.

https://github.com/JKISoftware/Caraya

[protomyth]

abstraction

I do wonder why some concept likes building chips doesn't make it into visual environments? I should be able to pass a chip with inputs and outputs to others.

[nitrogen]

It does in some. Visual programming environments are common for setting up the giant sound systems (think hundreds of channels of high-quality audio) that run everything from movie theaters to conference venues to parliamentary halls to amusement parks. Some of them support encapsulation of audio or logic elements into reusable packages.

Another technique they use for abstraction before that point include one-to-n on-page connectors and multi-signal buses when the visual wires get to be too cumbersome.

[DonHopkins]

Snap! supports user defined blocks, first class functions, lexical closures, eval/apply, and even call-with-current-continuation. See the summary and description I posted in reply to the GP.

[whatusername]

Node Red "Nodes" perhaps?

[im_down_w_otp]

I'm curious if you've tried Simulink? Because my experience with visual programming tools maps largely to yours. Especially the RAD tools of the late-90's and early-00's. Eventually you get to a place where the "simple" thing is a dizzying array of radio buttons and check boxes to manage that are all hidden away in their own little silos that you can only get to by drilling down through the visual hierarchy.

This becomes a huge problem with your "pivot" for changing things is plumbing up and down, up and down, up and down the hierarchy. Instead of being able to flip the whole thing on its head and seeing all the settings/flags/options for whole classes & categories of similar things and changing them from that perspective.

It's like there's a transition point where you know enough about how things are all put together that being forced to interact with multiple things at once only through the top of their individual silos starts to fall apart pretty dramatically.

The reason I ask about Simulink, is that it's very common in the toolchain of our customers (I'm CEO of https://www.auxon.io) and we're building an integration to it for our product. For the most part it seems to do a much better job of being an IDE for more complicated models/programs compared to the bevy of RAD tools I've used in the past. I have certainly encountered limitations reminiscent of those old RAD ways, but I can also see how much better a job it seems to do before you hit those snags.

[w_t_payne]

I've used Simulink a lot in the past, and the things that it gives you (as well as it's limitations) are a big driver for my attempts to build tools in this space (I think I'm trying to do a similar thing to you -- causal reasoning using data flow information and other graph-structured engineering data such as requirements traces).

[im_down_w_otp]

Yeah, that's the first half of our stack. Ultimately it exists in service of the second half of our stack which is for automatically stressing and analyzing system behavior to localize root causes, uncover emergent properties, and auto-optimize system parameters.

On the way toward building everything we needed for the analysis we wanted to do we realized we had a distributed tracing system suitable for continuous system lifecycles & embedded systems (as opposed to transactional lifecycles & IT systems) and a spec/query mechanism over what amounts to a logic model derived from system executions. That sort of thing tends to be valuable to folks who aren't as far along in their development or use case maturity to need bleeding out all the corner cases & "unknown unknowns" from their systems, so we exposed many of our building blocks as features themselves.

Somewhat ironically, given the thread this is all related to, everything we build today is for CLI consumption on Linux and Windows. We will build out a kind of IDE/Workbench UI this year to fulfill some of our vision around the category of CAE tools we're angling toward, and to access additional kinds of customers, but predominantly folks have preferred CLI shaped tooling because it's easier for them to bake our continuous verification & validation capabilities into their existing processes when we don't force them into a siloed GUI.

[w_t_payne]

I'd love to have a chat at some point. I'm trying to (slowly) bootstrap some tools for the embedded space, and we're trying to get a grasp on (a) what our MVP should look like, and (b) how to go about approaching customer #1.

[im_down_w_otp]

Happy to chat sometime. Any preferred way to connect?

[jimsmart]

> But you can only go so far with Scratch vs other programming languages.

A friend has built some pretty amazing stuff in Scratch, including a BBC Micro emulator (runs 60+ games), a few arcade game ports, and lots more [1].

As a developer myself, I find it quite surprising how far one can go with Scratch. (FWIW I've never coded with it myself)

[1] https://scratch.mit.edu/users/RokCoder/

[IdiocyInAction]

People have also made neural networks using Redstone in Minecraft. You can make anything you want in Scratch; the question is whether it is wise to do so.

[username90]

He seems to code an interpreter in scratch and then do the other stuff. Coding an interpreter is a lot easier than coding a game, and after that you really aren't coding in scratch anymore.

Complex minecraft works similarly, instead of working in redstone they make the logic gates and then the bit adders in redstone and then used programming as normal on those constructs.

[jimsmart]

In the case of his Beeb project, the 'interpreter' you speak of here is in fact a fairly full featured emulator. Although yes, the z-machine (Zork) is an interpreter of sorts.

But all of his other games - including the clones of arcade games - aren't emulators nor interpreters. They're just games, written from scratch (pun unintended), from the ground up, in pure Scratch.

After all, his day job is in fact games dev - and with 25+ years experience (I worked with him mid-90s), one could say he's a veteran in that field.

In reality, it depends on the what the game actually is, as to whether it is harder to implement than an emulator or an interpreter. e.g. I strongly suspect that Battleships was much easier to implement than the Beeb emulator was.

[jjoonathan]

Were there advantages? Or was it an exercise in determination?

[jimsmart]

He's been in the games industry for some years now, and as a side-project he teaches kids how to code — I'm pretty certain that he builds such crazy projects mostly as a fun hobby, perhaps also partly as a showcase for his teaching.

IMO, for these kinds of projects, I suspect Scratch doesn't offer many advantages (if any at all). He likes a challenge :)

— More details, including an interview, can be found here:

https://www.coderkids.com/blog/who-is-rokcoder

He's pretty responsive to comments on his Scratch homepage — and can also be found under the same name on Twitter/FB/etc. He's always been happy to help others. Give him a shout if you have any specific questions.

(FWIW: I worked with him — Cliff — for a short while, back in the 90s)

[namuorg]

Yup, I've been working on a visual browser automation tool (https://browserflow.app/) for the past year, and it's been quite the fun design problem to balance simplicity (so that it can be used by non-technical users) with flexibility (so that it can handle more than the simplest cases).

An approach that worked for me was to provide an escape hatch (in my case, giving the user a way to run arbitrary Javascript on the page being automated) so that the built-in commands could be designed for the most common scenarios and users would still have a way to handle gnarly edge cases.

[bena]

Yeah, I think the endgame of visual programming tools is to just eliminate syntax errors.

You could probably conceive of C as a visual programming language if you spent long enough time. All of your keywords can be reduced to blocks, forcing people to insert the appropriate parameters. And once you allow people to define their own blocks, you're like a good portion of the way there.

The problem is that after a while, it is simply faster to type. The breadth of options available becomes too much to manage from menus and drag and drop interfaces. Already you're probably typing in some values and names. So you're constantly switching between keyboard and mouse.

At some point, the benefit of perfect syntax doesn't outweigh the loss of productivity from not being able to immediately use any construct the language makes available to you.

[hermitcrab]

I think visual programming tools are great when they are aimed at a specific domain. but not when they try to do too much. While Scratch is great for teaching kids to code, trying to come up with a visual replacement for C++ is almost certainly a bad idea.

Also it is possible to blend the two approaches. For example by allowing users to script some of the boxes in a text based language. This is the approach I have taken with my own visual-based data wrangling tool. The standard transforms cover 95% of cases people need (re-order columns, pivot, filter etc) and you can script a Javascript transform for anything else.

[JPKab]

There is most definitely an unwinnable war between simplicity/ease-of-use and more power/customizability.

That being said, Alteryx is an example of a company that has made a ton of money via a data munging tool that is a visual programming language. The users are fanatical as well.

[hermitcrab]

It is not really a war though is it? Some people prefer visual tools like Alteryx, Knime or Easy Data Transform. Other people prefer R or Python. And some people will alternate approaches, depending on the problem at hand. Also, many 'visual' tools include the option of text based programming, for flexibility.

[DonHopkins]

I posted this about Snap! recently:

https://news.ycombinator.com/item?id=27397375

Snap! is not simply all the usability and functionality of Logo, but also all the functionality and power of Scheme! Without any of the dumbing down of Scratch or Logo. Visual block programming. Turtle Graphics. Sprites. Lexical scoping. Lambda. Closures. Call/cc. Plus JavaScript integration and web stuff. With extensions for networking, AI, machine learning, speech synthesis and recognition, graph theory, robotics, Lego, Arduino, 3d graphics, 3d design, 3d fabrication, and 3d printing, embroidery, etc. ;)

https://dl.acm.org/doi/pdf/10.1145/3386329

History of Logo. Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 79. Publication date: June 2020.

6.2 Brian Harvey’s Personal Narrative on Snap!: Scheme Disguised as Scratch (pp. 49-50)

In 2009, the University of California, Berkeley, was one of several universities developing a new kind of introductory computer science course, meant for non-CS majors, to include aspects of the social implications of computing along with the programming content. Scratch wasn’t quite expressive enough to support such a course (it lacked the ability to write recursive functions), so Prof. Daniel Garcia and I thought "What’s the smallest change we could make to Scratch to make it usable in our course?" After 20 years teaching Structure and Interpretation of Computer Programs [Abelson et al. 1984], the best computer science text ever written, I knew that the answer to "what’s the smallest change" is generally "add lambda." I joined forces with German programmer Jens Mönig, who had developed BYOB (Build Your Own Blocks), an extension to Scratch with custom (user-defined) blocks, including reporters and predicates. At that time we were hoping to convince the Scratch Team to adopt our ideas, so we took "smallest change" very seriously. BYOB 3.0 [Harvey and Mönig 2010], with first class procedures and first class lists, added only eight blocks to Scratch’s palette. (The code is almost all Jens’s. My contribution was part of the user interface design, plus teaching Jens about lambda.) Version 3.1 added first class sprites with Object Logo-style inheritance. The Berkeley course, The Beauty and Joy of Computing (BJC) [Garcia et al. 2012], is also used by hundreds of high schools, especially since the College Board endorsed it as a curriculum for their new AP CS Principles exam. Unfortunately, some teachers have no sense of humor, and so BYOB version 4.0, a complete rewrite in JavaScript, was renamed Snap! [Harvey 2019]. [18]

Since Scratch seemed to be positioned as the successor to Logo, it was a goal for Snap! to restore the features from Logo that are missing in Scratch. The most important missing feature, the ability to define functions (and therefore to use recursive functions), is at the core of the new language. (Scratch introduced user-definable command blocks in version 2.0, but still doesn’t support user defined reporters.) Scratch had also replaced the structured text (word and sentence) functions with a flat text string data type. We wanted to be backward compatible with Scratch, so we implemented words and sentences as a library, defining first, last, butfirst, and so on. (Since block languages allow multi-word procedure names, and you don’t have to type the long name in order to use the procedure, the library names are, e.g., all but first letter of.)

Lists are first class and can be arbitrarily deep in sublists. The usual higher order functions on lists are provided; the graphical representation of lambda is built into the blocks representing higher order functions, and so beginning users can use higher order functions in simple cases without thinking hard about function-as-data at all, but the full power of lambda is available to more advanced programmers. It took us three tries to get the lambda design right, but we’re very proud of its pedagogic benefits.

Another of our goals for Snap! is to be a complete version of Scheme; it was largely as a way of planting that flag that we added call with current continuation, not taught in BJC (nor even in SICP) but used to implement tools such as catch and throw as library procedures written in Snap! itself. As of this writing, macros are only half-implemented; users can define procedures whose inputs are unevaluated (more precisely, thunked, since procedures are first class), but cannot yet inject code into the caller’s environment.

Snap! is lexically scoped, not least to allow the use of closures as objects, but a planned extension is "hybrid scope": variable names follow lexical scope, but instead of giving an error message when no binding is found in the lexical environment, the evaluator will instead look in the dynamic environment. So name capture is impossible, since the global environment is examined before the dynamic environment. (Only if a mistyped name matches another name can the user get the wrong variable rather than an error message. But mistyping can’t really happen in a block language.) This, too, is an effort to be a Logo as well as a Scheme.

Since Snap! is free software (AGPL), it has served as the starting point for at least a dozen significant extensions, including BeetleBlocks [Koschitz and Rosenbaum 2012; Rosenbaum et al. 2011] for 3-D graphics and 3-D printing; TurtleStitch [Mayr-Stalder and Aschauer 2016] for controlling sewing machines to do embroidery; Edgy [Bird et al. 2013] for studying graph theory; NetsBlox [Ledeczi and Broll 2016] for access to online data APIs and collaborative editing of projects; and others. The ability to write new Snap! blocks in Javascript, from the Snap! editor, has allowed many other user-level extension libraries, including support for robots and other hardware. Snap! features such as first class procedures help authors develop these extensions, even if the users of an extension don’t see that.

[18] For non-Anglophones, "BYOB" is used in party invitations as an abbreviation for "bring your own booze."

Also:

https://news.ycombinator.com/item?id=27396842

Brian Harvey's books are excellent! Definitely check out Brian Harvey's and Jens Mönig's latest masterpiece: Snap!, a block based visual programming language with the full power of Scheme, but ease of use of Scratch and Logo, written in JavaScript and tightly integrated with web browser technologies and libraries (including Ken Kahn's eCraftToLearn AI Programming for Kids extension using Tensorflow).

Snap:

https://snap.berkeley.edu/

AI For Kids with Snap!:

https://ecraft2learn.github.io/ai/

Snap! 6 is here, and it's all about scale (HN discussion of Snap! 6 announcement):

https://news.ycombinator.com/item?id=24781716

Brian and Jens earned the NTLS Educational Leadership Award for their work on Snap!:

https://ntls.info/ntls-educational-leadership-award/brian-ha...

>The National Technology Leadership Summit (NTLS) Educational Technology Leadership Award recognizes individuals who made a significant impact on the field of educational technology over the course of a lifetime. The NTLS consortium is a coalition of twelve national teacher education associations that collaborate to advance effective use of technology in schools. The NTLS Educational Technology Leadership Award is the coalition’s highest honor.

>Brian Harvey and Jens Möenig, working together, have had an impact on the field of educational technology that is as significant as any other. The origins of their work dates to development of the first computing language explicitly designed for children. In 1966 Seymour Papert, Wallace Feurzeig, Daniel Bobrow, and Cynthia Solomon created the programming language Logo. Logo, whose name is drawn from the Greek word for word, is both a technology and an educational philosophy. Its inception also resulted in the development of an educational community that exists to this day.

>Brian Harvey had the opportunity to learn from Lisp inventor John McCarthy and Scheme inventors Gerald Sussman and Guy Steele, among others, as a student at the MIT and Stanford Artificial Intelligence Labs. Throughout the 1970s he was a frequent visitor at the MIT Logo Group, and starting in 1981 he was part of design teams for microcomputer versions of Logo for the Apple II, the Atari 800, and the Apple Macintosh. A high point of his career was establishing the Computer Department at the Lincoln-Sudbury Regional High School, in Massachusetts, offering ungraded courses that attracted a community of kids with keys to the lab and the responsibility for making the facility meet everyone’s needs.

>In the 1980s he wrote the three-volume Computer Science Logo Style, published by MIT Press. These books showed that Logo could be used beyond elementary school to introduce serious computer science ideas to a broad and diverse audience. He subsequently taught at the University of California, Berkeley, where he was recognized with the Distinguished Teaching Award, the university’s most prestigious award for teaching. He was lead developer of Berkeley Logo, which because of its status as free software has become a de facto standard for Logo implementations. Since 2013 he has been Teaching Professor Emeritus.

>On a parallel track, Jens Möenig collaborated with Alan Kay, inventor of Smalltalk, and worked with colleagues from the Xerox Palo Alto Research Center (PARC) who invented personal computing. He subsequently contributed to development of the block programming language Scratch, one of the languages influenced by Logo.

>Brian Harvey and Jens Möenig then embarked upon one of the most productive collaborations in the history of educational computing, jointly developing the block programming language Snap! The Snap! reference manual notes, “The brilliant design of Scratch, from the Lifelong Kindergarten Group at the MIT Media Lab, is crucial to Snap!.”

>Snap! makes advanced computational concepts accessible to nonprogrammers. Brian Harvey notes, “Languages in the Logo family, including Scratch and Snap!, take the position that we’re not in the business of training professional computer programmers. Our mission is to bring programming to the masses.” The Beauty and Joy of Computing, tightly integrated with Snap!, does just that. This curriculum, developed at the University of California at Berkeley, is notable for attracting equal numbers of male and female students.

>The course is approved for Advanced Placement credit by the College Board. With support from the National Science Foundation, professional development has been provided to more than one thousand high school computer science teachers. One computer science teacher who introduced the curriculum in his high school reported that, “Before using Snap! and the Beauty and Joy of Computing curriculum, I had one section of computer science with 17 students. Three of the students were girls. Now I have three full sections of the course with equal numbers of male and female students.”

>Snap!, provided as free, open source software, has inspired development of many extensions. Among others, these include environments such as Snap4Arduino, which supports work with microcontrollers and robotics; mathematics microworlds for elementary children developed by Paul Goldenberg and his colleagues at the Educational Development Corporation; and iSnap, an extension developed by Thomas Price which suggests hints to students based on the work of other students. Another extension, TuneScope, designed to facilitate exploration of coding through music, is being developed by a collaborative team at the Society for Information Technology and Teacher Education (SITE).

>Snap! is a remarkable technological achievement. However, like Logo, its greatest achievement is arguably the educational philosophy that it draws upon and supports, and the associated community drawn together by this philosophy. In a very real sense, the Snap! community embodies the spirit of the early Logo community, extending it for the modern world. The NTLS Educational Technology Leadership Award, awarded to Brian Harvey and Jens Möenig, is presented in recognition of that accomplishment.