How powerful is language build in vim compare with the language build in emacs?

737 views
Skip to first unread message

Peng Yu

unread,
Jan 25, 2010, 12:13:01 AM1/25/10
to vim_use
I have learned neither the language for vim scripting nor the language
for emacs scripting (which is lisp, right?). (I know mit-scheme, but I
have never used emacs) May I ask the following questions?

I know Lisp is very powerful. Is the language in vim as powerful?

For what type of tasks, it is more difficult to do in vim scripting
language than lisp in emacs? And for what type of tasks, it is easier
to do in vim scripting language than lisp in emacs?

Tony Mechelynck

unread,
Jan 25, 2010, 2:30:15 AM1/25/10
to vim...@googlegroups.com, Peng Yu

I don't know. I've seen some Lisp program sources, which AFAICT looked
like a soup of parentheses. Vim script, OTOH, is (to my mind) much
easier to read, and its commands are the "ex-commands" which you can
type at the command-line (where you get by hitting a colon in Normal
mode), including the commands you define. I'd say Vim script belongs to
the family of "structured languages" descended from ALGOL and which
includes C (I think) and Unix shell script.

See for instance ":help design-not" for a few examples of what Vim is
*not* meant to do.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
247. You use www.switchboard.com instead of dialing 411 and 555-12-12
for directory assistance.

Marczis, Peter (NSN - HU/Budapest)

unread,
Jan 25, 2010, 3:36:06 AM1/25/10
to vim...@googlegroups.com

Hi,
I would like to delete everything not matching to a pattern...
I usually do it this way:

:v/my pattern/d<CR>

and it works perfect to any single line pattern...

my problem is that I want to keep something like this:

ABC ...
....
....
...
And until the first empty line...

How it is possible ? I was thinking something like this:
:v/ABC\(.|\n)*^\s*$/d

but not really work.

Thanks in advice.

Br,
Peter.

Tim Chase

unread,
Jan 25, 2010, 8:25:53 AM1/25/10
to vim...@googlegroups.com
Marczis, Peter (NSN - HU/Budapest) wrote:
> I usually do it this way:
>
> :v/my pattern/d<CR>
>
> and it works perfect to any single line pattern...
>
> my problem is that I want to keep something like this:
>
> ABC ...
> ....
> ....
> ...
> And until the first empty line...
>
> How it is possible ? I was thinking something like this:
> :v/ABC\(.|\n)*^\s*$/d
>
> but not really work.

My first thought would be to use a "decorate-modify-undecorate"
pattern, something like

:g/ABC/,/^\s*$/-s/^/@

"on every line matching ABC, from that line through the next
blank line (minus one = "-", which you can remove if you want to
keep the blank lines), tack a '@' character at the beginning of
the line" (mark the lines we want to keep with a unique character)

:v/^@/d

"delete all the lines we didn't mark as interesting"

:%s/^@

"remove all the decoration we put in".

It requires being able to find a decoration character that isn't
in use at the beginning of any line, so you might have to use "%"
or some other character instead, but the pattern is the same.

As a side note, it does require at least one blank line after the
each ABC or you'll get a little complaint from Vim. It also has
difficulty if you have more than one ABC in a section such as

ABC
foo
ABC <-- there's no blank line above this
bar so the overlap with the first ABC
causes problems

ABC
...

-tim

pansz

unread,
Jan 26, 2010, 11:48:47 PM1/26/10
to vim...@googlegroups.com
Peng Yu 写道:

In theory, a turing complete language could do anything.

http://en.wikipedia.org/wiki/Turing_completeness

Two turing-complete languages are always inter-translatable.

It is said that Lisp is turing complete.

So if vim script is turing-complete, it is as powerful as Lisp.

Teemu Likonen

unread,
Feb 15, 2010, 12:42:31 PM2/15/10
to vim use
* 2010-01-24 21:13 (-0800), Peng Yu wrote:

> I know Lisp is very powerful. Is the language in vim as powerful?

No, it's not. It seems that there are still unique features in Lisp
which are not supported in any other language. In this sense Lisp is the
most powerful language available. Lisp is really different. I don't know
many languages but this is what other people say. Other languages have
gained power by copying Lisp's features.

For example, a Vim script programmer can't use the language to modify
and extend the language itself. On the other hand Lisp programmers do
that pretty much all the time. Emacs people have used Emacs Lisp to
implement quite big part of Common Lisp. A programmer does not see where
the "core language" ends and other features begin because there's no
difference. A good example for this are Common Lisp's standard macros:
the language was used to build part of the language itself.

> For what type of tasks, it is more difficult to do in vim scripting
> language than lisp in emacs? And for what type of tasks, it is easier
> to do in vim scripting language than lisp in emacs?

Now there's the practical angle. Obviously languages don't live in
vacuums; they are part of some environment and often it's the
environment which very much defines language's power and limits. Vim
script is very useful language for interacting with Vim's features. But
a Vim script programmer doesn't have as much freedom as Emacs Lisp
programmer because Vim environment sets more limits than Emacs.

The fundamental difference is that Vim as an environment is pretty much
closed and the Vim script language is just a _scripting_ language for
those features. On the other hand Emacs environment itself is mostly
implemented in Emacs Lisp so programmers kind of live inside the
environment. Emacs Lisp is not a scripting language but the
implementation language of the system itself. This blurs the distinction
between Emacs developers and users. Users get the same access as the
original developers, and all of it interactively without restarting
Emacs.

But are you asking concrete examples of operations which are _easier_ to
do with one editor? There are probably thousands of such examples but
they don't tell much about language's power or environment's abilities.
Well, in Vim script it's easier to go to the first line of current
buffer: 1 (that is, the command is just the number). Nothing can be
simpler than that. The same is more "difficult" in Emacs Lisp code.
Programmers typically do it with (goto-char (point-min)).

It's also probably easier to programmatically search and replace in Vim:

let cursor = getpos('.')
%s/regexp/replace/g
call setpos('.', cursor)

Programmer needs to understand a bit more about actual programming when
doing the same in Emacs Lisp code:

(save-excursion
(goto-char (point-min))
(while (re-search-forward "regexp" nil t)
(replace-match "replace")))

You know, a conditional loop and all. :-) Some things are easier in
Emacs Lisp - that (save-excursion [...]) macro being one example - but
then again these examples don't tell much about anything.

The bottom line is that

- on theoretical level no language is more powerful than Lisp and
therefore Emacs Lisp is more powerful than Vim script.

- on practical level language's power depends on features and limits
of the surrounding environment. In this area Emacs Lisp also wins
because the system is almost totally open for a programmer.

- Vim is obviously an excellent and powerful text editor. I'm just
comparing features and power of the languages and the two different
environments as a whole.

Teemu Likonen

unread,
Feb 15, 2010, 1:05:05 PM2/15/10
to vim use
* 2010-01-27 12:48 (+0800), pansz wrote:

> In theory, a turing complete language could do anything.

In practice the effort of doing things is not equivalent, obviously. :-)
The abstractness and features differ very much and not every programmer
is qualified to compare languages' power. Certainly I'm not.

I'll quote a few paragraphs from Paul Graham's article "Beating the
Averages". It's about comparing languages' power. The article is
available from <http://www.paulgraham.com/avg.html>.

