On 01/08/2014 06:10 PM, Mark Engelberg wrote:
When I fired up Light Table a while back, I felt completely hamstrung
-- I couldn't do anything the way I ordinarily would do it. The
notion of executing statements that live in a file didn't feel
anything like the workflow I was used to. It seemed distinctly weaker.
On top of that, at the time I tried it, Light Table couldn't properly
handle long and lazy outputs from functions. I also couldn't figure
out how to observe anything that printed to stdout. Because of that,
I couldn't use most of the REPL tools I was used to using (e.g.,
doc/source/pprint/trace) and the features in Light Table didn't seem
to be a compensation for having those tools.
With each new version of Light Table, I go through this process of
thinking, "Hmmm, I wonder if they have a usable REPL yet." I pop open
Light Table, read the docs which talk about the Instarepl quick start
and the live-code execution feature, no way to create a project from
scratch, and no discussion of a project repl. I shrug and say, "Guess
they aren't seriously targeting Clojure development yet; seems like
all the focus lately is on JavaScript and Python and underlying
infrastructure code." I shut it down and figure I'll try again in a
few months.
This time, I got excited because the announcement said there was lots
of "Clojure love" in this release. Again, I didn't see anything
obviously new relating to Clojure in the docs. So I'm left wondering,
"Does the Light Table team really think this current state is adequate
for Clojure development? If so, what am I missing?" This prompted my
earlier question.
I'm willing to accept that I might be underestimating the value of
what is currently there, and will give it an earnest try. I would
also welcome detailed workflow stories of how other users interact
with Light Table.
--
I don't know if I can answer your question, Mark but I think it is an
interesting one. One suggestion I'd make is that you really shouldn't
expect to do anything the way you ordinarily would. Maybe, but probably
not. The point for me is to figure out what its differences are and how
they might make me more productive.
I should say that, like you, have also played around with LightTable but
don't use it regularly. I did attempt to use it exclusively for a
project at work about a year ago. It wasn't easy, largely because this
was before you could change the key bindings. Hard to undo muscle memory.
That aside, one of the things I liked the most I think was a style of
workflow that I took to calling "spreadsheet programming." Think of a
spreadsheet with lots of formulas as an application and the values in
the various cells as the application state. The attraction of
spreadsheets is that you can see the whole thing at once and you can
manipulate state. You change a number here or there and watch as the
entire thing updates itself. The problem has always been that you can't
see the formulas unless you click on a cell. And even then only one at a
time in a tiny window. This is why most spreadsheet applications are
filled with errors.
With LightTable, I found I could achieve the same sort of thing except
the formulas were all there in plain view also. Say I had a function
that needed to do something. Using this style I would write the first
draft of the function in an instarepl and then a set of calls to that
function with various inputs below. I could then observe the results of
all those calls as I modified the function. It was this instant feedback
that I found productive and not as easy to duplicate with a regular REPL
environment. Once I felt the function worked the way I wanted, I would
generally move it into a file with its own namespace. At that point I
could still get at it from my instarepl via a require as I continued to
the next function.
As the results of my functions got more complex, I found the inline
updating broke down. It starts to take up too much real estate and
creates visual clutter. I think they do a better job with that now but
I'm still evaluating that. My fix for this problem was put in a
statement at the bottom of the instarepl that outputted results to a
file. I then put that file on an emacs buffer on another screen with
auto-revert-mode on. That really worked well for demos. I could
demonstrate the DSL-ish code I was developing on an instarepl and the
audience could see the results in my emacs buffer update as I
manipulated the inputs. I guess that's similar to the proof of concept
demos you saw in LightTable's early days but less graphical. In my case
that was ok since my application was manipulating text.
Some of the other nits you brought up about not being able to create
projects and the lack of tools are more or less valid, but I think they
are mostly a function of application immaturity and a developer
community that is still figuring it out. Steve Yegge wrote a blog post a
few years ago (
http://steve-yegge.blogspot.com/2008/04/xemacs-is-dead-long-live-xemacs.html
) where he implored the xemacs and emacs developers to unite against the
competition. He suggested that this competitor was Firefox. He argued
that since, like emacs, Firefox was self hosting and had plugins, and
since it had rendering capabilities emacs lacked, it would eventually
beat emacs at all the things it's good at. I found it interesting today
to re-read that essay replacing "Firefox" with "LightTable". I said
elsewhere this morning that with this new release, LightTable has become
topologically identical (in the mathematics sense) with emacs. That is,
they both have the ability (and give their users the means) to morph
into whatever they need to be for whoever uses them. I don't quite know
if LightTable has those chops yet or if enough people will participate,
but I'm still very keen to keep watching.
StanD.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
