Hacker Newsnew | comments | show | ask | jobs | submit login
LightTable detailed critique: Concept vs Reality (chrononsystems.com)
193 points by pdeva1 1228 days ago | 132 comments



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.

-----


> I just can't imagine anyone disagreeing that most code looks like this in the real world.

I disagree, at least when it comes to Clojure.

The size of the functions in the demonstration is about average for Clojure. The author of the critique suggests that the examples are "contrived", but speaking as a Clojure programmer, I didn't get that impression at all.

Hidden state change might cause problems for tracing the values of variables, and I wonder how well Light Table would work for Javascript. However, since Clojure is a functional language, there's very little hidden state to worry about.

Most of the critique seems to be either "This isn't new" or "This wouldn't work in Java". But just because something isn't new doesn't mean it isn't beneficial to do it, or that existing UIs could not be improved. The Light Table demonstration of inline docs seems more responsive and more immediate than the equivalent functionality I've seen in Eclipse.

Secondly, even though Light Table is supposed to be language agnostic, it doesn't really seem designed for languages like Java. The dynamic code traces demonstrated would work very well for Clojure, but I can certainly imagine production Java code being too complected for it to be useful. But that's fine; just because it isn't suited for Java doesn't mean I can't take advantage of it in Clojure.

-----


> I disagree, at least when it comes to Clojure.

This hits on another difference: Java is much, much, much more likely to be used in the real world over Clojure. The set of people who use Clojure are very likely to be in the set of people who write small functions, both because they're more "cutting edge" in terms of TDD, because they're only writing "toy" or "hobby" projects, or because they're just better programmers (e.g. Paul Graham's article on Python programmers tending to be better).

Having said that, please don't be offended - I'm speaking in generalities here. If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.

Btw, I completely agree that making an amazing IDE for only one language is still a great goal, even though I would personally find it hard to work with a different IDE for Clojure and for my other code.

-----


For those of you who don't know, weavejester is the creator and maintainer of a few of the more prominent (and, in my opinion, production ready) clojure libraries (thanks!), mostly centered around web serving. His code is concise and chunked into many small functions, abstracting out as much functionality as is possible -- this is the lisp way.

If you've written much clojure (or any other lisp, really) you likely realize that writing massive functions is not a part of the lisp paradigm, and for good reason -- not only are large functions tough to read, but the notion of everything being a function makes it natural to build what are essentially nested function calls into more abstract functional representations.

I understand why Chris has mentioned support for other languages (raising money + support), but anyone who approaches this project should really keep in mind the fact that it is being built with Clojure in mind. I'm sure that, should it be funded and seen to completion, Light Table will provide a rich experience for other languages, but what is most exciting about this project is its potential to truly cater to the needs of a functional programmer. As he correctly states in his introduction, functions are the most often used "block" in functional programming, and editors/IDE's should reflect that and I am hoping Light Table manages to do this.

Regarding the criticism of live code evaluation, I see it as a bit absurd. It should be obvious that the main goal of such an interaction with one's code is not to test functions on live inputs. I see this being most useful in scenarios where the programmer wishes to, say, process strings read in through a socket. Live code evaluation could be immensely useful in a situation in which someone writes their parsing functions and then calls the higher level function on that test input and sees the string progress through their parsing functions, making it much easier to debug. This is just one example.

This response is a bit scattered, as I wrote it piece-wise while cleaning up. Sold as-is.

-----


> If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.

Go look at any Clojure project on github. Seriously.

Stuart Halloway, one of the more prominent Clojure committers and evangelists once (semi-)famously said: "No function should ever be longer than 5 lines. And if you think you have one that needs to be longer, show it to me, and I'll prove you wrong."

That is some of the ethos behind the language.

-----


He later said that this is not true after some people provided some examples. Its more a 99% rule.

Most of them are Java Interop related but sometimes a algorithem is clearer in one function.

-----


>>sometimes a algorithem is clearer in one function.

Once many such reusable algorithms come up. The function sizes keep shrinking.

-----


I can say that all of the Clojure code I've personally seen for "real world" systems in Clojure tend to have a very small average method size, but I can't speculate on proprietary code I haven't seen. Certainly most open source Clojure code is very well written.

And if Light Table is only an IDE for "better programmers" then I don't think that's necessarily a bad goal to have. That said, since Light Table is supporting Javascript as well, it's not exactly only catering for minority languages.

