On 01/12/2012 01:50 PM, Charles Campbell wrote:
Reid Thompson wrote:
On Thu, 2012-01-12 at 12:07 -0600, sc wrote:
so there might be a faster engine for our scripts
:) heh lets embed tcc and write them all in C
Make lisp the default script engine and import emacs! :O
Look, whenever someone likes a tool, they'd like it used everywhere. Its
the "everything looks like a nail because I have a hammer!" syndrome.
I've seen this with "why learn [some-language: C Java C++ Perl], I think
[Fortran|Cobol|Ada] is fine and dandy and should be used everywhere". In
the present case, substitute {some-language=VimL} and put
Favorite-Other-Scripting-Language in [Fortran|...]'s place.
Points in VimL's favor include: current plugins,
backwards-compatibility, know how to use vim you know how to write much
of vimL.
Against: insular
Also against: lacks in power, a lot of little quirks and special cases.
Points in My-Favorite-Other-Scripting-Language's favor as default:
(please include JavaScript, Perl, Ruby, even lisp, etc) has a dedicated
fan base, those who know it don't need to learn something else,
naturally all the other Favorite-Scripting-Languages (including VimL)
are obviously inferior, we can throw out all the current plugins and
rewrite them in a nifty new Favorite-Other-Scripting-Language, if
compilable then faster
No, I don't think people say my favorite language X is better than
languages like Y, Z, VimL. I think most people would say anything
but VimL, specifically anything general purpose and more or less widely
used, dynamic, competent at text processing. Most would agree, even
if they don't use these languages, that perl, ruby, python and JS are
all fair candidates. I would say perl is somewhat less favorable since
its use is on the decline while the other three are growing. I would
also say JS is less favorable for the reason I already mentioned - most
of even those familiar with it only know a bit of it and in a niche
use case, while ruby and python are used very extensively in in wide
areas of application.
I prefer python as a matter of personal taste but I can take a step
back and say that either would be equally useful, in fact I don't
see any problem if a "huge-vim" package included both as main
vim scripting languages, is that really a problem with modern hard
drive sizes?
Points against: need to include FOSL with vim, knowing Vim doesn't aid
in knowing FOSL,
Knowing Vim doesn't really aid in learning VimL, except that you can
use normal vim commands in it, but you can use them in other supported
languages, as well, but wrapping them in respective function call.
The difficult part about learning a language, whether it's VimL or
something else, is learning data structures, functions in standard
library, etc. A regular Vim user who knows normal, command and insert
mode commands, will not find learning VimL appreciably easier than
learning python or ruby.
not backwards compatible, need to throw out current
plugin base (unless one is intending to bloat things by keeping VimL, too)
VimL should definitely stick around for 5-8 years at the least. A bit
more bloat is a small price to pay..
Look: the computing world has become a very-multi-language environment.
Wishing that the One-True-FOSL be supreme is wasteful of wishes.
Currently there are high performance languages used in areas where
they are required, JS is used as a niche language for web pages,
and a handful of general purpose, fast prototyping languages are
used for all other things. It's a bit of a tall order to have
people learn a language to make small changes or extensions to
editor functionality, where a general purpose language would work
perfectly well. -ak
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