Programmers get very attached to their favorite languages, and I
don't want to hurt anyone's feelings, so to explain this point I'm
going to use a hypothetical language called Blub. Blub falls right
in the middle of the abstractness continuum. It is not the most
powerful language, but it is more powerful than Cobol or machine
language.

And in fact, our hypothetical Blub programmer wouldn't use either of
them. Of course he wouldn't program in machine language. That's what
compilers are for. And as for Cobol, he doesn't know how anyone can
get anything done with it. It doesn't even have x (Blub feature of
your choice).

As long as our hypothetical Blub programmer is looking down the
power continuum, he knows he's looking down. Languages less powerful
than Blub are obviously less powerful, because they're missing some
feature he's used to. But when our hypothetical Blub programmer
looks in the other direction, up the power continuum, he doesn't
realize he's looking up. What he sees are merely weird languages. He
probably considers them about equivalent in power to Blub, but with
all this other hairy stuff thrown in as well. Blub is good enough
for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the
languages higher up the power continuum, however, we find that he in
turn looks down upon Blub. How can you get anything done in Blub? It
doesn't even have y.

By induction, the only programmers in a position to see all the
differences in power between the various languages are those who
understand the most powerful one. (This is probably what Eric
Raymond meant about Lisp making you a better programmer.) You can't
trust the opinions of the others, because of the Blub paradox:
they're satisfied with whatever language they happen to use, because
it dictates the way they think about programs.

I know this from my own experience, as a high school kid writing
programs in Basic. That language didn't even support recursion. It's
hard to imagine writing programs without using recursion, but I
didn't miss it at the time. I thought in Basic. And I was a whiz at
it. Master of all I surveyed.

Ben Schmidt

unread,
Feb 15, 2010, 5:33:11 PM2/15/10
to vim...@googlegroups.com
> In theory, a turing complete language could do anything.

Not 'do' anything, but 'compute' anything.

And even then, it's not necessarily particularly useful...if it doesn't
have an interface to get the appropriate 'anything' out...or the
appropriate input in. Almost every language is Turing complete, and
Vimscript almost certainly is, though your machine probably doesn't have
an infinite amount of memory. But Vimscript would be pretty useless,
even though Turing complete, if it didn't let you access the text of
your files and operate on it. Fortunately, though, Vim does.

It's a bit of a misunderstanding thinking you don't know Vimscript,
though. If you work in Vim, you already know quite a lot, as Vimscript
is just regular Ex commands. So the learning curve to learning Vimscript
is quite small. Yes, there are a bunch of commands and functions you
will use primarily or exclusively in scripts, but there are plenty you
use both on the commandline and in scripts. Lisp, on the other hand,
isn't the way one usually interacts with Emacs, as far as I know, so
must be learnt separately.

Vim is essentially an imperative procedural language. Lisp is
essentially a functional language. Most people find imperative languages
easier to understand because they're a bit more like recipes and a bit
less like Mathematics! Some people find the reverse, though.

Lisp is certainly more elegant than Vimscript, which is just a mess,
with as many exceptions as rules, and different escaping mechanisms
needed every few lines. If you want to do serious programming, Lisp is
the way to go. If you want a quick hack, Vimscript is probably easier.

Ben.


Sean DeNigris

unread,
Feb 15, 2010, 7:11:13 PM2/15/10
to vim_use
The other thing to consider is that Vim can be compiled with support
for other scripting languages e.g. Tcl, Perl, Python, and Ruby. I
write nearly all my scripts in Ruby, with a tiny bit of Vimscript glue
code.

Sean

Teemu Likonen

unread,
Feb 16, 2010, 12:44:33 AM2/16/10
to vim use
* 2010-02-16 09:33 (+1100), Ben Schmidt wrote:

> Vim is essentially an imperative procedural language.

Quite true.

> Lisp is essentially a functional language.

People keep saying that but Emacs Lisp and Common Lisp are really
multi-paradigm languages (Common Lisp more so). You can write these
languages just like you write procedural languages. I started writing
Lisp like I had written other languages - and often still do, whatever
feels natural. The FAQ for comp.lang.functional newsgroup does not even
mention Emacs Lisp and Common Lisp as an example of functional
languages. There is Scheme, though.

For example, you can write procedurally:

(defun sum-items-loop (list)
"Sum LIST's items using a loop and store the sum to variable SUM."
(setq sum 0)
(dolist (i list)
(setq sum (+ sum i))))