-----


I don't think it's even a matter of 'well written' as such, just how the language works.

When every code path must end in a return value, writing large functions becomes difficult.

-----


This made me go check our Clojure code base at work: including comments, docstrings and whitespace, our functions average about 11.5 lines each (and I know we could clean up some of our earlier code to reduce that average). So, yeah, I'll consider that evidence that real world Clojure is pretty tidy.

-----


Out of curiosity, do you know the average without the docstrings and whitespace?

-----


Real world Smalltalk projects have mostly short methods, with some exceptionally long ones.

-----


The gap probably isn't that wide, if at all, when only considering folks who might use Light Table.

-----


>>I'm speaking in generalities here. If you specifically have evidence that real world systems written in Clojure still look this tidy, that just makes me want to learn Clojure all the more.

The number of people even wanting to learn clojure are generally going to be in the bracket of people who are going to learn not just for a living but to perfect their craft. So you are likely to find good programmers in Clojure than in Java. In fact it might be difficult to find bad clojure programmers.

On the hand other chances of finding good programmers among java programmers is going to be difficult. And your average Java programmer can't even write a fully functional program let alone a full app without eclipse doing 90% of the auto completion, and vast part of code automation happening automatically for him. So the IDE use case for a java programmer is totally different. What a java programmer needs is a tools that can program in itself with little inputs from him.

Light table is not for code automation and auto completion in itself. Its for programmers who like think instead of IDE doing that for them.

-----


I think you are arguing a cultural phenomena.

I am an Eclipse power user myself but alas Eclipse is not an effective option if I need to drop into a remote server and cut some code. (Yes, I use VIM for these occasions.) And let's be perfectly frank: developers who get their start on IDEs are typically (not all, don't be offended) relatively clueless on the command line. IntelliSense gives these what unix commands have long given the developers who got their start on _nix, vim/emacs, and find, grep, awk, sed, etc. [their] way through their workflow.

