
LightTable detailed critique: Concept vs Reality - pdeva1
http://eblog.chrononsystems.com/light-table-concept-vs-reality
======
kenneth
You're comparing Java to Clojure. Conceptually, they're insanely different--
Apple and Oranges, really.

Clojure, Lisp, and similar languages are homoiconic. That means they're
beautifully suited to an interactive environment such as that provided by
LightTable. Conceptually, unlike typical IDEs, LightTable is not a series of
scripts that will attempt to help you deal with common development tasks such
as looking up documentation and refactoring. Instead, you're interacting
directly with the language.

I think it's quite telling that in Java, documentation is done through Javadoc
comments, which are ignored by the compiler and sought out by a completely
separate tool in order to build docs. In Clojure, documentation is part of the
homoiconic code itself:

    
    
        (defn my-fn
          "This is the documentation, can be inspected on the fly"
          [] …)
    

Instead of being a series of very reliable hacks on top of a language that
doesn't support docs, docs are part of the environment.

Additionally, when programming in Clojure, you can do it interactively by
modifying the environment on the fly. This was popularized by smalltalk, and
is an extremely gratifying way to program: you can inspect and edit your
program code while it's running, and have a fully-featured REPL into your
program. This way of doing things blows GDB completely out of the water.

Note also that when coding functionally, files are often made up of many small
single-purpose functions, which is actually much more maintainable than the
example "real-world use case" function you provided.

Essentially, your entire argument is based around the assumption that Java is
the right set of design patterns. I would argue that the Java language is
deeply flawed, and leads to a 30:1 ratio of boilerplate code, markup, and
structure to useful code. It's what makes Javadoc and IDE refactoring tools
possible, but it's also what makes Java a nightmare to maintain and (for me)
an extremely unpleasant language to work in.

I have never used LightTable, but for me, what it represents is a different
way of thinking about programming. It's about interacting with your code
directly and interactively. And actually, when writing Clojure, I often
program in quite a similar fashion with existing tools (VimClojure /
Clojure.tmbundle / Cake).

~~~
dibbeke
Java's annotations could be seen as 'part of the environment' (whatever that
may mean). I often use annotations which indicate how a method should be used,
and those annotations are used by static analysis to validate correctness.

When using Java, I often change my program while it is running. recompiling
classes on the fly. It works in most cases, and when it doesn't work, I
believe other languages would fail as well.

You say Java is deeply flawed. I argue that Java is one of the most successful
languages around nowadays. It does what it is designed to do: be relatively
easy to learn, a natural successor to C++ with a wide range of libraries. Yes,
Java code can often be verbose, but this depends greatly on the kind of
paradigms used. I can write verbose and ugly code in Clojure and write
relatively concise and elegant code in Java. It depends on architecture, a
good understanding of OOP (and its limitations), composition over inheritance.
The problem with Java is the sheer amount of 'bad' code written in it (because
of all the leagues of beginner programmers), giving it a bad name. Have you
seen Clojure code of a large product (equivalent to around 1M code lines of
Java), produced by a team of diverse programmers and maintained by another
team during a 10 year lifespan? You would cringe just as hard.

Finally, lighttable is a proof-of-concept... It's not there yet; there are no
reviews; leagues of smart engineers have tried to reproduce something similar
and could not escape the POC phase at all.

~~~
djhworld
I use Java in my day job and I find annotations a real blight on the language.
While I totally get the idea that they remove the need to write a lot of
boilerplate code, I still find a lot of them too "voodoo" for my liking.

~~~
dibbeke
Agreed, they aren't the prettiest thing in Java and they only allow one
'layer' of annotating (you can't use expressions in annotations for example),
they do prove it is possible to document your code in Java in a way that it
becomes part of the 'environment' (again, 'environment' is ill-defined, so all
arguments in this line are a bit frail).

------
zacharyvoase
I find this 'critique' (it's not a critique, it's a takedown) to run against
the spirit of Hacker News.

Someone built a concept showing how the experience of writing code, for their
corner of the software ecosystem, could be improved. They found popular
support, and they're now setting about to make that concept happen.
Congratulations; this is what Hacker News is supposed to be all about.

And here's someone summarily piecing apart and nitpicking on that concept (and
the details of the demo video) for no apparent reason—there's no feedback or
suggestions for improvement, it's just saying "well Eclipse does this and this
and this already". I'm not impressed.

