That touches on the reason these type of ideas haven't gone further. Programming is definitionally limited to cryptic text. Anything that deviates from that, especially if it makes it non-cryptic or easy, is no longer a programming tool; it becomes a tool for lowly users. This detracts from the identity of programmers because that is tied to producing and consuming cryptic text.
I think a system build along lines to violate assumption #1 will fail if it has the goal of making assumption #2 go away as well. The complexity of many things we manage in text will either appear somewhere else, or bubble up in even worse ways (missing functionality or a system that is broken by design). I would really like to see work that is focused on attacking assumption #1. I'm not going to try to dictate that no-one should work on #2, I just think it's been tried without much success so many times.
But yeah we gotta keep doing it until we can't, and leave a breadcrumb trail for others to continue.
Inputs are named based on what cells they are entered in, and the results are named from the cells the expression is housed in.
Never mind that the scope is by default the sheet, though one can access those in other sheets with a bit extra effort.
On top of this one get instant feedback when something is awry.
not entirely sure if it is possible to expand something like this into a more general purpose IDE though.
Beware, you all, the siren song of squares labled "concatenate." They will only add to your troubles.
Ladder logic predates PLCS though- essentially the same notation was used when relays were used to implement it, and EEs were fine with that.
That said, a complicating element is that PLCs can extend the basic diagram with custom blocks...
- It's concise, clear and unambiguous. - It's easily extensible. `def foo() ...` is all you need to define new word. What do you need to do to define new block in WYSIWYG that is still meaningful to the user? - It can be diff and search. Can you meaningfully diff visual graphic? And then merge it automatically? - It's stable. Do you think source code in WYSIWYG today will be usable in the editor 5 years from now?
Typing "cryptic text" is the easiest part in programming. "Thinking clearly" is the most important part, and most people are not specifying clear instruction to be made into program. It has nothing to do with programmer's identity crisis.
Also, when you're designing a text-based programming language, you can focus on the compiler, and users of your language can just use their existing text editor. When you're designing a language with a WYSIWYG editor, you just put the burden on yourself of also implementing that editor. Potentially on many different platforms, if you want to reach a wide audience.
Every programmer will at some point try to build a system that allows users to add their own fields, rules, etc. We try to program ourselves out of a job and fail.
Disagree. My first job trained non-programmers to be proficient in Ab Initio, whose first layer was visual directed graphs. It was a data processing tool, and yes you could click into the "cryptic text", but more often, due to the visual first layer that generalized basic data operations, the code beneath was quite understandable.
It is still Turing complete and an efficient language, just a little more accessible and easier for non-developers to pick up.
Plus, there isn't much code with this setup because it's easier to add another block to the graph than it is to add code to do the same task. Here's an example of a graph [1]. You can click into each block to see its parameters [2]. Once you click into the code, it's usually just one or a few line definitions of what each output item should be.
It runs in CPU-parallel by default without any adjustments from the developer, so pretty efficient. Also it was made by the guys who started Thinking Machines in the 80s, which was the hot AI company at the time.
At the time, Ab Initio was considered a Data Warehousing or ETL tool. The most conceptually similar modern tool I've seen is Luna [3], though I don't think that's considered "Data Warehousing" per-se. Anyway, I always felt it was a cool way to write software, having a visual layer on top to describe data flow.
[1] http://1.bp.blogspot.com/_FwFkbVFfnGQ/S_V4l062fNI/AAAAAAAABO...
[2] http://1.bp.blogspot.com/_FwFkbVFfnGQ/S_V1P_C64TI/AAAAAAAABN...
I am not trying to say this is my ideal definition of programming -- I think its a pretty stupid limitation. But after having discussed and researched this stuff for years and in the context of at least 8 or 10 tools, there is some psychological issue holding us back rather than a practical one. Which is not to say there are no practical issues -- its just that numerous tools have shown that they aren't insurmountable.
I think the benefits of graph-based programming are pretty clear. Having used such a tool already, I see the benefits of being able to visualize code at the top level. In fact, everyone does, we just don't have the time or willpower to recreate the visual layer for all our code. When that visual layer is built into the language, it saves everyone time, both in building and understanding.
I don't think plain code is going away anytime soon, and it will always be an option, but I'd like to see more done in the visual top layer space, like Luna.
It has a level of conciseness like fuctional programming that I enjoy. Almost like bringing back (Turing's?) finite state machines at a higher level.
I suspect the problem to which you allude, the lack of pervasiveness of visual-based programming, has more to do with how many folks have implemented it successfully.
You may not be aware, but Ab Initio runs in a lot of big enterprise software stacks. People trained in that software are proficient in building solutions quickly with little or no CS background. Jobs in that tool remain high salaried to this day. The company is quite secretive and only licenses/trains with certain consultancies.
Are you sure that things like graphical ETL such as SSIS, graphical or automated reporting, and more generally database-oriented RAD tools are not actually fairly common?
I don't know. I guess some programmers might turn their noses up at a graphical interface at the top level. But it doesn't matter. The result was always a working, maintainable, fast tool that achieved the desired goal.
If I built a machine using sticks and stones that could accurately predict the week's weather, how many people would care that I didn't use satellites? Probably the people in the satellite industry, but, if I demonstrate my solution is better, those folks will need to adapt or face loss of wages.
I was a CS major and went to work for an Ab Initio consultancy, not realizing they also hired non-programmers and trained them. It worked fine and we replaced Java consultants all the time because their code wasn't as maintainable or as fast as ours.
I'm not claiming that graphical tools will surpass Python, but based on my experience, I think they deserve a seat at the table.
> Are you sure that things like graphical ETL such as SSIS, graphical or automated reporting, and more generally database-oriented RAD tools are not actually fairly common?
I think they are common in enterprise, but the languages are often proprietary or don't have the level of open source support that traditional programming languages have had. I'm looking forward to seeing what will come of Luna lang [1] and stuff like 2D Syntax in the future.
You previously stated,
> Programming is definitionally limited to cryptic text. Anything that deviates from that, especially if it makes it non-cryptic or easy, is no longer a programming tool; it becomes a tool for lowly users. This detracts from the identity of programmers because that is tied to producing and consuming cryptic text.
But, graphical boxes on the screen can be thought of as libraries. We don't consider libraries to be tools for lowly users, just as we don't consider calculators or computers lowly. Things that make our job simpler aren't lowly, they're empowering.
Just take a screencast of yourself doing programming in Ab Initio for some things that involve little to no textual code input. Then find three or four programmers and ask them if they think you are a good coder/programmer/software engineer. If you get an honest answer they will say you are a good Ab Initio expert but do not believe you are doing programming. I dont think that is correct but I think this dumb perceptual issue where programming is tied to cryptic text is the reason those tools are not more popular for people who call themselves programmers.
Many people have tried to "make programming easy". It turns out to be a fundamentally difficult problem.
Of course, if you believe that all attempts were stopped by the Programmer Complexity Mafia, feel free to try yourself. It would certainly be a lucrative product if you can solve the problem.
Consider: The spreadsheet is a limited-domain example. Spreadsheets are great and they caught on like crazy. They were the killer app of PCs before the Internet. And they are an easy to use not-very-textual programming tool.
No, the unfortunate truth is that making a general purpose visual language is hard and that so far text is still the best we've managed to come up with.
That was actually a frequent complaint (along with the, research-backed, complaint that WYSIWYG editors make people, whether pros or not, worse writers) in the 1980s through early 1990s. You still sometimes hear it from pros that hold to archaic word processors, long-hand, or typewriting for manuscripts, or the TeX crowd.
It wasn't effective at stopping WYSIWYG from taking over virtually everything, but it wasn't an uncommon complaint.
None of the graphical tools integrate well with the programmers existing editors, vcs or anything else very well.
They need to be represented by a textual format, carefully planned so that it is easy to manipulate in an ordinary editor with understandable diffs in version control.