

TimL – Clojure like language which compiles down to VimL - daGrevis
https://github.com/tpope/timl

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

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

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

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

------
skue
> Is this a joke? > > If you mean the 6,000 lines of working code, then no, I
> poured hundreds upon hundreds of very serious hours into that. But if you're
> referring to the fact it's woefully underdocumented, adds considerable
> overhead to an already slow host platform, and ultimately unlikely to gain
> any traction, then yeah, probably.

This is the best sort of April 1 announcement - something ridiculously ironic
and playful, yet incredibly useful long term. Thanks so much for creating
this, along with all of your plugins.

------
mikegerwitz
In the never-ending Emacs vs. Vim debate, as a long-time Vim user (with no
intent on switching), I've always envied Elisp. tpope has once again delivered
and maybe now I can stop shamefully eyeing up Emacs from a distance.

I haven't given this a try yet, but I can expect that, if it works well, it
will be worth even a modest performance hit.

~~~
pekk
Rather than transpiling into VimL it might be more productive in the long term
to hack on Vim's MzScheme scripting interface...

~~~
Tyr42
Oh man, that would be pretty cool. I would like it more if we could pull it up
to Racket, since I've use that and it feels really good as a language. It's
what was mzscheme.

------
pi-rat
A lisp for vim - with months of commit history.. released on 1st of April..
awesome!

~~~
typicalbender
I'm still not convinced its not an elaborate april fools joke but I want it to
be real so bad!

~~~
nine_k
I wonder if someone has a VimL port to elisp in the works, waiting to be
released today.

------
rabino
Maybe the april fools' joke is that this is not a joke

~~~
krick
Then I wish everybody's april fools' jokes would be like that.

------
krick
It's so cool that I would be skeptic (real programming language that compiles
into VimL? God, that must be buggy!) already if not the fact that it's written
by tpope. That's totally awesome.

------
aktau
Even though I like clojure and think it's cool, I don't think VimL needs
another layer that slows it down. I'm putting my money on the VimL to Lua
translator that's currently being worked on by ZyX-l
([https://github.com/ZyX-I/neovim/tree/luaviml](https://github.com/ZyX-I/neovim/tree/luaviml))
for neovim. With that, we can run VimL as Lua code in LuaJIT, which will
transform VimL from one of the slowest scripting languages to among the
fastest.

Note that I said among the fastest, because VimL uses native integers which
Lua doesn't have. LuaJIT does have them but their conversion rules are
different so there has to be some shim code
([https://github.com/neovim/neovim/issues/392](https://github.com/neovim/neovim/issues/392)).
There's also many other VimL -> Lua incompatibilities that will incur some
slowdown but it should be wicked fast still.

Of course, I expect that many people will start writing native lua plugins
after a while, it is a far more pleasant language, after all.

------
seth1010
Oh, this is neat. (keeps reading...) HOLY SHIT TIM POPE

------
Morgawr
At first I started reading and I was skeptical, there are so many
abandoned/unused lisp dialects out there nowadays.. Then I checked the size of
the project and at the first mention of actual clojure datatypes I was
pleasantly surprised.

Kudos tpope, this is freaking awesome!

------
daGrevis
Here's an example of TimL in action!
[https://github.com/sjl/tslime2.vim/blob/master/plugin/tslime...](https://github.com/sjl/tslime2.vim/blob/master/plugin/tslime.tim)

~~~
cursork
Literally came here to post that!

The comment for send-line-to-tmux... I've felt that pain before.

------
SmileyKeith
As someone who develops some plugins this looks freaking awesome. Think I'm
past thinking this is a April fools joke, knowing his sense of humor, the
number of lines of code and the commit history.

------
jzelinskie
This could be totally awesome. Maybe with neovim's planned LuaJIT
implementation of VimL this can actually run quick.

~~~
nilved
You could just code it in Clojure if you were using neovim.

------
kul_
Can this be used to develop plugins for vim? I would love to see someone come
up with a plugin in TimL or port one to it!

~~~
amdt
Steve Losh has rewritten his 'tslime' port in TimL:
[https://github.com/sjl/tslime2.vim/](https://github.com/sjl/tslime2.vim/)

~~~
kul_
awesome!

------
tomphoolery
UGH! SO MONEY!!! <3 <3 <3

