* 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".
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