~~~
shadowmint
yes! So this. I agree; Let's see some constructive criticism and ideas for how
to improve the LightTable idea, instead of just trying to shoot it down as
'not novel'.

~~~
prospero
There is a valid point lurking in there.

The instant evaluation model doesn't play nicely with side-effects. Exactly
where side-effects occur can be difficult to determine, there's no simple way
to work around this.

This is less of a problem in Clojure, thanks to its immutable data structures,
but they're not a panacea. I'm also not sure how well this would work in JS
and Python, the other languages that Light Table intends to initially target.

One possible solution is to have hooks into side-effects: you could display
console output or logging alongside the instant evaluation. The real
difficulty is network communication: even if you're okay with actually sending
requests over the wire, there's an awkward balance between visibility and
generality. Something like libpcap [1] is very general, but gives minimal
insight into the content. Hooking into a particular HTTP client library gives
you a lot more visibility into what's going on, but you'll need to do this
every time you want to use a new library.

[1] <http://www.tcpdump.org/>

~~~
nightpool
you could mitigate side-effects by running all of lighttable in a VM, assuming
no files and creating all the ones you need. Network requests could be
intercepted. The key to make this workable would be sensible defaults,
allowing you to just open it up and start a new project instantly, and
allowing custimization for complicated projects.

~~~
prospero
The side-effect could also just be updating a mutable hash-map, which has much
of the same issues, and isn't something that you can sandbox.

~~~
stcredzero
In Smalltalk, this isn't a problem. Our Dictionary instances are mutable.
Usually, we realize it while continuing the debugging/editing (they happen at
the same time) and we either rewind the stack a little further to get a new
instance of the dictionary, or we can easily undo the side effect. It usually
happens in less than the amount of time you took to read the previous
sentence.

------
jroseattle
I find the OP to be off-base in critique of the LightTable concept. To be
sure, the concept has some likely drawbacks and would need real-world
application to gauge viability, but I thought the critique by comparison to
Eclipse missed the point. If there is anything that good design has taught us,
it's that doing things better has significantly greater value than simply
doing more things.

For example, the first comparative in this critique is the "docs everywhere"
feature. The OP shows that the LightTable concept "eats up half the screen",
"can't resize", etc. while showing that Eclipse has the same feature (with the
javadoc tab at the bottom of the screen.) The OP sees documentation show up in
both places, so it's called a wash/irrelevant.

When I view those same two screenshots, I see a significant difference. In
Eclipse, I see yet another tab/doc/thingy with information crammed in it; in
LightTable, I see information displayed in parallel with the code, not having
to compete for screen space. The OP's comment about documentation "eating up
half the screen size" implies that more information on the screen is better
than less information. I find the LightTable design in this scenario as saying
some information is more important than others.

It's mostly just aesthetics, but aesthetics is kind of the point behind
LightTable.

------
Swizec
I agree with most of the points - documentation is well covered by IDE's, yep,
I guess (don't use IDE's myself) ... finding functions is also pretty solved
(personally I just use grep).

But I disagree with the part about small functions and the example being
contrived because real world functions aren't small and you can't just get
your output directly like that.

First of all, functions _should_ be small. Anything you can unit test, you can
put in this sort of instant feedback. It's basically just a unit test! Input
goes in, output comes out. Without side-effects or other horrors.

Okay, so not _all_ functions make sense to be unit tested. Sometimes you need
an integration test and the function can't have direct output like that ...
you have integration tests don't you? Why not just evolve the "Instant
feedback" feature to being your set of tests?

I honestly don't care about much else in the LightTable demo. But I _love_ the
idea of instant feedback. Especially when working with Haskell or something.

~~~
feiern
I think the author did not really get the motivation behind the LightTable
concept. For those interested, it was this talk that inspired the guy(s):
<http://vimeo.com/36579366>

It's about the instant feedback during development as opposed to the classic
change/compile/reload cycle.

Especially for concepts it's important to understand the intention rather than
picking on it point-by-point (which in itself, while true for the most part,
seems rather pedantic to me).

~~~
Swizec
Honestly, I've been _aching_ for this to become a reality ever since I saw
that talk.

------
twelvechairs
Of course the original video was not perfect. It is a concept, not a fully
fleshed out product.

