4 ms·

> But I think you might be surprised at how un-half-assed these things can be. You might be surprised how little I care, because I'll just use a solid, battle-

> But I think you might be surprised at how un-half-assed these things can be. You might be surprised how little I care, because I'll just use a solid, battle-tested tool instead. Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better?

lisper 7y ago
> You might be surprised how little I care You obviously care enough to have taken the initiative to engage me on this. > Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better? No. It's generally never worthwhile to re-write anything. But one should not fall prey to the sunk cost fallacy either.
- jstimpfle 7y ago
  If you think we should not "fall prey to the sunk cost fallacy" and write future software in Common LISP, then I recommend you to start working on improving the Common LISP systems-level coding situation. Because I'm not willing to replace this unsigned long update_crc(unsigned long crc, unsigned char *buf, int len) { unsigned long c = crc; for (int n = 0; n < len; n++) c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8); return c; } with something like this (https://github.com/pmai/Deflate/blob/master/deflate.lisp https://github.com/pmai/Deflate/blob/master/deflate.lisp) #-lispworks (defun update-crc32-checksum (crc buffer end) (declare (type (unsigned-byte 32) crc) (type (simple-array (unsigned-byte 8) (*)) buffer) (type fixnum end) (optimize (speed 3) (debug 0) (space 0) (safety 0)) #+sbcl (sb-ext:muffle-conditions sb-ext:compiler-note)) (let ((table (load-time-value (generate-crc32-table))) (cur (logxor crc #xffffffff))) (declare (type (simple-array (unsigned-byte 32) (256)) table) (type (unsigned-byte 32) cur)) (dotimes (i end) (declare (type fixnum i)) (let ((index (logand #xff (logxor cur (aref buffer i))))) (declare (type (unsigned-byte 8) index)) (setq cur (logxor (aref table index) (ash cur -8))))) (logxor cur #xffffffff))) #+lispworks (defun update-crc32-checksum (crc buffer end) (declare (type (unsigned-byte 32) crc) (type (simple-array (unsigned-byte 8) (*)) buffer) (type fixnum end) (optimize (speed 3) (debug 0) (space 0) (safety 0) (float 0))) (let ((table (load-time-value (generate-crc32-table))) (cur (sys:int32-lognot (sys:integer-to-int32 (dpb (ldb (byte 32 0) crc) (byte 32 0) (if (logbitp 31 crc) -1 0)))))) (declare (type (sys:simple-int32-vector 256) table) (type sys:int32 cur)) (dotimes (i end) (declare (type fixnum i)) (let ((index (sys:int32-to-integer (sys:int32-logand #xff (sys:int32-logxor cur (aref buffer i)))))) (declare (type fixnum index)) (setq cur (sys:int32-logxor (sys:int32-aref table index) (sys:int32-logand #x00ffffff (sys:int32>> cur 8)))))) (ldb (byte 32 0) (sys:int32-to-integer (sys:int32-lognot cur))))) Have a good day.
  - lisper 7y ago
    That is not exactly an apples-to-apples comparison. You've taken a very simple C function and compared it to Lisp code written in two different ways to take advantage of features available only in specific compilers. Equivalent C code would be chock-full of #ifdefs and look just as ugly. I could produce an equally contrived example where to do the same thing as two lines of Lisp would require pages and pages of C. Second, these code snippets are not comparable in their functionality. The Lisp code generates the crc table, the C code assumes it has already been done. If you wanted to add bounds checking to the C code you would have to make major changes. If you wanted to add bounds checking to the Lisp code, all you would have to do is change the optimization settings. (This is one of the reasons that today's computing world is a swiss-cheese of security holes.) Third, there are any number of ways to make the Lisp code look significantly prettier. Comparable code would look something like: (defun crc (crc l) (dolist (item l) (setf crc (logxor (aref crc-table (logand 255 (logxor crc item))) (ash c 8)))) crc) It's even easy to embed an infix parser [1] in Lisp so that you could write: (defun crc (crc l) (dolist (item l) (setf crc infix(crc_table[(crc ^ item) & #xff] ^ (crc >> 8))) crc) if you wanted do. You could also embed all this in a little DSL so that the resulting semantics and even the generated code would be exactly the same as the C code. Fourth, most Lisp systems have a foreign function interface, so if you want to you can call C functions directly and so get all the benefits of C (such as they are) from within Lisp. --- [1] http://www.cs.cmu.edu/Groups/AI/util/lang/lisp/code/syntax/parcil/parcil.cl http://www.cs.cmu.edu/Groups/AI/util/lang/lisp/code/syntax/p...
    - ncmncm 7y ago
      Yes, I can call C from Lisp. Or just not bother with the Lisp at all. It's an easy choice.
      - kazinator 7y ago
        The wide-spread production practice of calling C libraries from dynamic (and other) languages is pretty much eating the world. The naysayers are being tripped over and trampled by throngs of doers. There are excellent reasons not to write the whole darn program in C, just because it happens to need a SHA256, CRC, access to graphics, or some number crunching or whatever.