(sum-items-loop '(1 2 3 4))
;; sum=10

But you can also write:

(setq sum (let ((sum 0))
(dolist (i '(1 2 3 4))
(setq sum (+ sum i)))
sum))
;; sum=10 (no other effects)

Or use recursion:

(defun sum-items-recursive (list)
"Sum LIST's items using recursion."
(if (not list)
0
(let ((i (car list)))
(+ i (sum-items-recursive (cdr list))))))

(sum-items-recursive '(1 2 3 4))
;; The return value is 10 and there are no side effects.

> Most people find imperative languages easier to understand because
> they're a bit more like recipes and a bit less like Mathematics! Some
> people find the reverse, though.

And some people like both and use Lisp. :-)

John Magolske

unread,
Feb 16, 2010, 1:01:05 AM2/16/10
to vim...@googlegroups.com
* Sean DeNigris <trus...@clipperadams.com> [100215 16:32]:

Anyone know if Lua support is getting any closer to making it into Vim?

Searching around, I see there's a patch:
http://wiki.linuxfromscratch.org/blfs/attachment/wiki/vim/vim72-lua-0.6.patch.gz

John


--
John Magolske
http://B79.net/contact

Teemu Likonen

unread,
Feb 16, 2010, 1:07:09 AM2/16/10
to vim use
* 2010-02-16 07:44 (+0200), Teemu Likonen wrote:

> Or use recursion:
>
> (defun sum-items-recursive (list)
> "Sum LIST's items using recursion."
> (if (not list)
> 0
> (let ((i (car list)))
> (+ i (sum-items-recursive (cdr list))))))
>
> (sum-items-recursive '(1 2 3 4))
> ;; The return value is 10 and there are no side effects.

The function can be written without the temporary variable i:

(defun sum-items-recursive (list)
"Sum LIST's items using recursion."
(if (not list)
0

(+ (car list) (sum-items-recursive (cdr list)))))

Ben Schmidt

unread,
Feb 16, 2010, 8:38:30 AM2/16/10
to vim...@googlegroups.com
>> Lisp is essentially a functional language.
>
> People keep saying that but Emacs Lisp and Common Lisp are really
> multi-paradigm languages (Common Lisp more so).

Yeah, I know. But I think the 'essence' of the language is more
functional, really. Even 'functional' is used pretty loosely, though.
I was aiming for a broad stereotype. Not like me. Usually I'm horribly
pedantic.

I should get around to learning some Lisp properly. It's somewhat on my
"I'm not all that interested" language list because of the syntax,
though; like Perl. A bit too flexible for my liking, as it can lead a
bit too easily to sloppy programs. And I've never been all that good at
counting parentheses!

Mind you, at least the syntax itself it is absolutely consistent.
Comparatively, Vimscript is a mess!

>> Most people find imperative languages easier to understand because
>> they're a bit more like recipes and a bit less like Mathematics! Some
>> people find the reverse, though.
>
> And some people like both and use Lisp. :-)

Touch�!

Grins,

Ben.


Teemu Likonen

unread,
Feb 16, 2010, 11:18:45 AM2/16/10
to vim use
* 2010-02-17 00:38 (+1100), Ben Schmidt wrote:

> And I've never been all that good at counting parentheses!

Neither have I. Lisp IDEs have features which make writing and
navigating through lists and other s-expressions really easy. For
example, Emacs users write and close lists with Alt+( and Alt+). Even
complex-looking structures are actually trivial to write. But I wouldn't
write a single expression of Lisp with Nano or Notepad! :-)

(if (setf (nth 3 *foo*) (cond ((and (= bar 1)
(> (length list) 3))
(do-this))
((or (> blah 1)
(< blah 5 ))
(do-that)
(and-some-more))
(t
(else-do))))
(then-this)
(else-this)
(and-that))

Bram Moolenaar

unread,
Feb 17, 2010, 6:45:26 AM2/17/10
to Ben Schmidt, vim...@googlegroups.com

> >> Lisp is essentially a functional language.
> >
> > People keep saying that but Emacs Lisp and Common Lisp are really
> > multi-paradigm languages (Common Lisp more so).
>
> Yeah, I know. But I think the 'essence' of the language is more
> functional, really. Even 'functional' is used pretty loosely, though.
> I was aiming for a broad stereotype. Not like me. Usually I'm horribly
> pedantic.
>
> I should get around to learning some Lisp properly. It's somewhat on my
> "I'm not all that interested" language list because of the syntax,
> though; like Perl. A bit too flexible for my liking, as it can lead a
> bit too easily to sloppy programs. And I've never been all that good at
> counting parentheses!
>
> Mind you, at least the syntax itself it is absolutely consistent.
> Comparatively, Vimscript is a mess!

I'll bite.

One of the most important aspects of a programming or scripting language
is that it's easy to read back. Only then can one figure out what it's
doing exactly and easily spot mistakes. Both Perl and Lisp fail
miserably on this aspect.

Unfortunately, programmers are proud of creating something that other
people have a hard time figuring out what it does. It's like a priest
talking latin, it sets them apart from the crowd.

--
Married is a three ring circus:
First comes the engagement ring.
Then comes the wedding ring.
Then comes the suffering.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Vincent Arnoux

unread,
Feb 17, 2010, 11:07:25 AM2/17/10
to vim...@googlegroups.com
On Wed, Feb 17, 2010 at 12:45, Bram Moolenaar <Br...@moolenaar.net> wrote:
> > Comparatively, Vimscript is a mess!
>
> I'll bite.
>
> One of the most important aspects of a programming or scripting language
> is that it's easy to read back.  Only then can one figure out what it's
> doing exactly and easily spot mistakes.  Both Perl and Lisp fail
> miserably on this aspect.
>
> Unfortunately, programmers are proud of creating something that other
> people have a hard time figuring out what it does.  It's like a priest
> talking latin, it sets them apart from the crowd.

Innocent question incoming: Wouldn't it be a good idea to write a
binding of Vimscript in, say, Python or Lua or any other more widely
spread language and ship it with vim?

- Vincent

Tim Chase

unread,
Feb 17, 2010, 11:26:47 AM2/17/10
to vim...@googlegroups.com

> Innocent question incoming: Wouldn't it be a good idea to write a
> binding of Vimscript in, say, Python or Lua or any other more widely
> spread language and ship it with vim?

You mean like it already does? :)

It has interfaces for Python, Perl, Ruby, TCL, and MZScheme. You
can find them enumerated at

:help reference_toc

and skim down to the "Interfaces" section. Your vim has to be
built with support, but Vim does allow for building with a
variety of language bindings.

-tim


sc

unread,
Feb 17, 2010, 11:47:01 AM2/17/10
to vim...@googlegroups.com

also, you can have your cake and eat it too -- vim's filtering
syntax is so good you can have a lean and mean vim with no extra
interpreters built in, then filter the buffer, or a select part
of the buffer through any script or program of your choice

if you are a fan of lisp and want to work on your buffer with it,
there's no need for a lisp-enabled vim, just send whatever part
of your buffer is relevant out to your lisp code and let it send
back the modifications

you are limited only by your imagination

sc

Teemu Likonen

unread,
Feb 17, 2010, 12:34:41 PM2/17/10
to Bram Moolenaar, vim use
* 2010-02-17 12:45 (+0100), Bram Moolenaar wrote:

> One of the most important aspects of a programming or scripting
> language is that it's easy to read back. Only then can one figure out
> what it's doing exactly and easily spot mistakes. Both Perl and Lisp
> fail miserably on this aspect.

Are there some reliable sources which indicate that Perl and Lisp code
are not usually read, debugged or fixed after the code has been
initially written? Or is there a general consensus or verifiable data
that fixing problems in Perl or Lisp code takes more time than fixing
problems in code written in other languages? "Failing miserably", as you
put it, sounds like there is a clear and somewhat objectively measurable
difference.

I have no answers to those but I sense a danger in discussions like
this. It can easily go to "my favourite language is a very clear one"
and "other people's code and favourite languages are unreadable."

My opinion is that a familiar coding style and familiar language make
code readable. And then also the programming style of not doing too much
different things in a tiny part of code. Perl "fails miserably" with me
because I still haven't had time to actually learn it. But I think it's
me who fails.

I'm relatively new to Lisp but I find it beautiful and clear. It's often
verbose and macros hide boring repetitive code and complexity. Then
again, I have had motivation to learn and understand Lisp. Motivation
helps a lot. :-)

> Unfortunately, programmers are proud of creating something that other
> people have a hard time figuring out what it does.

I can't comment about the pride but I'd like to ask what do you think
affects more, coding style or language? I'm asking because in the
previous paragraph you spoke about languages' readability and now you
switched to programmers. Maybe you mean that some programmers try to do
clever and powerful tricks which do a lot of things with a tiny piece of
code but are difficult to understand quickly (?).

Vincent Arnoux

unread,
Feb 17, 2010, 1:29:59 PM2/17/10
to vim...@googlegroups.com

I am sorry I was not clear enough... By "ship it with vim", I actually
meant bundle the (Python|Lisp|Perl|Ruby|Whatever) interpreter with vim
so that plugins written in this language are directly usable without
extra installation nor configuration. This would avoid having to
re-invent the wheel with another scripting language specific to vim.
Of course, your argument of the cake I can make myself and eat is
still valid...

- Vincent

Matthew Winn

unread,
Feb 17, 2010, 2:23:29 PM2/17/10
to v...@vim.org
On Wed, 17 Feb 2010 19:34:41 +0200, Teemu Likonen <tlik...@iki.fi>
wrote:

> I have no answers to those but I sense a danger in discussions like
> this. It can easily go to "my favourite language is a very clear one"
> and "other people's code and favourite languages are unreadable."

