Has some similarities to ipython notebooks... looks pretty interesting.
The Larch Environment
41–50 of 65 posts
Re: The Larch Environment
#42Earlier quoted context omitted.
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…
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 bo…
"The curse of Lisp" is a well known phrase that's been used in hundreds of essays:
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.
Re: The Larch Environment
#43Confession: I watched with interest until he added the reset button. At this point, he silently starts making classic textual changes. A non-obvious but quite bad thing is that it required simultaneous multiple edits in disparate parts of the file - each of which required expert knowledge of the libraries, the language, and the file itself. This is why visual programming environments suck - because in the end, you st…
Right, this is just regular code, drawn in boxes. This is not visual programming.
Re: The Larch Environment
#44Earlier quoted context omitted.
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 bo…
"The curse of Lisp" is a well known phrase that's been used in hundreds of essays: 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 bet…
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.
Re: The Larch Environment
#45Confession: I watched with interest until he added the reset button. At this point, he silently starts making classic textual changes. A non-obvious but quite bad thing is that it required simultaneous multiple edits in disparate parts of the file - each of which required expert knowledge of the libraries, the language, and the file itself. This is why visual programming environments suck - because in the end, you st…
First reply, be gentle. I think the problem you're describing is one that results when an expert tries to teach / design something to beginners and they forget how to present the information in an approachable manner. Sure, with code it _seems_ like "duh of course you need to _know_ the libraries to use a visual editor!" but that goes against the basic concept of having a visual styled IDE. I'm a UX / visual design g…
My wife is a visual designer (on feature phones, weirdly enough), she isn't very helpful with my own programming experiments [1] :)
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
Re: The Larch Environment
#46Confession: I watched with interest until he added the reset button. At this point, he silently starts making classic textual changes. A non-obvious but quite bad thing is that it required simultaneous multiple edits in disparate parts of the file - each of which required expert knowledge of the libraries, the language, and the file itself. This is why visual programming environments suck - because in the end, you st…
First reply, be gentle. I think the problem you're describing is one that results when an expert tries to teach / design something to beginners and they forget how to present the information in an approachable manner. Sure, with code it _seems_ like "duh of course you need to _know_ the libraries to use a visual editor!" but that goes against the basic concept of having a visual styled IDE. I'm a UX / visual design g…
This is spot on. In programming communities, design is frequently dismissed as an "implementation detail" or part of "making it look good" (i.e. marketing). This is a distinct and recurring cultural blind spot – more conceptually interesting programming tools than I can count have been torpedoed by a lack of attention to visual/UI/UX/HCI design.
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.
Re: The Larch Environment
#47Well this is awkward.
Re: The Larch Environment
#48Well this is awkward.
I took the username from a Monty Python skit.
Re: The Larch Environment
#49This 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,…
Have you tried Unreal Engine 4's Blueprint [1]? 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
Looks a bit like Quartz Composer although I've never actually used it.