> Example 1 has 2 LOC. Example 2 has 1 LOC. Does this mean C 'wins' here?
Yes, exactly. But the C isn't in my natural style.
The problem with Lisp and Scheme is that I am a total newbie and have no idea how Lisp code is normally formatted. C++ and OCaml I know. SML I thought I knew but had a big debate on c.l.functional about it. And I assumed that Java = C++ for formatting.
>> Is Lisp code not made less maintainable because of all those brackets?
> No. It is *more* maintainable. I am new (a few months) to CL, and I can > fix my code faster* than with C (seven years).
Sure. I am in the same situation with C++ and OCaml. But I want to know how ML and Lisp compare. Syntax is clearly one of the major differences between Lisp and ML.
> Difficult to explain really, but I get a visceral sense of 'stack pop' as > I type the closing parens.
Interesting. :-)
> This is probably due to Emacs highlighting each open-paren that my typed > close-paren balances.
Yep. That's a real life saver.
> My thinking goes "erm-close-squre-bracket erm-close-paren erm-semicolon" > instead of "done-done-done"
> Of course, it would be absurd to suggest that C code is less maintainable > because of all that _syntax_... Wouldn't it? :-)
No, not at all. Both sides of the argument have valid justifications, IMHO.
> * This is a lie: sometimes I just stare at it for hours, because I am > still > adjusting to the CL way of thinking. But this happens less and less > often. If I compare with the transition from C++ to C# (the most recent > addition, I guess), I am winning *big time* with Common Lisp.
> JH>> However, LOC overly penalises Lisp and Scheme, IMHO. Specifically, Lisp > and > JH>> Scheme programs are virtually unreadable unless the parentheses are > JH>> staggered by spreading expressions over several lines and using an > JH>> automatic indenter. So if I were to put a Lisp implementation of the > ray > JH>> tracer on my site then I'd either state that, or I'd give results using > JH>> some other measure of verbosity, like characters.
> Hmm. What would you (JH) be measuring here?
> a) Keystrokes required to produce the code (see below, though) > b) Some kind of 'intrinsic verbosity', which would require some *serious* > thinking about idiomaticity, relevance of formatting and massive, massive > sampling to make it statistically relevant.
>>i doubt lisp or scheme will gain anything there: the language defined >>words tend to be quite lengthy, and afaict that seems to encourage >>programmers to use pretty length identifiers for their own identifiers,
> Yes
>>so character count might penalize lisp even worse. otoh, the lengthy >>identifiers make lisp code quite easy to read and understand.
> Yes, and using a decent editor with auto-completion (Emacs) means that I hit > less keys to produce the token 'DESTRUCTURING-BIND' ( DE-B <META-TAB> ) than > you might think.
> Oh, and all the ')))))' you see probably didn't get typed by hand ( > <META-RET> closes all open parens).
>>token count probably would be better
> Yep, although (because I am biased) I would like to see > 'keystroke/mouse-click' count instead. I think that with the requirement > for idiomatic variable naming, CL might not come out as 'verbose' as you > think...
i was considering pointing out that most lisp development environments have features that would reduce the amount of keystrokes required to type in the program, but decided against it because i suspect that that is harder to measure than a token count
Jon Harrop <use...@jdh30.plus.com> writes: > Additionally (pun intended), we were all taught operator precedences in > conventional mathematics at a very young age. It seems at best odd and at > worst stupid to disregard this.
In mathematics, there are two precedence levels ({+,-} vs. {*,/} (and even, division is usually written as an horizontal bar, that is essentially just a big parenthesis). In C there are 28 levels. Do you know a lot of C programmer who know the exact precendence levels of each of C operators? I knew those of Wirth's Pascal, but never those of C: it was easier to use a lot of parentheses in C.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we. -- Georges W. Bush
Jon Harrop wrote: > Additionally (pun intended), we were all taught operator precedences in > conventional mathematics at a very young age. It seems at best odd and at > worst stupid to disregard this.
I hope there's little disregarding or idiocy going on. Many Lisp users use other languages regularly, so it's understandably hard for Lisp's unusual syntax to be lost on them.
I recall that early programming languages were designed to save money (increase programmer supply) by opening the door to less skilled programmers. A natural way to attempt this is by offering them an interface similar to what they've already encountered in school. Like highschool math notation, for instance.
But what happens when we stray from highschool textbook Fibonacci implementations? Some languages look great for solving Tower of Hanoi, but not so enviable in other domains. This is why people look towards "domain specific languages," and Lisp creeps into the conversation.
Now despite all this, Lisp DOES respect other traditions. Observe LOOP, which is like every for(;;) loop in every language rolled into one. Dirty and rewarding, the sort of thing which probably makes Haskellers and MLers scream indignantly. Also, there are infix parsers and whatnot floating around the net, for when conventional syntax is appropriate.
> > It seems likely to me that languages that require complex parsers are > > harder for humans to understand as well.
> There is unquestionably a huge amount of evidence to the contrary. Most > natural and programming languages have complicated grammars precisely > because it simplifies their use and makes them easier to understand.
Would you please point us to evidence in this direction?
Jon Harrop wrote: > Joe Marshall wrote: > > Is readability simply a subjective measure, then? If so, and if > > maintainability is about how easily a human can parse it, then > > maintainability is also a subjective measure (and not particularly > > interesting for comparing computer languages).
> Yes. Readability and maintainability are inherently subjective. However, > they are both very important when comparing computer languages.
Writing honest language vs. language benchmarks is notoriously full of landmines. Comparing readability sounds like its own Iraq.
Lisp is different, there's no question about that. It may be outflanked in specific areas; and today's Common Lisp is simply one little milestone in its evolution. Once, it was believed that an M-expression syntax would replace the current S-expressions, but many liked sexps. In the future, and given enough funding, we can wishfully predict human interface improvements where IDEs project Lisp code in some conventional way to the user, just as webpages don't look like HTML markup.
Or perhaps sexps lead the way to a more sensible syntax than the weaker one which mathematicians developed. Many claim that Newton's calculus notation is less flexible than Leibniz's, and no doubt various number systems have varying disadvantages. Perhaps Fermat's margin wouldn't have been a problem if he had Lisp macros.
Tayssir John Gabbour wrote: > Jon Harrop wrote: >> Additionally (pun intended), we were all taught operator precedences in >> conventional mathematics at a very young age. It seems at best odd and at >> worst stupid to disregard this.
> I hope there's little disregarding or idiocy going on. Many Lisp users > use other languages regularly, so it's understandably hard for Lisp's > unusual syntax to be lost on them.
Yes. This brings me to my next question: what other FPLs do Lispers know?
> Now despite all this, Lisp DOES respect other traditions. Observe LOOP, > which is like every for(;;) loop in every language rolled into one. > Dirty and rewarding, the sort of thing which probably makes Haskellers > and MLers scream indignantly.
Not really. OCaml has (more restricted) for loops and both SML and OCaml can implement customised for loops.
> Also, there are infix parsers and whatnot > floating around the net, for when conventional syntax is appropriate.
I heard that infix parsers are rarely used not because infix is worse but because infix is unusual in Lisp code and increases incompatibility. Would you agree with that?
>> There is unquestionably a huge amount of evidence to the contrary. Most >> natural and programming languages have complicated grammars precisely >> because it simplifies their use and makes them easier to understand.
> Would you please point us to evidence in this direction?
Firstly, do you agree that languages are evolving to be more concise? Secondly, do you agree that more concise languages tend to have more complicated grammars? Finally, what other reason could drive this association?
I believe that languages are evolving to be more concise and to have more complicated grammars. I can see no reason for complicating grammars unless it aids brevity/elegance/comprehensibility. So I see the evolution of natural and programming languages as a huge amount of evidence that complicated grammars are used to simplify the use of languages.
IMHO, humans are very good at deciphering expressions written in complicated grammars, and this is why we make things easier for ourselves by complicating grammars. In particular, we are better at understanding many short expressions written in the context of a complicated grammar, rather than many long expressions written with a very simple grammar.
>> Yes. Readability and maintainability are inherently subjective. However, >> they are both very important when comparing computer languages.
> Writing honest language vs. language benchmarks is notoriously full of > landmines. Comparing readability sounds like its own Iraq.
Yes, absolutely.
> Lisp is different, there's no question about that. It may be outflanked > in specific areas; and today's Common Lisp is simply one little > milestone in its evolution. Once, it was believed that an M-expression > syntax would replace the current S-expressions, but many liked sexps. > In the future, and given enough funding, we can wishfully predict human > interface improvements where IDEs project Lisp code in some > conventional way to the user, just as webpages don't look like HTML > markup.
Several people have now mentioned IDEs and I think that is something that I have ignored until now and should probably spend some time on...
> Or perhaps sexps lead the way to a more sensible syntax than the weaker > one which mathematicians developed. Many claim that Newton's calculus > notation is less flexible than Leibniz's, and no doubt various number > systems have varying disadvantages. Perhaps Fermat's margin wouldn't > have been a problem if he had Lisp macros.
> > This is not production-quality maintainable lisp code, because it > > ignores the conventions that have developed and are supported by the > > tools. However, if I take your mangled example, place it in a lisp > > buffer and ask my editor to reformat it (C-M-q in emacs, for > > instance), I get
> > and the code obeys more of the conventions: it is much easier to read.
> Can I just clarify - the only difference is the constant indentation on the > lines after defun? Unless I'm missing something, I can't see how this makes > it much easier to read.
It actually does, because of convention. The alignment of the body of the function is more "natural" to an experienced lisp programmer.
Seeing the function body closer to the left edge makes a difference, precisely because one gets used to reading the whitespace/indentation instead of counting the parentheses.
Actually, my preferred format for that example would use one additional line:
(defun fib (x) (if (<= x 2) 1 (+ (fib (- x 2)) (fib (1- x)))))
and thus more clearly allows quick identification of the two arguments to the + function.
> Surely if your constructs require ((...)) then you must count brackets to > ensure that there are two sets of nested brackets?
Only at the beginning. At the end, your Lisp-aware editor kindly matches the parentheses for you. It is, in fact, the same with C-style languages where you have all of those {} pairs to match up when you combine loops, conditionals and function bodies. But in some ways it gets a bit harder BECAUSE of the separate line convention, since it is more likely that the matching part is off screen.
-- Thomas A. Russ, USC/Information Sciences Institute
Jon Harrop wrote: > Tayssir John Gabbour wrote: > > Now despite all this, Lisp DOES respect other traditions. Observe LOOP, > > which is like every for(;;) loop in every language rolled into one. > > Dirty and rewarding, the sort of thing which probably makes Haskellers > > and MLers scream indignantly.
> Not really. OCaml has (more restricted) for loops and both SML and OCaml can > implement customised for loops.
If this is true, MLers may be more mature (or some might say twisted) than many Lisp users, as LOOP is offensive to a percentage of Lisp users for being "unlispy." Maybe too hedonistic. ;)
I think comparing LOOP to a for-loop is like comparing [insert apt mountain vs. molehill comparison here]. I like it a lot though.
> > Also, there are infix parsers and whatnot > > floating around the net, for when conventional syntax is appropriate.
> I heard that infix parsers are rarely used not because infix is worse but > because infix is unusual in Lisp code and increases incompatibility. Would > you agree with that?
Well, almost every domain-specific language is unusual. But Lisp invites people to craft such languages when appropriate for readability and maintenance.
For example, times and dates don't look "lispy" (8:34 at 8-2-2005, or RFC 2445's 19980118T230000), but I have "read-macros" which allow me to use this unusual syntax in sourcecode when performing datetime calculations.
> >> There is unquestionably a huge amount of evidence to the contrary. Most > >> natural and programming languages have complicated grammars precisely > >> because it simplifies their use and makes them easier to understand.
> > Would you please point us to evidence in this direction?
> Firstly, do you agree that languages are evolving to be more concise? > Secondly, do you agree that more concise languages tend to have more > complicated grammars? Finally, what other reason could drive this > association?
I feel I'm expected to be in some role debating you (maybe a weird spidey-sense left over from debate team), but I'm genuinely interested in the evidence you mentioned. So I'm still curious what evidence there exists, and don't feel suited to analytical debates.
That said, there are examples of languages designed both towards and away from syntactic concision.
APL/J/K seem to beautifully use concision. If Alan Kay is to be believed, one screen or so essentially holds short-term memory, and concise languages certainly help here. (I hope I'm not butchering his point.) http://www.archive.org/details/AlanKeyD1987_2
On the other end of the scale, I recall natural languages are quite verbose, relative to information content. Java is also quite verbose, more than I like, but it seems to be very popular...
Lisp is a bit tricky to place on this spectrum, since it contains uncommon abstraction tools like macros and whatnot. Many people (I think convincingly) point out that many of Lisp's features don't make much sense in small codebases; they spread their wings in large ones. So there are different paths to judging concision.
Pascal Bourguignon wrote: > Jon Harrop <use...@jdh30.plus.com> writes:
>>Additionally (pun intended), we were all taught operator precedences in >>conventional mathematics at a very young age. It seems at best odd and at >>worst stupid to disregard this.
> In mathematics, there are two precedence levels ({+,-} vs. {*,/} (and > even, division is usually written as an horizontal bar, that is > essentially just a big parenthesis). In C there are 28 levels. Do you > know a lot of C programmer who know the exact precendence levels of > each of C operators? I knew those of Wirth's Pascal, but never those > of C: it was easier to use a lot of parentheses in C.
C's precedence is easy! Just remember:
C's precedence does exactly what you want. Except when it doesn't.
Peter Seibel wrote: > ... > P.S. Which is not to say that the mental effort of dealing with > precedence rules is overwhelming
i am not so sure about that. sure, as long as you have only a few operators and only a few precedence levels, it's fine. but you only have to look at typical C code to see that quite a few programmers feel uncertain about C's precedence rules. you very often see unnecessary parentheses. i am not quite sure whether it is because the writers feel uncertain about the precedence rules or whether they fear that later maintainers are overwhelmed
