Yes, I agree. But not surprisingly, this is not easy to solve. You need a visual language as a consistent concept and then you need a actual visual framework, rendering it all, and enabling user input. You need a compiler compiling forth and back, between text and visu.
And then it needs to scale. And be performant enough to actually work with it and not just have a visual demo.
Sounds hard? Trust me, it is.
It occurred to me that data isn't like water, or electricity. Those are generic resources that can largely be easily standardised and treated consistently by any device. Data isn't like that.
Data formats and encoding vary hugely and can have crazy different properties. It's more like piping chemicals between devices in a chemical factory. You can't just take the output from a device producing acid and plug the pipe into the input of a device that's designed to process water, or ammonia, or petrol. They're all 'just' fluids and you can pipe them about, but their properties vary wildly. You can only feed one into a device as input if that device is specifically designed to process that specific material.
Yes it is possible to define standardised data formats, up to a point. XML, JSON, CSV, etc but even then you can't just feed arbitrary JSON into every program designed to ingest JSON and expect it to work, just because the data it expects is JSON formatted.
Yes Unix has pipes, but each tool in the pipe chain has to be told exactly how to process the specific input it gets from the previous tool. You can't just look in history for two arbitrary examples of using pipes, and cut and paste the first half of one pipe chain, and paste the second half of another arbitrary pipe chain on the end, and expect to get something useful out of the combination. Maybe you'll get lucky, but usually you'll get garbage.
Well, electricity is not really easy either. There is a huge effort, to transform the current in the needed shape (voltage, current, frequency, DC vs. AC, smoothened... And water is also not just water, as it can be clean drinking water, or sewage water, or hot (but slightly dirty) water for the heating, or you have hot, high pressured steam, ...
Not just coding is complicated ;)
I think it comes back to "No Silver Bullet" and what it has to say about accidental and essential difficulties.
There may be impurities in water, yes, and it can be several temperatures, but water is water is water. It's still chemically two hydrogen atoms connected to a single oxygen. We can define what pure water is. Having that definition allows us to define tolerances for how much "not-water" is in the water. What kind of pipe is necessary to deal with the not-water, etc. The essential difficulties of plumbing and water management are never really about the water, it's about how to deal with not-water.
Same with electricity, the way it moves may be differing, but it's still just electrons. There's no special electricity that will conduct through rubber. Again, we can define what electricity is. And again, having those definitions, we've moved our essential difficulties to the not-electricity part of the problem.
There is no standard "data". We cannot define what data is. Because it kind of is everything. It's a nebulous, abstract concept. It doesn't mean anything on its own. What we really want to do is process subsets of that data. And filtering to that subset is the essential difficulty. And then you have the issue that two consumers of data could want similar data, but not quite. So data's essentially difficulties come sooner and once you've transformed your data into water, you still have more essential difficulties to handle.
For example, lets say you want to code to check that your electric setup is right. Then you implement the concepts voltage, current, frequency, DC AC etc, and run it to see what the end result looks like. Coding this is of course more complicated than learning about the concepts in the first place. And as have been said many times before, coding this system is often the easiest part of the job, then you have to add all the helper systems, the UI etc, and that is the really hard part that often is the reason projects fails.
Of course taking electrical engineering in college is way harder than software engineering or computer science, but that is because the software engineering and computer science tracks in college are usually a joke. If you had to be able to code systems as described above then it wouldn't be easier at all.
I'm not a functional programmer, but don't monads aim to do something like that?
And they only understand byte streams, which are the simplest possible abstraction.
> Or like electrical devices, just channel the data between them.
If you get to that level of precision, there are visual tools for logical circuit design. But I don't think that's what the author had in mind.
Ever played SpaceChem?
The journey of media from print to VR. While it'll certainly take more than 1000 words to program the painting in VR, if a million people see it, the value ratio is pretty good.
I don't remember where I hard that, or close to it, but there's a lot of truth to it. There do seem to be some very useful visual logic and work flow tools, I hope that continues, but there's something magical about the ability of language to explain, describe and precisely define things.
Maybe eventually we'll arrive at a state where really good programming environments incorporate the advantages of both textual and visual tools in a powerful and dynamic way. I love films and picture books, I also love novels, but even the best novels are enhanced by really good illustrations and sometimes even maps. Some authors find visual tools like relationship maps and even geographic maps help them in the actual authoring process too.