Re: replace VimScript

[A.J.Mechelynck]

Robert Lee wrote:
Nikolai Weibull wrote:
On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote:
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.

What plugins/functionality are we missing that require better efficiency?

Efficiency is definitely important.

VimScript is probably in the order of 10^6 times slower (if not more)
than C, and yet we have loads and loads of usable plugins.

And what about the size of, for example, Tamarin.  It's quite a big
piece of software.  That would certainly incur a memory penalty.

> >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?

Microsoft has, though hardly to any real degree of success, always
pushed for VBA.  Sure it has JScript as well and many languages could
be used for application automation of windows applications.

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

Wasn't that sort of my argument?

Are there lots of VimScript libraries that are
outside the application domain? So how does replacing VimScript with
ECMAScript prevent these interesting possibilities?

I don't see why you have to replace VimScript with ECMAScript to get
ECMAScripts do what can be done with the, for example, Ruby bindings.

As for following the leader, you are on shaky ground.

No, but the following argument certainly is:

Vim followed in the
footsteps of vi just as Linux followed in the footsteps of Unix. Do 
you see
something wrong with adopting good choices simply because other 
people are
making the same good choices? I think that recognizing good choices 
being
made by others and benefiting from them is a pretty good idea.

Yes, Vim took over where vi had stagnated.  Linux was created as a
free version of a Unix-like operating system.  I don't see how that
has anything to do with "rip out all the internals of Vim and replace
them with a spider-monkey-type-thingy".  I mean, it's not like Bram
had Vi, removed insert mode and replaced it with virtual replace mode
and made a better editor.  (Yes, straw-man that if you like.)

And just because companies like Adobe and software foundations like
Mozilla have chosen JavaScript (and most Adobe applications have a COM
interface, so their not usually limited to just JavaScript) for their
extension languages doesn't mean it makes sense for others.

> >I would argue that international standardization lends ECMAScript an
> >edge over Lua, incidentally.
>
> Lua is standardized in the sense that it has only one implementation.

The same applies to Intercal. I don't see the relevance.

You seem to have a particularly hostile view toward ECMAScript, beyond a
simple preference for the status quo, and I'm not sure why. Would you 
like
me to talk about why I like it as a language, rather than why I think it
would benefit Vim?

Would you like it if I talked condescending to you?

The only question that is really relevant here is: why it isn't enough
with having an ECMAScript extension instead of having it replace
VimScript?

The following arguments have been given:

1.  Because people wouldn't have to learn another language
2.  Because it is standardized
3.  Because lots of people are working on efficient implementations

Argument 1) fails because not all people know ECMAScript in the first
place.  Arguably there are many other choices for languages that more
people know than ECMAScript.

This is completely true. EMCAScript, however, is never going away and is 
known by a very large number of users (both technical and 
non-technical). Frankly, one of Vim's greatest barriers-of-entry is the 
learning curve. I think much of this is due to its use of proprietary 
scripting formats. I think there is probably a great deal of overlap 
between Vim users and current EMCAScript (a.k.a. JavaScript) users. For 
example, I'd imaging that many PHP developers use Vim as their primary 
editor (such as myself)...and that most of those users use JavaScript on 
the client.
Argument 2) fails because using a standardized language instead of a
application-specific language gives us no advantages.  On can also
argue that the application-specific language is standardized in the
sense that it is the standard.

I disagree. By using a standard language you automatically inherit a 
great deal of existing frameworks, libraries and scripts...not to 
mention talent. I'd also state that it is no accident that EMCAScript 
(JavaScript) is a standard. It is a standard because it is a technically 
excellent scripting solution. It has vast support for object oriented 
programming, is extensible (think DOM), is easy to learn, is very 
mature, and has several available free and open source implementations.
Argument 3) fails because it simply isn't true.  Last I heard Tamarin
was going to be "integrated" with SpiderMonkey but that that mostly
meant phasing out SpiderMonkey and replacing it with Tamarin.  So that
leaves Tamarin.  And sure, there are probably a bunch of people
working on Tamarin, because it's a complex piece of software, but
plural number of (freely available) implementations I wouldn't say
that there are.

These are both working implementations. Lots of people are working on 
them. How is this not true? PS: You might be impressed by the Opera 9.0 
implementation (built into Presto) compared with the others in terms of 
footprint. It is also one of the fastest in terms of overall speed of 
execution.
 nikolai

I'd add at least two additional arguments:

4) Using an existing (unmodified) implementation takes some of the 
maintenance burden out of the hands of the Vim developer(s). Its always 
nice to let someone else to the work. :-)

5) EMCAScript is more mature and technically superior. You may not like 
the language personally, but certainly you cannot deny that there are 
advantages in using an object oriented language. It is not hard to 
imaging a DOM-like structure applying to the Editor environment (there 
is no directly translation between the DHTML DOM and the Vim 
environment, but there are interesting equivalents).

As far as designing an object interface goes, I don't think that this is 
something any one person could easily do. Frankly I think VimScript does 
an amazing job of encapsulating the shear amount of functionality that 
it does, and certainly don't mean to imply that it is not an impressive 
and effective solution. The earlier example got me thinking though:

:set fo-=t

Maybe something like this:

with (vim.options.autoFormat) {
 textWrap = true;
 maxColumn = 78;
 wrapExpression = php.formatExpr;
}

...where textWrap, maxColumn, and wrapExpression are all properties of 
the vim.options.autoFormat class, brought into scope using the with 
block for concision. The php class would be some user-defined class with 
at least one method: formatExpr, which should be called whenever 
auto-formatting (gq) takes place.

Just my $0.02.

-Robert


The argument that to me wins the day has already been voiced:

EMCAScript or ECMAScript (now which is it? You seem unsure yourself) is a 
_different_ language. People wanting to customise Vim would have to learn it 
_in addition_ to the Vim commands.

Vimscript is _the same_ language. Its commands are the same as the ex-commands 
I need to know anyway so I can use them within Vim.


Best regards,
Tony.
--
Computers are not intelligent.  They only think they are.