Hacker News Reader

I would say eclipse already does what light table aims to do.

Can you come to a realization in the middle of an Eclipse debugging session, get a great idea for making yourself more productive, take time to script yourself a working and fully debugged extension of Eclipse and continue what you were doing 20 minutes later?

I've done precisely this in Smalltalk on many occasions. You can script something like a custom browser that shows you everything that uses function A and also function B and has a reference to class C (and with complete syntactic accuracy) in around that time.

I suspect that this kind of very small grained toolsmithing is common for really good programmers in dynamic environments. The only problem is that it's been harder than necessary to integrate that with the most commonly used coding tool. (TextMate's ability to export selections to scripts is very nice, but it can go farther than that. Emacs is very powerful for this, but not everyone wants to script in elisp.)

It's not that Light Table is going to do something unprecedented. It's more like what git did with quick access to diffs: a quantitative change can become a qualitative change. Change the cost-benefit of toolsmithing, and you can use it in new ways.

Acme supports constantly improving how you work in little ways, better than tools with plugins or extension languages, by not having many features, and providing a good interface to route text through shell pipelines.

For a simple example, Acme has no paragraph justifier, but it doesn't need one, since fmt exists. To use it, highlight a paragraph of text with the left mouse button, highlight a typed-in |fmt command with the middle mouse button, and release the middle mouse button to run the paragraph through |fmt and replace it in place.

With this I can leverage anything I can call from the command line, in any language, to be part of my editor. No need to rewrite tools in the program's specific extension language, whether Elisp or Smalltalk or Clojure.

As another example, since it's so easy to just run a shell command from Acme (highlight the command text and middle-click it), I'm constantly customizing pre-written shell commands to e.g. grep for lines in code (to the point of creating indexes on the fly for files), and then right-clicking on grep -n output to jump to a specific line in a file.

You still need to use the mouse. One of the biggest benefits of Vi(m)/Emacs over everything else out there is that you don't need to use mouse for anything. For example, to justify a paragraph in Emacs I highlight it (several quick ways to do it with keyboard) and press C-u M-q. And you can do the general "replace text by running a shell command over it" by highlighting the text, and doing C-u M-| [shell-command-here].

The feature you're describing is awesome and useful, but I wouldn't be happy to have to use mouse for it. Is there a way to invoke it from keyboard in Acme?

Couldn't you build a LightTable-like IDE in Squeak right now?

Squeak is somewhat LightTable-like already, except everything needs to be refreshed manually. (And not all of it is obvious to the beginner, though all of it is readily available if you know how.)

You actually couldn't have everything update automatically and expect bad things never to happen. Functional programming has an advantage here.

Is Light Table written in Haskell-like language? Because other functional language still allow side effect and IO and running everything in those language can still cause bad things.

Well, you can have bad things happen even more easily in Smalltalk, but enough of the library is well behaved that it's workable in development, especially since you can save the image periodically and you have a transactional log for even what you do after your last save.

To make Light Table work, you don't need 100% perfect semantics. You just need 99% good semantics, plus some way of turning off automatic refresh and refreshing manually.

An Eclipse plugin usually takes me about half a day at this point. It's not good for short scripts, but these examples don't seem to be that either.

For the "20 minutes later" version, I typically abuse JUnit tests, or use search+working sets.

What Eclipse misses more than anything else is performance and generalization. It's sufficient for my Java work: it is insufficient for my four-language code base.

These were examples of extensions to make a point and not at all what we'll be focusing on. What we're making sure of is that the platform for such things exists and enables all of the things that old UI's and such don't allow.

I think the parallel to emacs is a good one and while I certainly won't say at this point that we'll be the "modern emacs", it's our hope we can come close.

out of curiosity, is js going to be your "elisp"?

Clojurescript, actually -- a Clojure dialect that compiles to JS.

Well, Clojure too, on the server side of things.

Are we really gonna need the JVM running the backend for this? That seems so unnecessary.

you could probably just precompile your extension

afaict, precompiled java still requires the jvm.

Given the initial goal was for a Clojure editor (which runs on the JVM), running the JVM was a prerequisite anyway.

I'm pretty sure the core of it is to be written in Clojure, so yes, you'll need the JVM running. It is necessary if it is to be written in a JVM language. Eclipse and a number of other IDEs also require a JVM to be running.

I think from the discussions and other threads what I infer is that we need a total re-look at the concept of an editor, Your way actually looks good. Except that we need to retain the 'Emacs infrastructure'.