lisper 7y ago

> You might be surprised how little I care You obviously care enough to have taken the initiative to engage me on this. > Are you suggesting we should rewrite compression or imaging or ... software in Common Lisp because it will be so much better? No. It's generally never worthwhile to re-write anything. But one should not fall prey to the sunk cost fallacy either.

jstimpfle 7y ago
If you think we should not "fall prey to the sunk cost fallacy" and write future software in Common LISP, then I recommend you to start working on improving the Common LISP systems-level coding situation. Because I'm not willing to replace this unsigned long update_crc(unsigned long crc, unsigned char *buf, int len) { unsigned long c = crc; for (int n = 0; n < len; n++) c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8); return c; } with something like this (https://github.com/pmai/Deflate/blob/master/deflate.lisp https://github.com/pmai/Deflate/blob/master/deflate.lisp) #-lispworks (defun update-crc32-checksum (crc buffer end) (declare (type (unsigned-byte 32) crc) (type (simple-array (unsigned-byte 8) (*)) buffer) (type fixnum end) (optimize (speed 3) (debug 0) (space 0) (safety 0)) #+sbcl (sb-ext:muffle-conditions sb-ext:compiler-note)) (let ((table (load-time-value (generate-crc32-table))) (cur (logxor crc #xffffffff))) (declare (type (simple-array (unsigned-byte 32) (256)) table) (type (unsigned-byte 32) cur)) (dotimes (i end) (declare (type fixnum i)) (let ((index (logand #xff (logxor cur (aref buffer i))))) (declare (type (unsigned-byte 8) index)) (setq cur (logxor (aref table index) (ash cur -8))))) (logxor cur #xffffffff))) #+lispworks (defun update-crc32-checksum (crc buffer end) (declare (type (unsigned-byte 32) crc) (type (simple-array (unsigned-byte 8) (*)) buffer) (type fixnum end) (optimize (speed 3) (debug 0) (space 0) (safety 0) (float 0))) (let ((table (load-time-value (generate-crc32-table))) (cur (sys:int32-lognot (sys:integer-to-int32 (dpb (ldb (byte 32 0) crc) (byte 32 0) (if (logbitp 31 crc) -1 0)))))) (declare (type (sys:simple-int32-vector 256) table) (type sys:int32 cur)) (dotimes (i end) (declare (type fixnum i)) (let ((index (sys:int32-to-integer (sys:int32-logand #xff (sys:int32-logxor cur (aref buffer i)))))) (declare (type fixnum index)) (setq cur (sys:int32-logxor (sys:int32-aref table index) (sys:int32-logand #x00ffffff (sys:int32>> cur 8)))))) (ldb (byte 32 0) (sys:int32-to-integer (sys:int32-lognot cur))))) Have a good day.
- lisper 7y ago
  That is not exactly an apples-to-apples comparison. You've taken a very simple C function and compared it to Lisp code written in two different ways to take advantage of features available only in specific compilers. Equivalent C code would be chock-full of #ifdefs and look just as ugly. I could produce an equally contrived example where to do the same thing as two lines of Lisp would require pages and pages of C. Second, these code snippets are not comparable in their functionality. The Lisp code generates the crc table, the C code assumes it has already been done. If you wanted to add bounds checking to the C code you would have to make major changes. If you wanted to add bounds checking to the Lisp code, all you would have to do is change the optimization settings. (This is one of the reasons that today's computing world is a swiss-cheese of security holes.) Third, there are any number of ways to make the Lisp code look significantly prettier. Comparable code would look something like: (defun crc (crc l) (dolist (item l) (setf crc (logxor (aref crc-table (logand 255 (logxor crc item))) (ash c 8)))) crc) It's even easy to embed an infix parser [1] in Lisp so that you could write: (defun crc (crc l) (dolist (item l) (setf crc infix(crc_table[(crc ^ item) & #xff] ^ (crc >> 8))) crc) if you wanted do. You could also embed all this in a little DSL so that the resulting semantics and even the generated code would be exactly the same as the C code. Fourth, most Lisp systems have a foreign function interface, so if you want to you can call C functions directly and so get all the benefits of C (such as they are) from within Lisp. --- [1] http://www.cs.cmu.edu/Groups/AI/util/lang/lisp/code/syntax/parcil/parcil.cl http://www.cs.cmu.edu/Groups/AI/util/lang/lisp/code/syntax/p...
  - ncmncm 7y ago
    Yes, I can call C from Lisp. Or just not bother with the Lisp at all. It's an easy choice.
    - kazinator 7y ago
      The wide-spread production practice of calling C libraries from dynamic (and other) languages is pretty much eating the world. The naysayers are being tripped over and trampled by throngs of doers. There are excellent reasons not to write the whole darn program in C, just because it happens to need a SHA256, CRC, access to graphics, or some number crunching or whatever.