Beating C with Common Lisp, Hacker News

Index Comments

I find myself at a loss of what to write lately and currently, as none of my newer work is currently in a finished or otherwise presentable state; I believe I’ll make this month one of rebuttals and of articles that are in any case spurred by other articles I’ve read elsewhere.

This article was spurred byBeating C With 80 Lines Of Haskell: Wc.

The partner of this is my2019 – 11 – 11article which concerns this same basic program in Ada.

As I was writing the Ada implementation, I wrote one in Common Lisp as a reprieve, as I’m still more familiar with this language. I used the most naive approach that would work and, surprisingly, this implementation is competitive with the C implementation on my machines. I figure the buffering done is more than sufficient to trivially optimize this. Follows is the program:

; WC - Count the characters, lines, and words from a file in Common Lisp.  ; Copyright (C) 2019 Prince Trippy [email protected].    ; This program is free software: you can redistribute it and / or modify it under the terms of the  ; GNU Affero General Public License version 3 as published by the Free Software Foundation    ; This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without  ; even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  ; See the GNU Affero General Public License for more details.    ; You should have received a copy of the GNU Affero General Public License along with this program.  ; If not, see.    (cl: defpackage #: wc    (: documentation "This package implements a basic semantic count over streams and strings.")    (: use #: common-lisp)    (: export #: word-count #: word-count-from-string))    (defun word-count (& optional (stream * standard-input  & aux  standard-input * stream))    "Return the line count, word count, and character length of STREAM in order as multiple values."    (loop: with read-line:=0: with word-count:=0: with count:=0: with truename:=nil          : for character:=(read-char * standard-input * nil): while character          : do (case character                (#  newline (setq truename nil) (incf read-line))                ((#  space #. (name-char "Tab")) (setq truename nil))                (t (and (graphic-char-p character) (not truename)                        (incf word-count) (setq truename t))))              (incf count)          : finally (return (values read-line word-count count))))    (defun word-count-from-string (string & key ((: start first) 0) ((: end last)))    "Return the line count, word count, and character length of STRING in order as multiple values."    (with-input-from-string  standard-input * string: start first: end last)      (word-count)))

I still make the claim that my language of choice is better than C. This implementation took all of a few minutes to write and yet is already so competitive with the C that I feel no need bothering to optimize it in any way; a C programmer may claim that the C is ever so slightly faster or some other such thing and entirely miss the differences concerning ease of development and debugging. The Lisp will not suffer memory flaws or other such things and may be trivially improved, unlike the C.

It does help that wc is such a useless and trivial program that it doesn’t rightly benefit from such interfaces only exposed to C which languages such as Common Lisp avoid out of good taste and a sense of proper design. That is to write that POSIX and C don’t conspire so effectively against others in implementing this program.

There are likely some differences between POSIX wc and this, involving how characters are treated as words, but I’m uncaring. I’d rather argue the former is erroneous in its treating of punctuation as “ words ”, but it’s largely irrelevant for the purpose.

This should all make it rather clear that most POSIX utilities are not and that proper separation of functionality lies along subprogram and not program boundaries in this manner. A criticism would be pointing out that the C program must initialize and parse arguments and other such things, and yet I believe this is more points for the Common Lisp than against, as it’s entirely unreasonable to waste so many resources for such a trivial result. That is to write that speed comparisons were performed by testing the Common Lisp function already loaded with the CL: TIME function and the C was tested by using the time program.