We need to really keep Lisp as the extension language.

I think what we need is Light Table with something like this : http://www.kickstarter.com/projects/568774734/emacsy-an-embe...

You have to develop Light Table ON the Emacs OS!

Lisp is the extension language :) Everything so far is Clojure + ClojureScript with the language backends written in the language they support (python in python and so on)

How about Stallman's idea for GUILE (Scheme) uber-alles. Do source-to-source translation of approximations of the supported languages to Clojure. This would allow everyone access to almost everything in the tool.

That effort hasn't even materialised for Scheme+Elisp for Emacs.

The whole approach is guaranteed to not produce a perfectly compliant of any other language.

Yes, that is the price. That's the price for native access to the entire codebase of the underlying editor.

So long as it's close enough, you don't need perfect compliance.

I disagree. If the support isn't perfect, you might as well not bother and help people learn your native language.

I think the popularity of CoffeeScript is a datapoint against your idea. I bet a lot of pythonistas use it because it's less of a shift than Javascript. Also, in such a system, if people are curious enough, they will learn the native implementation language as a result of the system being so constructed.

I'm not sure it's a datapoint against; most people I talk to use it because it fixes objective flaws in JavaScript.

It might have been better to demonstrate this with examples like:

  truth-tables for (nested) if statements
  petri-nets for a state machine
  etc. etc. etc.

What I worry about Light Table is what it won't be from Emacs. At the end of the day, Emacs is still a text editor, and still edits files. This means that I really can use it for anything, doesn't matter if I have a mode for it, or an embedded compiler/REPL. It still just works, and we can't forget this if we want a modern Emacs.

Emacs was born in a world of textfiles, Light Table shows us a post-textfile world, but before we can get to the future, it needs to be able to survive in the world we live in today, which is one where textfiles are king.

From the bottom of the post:

"If you couple [DSTs] with the generalized editing capabilities I showed last time, you have what we believe to be the future of tools: an environment that you are able to mold to the exact shape of your problem."

I agree, we have no intention of removing general editing - you need it as much as anything else at this point.

I'm more deeply concerned about the fact that Emacs is something which, roughly speaking, I can control. Emacs is a community project. Your project appears to be commercial in nature, regardless of whether or not it's open source. Your project will also be a dictatorship by dint of the fact that it belongs to you.

Why should I trust you to provide the most fundamental tool in my work?

It will probably be under the GPL just like Emacs, so I'm not sure I understand the concern?

I think the fear is in the "probably". YCombinator, for instance, doesn't have a good record of doing things just for the community good, they are after all profit seeking.

That's not to say it won't happen, but the fear is there.

I'm fine with profit-seeking, but GNU projects like Emacs tend to be too fundamental to allow a proprietary solution to predominate. (Cf. gcc)

I'm fine paying for servers, for contractors, services, random productivity-ware like Pivotal Tracker etc. but I'm never going to be okay with subjecting my development environment, something I've honed for years and years, to fee extraction or proprietary control by a commercial entity.

He doesn't have to cater to you or me and I think it would be a mistake to do so. Visual Studio is very popular... When Light Table comes out, at the end of the day I'll still be using vim and I suspect most emacs users will still be using emacs. We're not the target audience. I disagree that Light Table needs to be anything like emacs to dominate, it can even have a proprietary license, it can skip over us just as Eclipse, VS, et al. have done. That's fine. I'd rather that be the case and see a pretty end-product that serves its original goals well (and I may even try it for fun if it's free) than having a half-baked "vim-mode" stuck on at the end just to try and attract me.

Visual Studio is a unique case in that it had the giant of Microsoft and their windows platform behind it, and IIRC, at the time no opensource free alternatives. I'm not sure in a modern world, Light Table advantages would afford it the same spread.

>He doesn't have to cater to you or me

You're right.

>I think it would be a mistake to do so.

Maybe.

>Visual Studio is very popular... When Light Table comes out

Does not follow. Visual Studio users will NOT be using Light Table even if they're aware of its existence (and they won't be, save for the few poor bastards working in Microsoft-land and reading HN).

Light Table, in terms of addressable market, is really only talking to grumpy hackers like me and startup people. Maybe particularly keen hobbyists who are good at following the state of the art.

> We're not the target audience.

Then why is his open source community (Clojure) and people he's reached mostly involve exactly our target audience?

>I'd rather that be the case and see a pretty end-product that serves its original goals well (and I may even try it for fun if it's free) than having a half-baked "vim-mode" stuck on at the end just to try and attract me.

