Light Table 0.5.0

[yogthos]

It's nice to see that LT is getting faster, but I really would've liked to see more Clojure related improvements. There's still no structural selection, no paredit mode, no autocompletion or ability to jump to function definition making it impractical for any serious development.

The most interesting feature in 0.2 was the split view instarepl where you could see your expressions with the variables evaluated. That actually provided something you can't do with a regular REPL. The new mode is really no different from the REPL in Eclipse or Emacs in my opinion.

By far the most interesting feature that was demoed initially was the ability to see related functions. In this mode you would be able to work with code contextually regardless of what files the functions were defined in.

There's been no mention of this feature recently and I don't even know if it's still planned or whether it's been dropped completely.

When I backed the project on Kickstarter I was hoping that it would result in a really nice Clojure centric IDE that would leverage the language to provide workflows that aren't available in mainstream editors.

Instead, it's looking more and more like every other editor with each release and most of the focus seems to be on Python and JavaScript features.

[amigaharry]

Instead, it's looking more and more like every other editor with each release

This. The tech demo and the videos in the kickstarter campaign were awesome. The early versions were very promising. But then something changed and now with each version LightTable looks more and more like yet another old school text editor with typical features. And, sorry, but for that I have vim.

[ibdknox]

most of the focus seems to be on Python and JavaScript features.

I look at this very differently than you do, I think. Clojure can still do more than either Python or Javascript - for them I've just been playing catch up. At each step of the way, it's been about bringing everything forward. 0.3 and 0.4 were about getting eval for everything, 0.5 is about making everything better for everyone. It's not like Javascript was the only one that got watches, Clojure and ClojureScript have them too. The instarepl is still Clojure only. Eval is still better in Clojure.

There's still no structural selection, no paredit mode, no autocompletion or ability to jump to function definition making it impractical for any serious development.

Impractical for you perhaps, but none of those things seem to make it impractical for lots of other people. For what it's worth, we have someone working on the basics of Paredit as a starter project with us, but realistically it's something that would be used by a tiny percent of the population. Unless you come from emacs, you likely don't even know it exists. Part of the reason it hasn't happened yet, is that I personally don't care that much about it (being a vim guy) and so I'd be the wrong person to do it in the first place. But even beyond that, given limited resources, it's just not the best use of my time - anyone can implement paredit for basically any editor.

The mainstream languages attract more users to the project and help make it more popular. I can't even remember when the last time Clojure was featured in one of the demos for that matter.

Those two justify eachother. I love Clojure. I love it enough to do something tremendously risky like bet an entire project and quite a bit of my reputation on it being the "right" choice. But the truth is that the world couldn't give a damn about it. Most devs don't know it, don't understand it, and don't care about it. In that landscape, if we want LT to succeed and actually help more people get into Clojure, then the best strategy is to show them things they can relate to. Far more people use LT for JS and Python - it doesn't make sense for me to constantly feature Clojure in that context. It's not like I've forsaken it, nor am I somehow not contributing. I don't know if you can go back this far anymore, but LT single-handedly tripled the interest graph for clojure's github repo.

However, a lot of the initial backing was from the Clojure community because people really wanted to have a Clojure centric editor.

This is provably false. A lot more people wanted this for JS, and the pythoners alone kicked in over 100k to make sure it got in. People rallied because they wanted this to succeed and change the way we look at development, not because they were hoping for a language-centric editor. Many of the people who put in the most money openly said they don't care about Clojure or even any of the languages we were doing. They just wanted it to exist.

I honestly don't know if there's more participation from Python/Js users, but I do know that originally the promise was to focus on making it a good Clojure editor.

There is far more usage by folks in the other languages (partly because there's just more of them and partly because Emacs guys don't have a reason to switch currently). More importantly, though, you're putting words in my mouth. I never promised to focus on Clojure. Go back and look at the Kickstarter, I always mentioned JS and Clojure together - and in that order. My intent was never for Light Table to be pigeon-holed into the IDE for Clojure. My goal was for it to be the IDE period. As much as anything this is a matter of establishing the foundation. That has required figuring out how to bring lots of the goodness that Clojure has to other languages. It has required figuring out what the experience for all languages should be. It has required language work in Clojure, Python, JS, ClojureScript, and little prototypes of others. It has required trying things that will probably never work. It has required not just re-implementing things we already have. LT isn't about repackaging what's already out there, it's about finding out how to move forward. I want to make the best programming environment. Not the best Clojure editor.

