Why Java (& Python) Programmers Should Learn newLISP

[xytroxon]

I found this humorously titled Python article:
“Why Python Programmers Should Learn Python”

Referencing this Java article:
“Why Java Programmers Should Learn Python”

Posing this trivial programming problem:

Given the supplied library classes write some code in “quickSilver” to convert between word and decimal digits representations of positive integers less than 1001.

e.g. “five seven three” → 573

e.g. 672 → “six seven two”

The "Quicksilver Model Solution" presented to Java programmers was actually this (surprise!) Python code:

Code: Select all

class WordsFromNumber:
    def __init__(self,number):
        self.representationOf = number
    def wordsOf(self):
        lsd = self.representationOf % 10
        msds = self.representationOf / 10
        if msds == 0:
            return self.wordFor(self.representationOf)
        else:
            return WordsFromNumber(msds).wordsOf() + " " + \
                   self.wordFor(lsd)

def wordFor(self,numeral):
        return ["zero", "one", "two", "three", "four",
                "five", "six", "seven", "eight", "nine"][numeral]

class NumberFromWords:
    def __init__(self,words):
        self.representation = words
    def number(self):
        words =  split("\\s",self.representation) 
        return self.unpack(words)
    def unpack(self,words):
        if len(words) == 1:
            return self.numberFor(words[0])
        else:
            lswi = len(words) - 1
            lswi = words[lswi]
            msws = words[0:lswi]
            return self.numberFor(lsw) + 10 * self.unpack(msw)
    def numberFor(self,word):
        return {"zero" : 0, "one" : 1, "two" : 2, "three" : 3,
                "four" : 4, "five" : 5, "six" : 6, "seven" : 7,
                "eight" : 8, "nine" : 9}[word]

Which resulted in a less than stellar review by the WPythonPSLP author on the WJavaPSLP authors "Model Solution" Python implementation...

I have been amazed and awed to watch newLISP code questions being refactored on the newLISP Fan Club by it's clever members... (I SO miss lesser programmers being told to RTFM in those OTHER language groups ;) LOL

So this newLISP newbie thought it might be fun to see what you newLISP pros ;) can do to give the "newLiSP Model Solution" (or in Elica, etc.)...

-- xytroxon

[cormullion]

I'm no pro. But newLISP always looks good on the eye, at least to me:

Code: Select all

(set 'digit-words '({zero} {one} {two} {three} {four} {five} {six} {seven} {eight} {nine}))

(define (integer-to-words n)
   (join (map (fn (d) (digit-words (int d 0 10))) (explode (string n))) { }))

(define (words-to-integer s)
   (int (apply string (map (fn (wd) (find wd digit-words)) (parse s))) 0 10))

(integer-to-words 654)

(words-to-integer {six five four})

[lithper]

I found this humorously titled Python article:
“Why Python Programmers Should Learn Python”

Referencing this Java article:
“Why Java Programmers Should Learn Python”

It might be that these "studies" are invented on the spot, and their authors are blissfully unaware of some such comparisons already done in the past.
Which does not negate the fact that they were conducted, however.

Back in the late 1990s C, C++ and Java programmers were asked to write code that would print all possible ways a list of phone numbers can be "said" in words.
Shortly afterwards, some lispers got wind of the paper with comparisons, and a follow-up attempt in Lisp happened (insert "KABOOM" here).

Here's what Norvig from norvig.com writes of the test:

http://www.norvig.com/java-lisp.html
In the October 1999 Communications of the ACM Lutz Prechelt had an interesting article entitled Comparing Java vs. C/C++ Efficiency Issues to Interpersonal Issues which asked 38 programmers to implement versions of a program in C, C++, or Java. The conclusions showed that Java was 3 or 4 times slower than C or C++, but that the variance between programmers was larger than the variance between languages, suggesting that one might want to spend more time on training programmers rather than arguing over language choice. (Or, suggesting that you should hire the good programmers and avoid the bad ones.) The variance for Java was lower than for C or C++. (Cynics could say that Java forces you to write uniformly slow programs.) I applaud this line of work, and hope that more studies of this kind will be done.