My personal take on LightTable is purely aesthetic; I think it is gorgeous. Eclipse (and even IDEA) are really too noisy and just feel heavy. Psychological aspect of programming is very important. To wit, IDEs encourage complexity and bloat and fat function/methods. On the other side of the cultural divide, the tools really encourage (but don't force) you to be concise. Naturally, the language being used also has a significant say on what is idiomatic code.

I think it is perfectly fair to say that the LightTable concept may not scale to cover the entire spectrum of developers, but given a matrix of workflow, language, and development environment, it probably hits a sweet spot for a not so insignificant segment of coders out there.

-----


To wit, IDEs encourage complexity and bloat and fat function/methods

I write all my Clojure code in IntelliJ, using a (customised) version of La Clojure. Could you explain to me how this encourages complexity and bloat in my code?

-----


Encouragement is suggestive[,] not coercive.

-----


He is talking of programmers who start programming with IDE's and nothing else. If you belong to this category it will difficult to explain you the very concept of bloat, because that is what you have started with and feel it to be perfectly normal.

Most people who program in Editors I know read the documentation, manual and tutorial better. They think and code. On the other hand IDE only programmers I know can't write even simple functional programs without IDE, autocompletion and intellisense.

Take a big Java project and try to work on it without IDE/eclipse/IntelliJ, that would give a true picture of how much work IDE had automated for you.

-----


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.

-----


That's definitely pathological, but not from a "small function" point of view. xor_it is simple unnecessary to write and xor_them is just a fold on xor_it. This is undue multiplication of names.

    _ = require 'underscore'
    xor_them = (them) -> _.reduce(them, (a,b) -> a^b)
Or better

    import Data.Bits (xor)

    xor_them :: Bits a => [a] -> a
    xor_them = foldl1 xor

-----


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.

-----


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

As a longtime Smalltalker and contributor to a Smalltalk development tool, I think it is possible, though the odds are long, based on what the LightTable guy doesn't know.

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.

Eclipse has its roots in Visual Age for Java, which for many years was one of the best Java IDEs, and was originally written in Smalltalk. Smalltalkers often have a long view of progress in development environments, because they've witnessed lots of dumbing down of their ideas, which start out woefully inadequate then end up feature complete but hopelessly bloated.

The author of the article talks about finding functions, but offers as a comparison finding classes. This indicates a bias due to an incomplete understanding of how things work in other languages. In Smalltalk, I'm searching for functions all the time. Many times, I only look for a class because it has a certain function.

-----


Several people in the original LightTable thread mentioned that SmallTalk has many of these ideas. I confess that I know nothing about SmallTalk - can you please point me to a description specifically about SmallTalk IDEs and how they do all these things?

-----


I'd suggest as a simple introduction, downloading a copy of "Pharo By Example" and working through everything in it.

Pharo isn't the prettiest of Smalltalk experiences, but It will give you a glimpse into Smalltalk but really, it takes a good amount of time of use ( for me it was 9 months ) before I really got Smalltalk.

I'd also be completely happy to have an ongoing email conversation where I could answer any questions you have and fill you in on both the good and bad points of the current Smalltalk experience.

-----


I can't help but feel that every person I've seen who loves their IDE codes Java. I, for years, did not understand this finding vim and emacs perfectly sufficient. I liked SLIME, but found it only marginally better than any non-"superpowered" editor/repl pairing.

Then I tried programming Java. I concede totally. It's not just easier to program Java with an IDE, Java is essentially designed to be impossible to code without an IDE. The language is simply too large and spread out to be held in your head without the help of tools.

I think the complexity you talk about---large functions in particular---are also endemic of "Java style". Clojure is a great example of code designed without an IDE in mind where functions need to be small and orthogonal just to make it possible to survive without an IDE. I think Light Table embraces that idea and seeks to solve organizational issues involved with "Clojure style" coding.

-----


On could also see it exactly the other way round: Java's strong typing makes it possible for an IDE to do amazing things, which help you cope with horrible codebases, which in turn makes code viable that would be completely unmanageable in other languages.

As for "Java is essentially designed to be impossible to code without an IDE.", I'd say that's a pretty ridiculous statement given the state of art of IDEs at the time Java was designed and became widely used. They did little more than integrate editor, compiler and debugger.

-----


Perhaps it just has to do with modern practices and libraries encouraged by modern IDEs. I approached it recently, so I can't speak for times before the IDEs were there.

Strong typing is certainly very helpful for making smart compilers and tools---I can't deny that, I'm a Haskell junky. I don't think it's always a best practice though. Being able to handle horrible codebases means that the language/editor environment also allows horrible codebases to survive longer.

-----


That always seemed a really, really unproductive notion to me, that great tools must be bad because they help you deal with problems that would otherwise make you fail sooner.

-----


I didn't say IDEs weren't powerful or good in and of themselves. I indicated the opposite. Sports cars are fantastic. They are really fun to drive. I would start walking if everyone in America had one. Too dangerous.

-----


I didn't say IDEs weren't powerful or bad. I indicated the opposite. Sports cars are fantastic. They are really fun to drive. I would start walking if everyone in America had one. Too dangerous.

-----


No Sorry, And please.

Almost all Java programmers I've seen so far can barely write any code without IDE, autocompletion and intellisense. Even people who claim to have years of experience in Java.

Its just the community is very heavily on IDE side. The libraries, frameworks are all heavy bloats designed with the perspective that IDE is going to take care of that anyway.

In other words, Java world without IDE doesn't exist and I presume that is going to be the case for a long time to come.

And that is one of the reasons why I never went deep into Java because one tour of eclipse and the best and worst Java programmers both become the same.

-----


Yeah, do keep repeating your bias and prejudices while ignoring conflicting facts pointed out by others, and tell yourself that makes you smart.

-----


Its neither a bias nor a prejudice. Because I write in Java and Other languages like Python and Perl in my day job. Although I'm trying to run away from Java as quickly as I can.

Vast majority of Java programmers can't program without IDE's is a fact. Java being verbose is a fact. Java frameworks being bloated is a fact. Medium to large Java application not being easily handled thorough ordinary tools like text editors is a fact.

Its almost like what Dijkstra said couple of decades back about basic. It can destroy your thinking abilities. I don't want to risk mine with too much exposure to autocompletion and intellisense. And without them it makes zero sense to write in Java, as you can no longer be even remotely productive.

Well I don't know about others, but I, myself would not like to be bunched in that kind of commodity market of programmers whose only known expertise is 'Knows how to use an IDE'.

-----


http://en.wikipedia.org/wiki/Proof_by_assertion

-----


""looks cool, but can't be made".

Why not? It's definitely cool and definitely can be made. The question is: will anyone want to use it, or is it just cool? Is the learning curve too steep to make us want to adopt it as our primary text editor? Does it really confer efficiency advantages over Emacs/Vim/TextMate/XCode/Eclipse/etc?

To me, it stands a good chance of being widely adopted if and only if it is actually more efficient to use it and if the time of adoption doesn't outweigh those efficiency advantages. I don't have an answer to this question, because I haven't actually used it. I suggest that since everyone else hasn't either, we wait to pass judgment on whether it will work or not.

-----


Efficiency is actually not the only, or even most important, concern. At least, not necessarily.

For example, one important consideration is how easy to use it is, especially for new programmers. For better or worse, Eclipse makes programming in Java easier for many programmers. This is a pretty important consideration for most organizations.

-----


I think valuing how easy it is to learn over efficiency is not the best option: learning even a difficult text editor takes a constant and reasonably small amount of time. Being more efficient is a benefit proportional to how much you use the editor. So anybody planning to program for a long time is probably going to be well served by learning a more efficient but "harder" editor.

Now, in the real world there are other considerations and the question is more complicated with regards to actual editors. However, given a hypothetical choice between something harder to learn but more efficient or easier to learn but less efficient I'd go for the former each time.

-----


This whole talk of efficiency surprises me. if that is what we are looking for, then in my mind you are either writing too much code or aren't thinking the problem through. In my experience, coding takes up less time because you get better at it.

-----


Efficiency isn't really about entering text, it's about quickly navigating around large amounts of text, editing parts, performing larger operations, integrating the rest of your workflow (maybe a REPL or a browser preview or tests...), testing code, exploratory programming, combining different languages, working with markup languages (HTML, XML, Markdown, LaTeX), writing documentation, reading documentation...etc. The beauty of Emacs is that it does all this (and more :)) well for a whole range of languages.

