I'm also really excited about the behaviors stuff. It means that the entirety of LT's functionality is described in a datastructure that you could reasonably modify by hand. Here's a gist of default.behaviors: https://gist.github.com/ibdknox/6010853 The :+ is there because it's stored as a diff, which allows other behaviors files to add and remove functionality based on the order they're loaded.
> It means that the entirety of LT's functionality is described in a datastructure that you could reasonably modify by hand.
I'm confused. Emacs embraced this principle almost forty years ago. Would you mind explaining to me what's novel about LightTable's take on this old idea?
Is it "That, But Clojure!"? or "That, But With More Webkit!"? Each of these could be valuable in their own right... Or am I missing something more fundamental?
How about, "Turtles all the way down just like Emacs?"
I think you don't really have to come up with something revolutionary on top of the Emacs philosophy for it to be a very worthwhile pursuit. The things you mention plus the fact that it's as easy to get started as Sublime (or aims to) makes it a fantastic entry point for lots of new people into a tried, true and powerful way of working.
>I'm confused. Emacs embraced this principle almost forty years ago. Would you mind explaining to me what's novel about LightTable's take on this old idea?
That it's based on technologies, design sensibilities and UI ideas that weren't around "almost forty years ago".
I really love the philosophy of LightTable and will make a serious attempt with 0.5 to make it part of my standard dev workflow, but I keep wishing it had a single-stepping debugger built in, especially for clojure code. Am I doing something wrong that I keep depending on such an old-timey feature?
Again, thanks for the great work and sorry for talking about even more functionality (the existing LightTable is just so cool that I'd love to have it be even more awesome by including my favorite features :-)
I'm not sure I'll do it, but that's my answer for almost everything at this point. Ultimately this is why I'm taking the strategy I am - plugins will be able to do anything I can do quickly and efficiently. Integrating a step-wise debugger won't be a completely trivial amount of work, but I'd be surprised if it took more than a few days and it's something anyone should be able to do :)
After 0.5, my goal is to remove us as a bottleneck as quickly as possible and then who knows what'll happen :D
Nice you are probebly reading this, I'll ask here. I have started to use LT for some clojure/clojure script development and real like it. As much as you can like something that new, but I really belive it will replace everything, not just for development but also for 'normal' stuff.
There is one simple change that I would really like to see. In the Instarepl and the normal result that are shown 'in line', the result is just printed and not pretty printed, witch makes it almost useless in case of a complex datastructure. Is there any reason for that? Can I change that?
Im developing something that looks like a boardgame, and seeing the result of a function with a board in it is almost useless, I still have to pprint it to see whats going on.
It's something I was going to work on for 0.5. I do a fair number of things to make lazy seqs not blow everything up and pprinting will force lazy seqs to be realized causing all sorts of nastiness. There may be some decent middle ground in there somewhere though.
Ah, I see how this could be a problem. Maybe show it the like now, and then if you click on it one could pprint it. Does print-length work with pprint?
Fipp is awesome and I'd love to use it, but there doesn't appear to be a clojurescript implementation of finger trees and last I knew he hadn't solved the print-length/depth problem either.
Initially it will likely be easier to write plugins in ClojureScript, but there's nothing preventing JS ones from being written. Before the plugin stuff goes completely public, I'll probably write a little JS shim layer that makes it a bit more natural.
It's easy to spark interest in other developers by converting their Ruby/Python code to Clojure.
But LightTable has made it possible for me to recommend an editor that has integrated repl feedback and lets them hit the ground running with Clojure when they ask me how they should get started.
Since Lisps are so tool/workflow-dependent, it's just way too easy for a newcomer to dismiss it all after a bad experience because they simply didn't know about electric parens or they never discovered the tight repl feedback loop that makes us so productive. And it makes it frustrating for those of us as well that are trying to convince others to give Lisps a shot since we can't stand over their shoulders.
Sometime I'd like to make a well-planned gif (like that on the homepage of http://www.sublimetext.com/) that gives newcomers a glimpse of a solid workflow to strive for.
If someone were to implement an insta-repl as an IntelliJ plugin, or an emacs plugin, what remaining advantages would LT have? Is there something about the architecture of existing IDEs that is incompatible with an insta-repl?
Say I'm writing a medium size webapp, like, say, Gmail, in clojure + clojurescript. I don't understand how integrating my app into LT is going to 10x my productivity, outside of instarepl. Or being able to on-the-fly extend my IDE. Emacs can do that, and its not exactly a feature i can't live without.
It just seems like all the things you're talking about on the list, like [commands, settings, threading models, plugins, UX] are previously solved problems.
LightTable's trajectory is a bit different than what you're going to get with a monolthic IDE and the Clojure plugin that does its best to wrestle with the IDE.
I also don't think LightTable's core offering is a huge boost in raw productivity unless your workflow right now is notepad.exe and manual repl reloads. - Just to point out two features from the post: "watchers" (live runtime feedback) and one big extensible datastructure.
I actually disabled paredit when I was using vim and have done so again while using emacs+evil. The way I write code i typically simply do opening parens and at the end just jam parens until the rainbow-delimiters start to show up unbalanced (red in my case). If I need to pay attention because I'm not at the end of a top level form, I quickly glance to see which matched parens are flashing as I add each delimiter.
Honest advice: The power of paredit lies not in managing the closing parens. I found that the benefits of paredit show only when you use barf/slurp/split/join. Keep the paredit cheat-sheet around (http://www.emacswiki.org/emacs/PareditCheatsheet) for quick reference, and if you're anything like me and don't like the emacs-meta-ctrl-style key-combos, customize the keys, I've found the defaults to be quite lacking for vim/evil users.
Using paredit only for parens-matching feels to me like using only hjkl in vim. While you can use vim this way, you won't fully reap the benefits until you start to use the other movement commands.
Could you do a little write-up on your paredit workflow. Like the post you replied to I've found it mostly annoying to use in normal Emacs and nowadays with evil-mode.
I'll be honest with you: I'm maybe not the one to give proper advice on paredit. I'm using C# on my day job, and as such have no use for paredit (I do use ViEmu for VS though, which makes VS bearable) for most of my programming tasks.
Also, I've never done anything in clojure. I expect it to be a similar experience to CL, but the different types of parenthesis might have an effect on using paredit efficiently.
That said, I found that the following mapping really makes a huge difference when working with sexps & evil-mode:
Your mileage may vary, of course. I mapped it this way because my fingers dictated it, and it plays well with vim/evil.
As to how to actually use these commands: Try them out on a few sexps, it'll be clear to you pretty soon. Also be sure to check out Emacs Rocks! ep14 (https://www.youtube.com/watch?v=D6h5dFyyUX0), it's well worth the 3:40.
I actually find learning paredit to be very similar to learning vim: You start with almost nothing (maybe hjkl in vim, but even that takes a while to get used to), and slowly add new tricks to your tool belt. Also like with vim, everyone has their own style of using the tools.
Of course, there's a ton of other things in paredit which can improve your efficiency which I haven't added to my muscle-memory yet. It's just that I found barfing/slurping to be the most bang for the buck, so I added them first.
Great to see things are coming along with LightTable. I was a bit surprised by this:
> Lots of things that were blocking the UI no longer are thanks to some magical hackery (given the lack of threads in JS)
I thought WebWorkers where designed to alleviate these kinds of issues. It seems like Webkit supports WebWorkers so I'm surprised they weren't used - anyone know the rationale?
I can't do any kind of IO in a webworker, which means things like indexing the filesystem are impossible there. The vast majority of cases where I need to do background work I also need access to the host.
EDIT: I should note that I did start with webworkers for things like auto-complete, but what I'm doing now (spinning up another instance of node) is a lot more powerful and robust. As scary and sad as that may be.
because I wanted to use html/css as the UI toolkit and utilizing JS gives me a bunch of stuff for "free." I looked into using javafx and various other java-y things that embed webkit but they are painfully slow, to the point where it wasn't practical to even try using them.
That makes sense - if I was building any kind of UI these days it'd take a very strong argument to convince me not to build it with HTML/CSS. Working around some JS issues seems like a relatively small price to pay.
Would you be able to quickly explain LT's architecture from a mile above? node-webkit for an HTML based UI. How does clojure come into it? Or is clojurescript the workhorse?
It's all ClojureScript all the time :) Clojure is only used for evaling Clojure and doing languagy things. Not much has changed since the above post except that behaviors are now added to tags outside of code in .behaviors files.
I tried the alternatives and they were fundamentally unworkable. The cost here wasn't that great, mostly it was a matter of figuring out the least bad solution to the problem. Compared to the issues I ran into with java-based integrations, this really was of negligible cost.
Kinda tangential, but mentioning threads brought it up. I have core.async on the brain, so I was just wondering if you've looked at it or plan on using it for anything. David Nolen had a cool example using it for event handling.
There are places where it'd be useful, no doubt about that. Mainly it will be really useful in the cases where you want to ask a client something "synchronously". For example it'll make doing things like asking a language client where function boundaries are much nicer than the way I was going to have to do it before (waiting for events to be triggered async-style).
I use LT productively at the moment and really enjoy it, so thanks ibdknox!
I did see on one of the mailing lists that you had spiked up an integration with JSHint, and that might make it into LT 0.5. Is that still the case, or have you deferred that for implementing the plugin framework? I ask because I'd like to push it at work, but many of our developers rely on JSHint/SublimeLinter, and it's much nicer having that integrated into our editors.
This looks great! I'm really trying to use it more, though last time it did feel heavier than sublime. I'm glad that was addressed. Can anyone point me to a good tutorial/example regarding clojure and clojurescript projects in lighttable for windows and mac?
First of all, I use LightTable for all Clojure development at work (we use it for our tools) and I love it. One thing though, is there any chance of seeing goto-symbol like functionality in LightTable (thinking about goto-symbol in Sublime 3, super useful!)
I'm also really excited about the behaviors stuff. It means that the entirety of LT's functionality is described in a datastructure that you could reasonably modify by hand. Here's a gist of default.behaviors: https://gist.github.com/ibdknox/6010853 The :+ is there because it's stored as a diff, which allows other behaviors files to add and remove functionality based on the order they're loaded.