This is beyond my wildest wishes. Meaning I have wished, as a formerly active Vim plugin author now fully switched over to Emacs/evil, exactly for Clojure compiling down to VimL so that I could maintain my plugins as Clojure/Lisp code, compiling it to actual VimL for public consumption, as a preprocessor. I'd think that would mostly do away with runtime performance worries, and not require the plugin user to actually have TimL installed as a plugin. Which means it could ease the transition of plugin authors to TimL, until eventually it's ok (and perhaps performant) to have it as a runtime.
Needless to say, I love the fact that Tim Pope has hopped on the Clojure bandwagon, that the community can enjoy well thought out tooling such as he did/does for Rails.
That said, tpope is one of only a few driving forces over on the Vim side of Clojure, whereas most seem to flock to Emacs. So I see this as potentially a great opportunity to eventually have Clojure-ish compiling/running on both Vim and Emacs, so that plugin authors can literally write and keep a single codebase that maps into the respective editor APIs. Well, least common denominator I guess, with extras specific for each editor. And maybe, speaking from my experience developing Vim plugins and looking into Elisp code, we will need 'clojureditor' packages providing higher level functionality painstakingly implemented for both editors, since it would be plenty non-trivial code that probably doesn't belong in a core like TimL neither in a Clojure+elisp equivalent.
Then you could see this actually taking off big time since the more voluminous Clojure+Emacs community would be writing a good deal of plugins which would also work on Vim for free (imagine that!), so that they could support both platforms because it wouldn't be much extra effort. Hats off to the Pope for actually taking on the arguably tougher half, since Elisp should hopefully be an easier target for a lisp like Clojure.
Really hope this doesn't sound like belabouring the point but...
tpope is one of only a few driving forces over on the Vim side of Clojure
tpope is indeed one of the few, but I'd hate for people to dismiss https://github.com/guns for his work on vim-clojure-static, vim-clojure-highlight, etc. Both have done a great job on those projects, but also with engaging with the community.
And let's not forget Meikel Brandmeyer, met him once, lovely guy. But also spent a lot of time delivering VimClojure back in the day. (I'm glad I don't have to suffer nailgun any more!)
I think there's plenty enough willing people (I'm one - I've contributed 1 or 2 line snippets here and there). But the environment is actually pretty damn nice already. No complaints.
On the performance front, I would not expect TimL compiled down to VimL to be as performant as native VimL, even when done as a preprocessor instead of at runtime. One reason is because, as stated in the README:
TimL functions are actually VimL dictionaries (objects) containing a dictionary function (method) and a reference to the enclosing scope.
So calling TimL functions have overhead that calling VimL functions don't. I don't know if there are other performance quirks too, but I would not expect this to produce the most optimal VimL code.
That said, code that exists always performs better than code that was never written in the first place, so if this causes plugins to be written that otherwise would not, then that's a net win. It's also entirely possible that the performance concerns end up not being an issue.
Personally, I've never written a VimL plugin, and I've never had a reason to use Clojure, but now I'm tempted to try both.
So, the overhead I'm referring to isn't so much stuff like function dispatch (which is almost immeasurable with the heavy lifting happening in C), but idiomatic overhead. Creating an anonymous function to map across a lazy sequence wrapping a persistent data structure doesn't have a chance in hell against a native for loop on a native vim list. I actually did quite a bit of optimization in this area (that's where chunked seqs came from), and it's quite usable for many tasks, but it's still potentially bottlenecking so I never really found myself "trusting" it for anything significant.
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.
Creating an anonymous function to map across a lazy sequence wrapping a persistent data structure doesn't have a chance in hell against a native for loop on a native vim list
... until this thing actually gets traction and one decides to integrate a native TimL interpreter into vim alongside VimL (making this implementation a shim for older versions). Of course this would create two competing standards (until vim 8?) but the more than reasonable out of the box interop and readily available usefulness and unleashed power (you mentioned macros to alleviate pain points) makes it a honestly very reasonable scenario compared to python/ruby/lua bindings, which are honestly foreign and require an external dependency.
All of this is a sign of a brilliant hack: immediately useful despite having to bear with some caveats, with a clear path towards the future. Thank you sir.
I considered talking about the idiomatic angle, but I know very little about Clojure, and not much more about VimL, so I erred on the side of not listing that.
I am curious how much optimization TimL has. I haven't had a chance to actually look at it beyond the README (and I don't know if I'd understand anything if I did). Does it leverage an existing Clojure compiler, complete with optimizations, and treat VimL as a target architecture? Or is it closer to an AST transformation with all optimizations being hand-written for TimL?
So calling TimL functions have overhead that calling VimL functions don't.
But that's easy to optimize away, I imagine. I read this as a way for forming closures and it's easy to see during compilation if the closure is necessary.
Actually, it's not a case right now, but it is reasonable to expect to have TimL generate on average better VimL than handwritten, like many C compilers do with asm. I guess "make it work" is more important right now than "make it fast", but if it becomes used, I'm sure it will improve quickly on performance front.
Comments
This is beyond my wildest wishes. Meaning I have wished, as a formerly active Vim plugin author now fully switched over to Emacs/evil, exactly for Clojure compiling down to VimL so that I could maintain my plugins as Clojure/Lisp code, compiling it to actual VimL for public consumption, as a preprocessor. I'd think that would mostly do away with runtime performance worries, and not require the plugin user to actually have TimL installed as a plugin. Which means it could ease the transition of plugin authors to TimL, until eventually it's ok (and perhaps performant) to have it as a runtime.
Needless to say, I love the fact that Tim Pope has hopped on the Clojure bandwagon, that the community can enjoy well thought out tooling such as he did/does for Rails.
That said, tpope is one of only a few driving forces over on the Vim side of Clojure, whereas most seem to flock to Emacs. So I see this as potentially a great opportunity to eventually have Clojure-ish compiling/running on both Vim and Emacs, so that plugin authors can literally write and keep a single codebase that maps into the respective editor APIs. Well, least common denominator I guess, with extras specific for each editor. And maybe, speaking from my experience developing Vim plugins and looking into Elisp code, we will need 'clojureditor' packages providing higher level functionality painstakingly implemented for both editors, since it would be plenty non-trivial code that probably doesn't belong in a core like TimL neither in a Clojure+elisp equivalent.
Then you could see this actually taking off big time since the more voluminous Clojure+Emacs community would be writing a good deal of plugins which would also work on Vim for free (imagine that!), so that they could support both platforms because it wouldn't be much extra effort. Hats off to the Pope for actually taking on the arguably tougher half, since Elisp should hopefully be an easier target for a lisp like Clojure.
Really hope this doesn't sound like belabouring the point but...
tpope is indeed one of the few, but I'd hate for people to dismiss https://github.com/guns for his work on vim-clojure-static, vim-clojure-highlight, etc. Both have done a great job on those projects, but also with engaging with the community.
And let's not forget Meikel Brandmeyer, met him once, lovely guy. But also spent a lot of time delivering VimClojure back in the day. (I'm glad I don't have to suffer nailgun any more!)
I think there's plenty enough willing people (I'm one - I've contributed 1 or 2 line snippets here and there). But the environment is actually pretty damn nice already. No complaints.
On the performance front, I would not expect TimL compiled down to VimL to be as performant as native VimL, even when done as a preprocessor instead of at runtime. One reason is because, as stated in the README:
So calling TimL functions have overhead that calling VimL functions don't. I don't know if there are other performance quirks too, but I would not expect this to produce the most optimal VimL code.
That said, code that exists always performs better than code that was never written in the first place, so if this causes plugins to be written that otherwise would not, then that's a net win. It's also entirely possible that the performance concerns end up not being an issue.
Personally, I've never written a VimL plugin, and I've never had a reason to use Clojure, but now I'm tempted to try both.
So, the overhead I'm referring to isn't so much stuff like function dispatch (which is almost immeasurable with the heavy lifting happening in C), but idiomatic overhead. Creating an anonymous function to map across a lazy sequence wrapping a persistent data structure doesn't have a chance in hell against a native for loop on a native vim list. I actually did quite a bit of optimization in this area (that's where chunked seqs came from), and it's quite usable for many tasks, but it's still potentially bottlenecking so I never really found myself "trusting" it for anything significant.
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.
... until this thing actually gets traction and one decides to integrate a native TimL interpreter into vim alongside VimL (making this implementation a shim for older versions). Of course this would create two competing standards (until vim 8?) but the more than reasonable out of the box interop and readily available usefulness and unleashed power (you mentioned macros to alleviate pain points) makes it a honestly very reasonable scenario compared to python/ruby/lua bindings, which are honestly foreign and require an external dependency.
All of this is a sign of a brilliant hack: immediately useful despite having to bear with some caveats, with a clear path towards the future. Thank you sir.
I considered talking about the idiomatic angle, but I know very little about Clojure, and not much more about VimL, so I erred on the side of not listing that.
I am curious how much optimization TimL has. I haven't had a chance to actually look at it beyond the README (and I don't know if I'd understand anything if I did). Does it leverage an existing Clojure compiler, complete with optimizations, and treat VimL as a target architecture? Or is it closer to an AST transformation with all optimizations being hand-written for TimL?
But that's easy to optimize away, I imagine. I read this as a way for forming closures and it's easy to see during compilation if the closure is necessary.
Actually, it's not a case right now, but it is reasonable to expect to have TimL generate on average better VimL than handwritten, like many C compilers do with asm. I guess "make it work" is more important right now than "make it fast", but if it becomes used, I'm sure it will improve quickly on performance front.