
The Larch Environment - coherentpony
http://www.larchenvironment.com/
======
CoffeeDregs
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...

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

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

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

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

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

~~~
seanmcdirmid
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).

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

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

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

~~~
troymc
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)

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

------
lispm
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://www.mathedpage.org/t-and-m/turtle-and-mouse.html)

[http://web.media.mit.edu/~mres/papers/boxer.pdf](http://web.media.mit.edu/~mres/papers/boxer.pdf)

------
callmeed
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?

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

~~~
vegggdor
Please, do go on!

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

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

------
mcguire
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/](http://www.sds.lcs.mit.edu/spd/larch/)

~~~
davidgay
[http://www.cs.cmu.edu/~wing/publications/Wing87.pdf](http://www.cs.cmu.edu/~wing/publications/Wing87.pdf)

------
Scaevolus
Neat! This reminds me of "Usable Live Programming" by Sean McDirmid:
[http://research.microsoft.com/en-
us/people/smcdirm/liveprogr...](http://research.microsoft.com/en-
us/people/smcdirm/liveprogramming.aspx)

------
hardwaresofton
This reminds me of wolfram alpha's new programming language, except less
confusing

------
math0ne
Has some similarities to ipython notebooks... looks pretty interesting.

------
TheLarch
Well this is awkward.

~~~
TheLarch
I took the username from a Monty Python skit.

~~~
tizzdogg
And now, number 1. The larch. The larch. I appreciate the joke at least!