The goal is not just to be able to do anything you need quickly, but to do it in a way that doesn't break your concentration and doesn't take much thought. Moreover, this has to apply to pretty much every sort of thing you do with your source files, which is actually quite a lot. Today, almost any work you do on your software project as a developer involves text, not just programming, so efficiency really matters.

Additionally, it should be really easy to create complicated workflows for your specific project. For example, I am working on some code that operates on two trees and produces a third. It literally took me half and hour to create an Emacs command that took some (configurable) input, ran my function on it, rendered the result with LaTeX (using a tree-drawing package) and displayed it. This way, when I make an edit to the algorithm, I just run a single command and see the output immediately with a nice visualization. This makes playing around with modifications to the algorithm very simple.

-----


Right - I include that under the learning curve question. But, that said, there are plenty examples of editors that are obviously not easy to use(cough Emacs?) and yet tons of people still use them because (apparently) they are more productive in Emacs. I'm not one of those people - I tend to prefer TextMate or TextMate-like GUI editors. But I can see how people are willing to suffer through a steep learning curve in order to ultimately become more productive. LightTable might end up being the same way.

-----


Speaking of Sublime Text (2), I find that it has a lot of the features that Light Table is supposed to have. I can work with an abstracted view of file heirarchy (need to find a file? Shift+Cmd+P and then type anything - the fuzzy search beats wildcards any day). Need to find a function? Cmd+P and then type what you need.

Maybe in some version of ST2, they will add the ability to see documentation in an overlay when you mouseover a method (or maybe someone will write a Python plugin to do that). This editor already seems to be a long way towards the goals of Light Table.

-----


"looks cool, but can't be made"

Or, rather, "Looks cool, but wouldn't be really all that earth-shaking."

-----


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

-----


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.

-----


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

I use Java fulltime at work and also have some problems where recompiling classes on the fly doesn't work. I never had the problem with Smalltalk. To assume the problems in one environment will be problems in another is exactly the problem with the original article. It assumes that because something similar exists in X, it would be the same in Y and have the same sorts of issues and rewards.

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

A large chunk of what is in light table has existed in over a quarter century in Smalltalk environments and been used to build large and complex applications.

-----


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.

-----


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

-----


> he problem with Java is the sheer amount of 'bad' code written in it

java was designed to influence code towards solving all problems with classes. the "bad code" you speak of is idiomatic java code.

Jane Street wrote about how they migrated core systems to java, abandoned it because "But somehow when coding in Java we built up a nest of classes that left people scratching their heads when they wanted to understand just what piece of code was actually being invoked when a given method was called"[1]. then, the same team moved to a functional language to great success.