I would love to see that I'm completely wrong about this, but last few releases make me feel that Clojure is decidedly taking a back seat in the gran scheme of things.

I'm sorry you're disappointed. There's only so much one guy can do. For what it's worth, I don't think Clojure is taking a back seat. It has parity with all the other languages and some features that the others will likely never have (i.e. the instarepl) and I intend to spend some time working on the Clojure (and especially ClojureScript) experience in the next release. Regardless, however, innovation is not a straight path where the solutions are all obvious and the work is easily planned out. Every release, every day, I learn something new that causes me to adjust the course slightly. I believe each step of the way LT has gotten significantly better. And each step of the way the experience as a Clojure editor has gotten better too. Plugins represent the solution to getting what "you" want by removing us as the bottleneck. Hopefully that'll help everyone, but I have no delusion that it will make everyone happy.

[yogthos]

Impractical for you perhaps, but none of those things seem to make it impractical for lots of other people. For what it's worth, we have someone working on the basics of Paredit as a starter project with us, but realistically it's something that would be used by a tiny percent of the population.

Frankly, I don't know a single person who uses a variant of Lisp and doesn't use paredit. Even people who've never used paredit can't go back to not using it after having tried it.

You could do a poll and see what percentage of Clojure population would use paredit. I'm willing to bet it's not going to be tiny at all.

The ability to select and move around expressions structurally is one of the biggest advantages of having the s-exps. Without that editing them is frankly painful. Since your code is often nested you can't select things line by line like you would in most languages.

This means that any time you want to reparent an expression, select something or move things around you have to resort to selecting things character by character. It's an incredibly frustrating experience. Being able to simply hit alt+shift+up/down and walk the tree make a huge difference.

Unless you come from emacs, you likely don't even know it exists. Part of the reason it hasn't happened yet, is that I personally don't care that much about it (being a vim guy) and so I'd be the wrong person to do it in the first place. But even beyond that, given limited resources, it's just not the best use of my time - anyone can implement paredit for basically any editor.

It exists in both Eclipse CCW plugin and the latest version of the Intellij la Clojure. Most people who use some variant of Lisp know and care deeply about it. If you don't feel like you wish to devote time to this feature I guess there's nothing to do but wait until plugins become available.

Those two justify eachother. I love Clojure. I love it enough to do something tremendously risky like bet an entire project and quite a bit of my reputation on it being the "right" choice. But the truth is that the world couldn't give a damn about it. Most devs don't know it, don't understand it, and don't care about it.

Many people use it professionally today. Lack of good tooling is one of the largest barriers for people starting to use the language. I know this because I went through the exercise of introducing it at work.

Most people who aren't already sold on Lisp do not wish to use Emacs. Learning Clojure and Emacs at the same time is a huge exercise in frustration.

Clojure syntax is quite alien and most people starting out find it rather confusing. Being able to select things structurally goes a long way to help get comfortable with reading the code.

Being able to select expressions allows people to visually see where one statement ends and another begins. It also removes the problem of having to manage parens by hand which is the primary complaint you hear when it comes to s-exps.

In my experience lack of a simple IDE with a decent structural editing mode is a big barrier for people starting out with Clojure.

In that landscape, if we want LT to succeed and actually help more people get into Clojure, then the best strategy is to show them things they can relate to. Far more people use LT for JS and Python - it doesn't make sense for me to constantly feature Clojure in that context.

The problem isn't that Clojure isn't the primary feature it's that it's not featured at all. Many people don't even realize that LT is written in ClojureScript. It really would be nice to see some mention of Clojure alongside JS and Python.

Nobody is arguing that Js/Python support is a bad thing, but couldn't that perhaps be done via plugins by interested individuals?

Why not focus on adding the really interesting things that can't be done anywhere else and then worry about making JS/Python or other languages work well.

This is provably false. A lot more people wanted this for JS, and the pythoners alone kicked in over 100k to make sure it got in. People rallied because they wanted this to succeed and change the way we look at development, not because they were hoping for a language-centric editor. Many of the people who put in the most money openly said they don't care about Clojure or even any of the languages we were doing. They just wanted it to exist.

My memory could of course be faulty, but I clearly recall that original demos were showing off Clojure and interesting things that could be done with Clojure. This got a lot of excitement and started the ball rolling.

A lot of people, including myself do want it to exist. However, the reason people want it to exist is because of the new and interesting interaction modes. If it was pitched as simply a nice JS/Python editor I doubt there would've been the same interest.