It piqued peoples interest for good reason, because of a combination of many
ideas working together in a clean interface. To criticise it for details
('this takes up half the screen', 'some of these things have been done
before', 'this particular feature might not work for the kinds of work I do')
is to entirely miss the point of a 'concept'. It needs constructive input (eg.
'this is a good idea, but would work better if done like that'). The kind of
criticism provided here doesn't help anyone much at all.

~~~
Someone
Yes, but most, if not all, of the concept has been done before. Given that, I
think the question why things would work better this time is one that the
backers of this project should think about before starting development.

My input would be that I think the cute displays in the video will not work on
real-scale projects. One reason is that I do not see how the most interesting
part, the live display of a call graph, will work as nicely as displayed in
the video with:

    
    
      - functions that manipulate disk or network state
      - large functions
      - deeply nested functions, in particular recursive ones
    

I can envision each of them, but all in a somewhat ugly way. The first would
require programmers to write set-up and tear-down code; the second and third
would eat screen real estate and/or would involve scrolling and/or collapsing.

If you have to write that setup and teardown code, I do not see how this
interactive way of testing code is that much better than writing unit tests.

Translating that into constructive feedback: I would aim for building a good
tool for education first; then, work on the scaling problem. But, be prepared:
you should be happy if you get the education part only; you may not find a way
to scale this up to real-world projects. And you should also realize
beforehand that, if this does not scale, the educational program may be seen
as a toy, only useful in the first half-year or so, only because 'real
programmers' do not use it. It may take time to overcome that, just like it
took (or even: is taking) time to overcome the notion that real programmers do
not use IDEs.

[Going on a tangent: I would love to have a system that allowed me to split
unit tests into API examples and all the other tests (timing tests,
integration tests specific to certain bugs, etc.) That way, the documentation
system could grab the first kind of tests and show them in the documentation.

I also would like to see a system that forbid me to write code that is not
covered by a unit test yet. For example, in C, it would force programmers to
write the header file first, the unit tests exercising part of the code
second, and the actual code last. It should allow me to write the whole header
file, then implement and test that header in parts, though. I also might hate
it the moment I see it, but I need to see it to discover that.]

~~~
twelvechairs
Yeah, I think thats a very reasonable viewpoint to take. To me there was a lot
more depth in what you just said that the OP.

What I will say though is that to me when you 'envison.. in a somewhat ugly
way' its basically a guess that they won't find a nice way to solve the UI
difficulties of things that weren't in the video. You might be proved right,
but to really know (rather than guess) this, you need to spend probably some
days thinking about and prototyping it, which assumedly they will do (and we
have not).

I think they should be encouraged to do so, and my main problem with the OP
was its basically discouraging tone of 'its never going to work because you
haven't shown me a perfect final version that covers all bases'.

~~~
Someone
_"you need to spend probably some days thinking about and prototyping it"_

I would _guess_ that "thinking about it and researching it" will be time
better spent. Inventing the wheel often is a lot of fun, but it also can be a
waste of time. I do not know the literature, but it would not really surprise
me to learn that there is some cheap knowledge to mine from it.

------
edanm
Everyone is jumping in to disagree with the OP.

I have to be honest: I thought the OP's points were very well made, and as
much as I loved the LightTable demo, I think I immediately dismissed it, in my
mind, as "looks cool, but can't be made".

I think there is a big disconnect between this author, a "working programmer"
who actually writes code, and at least _some_ of the commenters in this
thread. Let me give my take on a few of the differences:

For one thing, the op mentioned that, while functions _should_ be small, they
usually aren't. And while functions, ideally, _should_ be self-contained, most
of the code people write is a mixture of calls to external sources, libraries,
etc. I.e., things that _can't_ be seen ahead of time. In practice, the OP is
100% correct. Most of the code I see, ends up being _exactly_ this kind of
code. I question whether anyone who claims otherwise has any experience with
real systems. I just can't imagine anyone disagreeing that most code looks
like this in the real world.

Another point of disconnect is the "I don't use an IDE" theme that's common
here. I think you'll find that HNers, as a whole, are a lot more prone to be
anti-IDE. Much of the "real world" programmers would be shocked that so many
HNers give up the comfort of all that the IDE provides. And, at least to my
mind, there is an attitude here that using an IDE makes you a worse
programmer.

The truth is, the author is correct to point out that a lot of the cool stuff
in the demo already exists. If for no other reason than to point out that, if
you think a lot of the cool stuff shown in the demo is worth looking into, you
might want to check out Eclipse or other IDEs.

Finally, let me make one final point, specifically to zacharyvoase and the
others who think this post is "against the spirit of Hacker News", etc. I
totally understand you, and I agree, the LightTable creator deserves a lot of
credit for what he's trying to do, whether successful or not. But I think that
a critique of the project, especially showing which parts of it have already
been created, is _amazingly_ beneficial. No, the OP did not offer many
suggestions. But I imagine that, if the LightTable group did _not_ know about
some of the things that Eclipse does already, this post will help them out.
And this post will certainly get them thinking about whether some of what they
demoed is possible.

In fact, if it were me running the LightTable project, I might decide to start
with an MVP of building LightTable as an Eclipse plugin, to check out some of
their concepts.

Edit:

P.S. I shouldn't have to give "credentials" for expressing a view on HN, but I
will anyway. I've been programming professionally for 8 years, and I now run a
freelance/consulting software company so have seen many codebases.

More importantly, I'm an IDE and editor nut. Most of the start of my career
was on Visual Studio, then SlickEdit, and since then I've tried out many IDEs
and editors. I now mostly use Vim, while sometimes dropping into SublimeText.

I think Eclipse is an amazing tool, and couldn't imagine programming Java
without it. I think most people here would be absolutely amazed at the help
Eclipse gives in writing Java code, which I'm sure gives many programmers a
huge boost in their time to code.

~~~
SoftwareMaven
_For one thing, the op mentioned that, while functions should be small, they
usually aren't._

Functions shouldn't be small just to be small. Functions should be exactly the
size needed to encapsulate their function. I had to wade through a few
thousand lines of JavaScript in which every function was made as small as
possible (since functions are _supposed to be small_ ). Stuff like (and I am
_not_ exaggerating):

    
    
      var xor_it = function(a,b) {
        return a^b;
      };
    
      var xor_them = function(l) {
        out = 0;
        for (x in l) {
          out = xor_it(l[x], out);
        }
        return out;
      };
    
    

Turns out that, when functions are written based on small size alone, it is
nearly impossible to build a mental model of a system. I've reverse engineered
some ugly code (the previous worst was an object oriented system hand-built in
C (with constructors, vtables, and all)). That was child's play next to a few
thousand lines of three-line functions.

On topic, I tend to agree with you. The best parts of Light Table have existed
in one form or another for years, but that doesn't mean it isn't worthwhile to
"Try, try again". Approaching an old problem with new vigor can result in
amazing things, or nothing, but if you aren't willing to listen to criticism,
you will never make a better mousetrap.

~~~
dirtyaura
I agree that code with too small functions can be hard to understand,
especially if the naming of functions is not top notch. And naming things is
one of the hardest parts of programming. Ability to give good names requires
thorough understanding of concepts involved, which often isn't true the first
time (or even second time) you write the code.

There's also interesting discussion about "optimal" function length in Steve
McConnell's Code Complete. If I recall correctly, there was no evidence that
functions of even 100 LoCs for complex algorithms were significantly more
error prone than similar code with shorter functions, and that very short
functions actually lead to more bugs than code with functions with reasonable
length. I think it is because of naming: it's hard to name hundreds of small
things well.

------
GlennS
I'm a bit unconvinced about the 'language agnostic' assumption.

For Java, you want to get the most out of your static typing. So, you need an
IDE filled with analysis tools.

For dynamically typed languages, Eclipse doesn't cut it. It gets sluggish and
crashes too often and that's not acceptable when your language is designed for
rapid feedback.

I want something that gives me feedback as if I were using Firebug, but feels
like I'm typing into Notepad++, and it seems like LightTable could fill that
need.

My thinking is that Light Table will live or die by how responsive it feels.

------
6ren
Apart from a sparser screen, the heart is "instant feedback". There are
challenges in scaling this up from the demo, but I want to see what can be
done - it's Research and Development, not simple implementation. Chris Granger
has a solid background for this (on the Visual Studio team). And working code.
:-) IMHO there are obviously solutions to these problems, but I'm not sure how
graceful/usable they'll be. Maybe great; maybe just a significant improvement;
maybe just good for some niche cases - we'll see!

