The Larch Environment(larchenvironment.com)
larchenvironment.com
The Larch Environment
http://www.larchenvironment.com/
64 comments
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.
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.
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.
> 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.
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.
I have very fond memories of using HyperCard in a public elementary school in the early 90s (mostly to create cartoon violence).
HyperCard supported run forward but not back. It had no concept of time manipulation as shown in Bret victor's videos.
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
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
Never seen it. Looks interesting, though very high level? I'll check out the youtube videos they mention: http://www.youtube.com/playlist?list=PLZlv_N0_O1gaG5BW72It4c...
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).
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 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.
Looks a bit like Quartz Composer although I've never actually used it.
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.
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.
Can you elaborate as to what you think happened to LightTable? What is this "curse of Lisp" that you speak of?
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.
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.
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.
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!
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!
> I know what you're building and totally rooting for you!
Any hints? I'm extremely curious!
Any hints? I'm extremely curious!
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 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.
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 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.
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.
> "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.
That's just it. Move on nothing to see.
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.
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})))
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.
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].
[1] http://www.infoq.com/presentations/Design-Composition-Perfor...
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...
When I think of worse is better, I think of Linux, MySQL, Hadoop, PHP and Windows 3.1/95. Even the original Volkswagen is a worse is better car.
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.
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.
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.
I recommend this to everybody with even a little bit of interest in mathematics: http://camdavidsonpilon.github.io/Probabilistic-Programming-...
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.
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.
It's meant to be. It has the infrastructure to be. It just doesn't have the documentation and ecosystem to show how.
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.
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.
True, I meant to refer to the visual 'augmented' programming as demonstrated in the Larch project. Not classical 'visual programming.'
[deleted]
Confession: 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 still have to know exactly what to do, and you have to do it simultaneously, without feedback. These kinds of things will continue to fail until you can add a reset button incrementally and visually.
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 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.
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.
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.
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.
You do know there is a whole field called programming language design right? Not everyone in the PL field is doing theory or chasing better performance, some of us actually focus on design (and I'm not the only one, and design has been studied and practiced since at least the 70s). Visual design is where we are especially weak, but we have our PX down (like UX, but User becomes Programmer).
Yep, I'm aware. I'm still just a student, but I try to follow PX-related research pretty closely, and I'm actually something of a fan of your work in this space in particular :) I've also got a lot of respect for projects like Elm, where an explicit focus on programming-as-UX has produced a language and development environment that (although incomplete) are collectively more accessible and learnable than many of the existing alternatives.
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.
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.
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
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
Instead of text editing, sliders and knobs to manipulate values work well. Music lends itself well to graphic interfaces, because of it's sequential nature, you don't usually work with text or conditionals. Especially for the _feedback_ anything visual works a treat though.
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?
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?
Right, this is just regular code, drawn in boxes. This is not visual programming.
This is a step in the right direction. I'm always looking for new tools that help in understanding code bases and streamline workflows.
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.
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.
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.
It's not my area, but it's my understanding that the same is true in digital compositing, with software like NUKE and Adobe After Effects
https://en.wikipedia.org/wiki/Digital_compositing
https://en.wikipedia.org/wiki/Digital_compositing
Likewise most 3d graphics software like Maya, Houdini, softimage ICE etc. These types of node-based interfaces tend to arise in applications which need high interactivity and have a fairly specific domain. They usually don't scale well to more general programming. For example, they are great for representing the flow of data through a network of functions but not so great at showing things like loops or recursion. That said, I do think graphics (and music) apps are at the forefront of "visual programming" but they are often not talked about in the context of programming language research. Language designers should be looking to them for inspiration.
[deleted]
Compare with 'Boxer', originally developed on a Lisp Machine somewhen in the 80s.
http://www.mathedpage.org/t-and-m/turtle-and-mouse.html
http://web.media.mit.edu/~mres/papers/boxer.pdf
http://www.mathedpage.org/t-and-m/turtle-and-mouse.html
http://web.media.mit.edu/~mres/papers/boxer.pdf
Can someone explain to me the difference between "visual programming" tools like this and environments that have existed for years such as VisualBasic, MS Access, Flash, Dreamweaver, and XCode Storyboards? (Yes, I know many are mainly about UI but they all allow programming to some degree).
Are tools like Larch and LightTable aiming to be "visual programming done right" or is this a completely new (buzzword warning) paradigm in programming?
Are tools like Larch and LightTable aiming to be "visual programming done right" or is this a completely new (buzzword warning) paradigm in programming?
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!
What else is there to say? Visual-enhanced programming environments are quite comment, to varying degrees of visualness. Heck, MS even once put out something called Visual C++ that was not very visual at all (beyond the IDE being a graphical application). The spectrum is so large, that it is not really useful as a label, you have to compare the programming experiences directly.
As for visual languages, that is whole different kettle of fishies not appropriate for this submission.
As for visual languages, that is whole different kettle of fishies not appropriate for this submission.
I was wondering about your comment on quartz composer, before I noticed that "cisual" is a typo ...
I started out on Visual Basic, it certainly helped to lower the barrier to entry a little bit. In the end it was all source text, with helpful library component selection (the timer function had an image of a clock) and ui layout editing.
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/
[1] http://www.sds.lcs.mit.edu/spd/larch/
Neat! This reminds me of "Usable Live Programming" by Sean McDirmid: http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
This reminds me of wolfram alpha's new programming language, except less confusing
Has some similarities to ipython notebooks... looks pretty interesting.
* I really thought CodeBubbles was clever and I'm sorry that it appears to be defunct...