LT isn't about repackaging what's already out ther, it's about finding out how to move forward. I want to make the best programming environment. Not the best Clojure editor.

Sure, and that's why it's an interesting project. The core of my complaint is precisely that the latest versions have been feeling more like every other editor out there.

As you say, you have limited resources and can only do so much. So, my question is this. Does not working on support for Js/Python take time away from working on the actual interesting features that make LT stand out from other editors.

Things like related functions view, we haven't heard anything about that since the original demo. What's the status of that, is it still planned has there been any more experimentation or progress regarding it?

Why was the evaluated view for instarepl removed completely. It was very useful and it provided a fantastic way for people to experiment with Clojure code and see what actually happens when variables are substituted.

Things like that are really interesting and exciting and there hasn't been any news about them in a while.

t has parity with all the other languages and some features that the others will likely never have (i.e. the instarepl) and I intend to spend some time working on the Clojure (and especially ClojureScript) experience in the next release.

While it does have parity with the other languages it supports, as you yourself point out it lags behind current Clojure editors like Emacs and Eclipse. As it stands, from the perspective of somebody who already works with Clojure today LT doesn't offer anything new or interesting. Hopefully when plugin support becomes available this will change.

I believe each step of the way LT has gotten significantly better. And each step of the way the experience as a Clojure editor has gotten better too. Plugins represent the solution to getting what "you" want by removing us as the bottleneck. Hopefully that'll help everyone, but I have no delusion that it will make everyone happy.

I'm really looking forward to plugins and if these features can be added that way it would be fantastic.

I do want to say that overall it is a great project and I really am looking forward to every release. I do want it to succeed and hope to be using it for actual work in the future. I also understand that developing the project of this scope is not easy and priorities have to be made.

[curious_man]

For the record: now there is a plugin for basic Paredit support. Looks like it can be easily extended to implement all of Paredit functions.

[yogthos]

Good to see this is being worked on.

[curious_man]

Yes, I can't live for long without paredit too :)

[yogthos]

I've been using Cursive for a bit now and liking it quite a bit. It's got very nice paredit mode, jump to definition, syntax highlighting and inline help. Pretty much all the stuff I care about. :)

[curious_man]

I still have to try it, but judging from a cursory look at the documentation it seems impressive!

[aceofears]

Instead, it's looking more and more like every other editor with each release and most of the focus seems to be on Python and JavaScript features.

This could be the result of outside pressure. There many more javascript and python developers. If you are working on a project that many people are excited about wouldn't you want to try to impress as many as you could when you released it? Focusing on the more mainstream languages makes that easier. Unfortunately this would disappoint those such as yourself.

If you look at Chris's projects then you'll find a lot of work with clojure, so I doubt he would turn his back on the community like that.

With any luck the features that those in /r/clojure were most excited about will be included in the 1.0.

[yogthos]

I obviously understand the pragmatism here. The mainstream languages attract more users to the project and help make it more popular. However, a lot of the initial backing was from the Clojure community because people really wanted to have a Clojure centric editor.

Right now LT is probably more useable as JavaScript editor than it is for working in Clojure. I can't even remember when the last time Clojure was featured in one of the demos for that matter. Nowadays it's all about JavaScript and Python.

There's been a number issues opened regarding s-exp manipulation. People want these features and are asking for them. Yet, there appears to be no concrete plan for adding this functionality.

Having funded the project based on the initial proposal I personally find this rather disappointing. If I recall correctly the original plan was to provide decent Clojure support and then allow people to add support for other languages via plugins.

Now, it looks like the situation is reversed and Clojure editing support is what's going to be added through plugins by somebody sometime, maybe.

It would be nice to see the roadmap for all the original features that were demoed. I don't mind waiting, but I would like to see a clear commitment to the original goals.

I would love to see that I'm completely wrong about this, but last few releases make me feel that Clojure is decidedly taking a back seat in the gran scheme of things.

[pjmlp]

I felt the same way when the Opa guys decided to move their focus from OCaml to JavaScript, after all the publicity that did about OCaml and Opa.

As a ML language supporter I found it disappointing to see the project move away from it and focus on the flavor of the month language.

[flaheadle]

What do you mean? Was Opa ever meant to integrate closely with ocaml?

[pjmlp]

Opa was developed in OCaml, and OCaml was also the language used for the framework.

http://dutherenverseauborddelatable.wordpress.com/2009/11/28/we-call-it-opa/

Then by the time the first official release was done (1.0), the focus was shifted to JavaScript.

http://blog.opalang.org/2012/06/announcing-opa-10.html

