31–40 of 65 posts
Visual programming is very established in contemporary music. Max/MSP and SuperCollider are state of the art, with dozens of papers written on it. I do not get why those languages are not used outside a very litte academic hipster music community.
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,…
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.
Earlier quoted context omitted.
LightTable will continue on, but it seems to no longer be the main focus of Chris. 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.
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.
"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.
Other uses of the term 'Larch' include a formal specification system[1], and I could have sworn there was a '80s/'90s programming environment research project. (Perhaps a structured editor?) [1] http://www.sds.lcs.mit.edu/spd/larch/
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,…
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. HyperCar…
Earlier quoted context omitted.
Visual programming is a broad term that has been used to describe programming with visual aspects. Lets not even discuss visual programming languages, like Quartz Composer.
Please, do go on!
As for visual languages, that is whole different kettle of fishies not appropriate for this submission.
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,…
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.
Earlier quoted context omitted.
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.
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 wor…
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.
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.