That's pretty much the reasoning with every claim for a language's
superiority or inferiority. I find Perl to be one of the easiest
languages to read because it's one of the languages I know best.
It's years since I did any Lisp programming, but I found that quite
easy to read when I was using it.

> I can't comment about the pride but I'd like to ask what do you think
> affects more, coding style or language? I'm asking because in the
> previous paragraph you spoke about languages' readability and now you
> switched to programmers. Maybe you mean that some programmers try to do
> clever and powerful tricks which do a lot of things with a tiny piece of
> code but are difficult to understand quickly (?).

Many of those clever and powerful tricks are standard techniques
of the language. In languages like Vimscript that support regular
expressions the use of such expressions looks like a trick that is
difficult to understand, but only to people whose knowledge of the
language is lacking.

--
Matthew Winn

Kazuo Teramoto

unread,
Feb 17, 2010, 5:10:56 PM2/17/10
to vim...@googlegroups.com
On Wed, Feb 17, 2010 at 4:29 PM, Vincent Arnoux
<vincent...@gmail.com> wrote:
> I am sorry I was not clear enough... By "ship it with vim", I actually
> meant bundle the (Python|Lisp|Perl|Ruby|Whatever) interpreter with vim
>

I really really really (for i in {1..100}; echo really) wish that
nobody ever listen to your idea... ("Mom, I bought a shoe with socks
attached to it!")

What about a read: http://en.wikipedia.org/wiki/Unix_philosophy

And if my wish fail, I vote for having openoffice bundled in vim, so I
can use macros!

Or bundle a full OS on it, so we dont reinvent the wheel too... Ops,
sorry Emacs already did that, ohhh dammit, too slow... :(

^____^

Kazuo.

PS. This is a humorous email, only laugh dont be mad please XD.

--
«Dans la vie, rien n'est à craindre, tout est à comprendre»
Marie Sklodowska Curie.

Ben Fritz

unread,
Feb 17, 2010, 6:25:42 PM2/17/10
to vim_use

On Feb 17, 1:23 pm, Matthew Winn <v...@mwinn.powernet.co.uk> wrote:
>
> That's pretty much the reasoning with every claim for a language's
> superiority or inferiority. I find Perl to be one of the easiest
> languages to read because it's one of the languages I know best.
> It's years since I did any Lisp programming, but I found that quite
> easy to read when I was using it.
>

I agree that Lisp and its derivatives are easy enough to read when
you're used to it, but only if the programmer followed a good style
and made it easy for you. Cramming everything on a single line makes
Lisp a nearly unreadable mess of parentheses.

As for Perl, I regularly make little scripts in Perl, and usually my
scripts are about 10-20% real code, and the rest comments explaining
what the hell the code is doing. I have found that Perl gives you so
many shortcuts and implied operations, which the documentation
*actively encourages you to use*, that it becomes very difficult to
read very quickly. Very powerful, very concise, yes...but hard to read
unless very well documented.

Matt Wozniski

unread,
Feb 17, 2010, 11:06:12 PM2/17/10
to vim...@googlegroups.com

And, again - in most vim builds, many interpreters *are* shipped with
vim, and plugins *can* be used without any extra work above the norm
for installing a vim plugin.

~Matt

Ben Schmidt

unread,
Feb 18, 2010, 3:32:03 AM2/18/10
to vim...@googlegroups.com, Teemu Likonen, Bram Moolenaar
> Are there some reliable sources which indicate that Perl and Lisp code
> are not usually read, debugged or fixed after the code has been
> initially written? Or is there a general consensus or verifiable data
> that fixing problems in Perl or Lisp code takes more time than fixing
> problems in code written in other languages?

I think both those languages definitely have a reputation, at the very
least for being 'hard to read'...

> "Failing miserably", as you put it, sounds like there is a clear and
> somewhat objectively measurable difference.

The ultimate point of my earlier post was that by an objective measure
of syntax consistency, Lisp wins, but that this isn't necessarily a good
measure. Most declarative languages are very consistent, with operators
and so on often defined in the language itself, syntactically requiring
few tokens but keywords, strings, and a handful of punctuation, with an
escape mechanism for each. Vimscript, on the other hand, has multiple
methods of escaping, tokens frequently mean different things in
different contexts, etc.. It frustrates me at times, but I can see why,
to an extent, it needs to be like that, particularly for interactive use
of Ex commands. The thing is that, despite this, in the eyes of many,
quite probably myself included, Vimscript is more readable than Lisp.

You'd probably have to exclude the use of complicated regular
expressions...

> My opinion is that a familiar coding style and familiar language make
> code readable. And then also the programming style of not doing too much
> different things in a tiny part of code. Perl "fails miserably" with me
> because I still haven't had time to actually learn it. But I think it's
> me who fails.

Well, that's an interesting thought, isn't it? If you had no knowledge
of either language, which do you think would be easier to understand? A
piece of Vimscript, or a piece of Lisp, with similar functionality?

Programming style can definitely make either unreadable.

What if you assume good style? Is one easier?

Ben.


Teemu Likonen

unread,
Feb 18, 2010, 7:14:18 AM2/18/10
to Ben Schmidt, vim use, Bram Moolenaar
* 2010-02-18 19:32 (+1100), Ben Schmidt wrote:

>> Are there some reliable sources which indicate that Perl and Lisp
>> code are not usually read, debugged or fixed after the code has been
>> initially written? Or is there a general consensus or verifiable data
>> that fixing problems in Perl or Lisp code takes more time than fixing
>> problems in code written in other languages?
>
> I think both those languages definitely have a reputation, at the very
> least for being 'hard to read'...

I'm sure most people agree on the reputation. The point I'm trying to
make is that the general programming community may not understand a
thing about Lisp but still a Lisp hacker can read the code like a
newspaper and spot problems quickly. Is this hypothetical Lisp hacker
smarter than most people or is she just one of those (rare) people who
have actually decided to learn the language? I don't know.

Obviously reputation does not make any language difficult to understand
(unless through strong prejudice). The raises comes from somewhere but
it's quite difficult to say if it raises from the language itself or
from the fact that it's rare and unknown. Lack of understanding leads to
fear. Fear leads to anger. Anger leads to hate. Hate leads to
suffering... or something like that. :-)

>> My opinion is that a familiar coding style and familiar language make
>> code readable. And then also the programming style of not doing too
>> much different things in a tiny part of code. Perl "fails miserably"
>> with me because I still haven't had time to actually learn it. But I
>> think it's me who fails.
>
> Well, that's an interesting thought, isn't it? If you had no knowledge
> of either language, which do you think would be easier to understand?
> A piece of Vimscript, or a piece of Lisp, with similar functionality?

Hard to say about tabula rasa situation. We usually know some other
languages and this leads to the question of what languages (and what
kind of languages) people typically know, that is, which are the most
popular. Vim script is closer to popular languages so I'm pretty sure
that most people find it easier. So in many people's perceptions Lisp
becomes "difficult" and "fails miserably" on the readability aspect.

But who really "decides" which language is easier to read and debug? Is
it the general programming community or the developers who are actually
working with the language in question? If Bram's statement "Both Perl
and Lisp fail miserably on this [readability] aspect" is true then it
must be difficult and slow for _everybody_ to debug Perl and Lisp code.
Do Perl and Lisp hackers say that debugging is slower and more
difficult?

Anyway, I think that widely established coding style and concepts are a
strong factor in general easy-to-understand comparisons. So, not only
"similar functionality" but similar implementation too. Previously I
made some examples that sum list's items (integers) so here is the same
functionality again with easy-to-understand code:

function Sum(list)
let sum = 0
for item in a:list
let sum = sum + item
endfor
return sum
endfunction

Evaluating Sum([1, 2, 3, 4]) returns 10. Making it as easy as possible
means that abbreviations like "fun" or "endfo" should not be used. Also,
"sum = sum + item" is easier to understand than "sum += item".

In Common Lisp the "easy" function could be one of these:

(defun sum (list)
(let ((sum 0))
(dolist (item list)
(setf sum (+ sum item)))
sum))

(defun sum (list)
(loop for item in list
with sum = 0
do (setf sum (+ sum item))
finally (return sum)))

(defun sum (list)
(loop for item in list
summing item))

(Recursion is not "easy" so the example is not included here.)

So (sum '(1 2 3 4)) will evaluate to 10. I'm quite sure that most people
here find the Vim script version the easiest to understand but I'm also
sure that the last and shortest Common Lisp version is the easiest for
me.

But really Common-Lispers would write the same functionality with this:

(reduce #'+ '(1 2 3 4))

It does it all. That is probably very difficult to understand for
non-Lispers because it doesn't use widely established looping concepts.

REDUCE is conceptually a so called higher-order function because it
takes another function as its argument (in this case, the summing
function "+"). The argument function is called with two arguments: (1)
the return value of the previous call and (2) the next item in the
sequence.

Higher-order functions are standard stuff in Lisp but probably weird for
many people because the the concept is not common and the feature of
first-class functions is not available in many languages. Nevertheless
they are powerful. REDUCE has many uses, for example:

(reduce #'max '(1 2 3 4)) => 4
(reduce #'min '(1 2 3 4)) => 1

(reduce #'(lambda (a b)
(if (char< a b) a b))
"characters")

The last example passes anonymous function as an argument. The anonymous
function compares characters and returns the one which is earlier in
alphabets. The return value of REDUCE is the character "a" because it's
alphabetically the earliest one in the string "characters". With CHAR>
comparison function REDUCE would return character "t".

Tom Link

unread,
Feb 18, 2010, 7:53:38 AM2/18/10
to vim_use
> But really Common-Lispers would write the same functionality with this:
>
>     (reduce #'+ '(1 2 3 4))

So cl with its vast standard library provides a function for that.
That's cool of course but nothing stops you from implementing such a
function in vimscript, perl or whatever.


function! Reduce(ffn, list) "{{{3
if empty(a:list)
return ''
else
let list = copy(a:list)
let s:acc = remove(list, 0)
let ffn = substitute(a:ffn, '\<v:acc\>', "s:acc", 'g')
for val in list
let s:acc = eval(substitute(ffn, '\<v:val\>', val, 'g'))
endfor
return s:acc
endif
endf


echom Reduce("v:val + v:acc", [1, 2, 3, 4])
echom Reduce("v:val > v:acc ? v:val : v:acc", [1, 2, 3, 4])
echom Reduce("'v:val' < v:acc ? 'v:val' : v:acc", split("characters",
'\zs'))


Now let's try to use dictionnaries for prototype-based programming and
I ask you to do something similar in say Scheme without any extra
libraries (using cl would be unfair):


let s:prototype = {'r': 0.0, 'i': 0.0}

function! C(r, i)
let c = copy(s:prototype)
let c.r = a:r
let c.i = a:i
return c
endf

function! s:prototype.Add(other) dict
let self.r += a:other.r
let self.i += a:other.i
return self
endf

function! s:prototype.ToString() dict
return printf("<%0.2f,%0.2f>", self.r, self.i)
endf

echom C(1.0, 2.0).Add(C(3.2, 4.3)).ToString()

Teemu Likonen

unread,
Feb 18, 2010, 8:17:15 AM2/18/10
to vim use
* 2010-02-18 04:53 (-0800), Tom Link wrote:

> So cl with its vast standard library provides a function for that.
> That's cool of course but nothing stops you from implementing such a
> function in vimscript, perl or whatever.

Now that was a piece of code which is difficult for me. I guess it's now
Vim script's turn to be "unreadable". :-)

> Now let's try to use dictionnaries for prototype-based programming and
> I ask you to do something similar in say Scheme without any extra
> libraries (using cl would be unfair):

I'm a afraid you need to ask someone who understands your code and knows
Scheme.

Teemu Likonen

unread,
Feb 18, 2010, 8:26:51 AM2/18/10
to vim use
* 2010-02-18 14:14 (+0200), Teemu Likonen wrote:

> But really Common-Lispers would write the same functionality with this:
>
> (reduce #'+ '(1 2 3 4))

Or

(apply #'+ '(1 2 3 4))

Ben Schmidt

unread,
Feb 18, 2010, 8:49:42 AM2/18/10
to Teemu Likonen, vim use
> (defun sum (list)
> (loop for item in list
> summing item))
>
> I'm also sure that the last and shortest Common Lisp version is the
> easiest for me.

I must say that it barely counts, though. It's borderline on defining a
sum function using a sum function.

On the whole, I liked the rest of your post, though, and the only other
comment I'll make is that Vimscript has some higher order functions, as
do many other imperative/procedural languages, so although perhaps not
all that common, they're far from rare, though obviously they feature
most strongly in functional, logic and similar languages.

Ben.


Mikołaj Machowski

unread,
Feb 18, 2010, 9:06:07 AM2/18/10
to vim_use, Ben Schmidt, vim use, Bram Moolenaar
Dnia 18-02-2010 o godz. 13:14 Teemu Likonen napisaďż˝(a):

>
> (reduce #'+ '(1 2 3 4))
>

To get sum of table elements you can use this in Vim:

exe 'echo ' join([1,2,3,4], '+')

I know this is not what are you really talking about but I really,
really like this trick :)

m.


Tom Link

unread,
Feb 18, 2010, 10:13:42 AM2/18/10
to vim_use
> Now that was a piece of code which is difficult for me. I guess it's now
> Vim script's turn to be "unreadable". :-)

Well, if you included the definition of reduce in your code, your
example wouldn't be that clean either. It is really pointless to show
off library functions that hide the messy details.

With respect to embedded languages, you should not only compare
language features but also the size of the interpreter + libraries,
for example.

Teemu Likonen

unread,
Feb 18, 2010, 11:30:27 AM2/18/10
to vim use
* 2010-02-18 07:13 (-0800), Tom Link wrote:

> Well, if you included the definition of reduce in your code, your
> example wouldn't be that clean either. It is really pointless to show
> off library functions that hide the messy details.

Hmm, first I'd like to emphasize that I was not trying to say that
REDUCE makes Common Lisp clearer than anybody else. I actually said that
it is more difficult. I only suggested comparison between the loop
examples -- and that's because of similar implementation. I brought
REDUCE only as an example of real-world usage.

About the quoted text above, I think I see your point but I don't
understand what makes REDUCE [1] a library function. Where does the
core/primitive part end and libraries begin? At least in CLISP
implementation REDUCE is defined in C source code so in that sense I do
agree that it hides messy details. On the other hand OR and AND are not
primitive code. They are macros which expand to IF forms. So in
different way OR and AND hide messy details too.

I'm sure you are more experienced and it's me who doesn't understand
this well enough so please help me understand the distinction.

---------------
1. http://www.lispworks.com/documentation/HyperSpec/Body/f_reduce.htm

Antony Scriven

unread,
Feb 18, 2010, 2:59:00 PM2/18/10
to vim...@googlegroups.com
2010/2/18 Mikołaj Machowski <mik...@wp.pl>:

> Dnia 18-02-2010 o godz. 13:14 Teemu Likonen napisał(a):
>
> >
> >     (reduce #'+ '(1 2 3 4))
> >
>
> To get sum of table elements you can use this in Vim:
>
> exe 'echo ' join([1,2,3,4], '+')
>
> I know this is not what are you really talking about but I really,
> really like this trick :)

Actually, they're the same (give or take). :-) --Antony

Antony Scriven

unread,
Feb 18, 2010, 3:19:18 PM2/18/10
to vim...@googlegroups.com
On 18 February 2010 12:53, Tom Link <mica...@gmail.com> wrote:

> > But really Common-Lispers would write the same functionality with this:
> >
> >     (reduce #'+ '(1 2 3 4))

Well that's just (+ 1 2 3 4) :-)

> So cl with its vast standard library provides a function
> for that. That's cool of course but nothing stops you
> from implementing such a function in vimscript, perl or
> whatever.
>
>
> function! Reduce(ffn, list) "{{{3
>    if empty(a:list)
>        return ''
>    else
>        let list = copy(a:list)
>        let s:acc = remove(list, 0)
>        let ffn = substitute(a:ffn, '\<v:acc\>', "s:acc", 'g')
>        for val in list
>            let s:acc = eval(substitute(ffn, '\<v:val\>', val, 'g'))
>        endfor
>        return s:acc
>    endif
> endf
>
>
> echom Reduce("v:val + v:acc", [1, 2, 3, 4])
> echom Reduce("v:val> v:acc ? v:val : v:acc", [1, 2, 3, 4])
> echom Reduce("'v:val' < v:acc ? 'v:val' : v:acc", split("characters",
> '\zs'))

Don't do this with string processing! Much better with funcrefs.

fun Reduce(funcname, list)
let F = function(a:funcname)
let acc = a:list[0]
for value in a:list[1:]
let acc = F(acc, value)
endfor
return acc
endfun

fun Add(a,b)
return a:a + a:b
endfun

fun Max(a,b)
return a:a > a:b ? a:a : a:b
endfun

fun Min(a,b)
return a:a < a:b ? a:a : a:b
endfun

let list = [1,2,3,4,5]
echo Reduce('Add', list)
echo Reduce('Max', list)
echo Reduce('Min', list)

--Antony

Antony Scriven

unread,
Feb 18, 2010, 3:21:50 PM2/18/10
to vim...@googlegroups.com
On 18 February 2010 12:14, Teemu Likonen <tlik...@iki.fi> wrote:

> [...]


>
> Higher-order functions are standard stuff in Lisp but
> probably weird for many people because the the concept is
> not common and the feature of first-class functions is
> not available in many languages. Nevertheless they are

> powerful. [...]

Most comp sci degrees teach functional programming in the
first year now. And don't forget that the world's most
popular programming language includes reduce and other HOFs
as standard. --Antony

Teemu Likonen

unread,
Feb 19, 2010, 1:28:47 AM2/19/10
to vim use

Good. Then perhaps (reduce <function> <sequence>) is also in the
category of easy-to-read. I thought I had found an area in Lisp code
which is difficult to understand quickly but it seems I was at least
partially wrong.

bill lam

unread,
Feb 19, 2010, 2:34:48 AM2/19/10
to vim use
ven, 19 Feb 2010, Teemu Likonen skribis:

It is fairly easy to understand when the function apply to an
argument, try another example to define a higher order function in terms
of purely other functions without explicit appearance of argument.

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Antony Scriven

unread,
Feb 19, 2010, 12:35:30 PM2/19/10
to vim...@googlegroups.com
On 19 February 2010 07:34, bill lam <cbil...@gmail.com> wrote:

> ven, 19 Feb 2010, Teemu Likonen skribis:

> > > [...]


> >
> > Good. Then perhaps (reduce <function> <sequence>) is
> > also in the category of easy-to-read. I thought I had
> > found an area in Lisp code which is difficult to
> > understand quickly but it seems I was at least
> > partially wrong.

Well it's going to depend on an individual's background of
course, but I think this style of programming is quite
prevalent now. It's available in many mainstream languages
and, don't forget, VimL has map() and filter().

> It is fairly easy to understand when the function apply
> to an argument, try another example to define a higher
> order function in terms of purely other functions without
> explicit appearance of argument.

Not 100% sure what you mean here, but writing HOFs shouldn't
be complex. I hope you don't mind me switching to what is
a more familiar language for me.

zipWith = function(fn,list1,list2)
map(function(val) fn(val[0],val[1]), zip(list1,list2));

I'm assuming that map and zip have been defined and that you
know how they work, of course :-). --Antony

bill lam

unread,
Feb 19, 2010, 7:38:01 PM2/19/10
to vim...@googlegroups.com
ven, 19 Feb 2010, Antony Scriven skribis:

> Not 100% sure what you mean here, but writing HOFs shouldn't
> be complex. I hope you don't mind me switching to what is
> a more familiar language for me.
>
> zipWith = function(fn,list1,list2)
> map(function(val) fn(val[0],val[1]), zip(list1,list2));

the list1 and list2 are arguments that I meant to eliminite, that is,
write a zipwith without explicit appearance of list1 and list2.

something like this,
http://en.wikipedia.org/wiki/SKI_combinator_calculus

Antony Scriven

unread,
Feb 19, 2010, 9:05:25 PM2/19/10
to vim...@googlegroups.com
On 20 February 2010 00:38, bill lam <cbil...@gmail.com> wrote:

> ven, 19 Feb 2010, Antony Scriven skribis:
> > Not 100% sure what you mean here, but writing HOFs
> > shouldn't be complex. I hope you don't mind me
> > switching to what is a more familiar language for me.
> >
> >    zipWith = function(fn,list1,list2)
> >        map(function(val) fn(val[0],val[1]), zip(list1,list2));
>
> the list1 and list2 are arguments that I meant to
> eliminite, that is, write a zipwith without explicit
> appearance of list1 and list2.
>
> something like this,
> http://en.wikipedia.org/wiki/SKI_combinator_calculus

Why you'd want to do that is anybody's guess! But if
ECMAScript properly supported currying you could write:

zipWith2 = function(fn)
compose(map(function(val) fn(val[0],val[1])), zip);

I wrote a curry function and faked compose and the above
does work, but you have to invoke it as
zipWith2(fn)(list1,list2), which is ugly but amounts to the
same thing. And now we're waaaay off-topic. --Antony

pansz

unread,
Feb 21, 2010, 11:08:20 PM2/21/10
to vim...@googlegroups.com
Teemu Likonen 写道:
> * 2010-01-24 21:13 (-0800), Peng Yu wrote:
>
>> I know Lisp is very powerful. Is the language in vim as powerful?
>
> No, it's not. It seems that there are still unique features in Lisp
> which are not supported in any other language. In this sense Lisp is the
> most powerful language available. Lisp is really different. I don't know
> many languages but this is what other people say. Other languages have
> gained power by copying Lisp's features.

Most turing-complete languages are equally powerful since you always can
write a compiler/interpreter inside one language to compile/interpret
another.

Or you can doing something equivalent without actually writing an
interpreter.

In my opinion, most languages are not more powerful than C because I can
use C to interpret most languages, so I always use C and embed different
kind of language interpreters inside my C program when required.


But different programmers have different definition about what is
"powerful".

The standard python has so many features in its standard lib. And it has
the benefit of having "the python" as "the standard lib". For example,
if you write a socket application in python you'll be sure it works
anywhere in any platform when python exists.

What about socket for lisp? yes, many lisp distributions provide socket
support but different lisp implementations implement them differently
and that is not the ANSI standard. not having a "standard lib" for "the
standard lisp" cause difficulties for migration.

In this point of view, python, or Java, may be more powerful than most
other languages, because they have the unique standard and the most
comprehensive standard library even to do platform-specific functions.

Well, your mind may vary, because different programmers have different
definition of what is "powerful".

Tony Mechelynck

unread,
Mar 25, 2010, 7:17:44 PM3/25/10
to vim...@googlegroups.com
On 15/02/10 23:33, Ben Schmidt wrote:
[...]
> Vim is essentially an imperative procedural language. Lisp is
> essentially a functional language. Most people find imperative languages
> easier to understand because they're a bit more like recipes and a bit
> less like Mathematics! Some people find the reverse, though.
>
> Lisp is certainly more elegant than Vimscript, which is just a mess,
> with as many exceptions as rules, and different escaping mechanisms
> needed every few lines. If you want to do serious programming, Lisp is
> the way to go. If you want a quick hack, Vimscript is probably easier.
>
> Ben.
>

You know, even in math there are a lot of recipes. Addition,
subtraction, multiplication, long division and rule-of-three I learnt in
grade school; in high school I learnt (in the very first year; my
classmates were aged 12) how to solve a linear problem by algebra; later
came (I don't remember in what sequence) how to compute a derivative, a
determinant, solve linear systems with determinants, solve a quadratic
equation, and much more (also how to compute a square root, but that
wasn't a required subject; I learnt it from the arithmetics book without
even telling the teacher, because it was my kind of fun). All of these
are recipes; even in college math there were a lot of recipes, but I
dropped out of college before graduating (that was in 1969), and became
an analyst-programmer, where I started to _write_ recipes (in the form
of flow charts first, and then translating these flow charts into
program language). The few subjects where there were no recipes were
much harder: I'll mention how to prove a theorem, or how to make a
construction with ruler and compasses (in high school geometry) or how
to solve differential equations (in college calculus): there you had to
guess, then check, proceeding by trial-and-error until -- if you were
lucky -- your guess proved right.

Lisp looks like Volap�k to me; Vimscript I can (more or less)
understand. Of course, the Blob argument invalidates this line of
reasoning, letting it even appear that "therefore" (which I challenge as
"the argument of obscurity") Lisp would be "more powerful" than
vimscript. What is "serious" programming anyway? AFAICT, the collection
of Vim plugins run the whole gamut from the most serious to the most
fun; but of course, for heavy number-crunching, vimscript has the same
performance liabilities as most interpreted languages -- maybe not
really all of them: so perhaps I could say that for serious programming,
FORTH is the way to go? ;-)

And BTW, (in answer to another post) how to compute an arbitrary sum (of
zero or more terms)? IIRC (it was several decades ago):

0
1 + 2 + 3 + 4 +
PRINT
----> 10

Simple isn't it? (And the 0 can be left out if you also omit the first
+) By the time you've finished entering the data, you have the result. :-P


Best regards,
Tony.
--
Iles's Law:
There is always an easier way to do it. When looking directly
at the easy way, especially for long periods, you will not see it.
Neither will Iles.

Tony Mechelynck

unread,
Mar 25, 2010, 7:39:54 PM3/25/10
to vim...@googlegroups.com, Kazuo Teramoto
On 17/02/10 23:10, Kazuo Teramoto wrote:
> On Wed, Feb 17, 2010 at 4:29 PM, Vincent Arnoux
> <vincent...@gmail.com> wrote:
>> I am sorry I was not clear enough... By "ship it with vim", I actually
>> meant bundle the (Python|Lisp|Perl|Ruby|Whatever) interpreter with vim
>>
>
> I really really really (for i in {1..100}; echo really) wish that
> nobody ever listen to your idea... ("Mom, I bought a shoe with socks
> attached to it!")

Oh, you mean moccassins?

>
> What about a read: http://en.wikipedia.org/wiki/Unix_philosophy
>
> And if my wish fail, I vote for having openoffice bundled in vim, so I
> can use macros!
>
> Or bundle a full OS on it, so we dont reinvent the wheel too... Ops,
> sorry Emacs already did that, ohhh dammit, too slow... :(
>
> ^____^
>
> Kazuo.
>
> PS. This is a humorous email, only laugh dont be mad please XD.
>

:-)

Best regards,
Tony.
--
Happiness, n.:
An agreeable sensation arising from contemplating the misery of
another.
-- Ambrose Bierce, "The Devil's Dictionary"

Antony Scriven

unread,
Mar 25, 2010, 8:45:39 PM3/25/10
to vim...@googlegroups.com
On 25 March 2010 23:17, Tony Mechelynck wrote:

> On 15/02/10 23:33, Ben Schmidt wrote:
> [...]
> >
> > Vim is essentially an imperative procedural language.
> > Lisp is essentially a functional language. Most people
> > find imperative languages easier to understand because
> > they're a bit more like recipes and a bit less like
> > Mathematics! Some people find the reverse, though.
> >
> > Lisp is certainly more elegant than Vimscript, which is
> > just a mess, with as many exceptions as rules, and
> > different escaping mechanisms needed every few lines.
> > If you want to do serious programming, Lisp is the way
> > to go. If you want a quick hack, Vimscript is probably
> > easier.

Depends on the hack. Vimscript is a domain-specific
language, so for quick hacks on text files, yeah.

> [...] (also how to compute a square root, but that wasn't


> a required subject; I learnt it from the arithmetics book
> without even telling the teacher, because it was my kind

> of fun). [...]
>
> Lisp looks like Volapük to me;

Then check out the SICP lectures. The videos are online for
free. The first one teaches you the basics of Lisp (well,
Scheme) in a few minutes, and it (or maybe the second one,
I can't remember) shows you how to compute a square root
:-). It really is a wonderful language.

> Vimscript I can (more or less) understand. Of course, the
> Blob argument invalidates this line of reasoning, letting
> it even appear that "therefore" (which I challenge as
> "the argument of obscurity") Lisp would be "more
> powerful" than vimscript. What is "serious" programming
> anyway?

Not having to prefix function parameters with `a:'! :-)

> AFAICT, the collection of Vim plugins run the whole gamut
> from the most serious to the most fun; but of course, for
> heavy number-crunching, vimscript has the same
> performance liabilities as most interpreted languages --
> maybe not really all of them: so perhaps I could say that
> for serious programming, FORTH is the way to go? ;-)

Not sure what you're saying here.

> And BTW, (in answer to another post) how to compute an
> arbitrary sum (of zero or more terms)? IIRC (it was
> several decades ago):
>
> 0
> 1 + 2 + 3 + 4 +
> PRINT
> ----> 10
>
> Simple isn't it? (And the 0 can be left out if you also
> omit the first +) By the time you've finished entering
> the data, you have the result. :-P

Now put your HP calculator away. :-) --Antony

Tony Mechelynck

unread,
Mar 25, 2010, 10:21:29 PM3/25/10
to vim...@googlegroups.com, Antony Scriven
On 26/03/10 01:45, Antony Scriven wrote:
> On 25 March 2010 23:17, Tony Mechelynck wrote:
[...]

> > AFAICT, the collection of Vim plugins run the whole gamut
> > from the most serious to the most fun; but of course, for
> > heavy number-crunching, vimscript has the same
> > performance liabilities as most interpreted languages --
> > maybe not really all of them: so perhaps I could say that
> > for serious programming, FORTH is the way to go? ;-)
>
> Not sure what you're saying here.

I was saying that FORTH is fast ("good for number crunching") even when
interpreted. And in answer to something said in a later post to the one
to which I was replying here, it is practically infinitely extensible.

>
> > And BTW, (in answer to another post) how to compute an
> > arbitrary sum (of zero or more terms)? IIRC (it was
> > several decades ago):
> >
> > 0
> > 1 + 2 + 3 + 4 +
> > PRINT

Instead of PRINT I should have written . (a full stop, which in Forth I
read "print").

> > ----> 10
> >
> > Simple isn't it? (And the 0 can be left out if you also
> > omit the first +) By the time you've finished entering
> > the data, you have the result. :-P
>
> Now put your HP calculator away. :-) --Antony
>

It wasn't an HP calculator, it was (I think) a simple example of FORTH,
though it doesn't do justice to the language. I doubt Lisp is more
powerful; I suppose it might be *as* powerful and I'm not sure about
speed -- oh well, let's give it the benefit of the doubt until I study it.

I suppose you confused FORTH with HP calculator programming because both
are based on postfixed Łukasiewicz notation.


Best regards,
Tony.
--
Genius may have its limitations, but stupidity is not thus
handicapped.
-- Elbert Hubbard

Teemu Likonen

unread,
Mar 26, 2010, 3:14:07 PM3/26/10
to vim use
* 2010-03-26 00:45 (UTC), Antony Scriven wrote:

> On 25 March 2010 23:17, Tony Mechelynck wrote:

>> Lisp looks like Volap�k to me;


>
> Then check out the SICP lectures. The videos are online for free. The
> first one teaches you the basics of Lisp (well, Scheme) in a few
> minutes, and it (or maybe the second one, I can't remember) shows you
> how to compute a square root :-). It really is a wonderful language.

Peter Seibel's "Practical Common Lisp" is a very good introduction and a
beginner's guide to Common Lisp. It's available online:

http://www.gigamonkeys.com/book/

Teemu Likonen

unread,
Mar 28, 2010, 4:25:51 AM3/28/10
to vim use
* 2010-03-26 03:21 (+0100), Tony Mechelynck wrote:

> [...] it was (I think) a simple example of FORTH, though it doesn't do


> justice to the language. I doubt Lisp is more powerful; I suppose it
> might be *as* powerful and I'm not sure about speed -- oh well, let's
> give it the benefit of the doubt until I study it.

A short introduction to Common Lisp's features ("power" meaning powerful
features):

http://abhishek.geek.nz/docs/features-of-common-lisp

A performance comparison of language implementations ("power" meaning
computational power):

http://dan.corlan.net/bench.html

I did the same performance test (the single-body version) with GCC 4.4.3
(a C compiler), GForth 0.7.0, SBCL 1.0.31 (a Common Lisp implementation)
and Python 2.5.5 (interpreted). My system is a 32-bit AMD Sempron 3000+.

GCC 0.47 seconds (the hand-optimized version)
SBCL 0.67 seconds (with DECLARE and THE expressions)
GForth 3.8 seconds (the hand-optimized version)
SBCL 9.5 seconds (without DECLARE and THE expressions)
Python 35 seconds

(Common Lisp has dynamic typing by default but programmer can use
DECLARE and THE expressions to give hints to the compiler about
variables' type. They help optimizing the compiled code.)

DISCLAIMER: My tests may suck so I suggest everyone do better ones. :-)

Antony Scriven

unread,
Mar 29, 2010, 4:01:22 PM3/29/10
to vim...@googlegroups.com
On 28 March 2010 09:25, Teemu Likonen <tlik...@iki.fi> wrote:

> [...]
>


>    GCC         0.47 seconds    (the hand-optimized version)
>    SBCL        0.67 seconds    (with DECLARE and THE expressions)
>    GForth      3.8 seconds     (the hand-optimized version)
>    SBCL        9.5 seconds     (without DECLARE and THE expressions)
>    Python      35 seconds
>
> (Common Lisp has dynamic typing by default but programmer
> can use DECLARE and THE expressions to give hints to the
> compiler about variables' type. They help optimizing the
> compiled code.)
>
> DISCLAIMER: My tests may suck so I suggest everyone do
> better ones. :-)

:-). Well I think I should mention that GForth is VM based,
or it was last I looked. A fast commercial Forth is probably
pretty close to the optimised SBCL. --Antony

Teemu Likonen

unread,
Mar 30, 2010, 9:08:41 AM3/30/10
to vim use
* 2010-03-29 21:01 (+0100), Antony Scriven wrote:

> On 28 March 2010 09:25, Teemu Likonen <tlik...@iki.fi> wrote:
>> DISCLAIMER: My tests may suck so I suggest everyone do better ones.
>> :-)
>
> :-). Well I think I should mention that GForth is VM based, or it was
> last I looked.

More accurately GForth uses GCC to compile direct or indirect threaded
code.

> A fast commercial Forth is probably pretty close to the optimised
> SBCL.

Yes, that's very likely. Here's an old comparison between Forth systems:

http://www.complang.tuwien.ac.at/forth/performance.html

GForth seems to be the fastest of those which do not produce pure native
code.

Yasuhiro MATSUMOTO

unread,
Sep 16, 2013, 11:05:07 PM9/16/13
to vim...@googlegroups.com
Or How about this?

https://github.com/mattn/lisper-vim

#Sorry_It_is_my_joke

John Little

unread,
Sep 18, 2013, 3:33:54 AM9/18/13
to vim...@googlegroups.com
On Wednesday, January 27, 2010 5:48:47 PM UTC+13, pansz wrote:
> In theory, a turing complete language could do anything.

brainfuck (see http://en.wikipedia.org/wiki/Brainfuck) is Turing complete...

Regards, John Little

Reply all
Reply to author
Forward
0 new messages