> 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
>>3. In a place (a fearful place :) ) that doesn't have emacs all is not >>lost. If lisp can read the code it can print it. So, I can quote the >>list with a quote mark*, and watch it:
>>'((defun fib (x) (if (<= x 2) 1 (+ (fib (- x 2))(fib (1- x)))))
>>It will then spit it back with whatever default formatting the lisp >>printer uses for lists (there may also be an option for printing >>functions in the printer). The formatting may not be very nice, but if >>the code is truely hairy it will be more understandable than it was. >>You can use this sort of this to do things like substituting sub-trees >>in your code.
> Right, I saw that in Sussman's lecture (IIRC).
>>(* quote marks are one of the few true bits of syntax)
Not quite. Common Lisp has a feature called "reader macros" that allow you to execute arbitrary parsing code when a specific character is hit. Assuming I had some other way to give the Lisp environment syntax trees, left parenthesis (, right parenthesis ), quote ', double-quote " and nearly all other syntax could be defined in Lisp. See SET-MACRO-CHARACTER.
The only thing that can't be defined is the core reader algorithm as described in <http://www.lisp.org/HyperSpec/Body/sec_2-2.html>, which parses symbols and numbers. Also possibly : and :: for naming symbols in other packages.
> Yes, "#" and ";" seem to be others. I don't know what "#" does.
# is a dispatching macro character that executes different parsing code depending on the next non-numeric character. See SET-DISPATCH-MACRO-CHARACTER. Some dispatching macro characters are:
#( for reading arrays, as in #(1 2 3) #\ for reading characters, as in #\a #< for signaling an error, as in #<FUNCTION CAR>
>>4. It makes macros easier to understand since they act on trees.
> So you predict that Lisp macros are easier to understand than OCaml's > macros?
Is this a fair comparison? Can OCaml's macros do the same things Lisp's macros can do? All the Lisp looping operations can be implemented as macros on top of if, tagbody, and goto. CLOS can be implemented entirely in CLOS-free Lisp using macros and functions. I don't know of any other language that has macros this powerful.
I can't imagine anyone having any more difficulty learning Lisp's DO than they would learning C's for. Nor finding DEFUN or DEFSTRUCT or DEFCLASS any more complicated than their equivalents in other languages. I find IF a bit irritating because you have to just remember that the first parameter is the test, the second is the "then" and the third is the "otherwise", but it's easy enough to make your own macro that fixes that:
(defmacro if+ (test &key then else) (list 'if test then else))
>>All of the above describes benefits in automatic formatting, not >>readability. >>Some people find it readable, some don't. I personally don't find it >>very easy or very difficult. There are a number of tricks to reading >>it and writing it.
> I'm finding prefix notation readable but overly verbose. Counting > parentheses is a real pain though. Assuming the Lisp advocates here also > know conventional languages then there is plenty of evidence that one can > learn to read Lisp.
Only for math or for all operations? It would be quite neat to have a language that allowed me to say:
if( a collidesWith b ) then bounce a offOf b
but would that be significantly better than the equivalent Lisp? I don't think so.
I find it funny that people constantly want infix, but only for mathematical operations. Even in the most mathematical intensive code I wrote, a general CSG library, I found that very few operations I did were supported by the built-in mathematical syntax.
However, if you feel you *must* have infix for some arbitrary set of mathematical operations, you can always write your own parser in Lisp, and then use macro characters to read it in. See <http://www.cliki.net/infix> for one such parser.
>>The easiest way to find out is to delete all the closing parens at the >>end with Emacs. You then replace them one by one, the cursor will >>highlight the opening paren as this happens. You can then watch them >>and check they go in the right places. Once you've finished closing >>the parens on the line you're on, the rest should match on the lines >>above to each left-most paren.
> Yes. That is almost exactly what I am doing.
Yuck. I suggest you find an editor that can auto indent Lisp code, like Emacs can. It is so much easier to find mismatched braces when the code is indented.
It's hard for me to describe what I enjoy so much about writing Lisp code. The best I can say is that Lisp is the first language I've used where every thing that should be simple to code up was actually simple to code up. For sure, closures, macros, and a simple (but extendable) syntax all help.
Jon Harrop <use...@jdh30.plus.com> writes: > Firstly, do you agree that languages are evolving to be more concise?
No. Hebrew is more concise than English. Even Latin is more concise.
> Secondly, do you agree that more concise languages tend to have more > complicated grammars?
Yes, somewhat.
> Finally, what other reason could drive this > association?
Mu.
> 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.
If that was true, you'd still be speaking Latin, or even some older language.
$ wc <<EOF Our Father, Who art in heaven, Hallowed be Thy Name. Thy Kingdom come. Thy Will be done, on earth as it is in Heaven. Give us this day our daily bread. And forgive us our trespasses, as we forgive those who trespass against us. And lead us not into temptation, but deliver us from evil. Amen. EOF 9 56 294
$ wc <<EOF Pater noster qui est in caelis, sanctificetur nomen tuum; adveniat regnum tuum; fiat voluntas tua, sicut in caelo et in terra. Panem nostrum cotidianum da nobis hodie, et dimitte nobis debita nostra, sicut et nos dimittimus debitoribus nostris; et ne nos inducas in tentationem Sed libera nos a malo. Amen EOF 9 50 306
English seems to be 11% less concise than Latin (in word count; it probably would be in character count too if it had a more phonetic orthography). Let's switch to Latin!
> 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.
Jon Harrop wrote: > ... > There is unquestionably a huge amount of evidence to the contrary.
i have my doubts
> Most > natural and programming languages have complicated grammars precisely > because it simplifies their use and makes them easier to understand.
if you believe chomsky, the human brain is hardwired for a certain style of grammar (at least that's what i read somewhere), so natural languages probably have a syntax that goes along with with this hardwiring. it might be complicated to describe formally, but isn't for people's everyday needs. if you go beyond that, things begin to look different. the mathematical notation (also a kind of syntax) was developed because natural language is woefully inadequate to describe mathematical problems without support of a more concise notation
> Additionally (pun intended), we were all taught operator precedences in > conventional mathematics at a very young age.
as far as i know, lukasiewicz invented the polish notation long before computers were invented (according to wikipedia in 1920). i couldn't fins anything about his motivation, but wouldn't be surprised that it had something to do with problems with the conventional notation once you begin to add operators and precedence levels
> It seems at best odd and at > worst stupid to disregard this.
that would depend on whether the conventional notation approaches its limitations or not
Pascal Bourguignon <s...@mouse-potato.com> writes: > Jon Harrop <use...@jdh30.plus.com> writes: > > Firstly, do you agree that languages are evolving to be more concise?
> No. Hebrew is more concise than English. Even Latin is more concise.
Right. B: in 'a (ha if in isolation): the cheder : room
> as far as i know, lukasiewicz invented the polish notation long before > computers were invented (according to wikipedia in 1920). i couldn't > fins anything about his motivation
He appears to have been working on multivalued logics and wanted to avoid parentheses.
Jon Harrop <use...@jdh30.plus.com> writes: > Christophe Rhodes wrote: >> Jon Harrop <use...@jdh30.plus.com> writes: >> Did you read just the first half of my sentence? Human programmers do >> not read the brackets, but instead read the indentation.
> If every bracket in Lisp were indented separately (i.e. on a separate line), > as braces are typically in C/C++/Java then I would agree. However, they are > not. In this case you have 12 brackets nested 3 levels deep on a single > line, where indentation cannot help.
The line (+ (fib (- x 2)) (fib (1- x))) is approximately maximally complex in terms of nesting: any more would definitely be frowned upon, and indeed I would prefer to see (+ (fib (- x 2)) (fib (1- x))) even in such "simple" cases.
>> If you are counting or reading brackets manually when writing lisp >> code, you are doing something wrong.
> Surely if your constructs require ((...)) then you must count brackets to > ensure that there are two sets of nested brackets?
You must trivially count opening parens as you type them, yes. You will never have to count closing parens: if you are composing this code, your editor will tell you what paren you have just closed; if you are editing this code later, the wrong number of closing parens will announce itself by the indentation of the rest of the code being wrong.
Jon Harrop <use...@jdh30.plus.com> wrote: >(defun fib (x) > (if (<= x 2) > 1 > (+ (fib (- x 2))(fib (1- x)))))
>In ML this is: >let fib x = if x<=2 then 1 else fib(x-2) + fib(x-1)
>That may be easier to parse for the machine (I don't think it is though) but >maintainability is about how easily a human can parse it.
Lisp simply trades in human readability for macros; you decide whether it's worth it. Some people argue that s-exps are actually more readable (well, I guess if you see nothing else for years or even decades, that might actually be true at some time) whereas others prefer to have compilers generate the parse trees for them. However, you lose the power of macrology in the latter case. Then again, while macros are certainly cool, I've never felt the need for them when writing SML programs... I don't know why, but maybe it's because the syntax is already there.
Jon Harrop <use...@jdh30.plus.com> wrote: >Ok. Can you give an example of a time when emacs has to guess?
Have you never tried to use Emacs with C, C++, Standard ML, awk, perl, sh, ksh, Pascal, or actually any language other than (Emacs-) Lisp? It can be a rather frustrating experience, especially since the editor insists on knowing better than you, and sometimes even "correcting" indentation even if you don't hit TAB.
Pascal Bourguignon <s...@mouse-potato.com> wrote: >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.
Plus, part of the precedence is erratic, as even BWK admits. On *BSD, theres an operator(7) manpage, which is very handy for cases when you're puzzling about precedence.
> 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.
Indeed. I think probably this statement is the problem I have with the 'shootout'.
If your comparison was telling me:
* For low-level hardware access - ASM, C,... * ... * For high-level nondeterministic programming: Prolog,Lisp,...
>> * 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.
> Should be able to chop a few characters off of that...
Yes, but I was trying to lose in every way that matters (# tokens, # characters, amount of syntax, etc), and win in the one way that makes no odds (# LOC).
JB>> Yes, and using a decent editor with auto-completion (Emacs) means that I hit JB>> less keys to produce the token 'DESTRUCTURING-BIND' ( DE-B <META-TAB> ) than JB>> you might think.
[snip]
> 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
It undoubtedly is, but I would find it _very_ interesting to compare the following environments in this way:
Common Lisp + Emacs + SLIME Java + Eclipse C# + Visual Studio.NET C++ + Visual Studio 6
Perhaps it is more-or-less meaningless to compare the language alone without a good development tool?
For instance, although I could write C# in Notepad, I wouldn't want to.
>>Ok. Can you give an example of a time when emacs has to guess?
> Have you never tried to use Emacs with C, C++, Standard ML, awk, > perl, sh, ksh, Pascal, or actually any language other than (Emacs-) > Lisp? It can be a rather frustrating experience, especially since > the editor insists on knowing better than you, and sometimes even > "correcting" indentation even if you don't hit TAB.
> again, while macros are certainly cool, I've never felt the need > for them when writing SML programs... I don't know why, but maybe > it's because the syntax is already there.
I missed them the other day. For each of the base types Int8.int, Int16.int, Int32.int, Int64.int, Real32.real, Real64.real, Word8.word, Word16.word, Word32.word, and Word64.word I had to for each of the constructors ref, vector and array to define three functions (one to register a, say, Int8.int vector with the garbage collector, one to look up a previously registered vector/array/reference cell, and one to unregister a root), which subsequently were to be exported by the FFI. In total I needed to define and export 90 functions.
I bailed out and write a Scheme programme that generated the functions, but if SML had macros that wouldn't have been neccessary.
> (defun fib (x) > (if (<= x 2) > 1 > (+ (fib (- x 2))(fib (1- x)))))
> In ML this is:
> let fib x = if x<=2 then 1 else fib(x-2) + fib(x-1)
The first one is easier to read.
I noticed in your code snippets (not only here) that you are sometimes after very packed code structures. Your programming style of one-liners is maybe good for writing down quickly code in an afternoon. However, are you sure that one liners are predistend for re-using code in the long run?
|
