On 4/25/07, Robert Lee <[EMAIL PROTECTED]> wrote:
Nikolai Weibull wrote:
> 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).
Never is a very bold claim. I'm sure Grace Hopper figured COBOL would be around a lot longer than it was (well, OK, it /is/ still around in legacy systems, but has, in essence, "gone away"). And how big is the user base for ECMASCript compared to those of Python, Perl, Ruby, PHP, Lua, Haskell, O'Caml, ML, Java, Scheme, Erlang, Lisp? And for the combination of language X and Vim?
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.
The greatest barrier is the radically different mode of operation. Most editors people come in contact with when beginning to use computers are the Notepad-type editors: you type in what you want and there are certain key combinations that you can strike to execute commands. Vi (and thus Vim) is radically different (although it wasn't the first editor to work this way). Getting used to working with modes and executing commands is what makes Vi(m) difficult for beginners. Having its own scripting language isn't. And in the end, how different is VimScript from other languages. The biggest annoyance I have with it now is that it's not easy enough to do prototype-based object-orientation with it and that parameters must be prefixed with a:.
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.
And how many PHP developers are using Vim? I'd argue that very few people developing with ECMAScript use Vim, considering the not-quite complete/updated syntax definition and the lack of a good indentation definition. I've written my own syntax definition and contemplated writing and indentation definition, but I don't use ECMAScript enough to actually get around to it. Obviously, few people have.
> 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.
It seems to me that you're using the word standard here to mean normal or common. I'll assume that were still talking about ECMAScript being a language with a standardization attached to it. The ECMA standard of ECMAScript doesn't standardize any frameworks, libraries or scripts.
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.
/Prototype-based/ object-oriented programming. This can be done with VimScript as well, although JavaScript has "slightly" better syntax for it. The DOM isn't defined in the ECMAScript standard. It is maintained by W3. Browsers enable access to the DOM in their ECMAScript/JavaScript API. Mature? ECMAScript is rapidly changing. Just check out what they're doing for 1.7. Sure, that doesn't mean that it's not mature, but it certainly doesn't mean that it's in any way done and you won't have to learn new stuff if you use it.
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. :-)
Yes. All you have to do is replace one of the largest parts of the code base.
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.
ECMAScript is a prototype-based language, just like VimScript. To be fair, I like neither language very much. nikolai
