The Larch Environment
larchenvironment.com
larchenvironment.com
* I really thought CodeBubbles was clever and I'm sorry that it appears to be defunct...
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.
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...
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.
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.
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.
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.
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.
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.
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.
With expert systems you work blind half the time, because of the size, that you can't get all into scope. So you simplify and make abstractions, but it's complicated to map multidimensional decision space onto 2d. Therefore a good visual programming environment would have to be a complicated system, that, well, you'd have to learn to navigate and memorize.
Don't know what you mean, how to _incrementally_ add or reset a button, like Undo/Redo?
I'm a UX / visual design guy very interested in learning to program, have been for several years. But it's just not approachable beyond stuff like CodeAcademy, as it quickly becomes a labyrinth of documentation, cryptic instructions, and unclear ways to approach building a worthwhile program.
I digress, as that's not my point. Point is, many visual editors, even Quartz Composer, fail on the same area; they aren't approachable beyond tinkering with the switches and buttons. UX isn't even a passing thought on these tools. I would love to participate in building one of these tools and learning X language in the process. Until a visual designer is involved, these tools will continue being relegated to tiny niches unless a visionary developer comes along (-and actually completes the thing, as was mentioned above about the LightTable Chris guy).
I'm not saying design is _the_ answer, but all the best tools have been co-created with a visual/ mechanical/ industrial/ designer of some kind.
Actually, we need a visual designer who is also versed in programmer experience (rather than end-user experience) design, and I haven't found anybody like that yet. A UX designer is not some magical person who can magically do design in any domain; even HCI researchers are not a panacea [2]. Also, designs, even by seasoned designers well versed in the domain they are working in, are never perfect, there are always trade offs to be made.
Nothing is ever finished, we only get closer to our goals that are infinitely away.
[1] http://research.microsoft.com/en-us/projects/liveprogramming...
[2] http://faculty.washington.edu/ajko/talks/CHI2006Barista.pdf
Design is absolutely critical when it comes to helping people understand complex systems. Well-designed tools work with the human brain to mitigate cognitive load, allowing the user to focus on making stuff happen rather than on juggling handfuls of information. Few programming tools, experimental or mainstream, fit this description; even fewer have anything like it in mind.
Successful efforts to make programming less opaque and more accessible will necessarily involve massive leaps forward in design. I'm glad to see design beginning to make some inroads into programming culture, but we've got a long way to go yet considering how frequently the Unix CLI is still held up as the state of the art.
That said, I'm still of the opinion that programmer culture at large is too quick to disregard design. I'd really like to see more programming tools for general use developed with an eye to design, and for more industry and hobbyist programmers to realize that the current baseline state of existence is not an absolute maximum but a local one. We've pushed plain text pretty far, but it seems obvious to me that there's much bigger wins to be had if we throw out some of the assumptions our culture tends to make.
The inline table is cool. I like the idea of embedded documentation like that, as long as its structured in a way that can be turned on-off.
The Scala plugins for Intellij and Eclipse both have worksheets, which I think as of REPLs on steroids.
The one thing I'm still missing from most mainstream development environments though is interaction of live, running programs - the kind seen in Common Lisp and Smalltalk.
Java has it kindof, then enhanced more with JavaRebel (a commercial tool). .NET edit-n-continue is still frustratingly crippled in many ways.
I still feel like I'm programming in a batch environment instead of "molding" my code though.
Are tools like Larch and LightTable aiming to be "visual programming done right" or is this a completely new (buzzword warning) paradigm in programming?
As for visual languages, that is whole different kettle of fishies not appropriate for this submission.