
Light Table - Embracing Abstraction - bpierre
http://www.chris-granger.com/2012/09/25/light-table---embracing-abstraction/
======
davidp
> we are not the recipe writers we were 20 years ago - that instead we are
> "abstractioners"

> we have to know far more than just the basic consturcts [sic] of the
> language and things like IO

Did anyone else find these annoying? I recall building a great deal of
abstraction into my systems 20 years ago, and we certainly used frameworks at
various layers of the system. We had to know far more than basic language
constructs and IO.

Today's systems and frameworks are more available (open-source) and
differently targeted (e.g. cloud-scale problems), but they're still just
building abstractions on what came before, just like us old fogies were doing
20 years ago. The problems and solutions are not qualitatively different --
they just have different scale and connectivity.

All that said, Light Table seems pretty cool. But it's not evidence of deeper
insight than what came before.

~~~
jgrahamc
Yes, I found that annoying. But it's not uncommon when reading stuff written
by programmers who make extensive use of JavaScript. For whatever reason it
seems to have attracted people who don't have much breadth or depth of
programming experience yet at the same time like to make grand statements.

It's interesting that the author, who is speaking about things that were
happening 20 years ago, graduated from college in 2008 (<http://www.chris-
granger.com/resume/>) and thus 20 years ago he was likely a very small child.

This combination of lack of depth and yet grandeur is seen in other projects
and is annoying because it means that one is forced to wade through a lot of
noise to understand projects like nodejs, couchdb, etc. And it does the people
who write like that a disservice. Rather then overselling their weak knowledge
they should point out the cool stuff in what they are doing and let that speak
for itself. It's counterproductive to pretend to be smarter than you are.

~~~
zainny
I wouldn't necessarily pinpoint the Javascript community, but yes, I would
agree that there does seem to be an awful lot of really young and frankly
inexperienced developers who seem to have ridiculous delusions of grandeur and
are completely ignorant of the rich history of brilliant and accomplished
people who have explored the problem spaces they are also exploring.

I blame the whole Silicon Valley "10x hacker" mentality. There's a whole lot
of young and frankly pretty mediocre developers strutting around thinking that
because they (a) live in the valley and (b) built shittytodoapp.io they're at
the same level as Knuth.

~~~
jgrahamc
You are correct that I should not claim that the entire JavaScript community
is like that, but that's where I've seen the most prevalent delusions of
grandeur problem.

------
agentultra
I think Mr. Granger should refrain from using inaccurate remarks about the
history of programming. Light Table is neat but it is not the first attempt at
an interactive development environment. His ideas were quite common 30+ years
ago (20 years ago would have been right about the time when this style of
programming started falling out of vogue). Alan Kay does a far better job than
I can in explaining some of this history:

[http://www.youtube.com/watch?v=FvmTSpJU-
Xc&feature=youtu...](http://www.youtube.com/watch?v=FvmTSpJU-
Xc&feature=youtube_gdata_player)

 _Update_ I wasn't being terribly fair. Granger might simply not have been
aware. In that case I hope he sees my comment and watches the above video. :)

~~~
seanmcdirmid
When I gave my talk on live programming in OOPSLA/Onward! 2007, one of the
gang of four (of Design Patterns fame) criticized me on not mentioning
smalltalk enough. You know, I think we are all aware of Smalltalk and its
ability to reload code on the fly, or the "live" eToys demo Alan Kay was
giving in the late 90s/early 00s (I saw it the first time at his ECOOP 2000
banquet speech). But there really is something special in Light Table (and
other projects, including my own) that go beyond that; they are working on a
practical tool for programmers, they are really focusing on an interactive UX,
which to be clear, Smalltalk environments never really had.

Yes, get your history and citation right to avoid being flamed. But no, it
didn't end with Smalltalk (or Lisp, or whatever) and we are not just going
back to that.

~~~
jgrahamc
"Yes, get your history and citation right to avoid being flamed."

That's the wrong motivation for understanding the history of computing as it
relates to what you are working on. There are things to learn from history.
It's not the ability to correctly cite Smalltalk etc. to quiet some older
programmers , it's the ability to compare, contrast and learn from what came
before. The really debilitating thing about not understanding the history is
that you are doomed to repeat the same mistakes; it's better if you can make
new mistakes.

For example, you say "But there really is something special in Light Table".
Great. What is it?