Firstly, we can sandbox - including the file-system; even make a copy, so it
runs without "really" changing anything (in the limit, there's
virtualization). Second, some of these problems are common to testing, where
mocking is a standard solution to the same problem of wanting to run just
_some_ code. [Perhaps a significant result will be a way of auto-mocking?] And
even if you don't Test, you still run code to see if it's working - this is
the same; just faster. How do you control what code you run? Light Table can
incorporate the same techniques. OTOH, I run code with ctrl-tab, up-arrow +
return. It's pretty fast. Easing the setup of that would be good though.

The full version is not going be as magical as the demo; but it seems unlikely
that current IDE tech has reached perfection, and cannot be improved upon...

------
sirn
> Even if it were somehow to ignore api calls that say, modify your
> filesystem, how would the IDE 'know' about that api. Will someone have to
> manually go through all the apis in existence and make a list of which ones
> to emulate and which ones to not? That doesn't seem practical.

Why do Light Table need to emulate something? People have been _executing_
code in REPL since forever, Light Table instant feedback seems like an
extension to the REPL concept, with an ability to substitute all variables
visually in-place. I can't see why it should be any different.

~~~
lemming
Because when you execute code in a REPL you choose when to do so, presumably
because you understand the side effects. The IDE doesn't but has to execute
the code anyway to give you the feedback. This might be useful for pure
functions but you'd need some kind of integrated mocking functionality for
impure code.