Writing "good code" in java takes discipline and expertise to overcome Java's gravity towards classes. Without discipline and expertise, teams end up at the natural equlibrium you read about on thedailywtf.com. java did an awesome job of replacing C++ for the last 15 years, but there's something inherent about the design of java that doesn't scale well with the bigger, higher complexity problems we face today.

[1] http://queue.acm.org/detail.cfm?id=2038036 ~10 paragraphs in

-----


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.

-----


one reason is probably that he is the developer of a "DVR for Java" that "Record entire execution of your Java app" and allows you to "Play it back on any machine".

That and the clear lack of experience with anything different than Java is clearly heavily influencing his perspective.

And I think there is no malice, it's just biased without realising it

-----


I smell 'ad hominem'

-----


not really, just that all of us come with a point of view and I think his is made clear by the work he is doing on that project.

Never used it, looks interesting and useful for Java. That's where I think the problem is: if you have used only one tool you tend to see everything from that perspective.

-----


His argument is on how most concepts in light table are not novel. Branding light table as novel or groundbreaking is therefor incorrect and his post is called for.

You seem to attack his argument on his background as a Java developer and not on parts of his argument. As far as I know, this is called an ad hominem attack and in my opinion does not belong on Hacker News.

If you can find good counter arguments on his arguments:

