Excerpts from Ingo Karkat's message of Tue Jul 12 09:36:52 +0200 2011:
> IMO most of the complexity is due to the Vim API, not VimL itself. So, unless
> you completely redesign the API (and that probably means changing much of the
> core Vim implementation as well), you won't gain that much.
>From your homepage it looks like you've spend some time with various
programming languages. I read "Java, C++, Unix Shell scripts, Perl, ..".
So probably you love error messages like something has gone wrong in
10..27..34 as much as I do. [1]
This happens if you use the "advanced features" of VimL: dict functions.
If you compare this to nice stack traces of python, ruby, HaXe, JS you
see the difference.
And the amount of plugins available for Opera, Firefox which have been
written in JS at least proof that JS is a language many devs can pick up
and to turn their browser into what they want as well.
Moreover for JS etc there exist many more libraries such as parser
generators etc. You're right: For VimL there exist XML parsing libraries
as well (-> webapi-vim on github). But it took 30 years until someone
stepped up to write it. And still then it was buggy and had to be fixed.
Resources are wasted here. Keep that in mind. Those resources could be
spend on writing a web aware vim implementation or on Uganda or on
installing energy saving items in your house.
Or on writing what many people ask on irc:
Writing howtos about how to apply Vim to user specific problems such as
- setting up Vim with python development
- setting up Vim for web development
- ...
- People *do* join #vim and ask those questions. So we don't have
documentation satisfying that. We should work on that rather than
writing yet another library which already exists in 10 other languages
(and just works) in VimL (my 2 cents).
Historical VimL was perfect. 30 years ago there was neither JS, PHP,
perl, ruby, ... So VimL was a huge step. Today
> So, for me, I'd like to keep VimL (and the many extension languages that are /
> can be supported by Vim).
Yes, have close look at the python "support". The python module does
not even have a "escape_for_vim" function !
Yes - you can get your job done. But a clean interface would allow you
to map python callbacks to <cr> or the like directly.. The problem is
that the time of each individual is limited. And you don't have time to
learn 50 languages and implement things in those. Thus if JS would be
used only you could script your browser and Vim
We all love that "English" is an universal language and that we can
understand each other. It would be equally nice if browsers and Vim had
the same scripting language. eventually you should translate Vim
documentation into Esperento because its easy to pick up..
The end result is you still have to learn English because most
interesting documentation has been written in English.
If ZyX manages to optimize VimL I'd be happy cause I had to stop two
projects due to speed reasons. (One was about completion for Delphi. It
partially works. But its much too slow even when using as much caching
as you can - the other was about tagging as3 sources on the fly -
because I don't like to retag sources always. I want things to work
without me taking action - EAch time it partially worked - but I spend
hours on getting response time to less than a second - and I was still
not satisfied.) - Yes you're right: I should not have used VimL in the
first place. Which value does VimL provide then if you have to learn
VimL, then you have to learn that VimL doesn't satisfy you, then you
have to rewrite your stuff?
Anyway I would have been much happier if it worked out of the box.
Today you can't do everything on your own:
- maintain a language for an editor
- support editors
- write editor tools to support other languages
- ...
Maybe its only me who wants this all.
If was using Vim to write emails only I'd be happy.
Marc Weber
[1] Example triggering those kind of messages:
let a = {}
fun a.a()
call self.b()
endf
fun a.b()
call self.a()
endf
call a.a()
we both agree that in this case its easy to see what's going wrong.
But now use more complicated code .. good luck.
Maybe there is even a way to iterate over all objects VimL knows about
to find out what func 77 is. But why should people learn about all this
stuff?
--
You received this message from the "vim_dev" 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
