8 ms·

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/* http://cs.brown.edu/~spr/c

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/* 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 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...

mtrimpe 12y ago
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.
- SeoxyS 12y ago
  Can you elaborate as to what you think happened to LightTable? What is this "curse of Lisp" that you speak of?
  - mtrimpe 12y ago
    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 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.
    - seanmcdirmid 12y ago
      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.
      - ibdknox 12y ago
        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.
        mtrimpe 12y ago
        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!
        blueprint 12y ago
        > I know what you're building and totally rooting for you! Any hints? I'm extremely curious!
      - lkrubner 12y ago
        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.
- dvanduzer 12y ago
  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.
  - noir_lord 12y ago
    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.
    - dvanduzer 12y ago
      I recommend this to everybody with even a little bit of interest in mathematics: http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/ http://camdavidsonpilon.github.io/Probabilistic-Programming-...
namuol 12y ago
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 https://www.unrealengine.com/blog/blueprint-basics
- CoffeeDregs 12y ago
  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_O1gaG5BW72It4chjhypxIO9ZB http://www.youtube.com/playlist?list=PLZlv_N0_O1gaG5BW72It4c...
  - namuol 12y ago
    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.
    - vegggdor 12y ago
      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).
      - namuol 12y ago
        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.
lispm 12y ago
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.
- mtrimpe 12y ago
  It's meant to be. It has the infrastructure to be. It just doesn't have the documentation and ecosystem to show how.
  - ibdknox 12y ago
    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.
    - mtrimpe 12y ago
      True, I meant to refer to the visual 'augmented' programming as demonstrated in the Larch project. Not classical 'visual programming.'
  - deleted 12y ago
    [deleted]
lkrubner 12y ago
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 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.
- bithive123 12y ago
  I have very fond memories of using HyperCard in a public elementary school in the early 90s (mostly to create cartoon violence).
- seanmcdirmid 12y ago
  HyperCard supported run forward but not back. It had no concept of time manipulation as shown in Bret victor's videos.
- captainmuon 12y ago
  > 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.
rm445 12y ago
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.
- vibrolax 12y ago
  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.

mtrimpe 12y ago

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.

SeoxyS 12y ago
Can you elaborate as to what you think happened to LightTable? What is this "curse of Lisp" that you speak of?
- mtrimpe 12y ago
  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 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.
  - seanmcdirmid 12y ago
    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.
    - ibdknox 12y ago
      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.
      - mtrimpe 12y ago
        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!
        blueprint 12y ago
        > I know what you're building and totally rooting for you! Any hints? I'm extremely curious!
    - lkrubner 12y ago
      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.
dvanduzer 12y ago
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.
- noir_lord 12y ago
  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.
  - dvanduzer 12y ago
    I recommend this to everybody with even a little bit of interest in mathematics: http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/ http://camdavidsonpilon.github.io/Probabilistic-Programming-...

namuol 12y ago

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 https://www.unrealengine.com/blog/blueprint-basics

CoffeeDregs 12y ago
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_O1gaG5BW72It4chjhypxIO9ZB http://www.youtube.com/playlist?list=PLZlv_N0_O1gaG5BW72It4c...
- namuol 12y ago
  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.
  - vegggdor 12y ago
    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).
    - namuol 12y ago
      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.

lispm 12y ago

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.

mtrimpe 12y ago
It's meant to be. It has the infrastructure to be. It just doesn't have the documentation and ecosystem to show how.
- ibdknox 12y ago
  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.
  - mtrimpe 12y ago
    True, I meant to refer to the visual 'augmented' programming as demonstrated in the Larch project. Not classical 'visual programming.'
- deleted 12y ago
  [deleted]

lkrubner 12y ago

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 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.

bithive123 12y ago
I have very fond memories of using HyperCard in a public elementary school in the early 90s (mostly to create cartoon violence).
seanmcdirmid 12y ago
HyperCard supported run forward but not back. It had no concept of time manipulation as shown in Bret victor's videos.
captainmuon 12y ago
> 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.

rm445 12y ago

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.

vibrolax 12y ago
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.