------
shadowmint
Don't agree with everything the author has to say (particularly functions) but
I think it's fair criticism.

LightTable isn't going to be a great fit for some languages, specifically c,
c#, java and c++ style languages; I'm extremely dubious you'll be able to get
the sort 'instant feedback' shown in the demo for that sort of compiled
complex language with cyclic dependencies (A imports B imports C, imports A.
Yay, java... :P).

...but really, that's not what it's targeting.

So, fair criticism to the author I feel: don't complain you won't be able to
use a hammer to cut down a tree.

------
iamgopal
I had an idea of creating IDE which frees developer from organizing files and
functions etc. Every class definition and functions will be stored in CodeDB.
Compiler/Interpreter talks to CodeDB to resolve. Controller seats in the
middle and talking to All three, developer, CodeDB and compiler. Maybe I
should create concept demo/video/image of it.

~~~
spooneybarger
You should check out a Smalltalk environment that isn't Gnu Smalltalk or
Redline Smalltalk, neither of which currently has the full Smalltalk IDE
experience.

"Pharo By Example" would be a good starting point. If you are interested, feel
free to email me, I'm quite happy to introduce people to what a Smalltalk
environment has to offer so they can take it back to their day to day and
start to spread the ideas.

------
jsmcgd
This critique seems to be analogous to a low level language programmer
dismissing the benefits of a high level language because both are Turing
complete.

Yes both IDEs may be able to do similar things, but it's the immediacy with
which you can do them which sets them apart.

<http://www.paulgraham.com/avg.html>

~~~
zerostar07
You gave the answer yourself: if you want to make programmers more productive
build a higher level _language_ , not an IDE.

IMHO IDEs are overrated. If any process can be automated, it will eventually
end up in code, not in a GUI.

[disclaimer: i dont use any IDE)

~~~
gnaritas
Your critique is off the mark. IDE can do things that make no sense as a
language feature but help you write code very fast. Command keys for things
like show me all senders of this method, show me all references to this class,
show me all implementations of this method, show me all inheritors of this
method, go to the definition of this thing, show me a tree of the class
hierarchy, rename this method fixing all senders, extract this code into a new
method, extract these methods into a new superclass, push these methods up or
down in the hierarchy.

These are things IDE's can do for you to enable you to code much faster by
being aware of the structure of the language rather than editing everything as
streams of text. I work in sublime text 2 doing ruby code, and I miss the hell
out of these Smalltalk IDE features, text editors just can't compare; they're
great at slinging text, but I don't want to sling text, I want to sling around
semantically relevant chunks of code in ways that don't break it
automatically.

------
politician
There are many _many_ comments from people who watch the Light Table video,
which is clearly written in a Lisp, and come away thinking that it'll work for
their Javas, Pythons, or C#s. Yet, it is not at all clear to me that Light
Table is an appropriate IDE for languages that are not functional and are not
homoiconic.

I don't think it is entirely Chris's responsibility for dispelling Java
developers of this crazy notion that Light Table is for _them_ , and it might
hurt the fundraising effort; but would you really want to be funded by people
who have no real grasp of what you're building?

------
pbreit
The OP comes off as a jerk, mistakenly claiming that Light Table was presented
as "game-changing" or "revolutionary, outright dismissive of things that "were
done 10 years ago" and, worst of all, critiquing in detail something that
doesn't even exist.