~~~
seanmcdirmid
I've mentioned in a peer post that his design is very well done; they are
focusing on awareness and code topology issues that I think is long overdue.
Now, do I know exactly what the differences are between smalltalk yet? No, not
at all. But I've never seen smalltalk demos like this (the closest would be
etoys, which was a not-very-comparable end-user programming experience).

Again, its a blog post and a talk, I don't think we should expect rigor on
previous/related work coverage at this point, that will come with time.

------
makmanalp
I was skeptical of buying into the light table idea until now. Now I see it
for what it is: A programmable debugger with a dashboard for your software, as
well as an editor, the latter part being less important. It's like if gdb had
a baby with some visualization app.

The debugger already is omniscient in terms of what is going on within the
program, but it's inept at showing it to you. It's too low-level in that it
doesn't know what specific entities are important in your program. It knows
addresses, variables, maybe objects. But you have a mental model and instead
of trying to get your mental model into low level terms you can program it to
have some notion of what to display.

~~~
moconnor
I've spent the last decade writing debuggers; they are anything but
omniscient. It's a miracle that they work at all, frankly.

In principle gdb _could_ look at everything that's going on, but in practice
doing so would (a) hit a bug in the compiler's debug output and fail, and (b)
take forever for any program worth debugging.

~~~
makmanalp
Interesting! The point I was trying to make wasn't that it knows _everything_
everything, but it knows a lot more useful information than you.

------
veb
I'd really really like to watch this video, and countless of other awesome
tech videos -- but I can't, there's no captions. As someone who is hard of
hearing, I have to wonder how many things I end up missing out on when I can't
watch things like this.

Grr.

~~~
tisme
The video doesn't show any time marks so you'll have to interpolate the
locations.

\--

So the first thing I thought we would do is create a little custom git widget
that shows the files modified in our repository.

So we add a custom object.

And we're going to write some clojure script code just to hold the state of
our (circle??) the git status

We just need a way then to get that

So we ask the server for it

And... here we're just creating some html representation of our list of files

And then when we save

We're going to make sure we update

So if we run this

We should see

Yes, there we go we have a list of modified files

We can add some css to make it look prettier

And now I can just move this wherever we want

I'll put it down here

And let's actually open a file and modify it and prove that our widget is
actually working

So, we have server.clj here

And when I save it

Yes, there we go

It's changed

And if I remove that modification, then it goes away, great!

Then I thought we should do something a bit more interesting than that.

I've been working on a game with my little brother

So let's build an environment to play that game in and work on it

It's written in Javascript so we're going to need a canvas element

So that we can put the game on the canvas

Canvas by default isn't visible so you dont't see it immediately

So Let's give it a background, black just so we can actually see that we added
something.

here we go

And we'll move this over to this this side so don't have it in the middle of
our workspace

And that as well

Let's run the game to make sure this is all working as expected

There's the game

there is the javascript file

execute it

there we go

Now we have the game running, You can see I can play it here

You can move around, some little bad guy shooting me. Cool!

now I talked about being able to build, to bring your abstractions into the
environment

Let's control the game from light table

I add another custom object

We're going to create start and stop buttons for the game

We start writing the clojure script here

we create a little function to create a button

That has a label and an action

And here is our init which just returns the html that we want it to to be
represented as

And you can see after executing it you get a start and stop

Some css here , that's a little too big

Let's actually shrink the font size a bit

that's still too big.. 11 60

Great, now if I click stop, he stops moving there you go

And If I click start he starts moving again

And you can see what this init function is doing is calling our javascript
code

Move this guy down here

So let's take this up a notch

Let's actually bring one of the abstractions from the game directly in.

So games are usually composed of entities that get drawn to the canvas

So let's create a list of all the entities

to do that

We need some state for our entities

And a way obviously to add and remove them

And then we need a representation of them in html

We have this little item function

We're setting our on-add and on-remove functions within our game to our add
and remove

Execute this and

Do the magic of some data binding here

We'll see that

Every time something gets shot a new entity is added to the canvas

So if I shoot this guy, he actually explodes into a bunch of shrapnel

let me show this

there you go

so there is a bunch of shrapnel that's been added

And as it sort of fades away it goes away again

Cool!

So we've actually created a little environment for our game here

the whole thing was less than about 50 lines of code