- Light Table is not novel or groundbreaking since Eclipse has had these kind of features for at least a decade (and several Smalltalk IDE's have had them for several decades), - Light Table's examples are contrived because real world examples do not behave in this way,

we'd be having a real discussion.

-----


first: I replied to zacharyvoase's comment and therefore my comment was related to his, don't take it in isolation.

There are plenty of other comments here that explain why pdeva1 is coming from the wrong angle therefore I'm not going to repeat them.

Chris never mentioned novel or groundbreaking, others have so go and ask them but please before you do that look up the difference between invention and innovation and also remember that novel really means fresh or refreshing (although it's used most of the time to indicate new)

-----


As far as I can see, you're arguing:

"Since he's a Java developer, he delivers critique on LightTable".

thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.

On your last argument I would like to add that on Hacker News it is clearly branded as the next big thing since sliced bread.

Of course languages such a Clojure, Scala and Haskell need more sophisticated IDE's than vim + plugins. Especially for larger projects. And as such I think the features in the POC are a good idea. Still, they are nothing new and I'd expect them in any modern IDE. I could add some idea's of my own (stealing from an IDE I use daily):

- annotate the source with a git history - highlighting based on AST instead of regex's - outlines

Anyways, we agree that Light Table is not novel, nor groundbreaking and it's not an invention. Exactly the point Prashant Deva was trying to make. Nothing to see here, move along.

-----


"Since he's a Java developer, he delivers critique on LightTable".

thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.

No, it's more that he's writing as if he's unaware how parochially Java-centric his viewpoint is. Many of his points aren't very useful for other languages.

-----


Ah, finally, here we have the gist of the argument: "Many of his points aren't very useful for other languages." The rest is all noise and no signal.

Well, although that point has been answered on other parts of the forum, it seems the auto-eval function is reserved for immutables only and non-recursive languages. So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points?

-----


So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points?

It seems we've touched a nerve, which is a bit embarrassing. Clearly, the kinds of things the Light-Table gentleman is talking about are applicable to more than zero languages. I know because I've spent 1.5 decades coding in one. That you'd make such an argument indicates you aren't in command of all the facts, or you're willing to take or build up strawman interpretations.

(One famous gentleman once said, "If you ever get someone upset, you've struck gold!")

That said, "auto-eval," if this means automatic re-evaluation of everything is slick demo stuff. But nimbly being able to edit and save any source code, then being able to fearlessly rewind the stack to an appropriate point and go on as if the change was always there would be appropriate even for very involved and long running code, and is quite real.

Similarly, I know for a fact that everything else in the Light Table video has approximations in real environments.

-----


How would you render trees or (big) matrices? Recursive functions? Infinite lists?

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts"); by claiming a conflict of interest while this is not applicable (the OP does not claim authority!); or by appeals to authority ("because I've spent 1.5 decades coding in one").

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

-----


How would you render trees or (big) matrices? Recursive functions? Infinite lists?

You don't. I think the Light Table author is naive here. Instead, you let the programmer rewind the stack at will.

I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts")

The facts in question have to do with things I've seen implemented. Your argument is an indication you aren't aware of the same. That's not tainting your credulity. I'm questioning if you have all the facts.

By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.

You are the one who is upset. You are also incorrect about what you purport to be upset about. (My intentions in pointing out certain facts and their implications.) Please process this data.

-----


Ad hominem aren't always a logical fallacies, and, in this case, might not bet at all. Ad Personam are.

You should read Eristic Dialectics: The Art Of Being Right by Arthur Schopenhauer.

Saying he is biased because he is a java-only programmer isn't clearly a wrong statement, and it doesn't mean he's totally wrong either.

Just saying, but that's not the point of the article.

-----


Thanks for the reference, I'll surely read it. [Pause] I've just read the first couple of chapters and it is most surely an enjoyable read. It brings the current discussion into a completely different light. Thanks again.

-----


I'd say that instant eval in the 'inventing on principle' fashion does make it novel and groundbreaking. Everything in it don't have to be. The core premise, a general purpose IDE based around those ideas is.

-----


I don't even see it as a critique, it's more of a "I use Eclipse and I like Eclipse because it is tailored to my needs as a Java developer" article.

-----


Exactly... though it really underscored the idea that the tools we use (and the tools that go with those tools) can shape our worldview.

What would have happened if the author took those objections and turned them around, asking instead, what sort of language would need to exist to work ideally with a tool like light table? And, possibly, what sort of problems could more easily be solved if we adapted our language/development model to work with an environment like light table?

There may well be no amazing breakthrough here, just as the OP seems to argue, but it certainly seems as though it could (or should) function as an opportunity to rethink our tools and development methods a bit...

edit: Also, to the claim that many of the features of light table have been implemented elsewhere already, I'd point out that rarely are good ideas purely new, but successful advances come from sticking many little bits of innovation together in a powerful way

-----


I'd agree.

As with all things in life, sometimes even the best of us get into arguments. From semi-colons to jumping the shark because your app is published on multiple platforms, geeks have been known to have their fair share of silly rants. And this article represents one of them.

Let's ignore the obvious confirmation bias of the author with their Eclipse background and ask ourselves the pertinent question: even if the author is correct, so what?

With open choices, we can choose to use any IDE we feel like. Some, like myself, feel that Eclipse is too cluttered and would prefer a visually streamlined system. Why then devolve yourself into putting down the work of others because you don't like it?

There's an absolute difference between a review and the way the author propositioned and explained his rationale as to why Light Table was not for him, explained by the reactions here in HN.

Let's be critical, rather than criticise.

-----


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

-----


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/

-----


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.

-----


All you need is a VM, a good standard library with mostly functions with minimal side deffects, a way to save all runtime state, and a way to log every change and replay them in case of a crash.

-----


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.

-----


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.

-----


Parenthetically, I get rather irritated with people who like to criticize everything as "not novel." Depending on how you look at it almost nothing is completely "novel" ("nothing new under the sun" and all that).

What is important is the execution and new wrinkles in the CURRENT iteration - NOT whether something vaguely or even pretty similar was attempted or proposed at some point in the past.

-----


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.

-----


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

-----


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

-----


Dynamic programming environment. Not dynamic language.

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

-----


Thx.

-----


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.

-----


I wonder if this is one of the reasons we are stuck with crappy development tools in era of slick iPads. Not only do we balk at the amount being raised (also happened with ruby.app), we also tend to criticize any thing that looks new and trying to change status quo. At the worst this will be a half baked IDE while still offering some creative features paving way for (hopefully) better future IDEs. You don't see many people haring off to criticize other creative projects the same way outside programming world.

-----


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

-----


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

-----


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

-----


I also would like to see a system that forbid me to write code that is not covered by a unit test yet.

I suspect that would lead to the people who are currently not writing unit tests writing useless tests just to circumvent the requirement. It would also make exploratory programming, where you haven't completely figured out what you want it to do much more difficult.

-----


See, THAT is why you think before you leap. Iteration #1: make it 'forbid to commit code' instead of 'forbid to write code'.

And I agree that that might only work fine in safety-critical code.

And writing useless tests won't help if this would be as strict as I envision. Imagine a project where you cannot commit

   if flag:
     doA
   else:
     doB
unless you have a test that hits the doA part and a test that hits the doB part. Complete code coverage, enforced by the system. I am thinking more and more that I do want to see such a tool, but not really will want to use it. Maybe iteration #2 is "hm, that is not the best of ideas". Although, if somebody would want to pay for such enforced code coverage, it could be fun to search for with design patterns that help it make easier to write such code...

-----


Are you reinventing design by contract using tests?

-----


Now you mention it: yes, probably.

-----


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.

-----


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

-----


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.

-----


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

-----


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.

-----


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

-----


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)

-----


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.

-----


These days, the IDE is apart of the language; we will see more languages that push integration with their IDE in as much as Smalltalk did in the past.

No one would think about using a language without a compiler, developers increasingly feel the same way about the IDE.

-----


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?

-----


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.

-----


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.

-----


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.

-----


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.

-----


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.

-----


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

-----


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.

-----


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.

-----


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

-----


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

-----


As he says in the article, functions should be small but real world code isn't always written the way you'd want it to be. I think instant feedback would be great for understanding a piece of code that I didn't write but the chances are that if I don't understand it it is probably badly factored with large function sizes and mixed responsibilities all over the place.

Ultimately there will be code for which this feature is useful and code for which it is not. I can't say I wouldn't want it to be in my IDE's bag of tools though.

-----


It should be annoying as possible to write/read long functions. I don't know why IDE's/editors make it so easy to write 500 line functions; it's always bad. I interview over 10 programmers/day and function size is a huge filter; you recognize crappy programmers fast that way.

-----


Instant feedback is what makes LightTable the great concept it is.

-----


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

-----


Eclipse as a good ide ? mpprfrffrt

-----


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

-----


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?

-----


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.

-----


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.

-----


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.

-----


I would translate it exactly like that, though it's actually not ad hominem but ad humanitatem, really. We are all biased creatures, as others have pointed out. I think the critique is biased, I think it is biased because the author put a lot of effort in his (otherwise awesome) Java product, and therefore I quoted Upton Sinclair.

For instance, he argues that it would take a lot of working around to provide instant feedback for code with side-effects, but isn't that obvious? The LightTable video doesn't claim it magically mocks every external component or does some other fancy stuff. That doesn't make the feature less useful, especially in a language like Clojure, which was used for the demo. For me, that part reads much like "since it ws so hard to create Chronon, one cannot pretend the LightTable features are so easy to implement. Let me prove that by putting LightTable in the context of my product."

There was — deliberately, yes — a bit of snide and a lot of cynicism in my post, but I hope to have made it clear that it was not without a reason (for the cynicism, at least).

-----


If a scientist is funded by the petroleum industry and publishes articles saying that climate change isn't happening, is his connection relevant?

If a doctor is funded by a drug company and publishes articles saying that the company's drugs are good, is her connection relevant?

Even the best scientists can be biased, and being aware of the biases can help one decide how much attention to give arguments. If Prashant Deva is biased by his experience and funding against the technology that he is critiquing, then that is relevant information to me and many other people who read his critique. To suppress that information, as you seem to be trying to do, would be a blow against transparency. In my opinion, that would be a bad thing.

-----


In peer-review, the original authors are redacted, so the peer-review committee's bias is reduced (not eliminated, of course).

When a scientist is funded by the petrol industry, but has a long history of showing sound scientific results, I'd give him my full attention. Perhaps my reading of his results would be biased negatively if I would know his research is funded by a certain industry.

When that doctor publishes an article on his new drugs, I question where it is published, whether there have been similar results by other researchers, whether similar approaches have seen widespread application, whether the author can connect the results logically with other research, whether there has been a good peer review and whether I can understand his results. These metrics give me confidence. The funding of the researcher might interest me, but another researcher with a perfect clean sheet might get his funding in a more black-market way. They say you should follow the money, but generally it is difficult, if not impossible, to find the trail.

This means I question almost everything I read and unfortunately have little certainties. Then again "Nothing is so difficult as not deceiving oneself." -- Wittgenstein

-----


I use eclipse every day and don't have much good to say about it except that it starts up regularly and i can't about intellij on my machine.

-----


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.

-----


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.

-----


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.

-----


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.

-----


I'm not familiar enough with Clojure to comment.

-----


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.

-----


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

-----


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.

-----


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.

-----


Smalltalk?

-----


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

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: