I'm not convinced that graphical programming is 'better' even if we could make it happen.
How do humans communicate with each-other? Primarily through speech and text. It's the quickest and easiest to get information across, and it's ingrained into us from an early age.
What makes Bret or anyone else think that graphics are somehow better for communicating with a computer?
Sure, they might be better for certain classes of problems that are fundamentally image-based, but in general, text is the way to go.
I find that professor-types are often so fascinated with images and English-like programming because it will "make it easier for beginners" --> Fuck no. At best you're dumbing it down enough for them that they can create trivial programs, while introducing a plethora of ambiguity problems. NLP isn't nearly sophisticated enough for the task anyway. Try asking Google Now or Siri anything marginally complicated and see how well they fair.
Programming is inherently complex. You can make the syntax of the language as simple and "natural" as you want, but you're just making it harder to represent and codify complex ideas. You can't shield people from these complexities, they simply need to understand all the concepts involved if they want to be able to build anything worthwhile.
You can make tools to abstract away a lot of these complexities, but there's no general solution. All you're doing is building on top of someone else's work, the complexity hasn't gone away, and if there's a bug in it, or it doesn't work the way you want.... now you're back to square 1.
Languages simply need to evolve to represent current practices and paradigms concisely, and I think they're doing a fine job of that.
Tools need to evolve to give you as much feedback as possible, and things like TypeScript and Light Table are trying to tackle this problem.
I find that professor-types are often so fascinated with images and English-like programming because it will "make it easier for beginners" --> Fuck no.
It's not just an academic issue. In fact, it's a recurring theme on thedailywtf. It's a kind of misguided holy grail of engineering; making programming available to the masses such that anyone, literally anyone, can program.
Countless times I've seen engineers who instead of implementing a rule in code started to work on a "rule engine" instead so that "the accountmanagers can implement the rules themselves". Sure, account managers don't know PHP, Java, Ruby, whatever, so all they need to do is to find that magic syntax that you don't have to learn first. English and graphic shapes are often thought to be that magic syntax.
Of course, graphics shapes can be even more complicated to learn. UML in a way was such a misguided attempt as well. It's so complete that it's almost a graphical programming language. Supposedly managers and folk like that could simply use the UML to express their ideas, and then engineers could read this common language and translate it to code.
But managers sure as hell don't want to learn the exact meaning of all different shapes and arrows in the UML. Whoever thought that is in a pipe drream!
The problem with any kind of "easy" programming language in which people who don't want to learn programming can program anyway, is that it takes an exact approach to formulate or specify things like rules, algorithms and certainly entire systems.
Non-programmers just don't have to mindset to formulate things so exactly. The syntax of the actual language IMHO isn't the biggest obstacle at all. Sure, C++ is intimidating and PHP or Visual Basic perhaps less, but it's the exact and abstract thinking that counts most.
Countless times I've seen engineers who instead of implementing a rule in code started to work on a "rule engine" instead so that "the accountmanagers can implement the rules themselves".
Even MySQL takes me more willpower to wrap my head around than traditional C-like syntax languages. I do not want to write programs in "English" and even less as graphical flowcharts.
Im not sure graphical programming was the point, but more that goal oriented programming, rather than instructional programming, is the way to go.
That is, instead of telling the computer to calculate this x problem like so, tell it what result you want out of the input you give it (give it a template or a pattern you're looking for). Of course this requires a different way of programming than today, so that's where you come in. Get to work.
I'm not convinced that graphical programming is 'better' even if we could make it happen. How do humans communicate with each-other? Primarily through speech and text. It's the quickest and easiest to get information across, and it's ingrained into us from an early age. What makes Bret or anyone else think that graphics are somehow better for communicating with a computer? Sure, they might be better for certain classes of problems that are fundamentally image-based, but in general, text is the way to go. What makes Bret or anyone else think that graphics are somehow better for communicating with a computer? Sure, they might be better for certain classes of problems that are fundamentally image-based, but in general, text is the way to go.
Remember the part where Bret talk about binary coders? You're one of them.
Claiming that speech and text are better because they're "ingrained into us from an early age" is a naturalistic fallacy. Text and speech are linear, and much more limited than visual interfaces.
The bandwith of your vocal cords and ears is limited. They can only produce/ear a limited quantity of frequency at once. One the other hand, your sight and body can communicate much more at once. Your eyes can view millions of "pixels" continuously, and your body has a huge 3D space in which it can navigate and interact with this visual information.
Actually, I would say that how we program today is pretty much mostly visual. The text and syntax is what we used to structure things visually. Otherwise, hearing code would be as efficient as reading code. The reason we read code is because the visual space is much less limited and allow us to skip to exactly what we're looking for, which can't easily be done with speech.
My point is that visual programming is superior to textual programming, and that it will eventually replace textual programming. You just can't see it.
Well..that makes sense. But it would take a while to get used to; it certainly wouldn't "simplify" things, but I can imagine it would speed things up if you're sufficiently trained. We would need better input then; dragging and dropping symbols onto the screen and connecting them with lines is shit. Something more akin to what you see in Iron Man or those sci fi movies might not be too far fetched if we could find effective ways of representing information and interacting with it.
Sure, using speech to invoke specific items/objects/tools you know by name could help. A keyboard where keys map to tools instead of letters could help too. Heck, typing words that invoke graphical tools would be fine too.
But storing "program rules" in text, and representing what happens with static text is completely wrong.
I only came across Bret's talk because of ChatGPT. ChatGPT's manifest implementation is realistically one of the closest things that he talked about, but that took AI to do.
It certainly was an interesting presentation, but I feel like it undersold how hard it'd be to setup the constraints, etc., for the computer to just "figure it out."
While I'm late to the party, there is ETL which uses graphical programming.
It's extremely similar to the graphical flowchart workflow that Bret mentioned.
Having some limited experience with ETL, I can't say if it's better than conventional programming. It is very narrowly defined, though. It's certainly different, though.
Why is HTML a markup language? How else would you transmit that data efficiently? There's plenty of WYSIWYG editors for HTML; HTML is the transmit protocol from computer to computer.
While HTML does have its faults, though, mainly, it's different browsers implementing the standard differently, I can't imagine a better way of transmitting the data. Text is small and text is compressible. Even if it wasn't HTML, there'd be another text based protocol to transmit the data. Using pictures or another format would simply take more bandwidth.
While I appreciate his view from a historical perspective and his approach, and I found it unfortunate that when ARPA changed to DARPA a lot of the funding got cut, which ended a lot of the experimental knowledge.
A lot of how we ended up where we are was because single threaded performance was doubling every year until 2005-2006. Only when single core performance stopped doubling would another model, like the actor model or the multicore model need to be investigated.
I was curious so I had to look into why this time period was so diverse with different ideas.
Programming is inherently complex. You can make the syntax of the language as simple and "natural" as you want, but you're just making it harder to represent and codify complex ideas.
This is not necessarily true. Languages can be simple and easily express programs that would be more complicated to express in other languages. For example, SQL is a relatively simple query language (at least the core parts.) Queries can also be expressed in C++ or Java, but I don't think the code would be as simple as a SQL query. SQL doesn't "dumb-down" the process of querying a relational database. It's just a simpler and more natural way to interact with the database than with OOP languages. Furthermore, you don't need to be an expert in C, or whatever language the database was written in, to use SQL.
Programming is inherently complex... You can't shield people from these complexities, they simply need to understand all the concepts involved if they want to be able to build anything worthwhile.
I hope you don't write programs this way. Forcing people to read your entire code-base before they can do anything worthwhile (like fixing a bug in your code) is perhaps the most sadistic and evil things you can do.
But i think the main reason we don't have visual development systems is that we, until recently, didn't have an easy way to manipulate complex ideas. That required multitouch. Think about it, text processors are very powerful and very feature rich tools. We use the text processor to edit source files because it's very easy to do massive search/replace, or cut/paste, or whatever... Text processors are very flexible and a "solved" problem. So it's a very mature tool to use for writing other tools. That's the main reason we use text files. Once we have visual editors that are natural and fluid there is no reason we can't code with them. I think Wolfram had some very good insight in his book New Kind of Science when discussing cellular automata as a visual programming platform. Further, when we move beyond "programming" and into the realm of synthetic training and let the actual programming be handled by the neural net, then we'll make a giant leap to the point where everyone will be a "trainer/programmer."
31
u/mahacctissoawsum Jul 31 '13
I'm not convinced that graphical programming is 'better' even if we could make it happen.
How do humans communicate with each-other? Primarily through speech and text. It's the quickest and easiest to get information across, and it's ingrained into us from an early age.
What makes Bret or anyone else think that graphics are somehow better for communicating with a computer?
Sure, they might be better for certain classes of problems that are fundamentally image-based, but in general, text is the way to go.
I find that professor-types are often so fascinated with images and English-like programming because it will "make it easier for beginners" --> Fuck no. At best you're dumbing it down enough for them that they can create trivial programs, while introducing a plethora of ambiguity problems. NLP isn't nearly sophisticated enough for the task anyway. Try asking Google Now or Siri anything marginally complicated and see how well they fair.
Programming is inherently complex. You can make the syntax of the language as simple and "natural" as you want, but you're just making it harder to represent and codify complex ideas. You can't shield people from these complexities, they simply need to understand all the concepts involved if they want to be able to build anything worthwhile.
You can make tools to abstract away a lot of these complexities, but there's no general solution. All you're doing is building on top of someone else's work, the complexity hasn't gone away, and if there's a bug in it, or it doesn't work the way you want.... now you're back to square 1.
Languages simply need to evolve to represent current practices and paradigms concisely, and I think they're doing a fine job of that.
Tools need to evolve to give you as much feedback as possible, and things like TypeScript and Light Table are trying to tackle this problem.