That is...not what I was talking about. Did you even read what I said?

I was talking about freedom, not bolting it onto an existing editor. The point is that I don't want to Monsanto-ify my tools and be dependent on an unaccountable commercial entity for how I work.

What kind of business strategies would be compatible with that?

Also emacs provides an extensive platform with tons of modes to support pretty much anything you can throw at it, works in a terminal if needed, has an abstraction over files (buffers), debuggers, easy modes for vi/cua users, can connect to browser instance if needed and tons more.

Building a lighttable mode or even several small modes (libraries vs framework) for emacs would make more sense.

It is going to require a huge effort to duplicate a fraction of what it provides already.

But from a marketing point of view it is/was probably smarter to show eye candy to attract funding, but I am not sure it is the best route in the long run.

The advantage of LightTable's approach is that using HTML, is a simple, trivially extensible and powerful way to provide advanced UI widgeting, something modern emacs supports very poorly. Mostly due to working in a terminal if needed, but I think it holds it back a bit. The closest thing we have in emacs is pixmap support, which is poor, and painful to use!

Though, is LightTable the best/easiest way to get that? I don't know, it may be easier to render emacs buffers into a webkit view, it may also not be.

> Though, is LightTable the best/easiest way to get that? I don't know, it may be easier to render emacs buffers into a webkit view, it may also not be.

That is what I meant with "connect to browser instances" (swank-js already allows that, among others). Basically when you need more advanced rendering, or browser environment when it is your target (browser based games and whatnot), this could be good enough and you can leverage a huge ecosystem for all the rest.

Sure, it could be good enough, but the ecosystem has not been building up around that. Perhaps it's the seperate languages used, or the clunkiness of having to use another browser and all the setup just to render a simple graph. But I personally have not found an extension that takes advantage of that.

It's the versatility of emacs that keeps me coming back. I need to use R for this project? Python? C? Well, at least I can use it through the comforting interface of emacs.

> minus Eclipse programming in Java would be a very frustrating experience

I'm not sure about that... Eclipse gets fatter and slower with each release. Of course, I still use it because Google really wants Android developers to do so. In my opinion, the most frustrating thing about using Eclipse for Android work is that it crashes every time I try to export a package, unless I close every open file and restart Eclipse before trying. (the problem is mitigated by disabling automatic builds)

I guess that's because Eclipse runs on Java and Java is wasteful. It would be really nice if we could have a "native" equivalent of Eclipse, with less bloat.

I face similar issues at work but I don't think Eclipse's issue is Java, else you're saying that anything developed in Java will face a "boated" fate. Eclipse's problem is exactly what Chris mentioned in the article, ok on most things and awesome at none.

Edit: Typos.

Indeed, it's not all Java's fault. But I think Java does contribute to the overhead because my experience with Java programs in general usually involves long startup time and excessive memory usage.

(And then there's the UI bloat, which makes Eclipse look like this by default: < http://www.flickr.com/photos/geofharries/5145925147/sizes/o/... >. But that's a totally different issue. Thank goodness for Fast View.)

I see your point there. I myself tolerate Eclipse on Ubuntu, where the UI surprisingly fits, at least for me. Its almost indistinguishable from other UIs, except maybe Spotify which is (IMO) way ahead of the rest. But I cant stand Eclipse on my Mac OS X and there you can see all the stuff you mentioned.

At it's core, Eclipse is really good at Java. It's why it killed off Visual Cafe and most other commercial IDEs (was sad to see Borland go).

The issue is that it's more than just a Java language editor. Once you load it up with all the extras to accommodate development models, frameworks, runtimes, build processes, etc. it does become an unwieldy mess. But it's really hard not to considering how moving parts large-scale development has.

I think Light Tables target is dynamic languages, which the current crop of IDEs dont have great support for.

If we assume dynamic languages are the future, then scripting is absolutely the right answer.

However, what I see is people using dynamic languages because they are what frameworks are written in, not because they want to use a dynamic language. I hope that LightTable incorporates a packaging mechanism such that we can have a Ruby on Rails package, for example, and the 60% of RoR developers who never tweak anything can be more productive.

The problem is that you can give an excellent developer an unspecified tool and they will make it serve their purpose. We need the ability to pass those productivity improvements down the food chain, which is where Emacs fails utterly.

> But its really wrong to say IDE's like Eclipse don't do one specific task well. Eclipse really makes Java programming very easy.

“Making Java programming easy” is not one specific task!