------
gfodor
Nobody said it was going to be easy. Where's the author's imagination? My
guess is it was slowly killed by working inside of Java for many years.

------
daniel_solano
Is the demo a bit contrived? Sure, but it's an inspired vision that was
whipped up _inside of a week_. I don't think the creator has any illusions
that making the vision a reality will be _easy_. However, it is clear that
this vision is inspiring to a lot of developers and has some traction.

------
NathanRice
I don't much care for trendiness or bandwagon hopping, but there are a few
things about lighttable clearly hit on the future of computing (though quite
by accident, I imagine).

First, programs and databases will grow together continuously. The missing
piece of the puzzle here is that currently most people view databases as a
single correct representation of the world, and assume that whether you have
an acid database or a nosql solution, all transactions must eventually be
reconciled, and a single truth must emerge. This is patently false. In
actuality, database systems will begin to resemble distributed version control
systems very closely over the next five to eight years, until they are almost
indistinguishable. The two will meet in the middle as all distributed revision
control systems end up using off the shelf graph database systems, and these
graph database systems incorporate additional functionality to support one
them. At some point most editors will be capable of speaking directly to the
database systems without file intermediates, and if we need to transmit
program data from one place to another, it will be via cloning/replication, or
a textual dump and restore in some (rare) circumstances. Make no mistake about
it, the key-value and column based architecture of current nosql solutions is
going to transition to graph databases in the not to distant future - the
algorithms to make efficient use of graph databases aren't _quite_ there yet
but it is getting very close. The idea of a single consistent world view is
going to shift to various contexts and sub-contexts where consistency need not
hold throughout the hierarchy (exactly in the manner of forks and branches).
We will share data by establishing contextual nesting and hierarchies of
information primacy.

Files are an artifact of early computing architecture, and holding on to them
beyond their useful lifetime will only anchor us.

------
blahbap
There is definetely room for an IDE that is more intuitive and slick than
Eclipse - I find Eclipse's many views and modes distracting. Perhaps Light
Table is not a revolution of IDEs, but it is certainly a welcome leap in the
evolution.

------
loup-vaillant
> _I am assuming java here, so i will refer to classes instead of functions
> for my examples._

This particular difference makes this part of the comparison meaningless.
Functions and classes don't operate at the same level of granularity. Thinking
classes vs thinking functions can produce very very different code, especially
if your classes are assignment happy, and your functions avoid side effects.
Plus, you wouldn't search the same way. In a class setting, one would search
for _data_ to process, while in a function setting, one would seek to
_process_ data.

------
xer0x
I'm really impressed with LightTable, and I was hoping for a more insightful
critique of the project.

The integrated prototyping playground within the app is an excellent idea.
Yes, LightTable is borrowing many ideas from WorryDream.com and that is one of
the reasons it is so promising.

Anyway, seeing so many people missing the point of this project finally pushed
me into sponsoring it on KickStarter.

------
overshard
I'm not sure why so many people are up-voting this. It isn't constructive or
useful. It seems to be a guy who has a vested interest in Eclipse and Java
trying to downplay a possible future competitor to a framework and environment
he is comfortable with...

------
Rage
Eclipse as a good ide ? mpprfrffrt

~~~
andos
"It is difficult to get a man to understand something, when his salary depends
upon his not understanding it."

That's the blog of a company that makes a tool that integrates with Eclipse.

~~~
dibbeke
Ah, another ad hominem! Let me reply with an ad hominem:

Would you translate your statement into:

"It is difficult to get Prashant Deva to understand something, when the salary
of Prashant Deva depends upon his not understanding it"?

No? Then don't make your senseless statement. Please argue his statement
instead.

Or, maybe you're not a computer scientist, because you're not able to
comprehend and participate in a normal discussion?

~~~
Rage
Well, Eclipse is slow, crashes, has a lot of features but doesn't really do
anything nicely (javadoc integration is damn awful tu use). More features
doesn't mean better.

What i like about LighTables is that it seems to have few features, but do
them well. It has a nice clean UI (even if it's just mockup, i don't think it
needs anything else) and the UX seems nice too from what i understood.

Maybe what you didn't understood is that it's NOT an IDE for computer
scientists : it's more aimed to visual programmer, webdev, or gamedev,
creativecoders. People that want to do both design and coding.