And it was completely trivial to build

there you go!

Fun little way to show how

You can extend light table

~~~
veb
No, _you_ don't have to. It's just annoying when people give talks, or make
interesting videos for a product and they forget about people who may be hard
of hearing, Deaf or from overseas.

That's such a big chunk of the market that they're missing out on.

~~~
pc86
It sucks that you have to put up with this, but let's not pretend it's a "big
chunk."

According to the Journal of Deaf Studies and Deaf Education, an article
published in 2005 cites 11MM HOH and deaf individuals in the United States[1].
The Population Reference Bureau cites 296MM US citizens in the same year[2].
It's important to note that according to the first source, "over half" of
those that are HOH or deaf are over 65 - likely not the target market of this
video.

Even if we were to completely ignore the demographic issue of who makes up the
majority of HOH and deaf individuals, we're talking about just over 3.7% of
the population in the US (I would assume it's roughly similar when
extrapolated to the entire internet population).

I think that anyone for whom the HOH and deaf population was a target market
would certain take every opportunity to make their materials accessible.

[1] <http://jdsde.oxfordjournals.org/content/11/1/112.full> \- ABSTRACT [2]
<http://www.prb.org/pdf05/05worlddatasheet_eng.pdf> \- PAGE 2

~~~
dllthomas
It's a much bigger chunk if you include those with missing/broken speakers,
easily annoyed roommates, a loud environment, or who are otherwise incapable
of listening to sound, permanently or transiently.

~~~
alttag
I can't reply to the sibling comment (davidw's) about video (level cap?), but
I vehemently agree. I can read much faster than most people speak, (and can't
"skim" a spoken monologue), so I almost always prefer text to video.

I'm feeling increasingly like an old gaffer complaining about these "young
'uns" and their "yoo tubes" (at a middling 30-something), but I see this trend
toward video when text would suffice as evidence of a societal lack of good
(writing) education.

Sure, in the OP's instance, it's a presentation he made to someone else, so a
video is probably easiest, but this was a good opportunity to rant.

EDIT: And now the reply link appears. Weird.

~~~
dllthomas
My understanding is there's a _relative_ level cap for the "reply" link, but
no absolute level cap. So if you want to reply to something that lacks the
reply link, click its "link" link to view it directly, and you can reply.

~~~
scott_s
It's a time delay, meant to discourage furious back-and-forths.

------
mempko
It is clear they have no idea what an abstraction is. Abstractions
deliberately throw away information. He is instead making widgets which reveal
more information.

What he calls abstractions are nothing of the sort.

~~~
koide
He isn't calling the widgets he creates abstractions. He is saying that
LightTable allows you through these widgets to dynamically control and display
the existing abstractions of your code.

~~~
jmilloy
I still don't get it. What existing abstractions did he display? What were
they abstractions of?

~~~
eternalban
You didn't note the abstracted component connectivity bit, where buttons got
hooked up to other components and used as commanders?

~~~
jmilloy
Can you concretely state what the abstraction you are describing is? In
particular, what details does it hide or factor out?

------
sergiotapia
Cool demo I guess, but I have no idea how this could fit into current
workflows or even be applied to traditional applications or websites.

Anyone care to enlighten me?

~~~
squidsoup
The web development workflow is something that will be getting a lot of
consideration in Lighttable - Chris Granger is the author of Noir which is the
closest thing to a web 'framework' in the Clojure world.

------
moconnor
I just watched this right after reading Bret Victor's Learnable Programming
essay (<http://worrydream.com/LearnableProgramming/>).

The dissonance between Bret's visions and where even a quite progressive
modern IDE is at disturbed me deeply. Nothing that Chris showed was "trivial"
when seen from the perspective of how things might be rather than how Eclipse
does things.

------
tisme
This is really neat. I see a lot of connections to Borlands visual C builder.
Create a canvas, drag elements onto the resulting form and change their
properties and code up actions. Of course this example here uses 'clojure' but
there are a lot of similarities.

Something like that could make writing web applications much easier than it is
right now. Interactive web application development could be a real game
changer.

------
pnachbaur
This is exceedingly cool. I'd love to see this in action for something that
isn't a game (preferably my own project haha). Looking forward to the release!

------
cbaleanu
Nice to see Javascript being used in the movie.

------
mjcohenw
Also, please spellcheck!