It turns out my hopes were answered. First, Prechelt published another article that covers Tcl, Python, Perl, and Rexx. Also, Ron Garret (nee Erann Gat) did a follow-up study in which he asked programmers to write Prechelt's test program in Lisp. His results show that the resulting Lisp programs ran faster on average than C, C++ or Java programs (although the fastest Lisp program was not as fast as the fastest C program), and that Lisp programs took less development time than the other languages.

I did not participate in the study, but after I saw it, I wrote my version in Lisp. It took me about 2 hours (compared to a range of 2 to 8.5 hours for the other Lisp programmers in the study, 3 to 25 for C/C++ and 4 to 63 for Java) and I ended up with 45 non-comment non-blank lines (compared with a range of 51 to 182 for Lisp, and 107 to 614 for the other languages). (That means that some Java programmer was spending 13 lines and 84 minutes to provide the functionality of each line of my Lisp program.)

The paper with lisp results is here: http://www.flownet.com/gat/papers/lisp-java.pdf

[xytroxon]

Oops!!! Forgot the link to the "reddit programming" comments for the article:
http://reddit.com/r/programming/info/6b511/comments/

Some php, factor, and CL examples... Also the python "zip" function is explored,,,

[cormullion]

I ended up with 45 non-comment non-blank lines (compared with a range of 51 to 182 for Lisp, and 107 to 614 for the other languages). (That means that some Java programmer was spending 13 lines and 84 minutes to provide the functionality of each line of my Lisp program.)

I've noticed that 'lines of code' is a good thing to boast about if you're a Lisp programmer, since white space isn't compulsory and you can squeeze a lot of function calls into a 'line'. In the same way, Python programmers could boast about how their programs are beautiful because they use a lot of white space, and Perl programmers could say how their code uses more of the ASCII character set than other languages... :)

Perhaps working out how many function calls are required to do a task would be a better way of comparing languages, if you really must compare them.

[cormullion]

Here's find-all at work:

Code: Select all

(set 'digit-words '({zero} {one} {two} {three} {four} {five} {six} {seven} {eight} {nine}))

(define (integer-to-words n)
   (find-all {\d} (string n) (print (digit-words (int $0)) { })))

(define (words-to-integer s)
   (find-all {\w+} s (print (find $0 digit-words))))

(integer-to-words 654)
six five four 

(words-to-integer {six five four})
654

It's cheating a bit, since that 654 only looks like an integer... :)

[lithper]

I've noticed that 'lines of code' is a good thing to boast about if you're a Lisp programmer, since white space isn't compulsory and you can squeeze a lot of function calls into a 'line'. In the same way, Python programmers could boast about how their programs are beautiful because they use a lot of white space, and Perl programmers could say how their code uses more of the ASCII character set than other languages... :)

Perhaps working out how many function calls are required to do a task would be a better way of comparing languages, if you really must compare them.

That is totally beside the point.
The point is simple:
2.(6) minutes per line to the total of 2 hrs
VERSUS
80 minutes per line to the total of 60 hrs

AND - virtualy nil difference btw several programmers in Lisp in their code.

(1) and (2) means easier maintainability of code and much cheaper development.

The third point is that human brain is limited as to the size of the "buffer" to roughly 1000 lines. Write more, and you'll have to split your file, or start losing your way in it.
Density (not in that disparaging sense English ascribes to it) of the text you produce is one of the major characteristics of high-quality thinking and expression: it's ability to convey information without diluting it.

[Elica]

The one-two-three<->123 problem is not fair, because it relies too much on the libraries, instead on the language itself. So one may slip into comparing libraries and applying the result on the languages themselves.

If your favourite language has a suitable library function, you can solve the problem in ... let's say ... one ... well, maybe half ... or even a quarter of a line.

Here is another example of unfair problem: Write a translator for programming language X written in the same programming language X.

Lisp has eval, Logo has run but what about poor C-ers, C++ers, Pascal-ers, etc.