I've actually wondered why there hasn't been more exploration into visual / declarative programming since it has the appeal of being very easy to get started.
It's commercial and proprietary software but it has an open-source "cousin" called Pure Data.
Both applications were created by Miller Puckette and his creations inspired a lot of more or less similar systems.
One worth noting is vvvv. It doesn't have musical programming roots and uses some unique and really powerful concepts to make graphics programming easier. http://vvvv.org/documentation/of-spreads-and-slices
Also it's a very pragmatic system which is built and maintained by people who do really cool and sometimes complex projects. http://www.meso.net/vvvv
Oh I just remembered there was a successful kickstarter for flow-based IDE. The interesting thing here it demonstrated some interest from the general public. http://noflojs.org/
Subtext (http://subtext-lang.org/) - in particular check out the video on "schematic tables," which is very immediate and direct like Excel but better for general purpose.
Some of Bret Victor's work: Inventing on principle (http://vimeo.com/36579366) Media for the Unthinkable (http://worrydream.com/MediaForThinkingTheUnthinkable/) He has a lot of examples of similar interfaces for more domains than just what Excel is good at.
Another example, although much less so, is Unity's editor- property editing and level editing are very immediate and visual even for things like behavior.
Hundreds of thousands developers are still pissed at Microsoft in 2014 (according to Wikipedia): http://en.wikipedia.org/wiki/Visual_Basic
(I moved on to various other languages, but I still have VB in fond memories.)
Looks like Microsoft was correct in their assessment of shooting VB6. Nobody using it was willing to pay money.
There's just no money in doing so.
People used VB6 because it was easy and cheap. They're not going to suddenly turn around and start spending 7 figure sums of money. They'll just hobble along until they don't make a computer that can run VB6 and Windows XP any longer.
Does it, really? I spent the last 2 years building systems that ran off of workflows (as in flowcharts), and I think now that they don't make the big hurdle (capability for abstract reasoning) any easier at all.
They are fine to document and communicate things, but as input they are just flawed (except for some very very specific niches).
That last property is one of the reasons I think that flowcharts can work in some niches (like video and audio processing).
The flaw is to assume there is only one mental model that Visual Programming Languages should operate under: say only workflows for example (a mistake all VPLs I've seen have done). This is like assuming that there should only be object-oriented programming when there are other methodologies we use as programmers to form mental models such as declarative programming, functional programming, structured programming, etc.
It doesn't make much sense to code out mathematical equations using flow charts.
A VPL which supports multiple mental models is able to best represent behavior based on specific business domains. The right tool for the right job.
To me, this sounds like someone in the literary field of the arts telling an artist or musician that those fields of the arts are not directly useful.
Music and art? Those visual (and aural) embellishments are not directly useful.
There was a great HN post (https://news.ycombinator.com/item?id=7543691) on visually stunning math concepts. What you are implying is that coding out a mathematical equation as opposed to representing it using actual equations (http://i.livescience.com/images/i/000/036/119/original/minim...) is a visual embellishment that is not directly useful?
> Functional VPLs have the same abstraction/scaling up problems as OO VPLs.
This could be a problem with VPLs or it could be a sign of some root cause problem(s) with how we code today. Perhaps, there are better programming abstractions/methodologies that work equally well as words (source code) and as VPLs.
> This could be a problem with VPLs or it could be a sign of some root cause problem(s) with how we code today. Perhaps, there are better programming abstractions/methodologies that work equally well as words (source code) and as VPLs.
The language center of our brains evolved 50-100 thousands of years ago, which eventually led us to technology and civilization (things really pick up after we discovered writing at about 10kya). The reason we use words for programming is that we are biologically evolved for that. Are you seriously suggesting that there might be a better way for us to communicate and express ourselves concisely?
http://upload.wikimedia.org/wikipedia/commons/e/e2/OrteliusW...
http://upload.wikimedia.org/wikipedia/commons/thumb/5/5e/Joy...
http://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/Exp...
http://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Maq...
http://upload.wikimedia.org/wikipedia/commons/2/2e/Radial_en...
War and Peace has been made into a movie at least half a dozen times.
I've never suggested any such thing. In fact, I hinted at just the opposite when I wrote
"The flaw is to assume there is only one mental model that Visual Programming Languages should operate under: say only workflows for example (a mistake all VPLs I've seen have done)."
I wrote a blog post on VPL - Snapshots (https://news.ycombinator.com/item?id=7274674). The pattern I noticed on these VPLs (of which there are close to a hundred in that list now) is that they all attempted to use a single mental model (some are flow, some are spatial, some mathematical, etc.). None of them support different mental models (say flow based when defining business process and mathematical when defining equations).
The flaw is assuming a single mental model can be used to most efficiently describe all real world systems. Given a real world system, there may be one or more approaches used to efficiently describe that real world system in a computing device. That mental model could be textual, it could be visual or it could be both.
Taking the position that no VPL(s) exist that could better describe a particular real world system better than a textual language is standing on loose ground. Perhaps a general purpose domain agnostic VPL doesn't exist (yet), but VPLs shine for some domain specific solutions (gaming engines for example).
> Are you seriously suggesting that there might be a better way for us to communicate and express ourselves concisely?
I'm suggesting that to assume otherwise is limiting our chances of growing Information Technology as a community. I'm suggesting that if we "get it right" then our programming abstractions would be equally useful and descriptive in both a textual and visual language formats.
I remember this post and participated :) I've also designed and built my share of visual languages and have been studying this field for about a decade now.
> The flaw is assuming a single mental model can be used to most efficiently describe all real world systems.
There are two things going on here: the paradigm of the language that guides but restricts its users, and the notational syntax of that language that limits its expressiveness and abstractive power. You seem to be conflating them together, but paradigm is separable from notation (textual flow-based languages are common), while notation is solely related to the textual vs. visual debate.
> That mental model could be textual, it could be visual or it could be both.
When you think about something, do you not talk to yourself? I have only my own experience to go by, but it takes some effort to call forth images and it definitely interrupts my ability to think through something.
> I'm suggesting that to assume otherwise is limiting our chances of growing Information Technology as a community.
I am suggesting that our love of words and text is biological. We also have capabilities for sensing space, color, and so on, but these are adapted more to experiencing and reacting rather than communicating. If it is indeed a biological limitation of human beings, then it would be impossible to get it right enough (though I could be wrong, and please try if you think otherwise).
"It (Visual Thinking) is common in approximately 60%–65% of the general population." - http://en.wikipedia.org/wiki/Visual_thinking
http://en.wikipedia.org/wiki/Autism_spectrum
An amazing lady: Temple Grandin. (https://www.youtube.com/watch?v=fn_9f5x0f1Q) (http://www.grandin.com/inc/visual.thinking.html)
I happen to lean towards visual thinking. I can see and run systems in my head. When I see a mathematical equation I understand, such as f=ma, I feel momentum and see acceleration of shapes in my head. If I can't form that mental picture, I can't do the math. It sucks because even though I can do all of that in my head, I can't remember your name. This is just me. People don't think the same way.
Now, let's considering the situation where source code is the only way to program a computer. This leads to a self-fulfilling prophecy where a majority of the programmers are a certain types of thinker. Sure, people can think using different approaches (as you pointed out: "but it takes some effort to call forth images and it definitely interrupts my ability to think through something"), but it isn't easy for them. It takes extra effort.
> paradigm is separable from notation
I guess I may be conflating them because I see paradigm as driving notation and/or notation can drive paradigms. But perhaps this is a result of how I understand things.
The brain is a fascinating piece of hardware, especially how it supports language. For example, I would guess OOP is more suited to human thinking because language (and hence metaphor) is supported directly in the brain while mathematics is a more recent invention that we have to "learn."
I guess there is a reason research in visual programming started the whole field of HCI. Good luck with your work!
[1] http://www.forbes.com/sites/timworstall/2013/02/13/microsoft...
When I worked in a (science research) lab, we had a few Excel files we passed around for performing various calculations. These were great in that my non-computer-fluent boss could use them (and even contribute). There were a few input boxes to fill out which were run through some calculations, and the answer spit out.
Pros:
* Single file
* Everyone has Excel installed on desktop
* Accessible. Even if you're not an Excel wizard, you can see and edit the basic formulas.
Cons:
* Rigid grid (Any documentation, notes, etc. must fit into the grid)
* Formulas are hidden, when you might want to highlight the most critical ones
* If you want to calculate intermediate results (which you do, to prevent very long formulas that are hard to read), you've got to plop them in some cells
* No meaningful variable names, A10:A55 what?
Excel is so entrenched, it'd probably be difficult for a slight improvement to gain any traction, but it would have made my life a heck of a lot easier.
And I'm by no means an Excel wizard, so there's a good chance that some of the Cons above can already be avoided... But I still want some kind of hybrid of LabVIEW and Excel.
Massive files especially is something Excel "should not be doing" for superficial technical reasons that are mostly unrelated to whether the UI is a good fit. "Enormously complex formulas" do call for better editors, but again don't damn the model.