BTW : i just trashed Eclipse, not anyone. I still use it because it's still
the best ide for javacoding (even if i haven't done any in a while), which, to
me, isn't really flattering for the state of coding IDEs.

~~~
dibbeke
Eclipse needs a good amount of memory and recently, unfortunately, has a
tendency to crash. Most of the features can be disabled; the UI can be
reconfigured to your liking. Btw, I generally disable the javadoc view and
just F3 to the location to see the code and docs together (docs are often
wrong anyways).

The problem with mockups is that they haven't touched reality yet: there is
always so much detail you don't see at the start.

~~~
Rage
yup, but eclipse is too big for me i think, i'm not really a fan. I prefer to
user sublime text with completion help that run instantly.

------
richardk
_Also even if the code were indeed based on just basic numerical or string
primitives, how would the 'instant feedback' work if the code were in a long,
tight loop or did heavy cpu intensive stuff?_

I think this is a critical point, has the author of LightTable considered what
would happen with instant feedback for less trivial pieces of code?

Besides that, I think this critique is fair, because honestly when I saw
LightTable, it seemed like smoke and mirrors. I have a friend quietly writing
an innovative new text editor, I expect it will be more 'ground-breaking' than
LightTable, but I don't see him trying to take everybody's money.

~~~
Zak
_I think this is a critical point, has the author of LightTable considered
what would happen with instant feedback for less trivial pieces of code?_

Some of the code in his demo talked to the web framework he wrote (that I use
in production code) and IIRC to the SQL abstraction layer he wrote (that I
also use in production code). Something makes me think that he has given some
thought to how these things might interact with the real world.

I think it's fair to ask for money. Chris Granger has a track record of
building useful, production-worthy libraries and tools both professionally and
as a hobby. If he's going to not work for a while, possibly hire other people
and build an open source IDE, it's reasonable to ask for outside funding.

~~~
richardk
I'm not sure about others, but I wouldn't give my money to any software
project that didn't describe in detail how it might overcome such glaring
design challenges.

~~~
Zak
You seem to be focused on the instant feedback and stack display issues.

Instant feedback is not meaningfully different from a REPL in this respect. It
is unlikely you would type imperative things like "delete this directory" in
to a source file. You might define a cleanup function that deletes files, but
it would be pretty unusual to call it at the toplevel unless you were
intentionally using the code buffer as a REPL. I'll grant that immediate
evaluation of such things might be a little dangerous, but Clojure, though the
JVM does have mechanisms to dangerous things like file IO.

Stack display seems like an easier problem to solve: only display a certain
depth, or just put a scroll bar on it. It doesn't matter how much stuff there
is as long as you're looking at the part you're likely to want by default.

I think the one downfall of this project as currently envisioned might be that
this is a great concept for Clojure and perhaps some other functional
languages. It _could_ be good for JS if written in a mostly functional style.
Python is a little less functional and is commonly used for scripts, which
wouldn't play as nicely with instant feedback.

Scripts are distinct from applications or daemons in that they normally
contain a sequence of imperative actions that they evaluate and then quit.
They might not define any functions at all. Applications and daemons typically
run code from an entry point like a main() function. LightTable seems to be
designed with Clojure in mind, and Clojure was not designed with scripts in
mind.

~~~
richardk
I'm not familiar enough with Clojure to comment.

------
ABS
classic example of "a little knowledge is a dangerous thing". Many of the
other comments explain why.

------
catshirt
herein someone who doesn't program functional or dynamic languages concludes
light table is contrived or impossible because Eclipse already does the job
for them.

likewise, criticizing the long term potential for a project like this because
it had tabs in the concept video is silly.

------
camperman
"Since I am a Java guy and the IDE concepts are defined as being language
agnostic and that support for additional languages can be added later, I will
compare the examples using Java code and Eclipse as the IDE."

And you end up proving nothing more than Java isn't a dynamic language where
everything is available to you all the time without recompiling - and
therefore won't really fit into to LightTable very well. The examples in
LightTable are not contrived as you call them - people using dynamic
programming environments work with instant feedback like this all the time.

~~~
Uchikoma
I'd like to learn how a dynamic language here is different from "static"
language like Scala. Care to explain?

~~~
quadhome
Dynamic programming environment. Not dynamic language.

See: SLIME <http://www.youtube.com/watch?v=_B_4vhsmRRI>

~~~
Uchikoma
Thx.

------
rjurney
Java is an Integrated Develompment Environment scripting language that is
incompatible with Light Table.

