This is the 3rd or 4th time I've seen a proposal for visual programming environments (e.g. see http://cs.brown.edu/~spr/codebubbles/*, LightTable, this one, probably others) and I'm not sure why they don't take off. On the one hand, they seem incredibly useful and I really like Code Bubbles' approach to automatically pulling in relevant code (http://cs.brown.edu/~spr/codebubbles/bubbles01.gif). On the other hand, none of the projects seems to have significant traction (though LightTable seems to be growing). Are existing environments good enough? Is there an impedance mismatch between existing languages and visual code-design/programming?
* I really thought CodeBubbles was clever and I'm sorry that it appears to be defunct...
The one that really worked was HyperCard. Though it is now forgotten, it had a large following back in the late 1980s and early 1990s. It was also used to teach programming to children in some elite private schools (maybe it also made it into the public schools?). Danny Goodman wrote a book about it that some of us remember fondly; it was as good an introduction to basic programming as anything ever written.
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.
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.
> The Internet will need a new protocol for apps, rather than documents.
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.
I wouldn't really call it "high level" -- it appears to me to interface pretty directly with underlying C++ classes and methods, and the actual flow of the code is exactly a sort of single-threaded flow of "ordinary" programming languages.
With the amount of supporting and abstracting classes supporting the wrapped ones, of grunt work done already, it sure as hell is high level. Visual Programming is not a paradigm like functional or declarative. In this case though, it offers separation of presentation and implementation, if that makes any sense. I never quite grogged that idiom.
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).
Blueprint follows a pretty strict procedural design, but it executes it quite well. It's easy to imagine Blueprint's design used essentially to write something like vanilla C (without support for preprocessor).
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 think people are still underestimating the complexity and raw hard work involved in making these visuals scale.
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.
That is unfair. From what I understand, Chris and company had ambitious goals for lighttable that were not achievable because of the Clojure programming model, so rather than give up, they are taking the next step that they see as necessary.
That's correct. There are so many things we'd love to do with LT, but the truth is (as Sean knows quite well) our current programming models simply don't support a lot of the experiences we should have.
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 to be clear... I know what you're building and totally rooting for you!
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!
Did you read the URL that they just posted? You are re-stating "the curse of Lisp" in just a slightly different way. To quote the article:
"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.
I'm sure that exists, and it is not limited to Lisp, but it is a crazy horrible label to apply to specific people, especially when they produce something in a "worse (not everything we wanted) is better (but still better than what's out there)" fashion. We reach points where we realize our original vision isn't achievable or even desirable, and adapt it to fix those problems. That doesn't mean giving up or getting bored, that is just being realistic.
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.
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?"
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.
ESR knows nothing about painters. The painter knows there is never a "best" brush, just different ones. Painters often thrive creatively via constraints, and so the uber brush would actually be unwanted anyways. But I don't see what is relevant here.
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.
Actually, the quote is from Paul Graham, who does happen to know a little about painters, being one himself. Also, he wasn't claiming that Lisp is the "best" brush, only that it is analogous to a brush that will make you a better painter… somehow.
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].
> "The curse of Lisp" is a well known phrase that's been used in hundreds of essays:
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.
You just made some new friends. (seriously, love your attitude (shit, I still sound snide (not being snide, {although parens are making it look that way})))
The notion of a Lisp curse and the Bipolar Lisp Programmer is just bullshit. What he describes, true or not, is not particularly tied in any way to Lisp. He perceives it, because he lives in his bubble surround by his Lisp dialects and the attempts to make it popular.
LightTable started from Clojure. Larch is based on Python.
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'm not a mathematician but last year iPython saved my bacon big style when I suddenly needed to convert a dozen pages of dense math to an API with no notice.
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.
There are SOME successful visual programming environments, though not in the mainstream programs-for-PCs-and-servers arena.
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.
National Instruments' Labview environment also fits in this category. To me it feels like an analog of an electronic schematic diagram editor. I find that it turns into a visual mess as the system becomes complex. To counteract this, one has to spend a lot of time and effort revising the visual elements, and this is not time spent solving the problem better. Of course, many of us spend a lot of time revising our text-form code for clarity and ease of maintenance.
I don't think Lighttalble is a visual programming environment. Last I looked it just had some visual enhancements, but the code is plain old text in files.
My original goal wasn't ever to really create a visual programming environment, though the mismatch here might just be us using the term "visual" differently. We wanted to make something that allowed people to create whatever representation of their code/project/etc they want, but I didn't really expect that to ever turn into code generation via graphical media.
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.
* I really thought CodeBubbles was clever and I'm sorry that it appears to be defunct...