HyperCard had most of the features that Chris Granger talks about when he talks about LightTable. In HyperCard, you can see all the variables as they updated, as your program ran. There was no real compile step, you could hit "Run" and watch you variables change as the program ran.

You can read more about it here:

http://en.wikipedia.org/wiki/HyperCard

Apple eventually abandoned HyperCard, as perhaps it became obsolete in the era of the Internet. I believe we will again have something like HyperCard, in the future, but not while we still have the document model imposed on us by HTML. The Internet will need a new protocol for apps, rather than documents. When that day comes, I suspect we will see something like HyperCard return. People like Chris Granger are already doing very cool stuff with Javascript and LightTable, but they are forced to work within the document paradigm (with a hierarchical DOM) which is not a good fit for applications.

A bit off-topic (sorry), but that's a good point. I believe it would be great for a future version of HTML to have two 'profiles', one for documents and one for apps. The document metaphor is great for, well, plain documents, but it is problematic for apps, like Gmail. For example it can be annoying if you have JS-heavy sites which break document-related features (navigation, resizing, printing, copying).

Have a document profile where you have all the markup features, but the javascript features are possibly restricted. This corresponds to a lean version of HTML5. You know HTML6-doc pages will look reasonable and load quickly on all devices, including on ebooks and printed out.

Then have a app profile where you don't even need a document - you can just draw on canvasses if you want, but you can also create HTML elements. I imagine that people write GUI libraries for it. You have access to all fancy modern JS features, like sockets, webcam, etc.. This would be the time to change the wierd security model of HTML - a page with the DOCTYPE HTML6-app would opt into a new model, where pages don't have access to all credentials and cookies by default, so it is reasonably safe to give them net access (they can't buy stuff if you are logged into amazon in another tab, for example).

The best thing is, we can start using these new paradigms today - and maybe have nice little badges to show we are following the new "best practice" :-). Restict yourself to minimal, presentational, progressive-enhancement JS for documents, use semantic markup, check that it looks good on all devices etc.. And when you are doing a (single-page) app, it doesn't have to look like a document, but heed all the advice for non-web desktop or mobile apps - and make sure your app doesn't break navigation.

It's probably the first visual programming that "made sense" to me. Its use is limited to UE4 games, of course, but I think its design would be suitable for more general use.

[1] https://www.unrealengine.com/blog/blueprint-basics

This isn't exactly ment for Programmers, but level designers going one step further. Besides that, it offers accessibility that is very immediate. The visuals can provide a direct feedback of the signals processed (may the movement in the background not be random), relating the properties of the signal to other signs than textual symbols (e.g. to show a color's hue just dye the slider).

I don't see how the inclusion of support functions and classes for engine interaction implies that Blueprint's language design is "sure-as-hell" high-level, per se, but in practice you're right that its design case is pretty high level.

I also think it's inevitable in the long run, but developing them properly still has similar complexity as building IDE plugins except now having the IDE replaced with a 'language plus some form of IDE.'

LightTable really seemed to be on the right track there, but from what I can tell it has fallen prey to the curse of Lisp with Chris seemingly moving on to an even more awesome language project instead of putting in the hard (and probably quite boring) work to get visual augmentation to the masses.

The curse I speak of is http://www.lambdassociates.org/blog/bipolar.htm Not that I'm implying Chris is bipolar at all but it's an apt description of the trap many great Lispers fall into.

We started to hit roadblocks with our current paradigms and we happened to get lucky enough to stumble on some ideas that could move us forward. What we're working on now is the foundation necessary to do things we've always wanted to do (and awesomely, far more).

We'll be announcing some cool stuff soon, but the gist is that we have to look at the whole stack to find something better. So that's what we're doing.

Just meant that the dream, or more precisely my dream, of LightTable is delayed/put aside by this new project.

The curse of Lisp, to me, is being pulled into ever deeper more beautiful solutions, which you're definitely flirting with, but it's also just an allegory so I really hope you pull it off!

Any hints? I'm extremely curious!

"I want to look at the brilliant failures. Because brilliance amd failure are so often mixed together and our initial reaction is it shouldn't be. But it happens and it happens a lot... Another feature about this guy is his low threshold of boredom. He'll pick up on a task and work frantically at it, accomplishing wonders in a short time and then get bored and drop it before its properly finished. He'll do nothing but strum his guitar and lie around in bed for several days after. .... Generally he would come alive in the final year project when he could do his own thing and hand in something really really good. Something that would show (shock, horror) originality... The 'vision thing' as George Bush Snr. once described it, is really one of the strengths of the BBM. He can see far; further than in fact his strength allows him to travel. He conceives of brilliant ambitious projects requiring great resources, and he embarks on them only to run out of steam. It's not that he's lazy; its just that his resources are insufficient."

This essay, "The Bipolar Lisp Programmer", does a good job of describing Chris Granger and his experience with LightTable, which is exactly the point that mtrimpe was making. There is nothing unfair about the comparison, it is exact.

