once again, someone has a strong opinion on something they have never used or don't know much about. in my personal opinion, scratch and blockly have very litt

once again, someone has a strong opinion on something they have never used or don't know much about. in my personal opinion, scratch and blockly have very little to do with visual programming. they are nice little experiments but just repeat what's bad about text-based programming into visual blocks, which just compounds the issue. i honestly am surprised mit and the media lab have dumped so much time into scratch. i have said this before, but the most productive visual programming language and environment is labview. it certainly has its problems, and i am a big critic of it, but its visual programming style and dataflow paradigm are more powerful than people realize. it has some seriously good ideas that aren't found in many other languages, and it had many innovative features well before other languages. for example, doing concurrent programming in labview is a breeze. on the other side, you see that modern IDEs are starting to add a lot of visual content to help the programmer out. the languages remain text-based, but the environments are adding visual features. i think that there is a lot of untouched ground regarding hybrid environments and languages that merge the ideas of text-based programming with visual-based programming. in addition, the dataflow paradigm is also underused. there's also other computation targets other than CPUs such as FPGAs. it's silly in verilog and vhdl how you often have to manually label up wires where in labview, the tool and language do that for you. you simply draw your circuit out as you would in a diagram. common complaints against visual programming have almost no weight. for example, "oh, you can't diff visual programs like text programs". yes you can. it's not like computers were gifted by god text-based diff programs. these things were developed and iterated on. labview has a diff mechanism. it isn't great, but my point is that people view text as some sort of innate trait of programming and all the tools are "natural" and already exist as if they just poofed into being once programs started being written. but if we put some thought and work into the tools for visual programming, similarly to how it has been done with text programming, it's possible to create really powerful environments and languages. where visual programming languages often have a ceiling is abstraction. for example, labview has object-oriented features, but it doesn't go far. i program on the side in f# and racket, which have an amazingly high ceiling for abstraction, but interacting with these languages is often frustrating coming from labview. there are many things that are simply easier in labview. some of that is tooling. some of that is the visual language and dataflow paradigm.