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