Achieving your vision is a long, arduous, and mostly thankless process. And frankly, being in the limelight can make it much harder because people are impatient and constantly judging you.

https://www.google.com/search?q=the+curse+of+lisp&oq=the+cur...

There has been much debate about why Lisp has not taken over the world of computing. It was invented in 1958, it was taught in all the best schools, yet it has not gained mass traction. Paul Graham has touched on this issue in one of his essays:

"So if Lisp makes you a better programmer, like he says, why wouldn't you want to use it? If a painter were offered a brush that would make him a better painter, it seems to me that he would want to use it in all his paintings, wouldn't he? I'm not trying to make fun of Eric Raymond here. On the whole, his advice is good. What he says about Lisp is pretty much the conventional wisdom. But there is a contradiction in the conventional wisdom: Lisp will make you a better programmer, and yet you won't use it. Why not? Programming languages are just tools, after all. If Lisp really does yield better programs, you should use it. And if it doesn't, then who needs it?"

http://www.paulgraham.com/avg.html

This issue has been discussed and debated for decades. Your statement "it is not limited to Lisp" is simply ignorant. There is something special about Lisp: no other language has received so much praise and so little use. Essays like the Bipolar Lisp Programmer are important contributions toward understanding what the problem is. And when a real-world example appears, it is utterly stupid to ignore the fact that what you are looking at is a real-world example. Your comment "worse (not everything we wanted) is better (but still better than what's out there)" is a non-sequitur, since the quality of Chris Granger's work was never questioned.

If you actually look through the Google results, there are not that many 'essays' about that topic.

> There has been much debate about why Lisp has not taken over the world of computing. It was invented in 1958, it was taught in all the best schools, yet it has not gained mass traction.

This fate is shared by a lot of things.

The whole idea that Lisp needs or will get 'mass traction' is just complete bullshit. There is no reason for that expectation.

> Your statement "it is not limited to Lisp" is simply ignorant.

No, it isn't. The whole idea is just unscientific bullshit.

> There is something special about Lisp: no other language has received so much praise and so little use.

So, what. Lisp exists since 1958. During the last 50+ years people have written a lot about Lisp. That's it. There are now many times more articles published in the past year about Java and its ecosystem than over Lisp during its whole lifetime.

> Essays like the Bipolar Lisp Programmer are important contributions toward understanding what the problem is.

Tarver has very little idea what he is talking about. He lives in his own world. Everybody at an university has seen similar behavior in different contexts. But I would not call it 'bipolar', because this is just a bullshit label, failing to describe anything credible.

Lisp got used in a lot of innovative projects often in a R&D and University context. As a rapid prototyping tool, as a research vehicle, ... That their 'products' are not polished and tend to fail, is just normal. Innovation fails a lot. Also Lisp was often a prototyping tool. Prototypes tend to be reworked into products using a different technology. Just like somebody makes a prototype using a high-end CNC machine and later uses different production technologies for mass production. It also attracts people, who are innovative. It's just like startups, which fail a lot.

That's just it. Move on nothing to see.

There are plenty of languages that have received lots of praise but little use. Erm, Haskell anyone? And you really have to clarify what "use" means, because Lisp is definitely used. Again, I see no relevance.

My comment on "worse is better", it is also Lisp oriented (well, more specifically CLOS). You should look it up.

Interestingly, the "other big Lisp advocate" just happens to also advance the idea that programming against constraints is good for the same reason you mention, except that he used examples of famous composers rather than painters since he's a musician himself[1].

[1] http://www.infoq.com/presentations/Design-Composition-Perfor...

Neither is based on Mathematica.

edit: What I mean is that iPython Notebooks are one of the few toolkits that are starting to take hold in academia in applications where Mathematica rules. Nobody in "serious number crunching academia" uses Clojure.

I checked it all into iPython and then poked around playing with the equations to get a grasp of how they worked and what sane outputs would be, it was an incredibly powerful experience as it allowed me to visualise what was happening in a way I'd never been able to before, it also made me think there is a huge gap in the way math is taught in the UK, if I'd have had iPython when I was 15 I might not have needed to resit.

Firstly, simulation of dynamic systems in systems such as Simulink (Matlab) and Xcos.

Secondly, PLCs are frequently programmed via ladder diagrams (though I'm not sure of what tools are used to translate between the ladder logic and the machine code).

What these have in common is that there's a fairly simple mental mapping between the desired behaviour and the feedback loops involved, and the inputs and outputs are quite simple (though the emergent behaviour of the system may be quite complex). What this suggests, though I can't prove it, is that visual programming is attractive for simple layouts but becomes unattractive as systems become more complex and there's more possibility for coupling in the system to produce a visual mess.

Code Bubbles isn't visual programming as the term is typically used, it's just a way of organizing text in a more meaningful way.