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?
Grandparent was correct. Vim's basic completion is "similar words in the current file" (plus some other things), but omnicomplete is an arbitrary algorithm that can get pretty fancy. For example, in Ruby, omnicomplete on 3.14.tr will include truncate, while omnicomplete on [[1, 2]].tr will include transpose.
I doubt it. Spam bots are at the other end of the spectrum, with large numbers of short lived, seldom noticed accounts. This has to be about the Justin Biebers and Charlie Sheens.
There's lots of ways YouTube could marginalize H.264 without turning it into a full fledged game of chicken. They could make HD content exclusively WebM but still serve H.264 SD. They could prioritize WebM encoding so that there would be a delay before H.264 content was available (imagine getting told "this video is not yet available on your device" once every 6 months or so). They could make the most popular stuff in both formats but only offer WebM for stuff at the end of the long tail. They could offer a more favorable cut of ad revenue to content providers who opt out of H.264 (ostensibly because it saved on licensing fees).
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.