On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:
On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote:
> On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:
> >On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote:
> >> Robert Lee wrote:
> >> [snip]
> >> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe
> >> > using SpiderMonkey) so that people don't need to learn a new language
> >> If I understand you correctly, you assume that
> >> ECMAScript is the most popular language among
> >> the people that wish to customize VIM. How
> >> do you know the assumption is right?
> >> [snip]
> >
> >Actually, I like the proposal for two entirely different reasons:
> >
> >1) the language specification comes from an international standards body
>
> So? In what way does this make it a good language? In what way does
> this make it a good language to extend Vim with? Anyone can write a
> standard. It doesn't mean that it's good or what is being
> standardized will be, either.
Where did anyone say that standardization made it a better language than
any other? Most of what makes it a good language has been there since the
earliest JavaScript implementations. Many of the issues that have made it
difficult to work with in the past have been hammered out during
standardization or were API issues rather than language issues.
But even that isn't what standardization buys you. The main advantage is
interoperability. If someone writes some excellent library for use in some
Flash app, but is of use in some other environment that provides ECMAScript
extension, you can just copy it over and use it. I'm capable of porting an
algorithm in one language I know to another language I know, but that's a
bit more work than copy and paste.
> >2) there are lots of people working on efficient implementations, at least
> > two of which are open source (SpiderMonkey and Adobe's Tamarin, though
> > there seem to be some plans to convert SpiderMonkey to use Tamarin)
>
> SpiderMonkey is a terribly inefficient implementation, which is why
> Tamarin will be used in future versions of Gecko. And I wouldn't say
> that efficiency is the primary concern of a language/runtime engine to
> use for Vim.
I strongly disagree with that statement. Efficiency is certainly important
for an editor. I don't want to sit and twiddle my thumbs while vim starts
up or executes hooks on file read, nor do I want it to suck up a big chunk
of memory while it's going about its business. In fact, what I'm asking it
to do currently rarely takes much time, but it could be really nice to ask
it to do a lot more and still not pay a huge time or memory penalty.
Efficiency is definitely important.
> >It is looking more and more like the world of scripting languages for
> >application extension (as opposed to standalone scripting languages) is
> >converging on ECMAScript and Lua, particularly for interactive apps.
>
> I'm sure Microsoft agrees with this sentiment.
What does Microsoft have to do with anything?
> >There's a lot to be said for following a path that leads to
> >interoperability and code reuse.
>
> Yeah, follow-the-leader is everyone's favorite game. And just look at
> all the libraries for both these languages. Application extension may
> sometimes be restricted to the domain of the actual application, but
> having an abundance of libraries certainly opens up for more
> interesting possibilities.
Vim already has Perl, Python, and Ruby interpreters for application
extension, assuming you build it with the appropriate options. Any library
available for any of these languages can be made available to the Vim
runtime with minimal hassle. Are there lots of VimScript libraries that are
outside the application domain? So how does replacing VimScript with
ECMAScript prevent these interesting possibilities?
Cool down. "vimscript replacing with EcmaScript" is not on the horizon,
is not on the agenda, not going to happen.
The only alternative to vimscript that Bram once contemplated
was python, and it was decisively voted down by feature voting.
(Python was considered at one point by Bram because Python is
Bram's favourite language.)
So do not worry, replacement of vimscript by the favourite language
of some vim's random user is not going to happen.
Yakov