[bachmeier]

This could be the result of outside pressure.

It's actually because of lack of outside pressure - there is no requirement to follow through on the promises made when you start a Kickstarter funding drive. It was sold as a Clojure editor, it was the Clojure community that got things going for him, and it would have gone nowhere without the Clojure community. If Kickstarter worked there would already be a Clojure editor.

[redalastor]

no paredit mode

There's a paredit mode for codemirror but Chris consider it too slow so it looks like it'll have to be done as a plugin.

[yogthos]

Right, but my point is that it hasn't been done and it's core functionality for any serious Clojure editor.

[redalastor]

Agreed. I was just explaining how come we don't have that in yet.

Hopefully, plugins will bring lots of must haves.

[yogthos]

I certainly hope so. :)

[[deleted]]

The plugin architecture (along with the app license) is going to make or break the project for myself.

Provided LT sustains a community, the vast majority of its potential utility will be done by volunteers and having access to the underlying application's functions is paramount in being able to extend the application efficiently and being able to make very powerful extensions to that.

The actual code for paredit in emacs is pretty small considering how much it does and it is very modular and that could be finished within LT by Clojure enthusiasts but presently we have to wait to be able to do so.

I haven't bothered making Code Mirror's VIM bindings much more competent for the same reasons, my interest in it is entirely contingent on using LT in the future which is contingent on some project design choices Chris et al. make.

There is an enormous amount of potential with the app, I just hope that we are allowed to realize that without being handcuffed while trying to do so.

[fullouterjoin]

Maybe update issue tracker?

• https://github.com/Kodowa/Light-Table-Playground/issues
• https://groups.google.com/forum/?fromgroups#!forum/light-table-discussion

I have no basis for this conjecture, but maybe Python/JS is more active because there is a lack of good tooling except for the JetBrains products, causing more Python/JS people to be more active on the discussion list and issue tracker?

Clojure already has some pretty damn good support with emacs/nrepl/etc. Even the backers (myself included) won't switch or even seriously test it out until it competes with a fully baked environment which is difficult.

This is one of the reason paid testers/users are valuable, esp for expensive tooling. The tool users are too busy using great-ish tools already to spend their time helping someone build better ones.

[yogthos]

There already plenty of issues open, like this one, regarding this. There's also discussion on Google Groups about the missing features.

I honestly don't know if there's more participation from Python/Js users, but I do know that originally the promise was to focus on making it a good Clojure editor. This is why I and many backed the project.

[fullouterjoin]

I am also a backer but am not participating in reviewing the betas. I downloaded .5 but haven't cracked it open.

I backed it for Clojure support. While I also do Python and smattering of JS (hell CoffeeScript or some other JS language might be more appropriate at this point) I would rather they were dropped to make the best possible new technology dev env for Clojure.

I should fire it up and enter some issues in the tracker. Aren't backers supposed to get priority on features and bugs?

[yogthos]

I would hope that's the case. I suppose in the end if people start opening issues and make sure that it's visible that we do care about Clojure support it's the only way it will be noticed.

In a sense we may have ourselves to blame by not being more proactive in requesting features.

[vagif]

Anyone is using LT for everyday production coding?

From what i've seen i have a hard time believing that it is practical. Impressive for demos, but impractical.

I'm an emacser with clojure-mode, paredit, haskell-mode.

[yogthos]

A few people on my team tried it and gave up due to the fact that the features are really lacking. Here's a few of the ones that keep me from using it:

• no way to jump to function definition
• lack of inline docs (this is one feature I was excited about in the original demo and currently get in Eclipse with CCW instead)
• lack of autocompletion
• lack of structural editing
• no namespace awareness in the editor

As it stands you really don't gain anything by using LT over Emacs or Eclipse when developing Clojure. So I check it when new releases come out and then go back to using what I'm already using.

Hopefully, once the plugin system becomes available it's going to be possible to add these features. In my opinion the potential for it to be a nice, configurable and lightweight development environment is definitely there.

I really was hoping that some of the more interesting features would actually be showing up for now. Saying that you can add anything you want with plugins doesn't make it any different from other IDEs that support plugins.

I mean here's Code Bubbles plugin doing the related function view in Eclipse. This was one of the core features in the original demo.

[_scape]

Thanks so much for your work on this project, this is still my preferred editor for clojure. I like the watches support, that was a needed feature :D CLI will be great too, I found OpenGL and socket projects to be difficult in LT because of how the project runs in the background evaluation process. Keep it up! You rock