3 ms·

>> I don't think it's generating a table, just calling generate-crc32-table. > Well, yeah. What do you suppose a function called generate-crc32-table could pla

>> I don't think it's generating a table, just calling generate-crc32-table. > Well, yeah. What do you suppose a function called generate-crc32-table could plausibly do? ... > That's 14 LOC, and 8 of those are declarations. It's considerable boilerplate, so much that I think you must really be in love with LISP to be able to deny that it is forbiddingly more work. It's 202 characters in C vs 573 characters in LISP if we remove the initial whitespace from your LISP version. I'm not saying we should do APL, just that C is efficient at what it does best, and that's a good thing. > For an example that you cherry-picked to be a perfect match for the kind of task that C was designed to do. I didn't cherry pick at all, just got the first good looking code from github that implemented deflate, as in my comment before ("compression or imaging..."). All I'm aiming to do is to disprove the statement that LISP is universally the best programming language for anything and everything. I'm not the one being bold. > Is that what you want to see, a cleaner syntax for type declarations? Of course, that's what I wanna see. Haven't seen it yet. > Because that's trivial, a few DEFTYPEs and a two-line macro. Show me and tell me all the reasons why that's not worse than just writing it in C. > That's right. And why is it that you don't see that in C? Because adding that to C is hard. Really really hard. Absolutely. It's just not possible. You make tradeoffs when you write C code just as in any other language. And personally I like making the tradeoffs that come with C. That allows me to write self-contained, modular code, and to avoid a lot of boilerplate and duplication. > You want to know what is ridiculous? A language that after 47 years still doesn't have a linked list as part of its standard library because the language design makes it impossible. It's not that it's impossible to add one to the standard library. But there is enough crap already in the standard library. There are various ways to do such a thing as a linked list, each with different tradeoffs. And using off-the-shelf data structures just doesn't align very well with a typical C programmer's mindset. Often it's a good idea to just quickly code up your own so that you can integrate it better with the rest of your project. But have a look at Linux'es intrinsically linked list.h (or rbtree.h) for example, or at glib's extrinsically linked list if you want to depend on that and don't care about performance. If you don't like that, you might just want to achieve different things than me. That's fine with me. Pick your own poison.

lisper 7y ago
> It's considerable boilerplate No, it's not boilerplate, it's actually functional. Type declarations in Lisp are optional (because they are there only to improve performance, not to change the semantics of the code). > > Is that what you want to see, a cleaner syntax for type declarations? > Of course, that's what I wanna see. Haven't seen it yet. OK, here is one possibility: (deftype u8 () '(unsigned-byte 8)) (deftype u32 () '(unsigned-byte 32)) (deftype array-of (type &optional size) `(simple-array ,type ,(or size '(*)))) (defmacro c-defun (name args &body body) `(defun ,name ,(loop for (var) on args by #'cddr collect var) (declare ,@(loop for (var type) on args by #'cddr collect `(type ,type ,var)) (optimize (speed 3) (debug 0) (space 0) (safety 0))) ,@body)) (defmacro c-let (vars &body body) `(let ,(loop for (var nil val) in vars collect (list var val)) (declare ,@(loop for (var type) in vars collect `(type ,type ,var))) ,@body)) Now you can write: (c-defun update-crc32-checksum (crc u32 buffer (array-of u8) end fixnum) (c-let ((cur u32 (logxor crc #xffffffff)) (table (array-of u32 256) (get-crc-table))) (dotimes (i end) (c-let ((index u8 (logand #xff (logxor cur (aref buffer i))))) (setq cur (logxor (aref table index) (ash cur -8))))) (logxor cur #xffffffff))) Better? > Show me and tell me all the reasons why that's not worse than just writing it in C. I didn't say it was better to write this code in Lisp. I said it was easier to make this kind of change in Lisp if you want to.
- jstimpfle 7y ago
  > Better? I can empathize with your enthusiasm that you can improve the situation a little on the surface, which feels like an achievement, but frankly, I think the code still sucks a lot... There's no way I could sustain writing the kind of code I like to write in this fashion. From an engineering standpoint, using this was probably a poor choice (again, think error messages, tooling, mindshare...) The metaprogramming code looks ugly and brittle to me, although I'm not in a position to judge.
  - lisper 7y ago
    > I think the code still sucks a lot.. Why? How would you want it to be different?

lisper 7y ago

> It's considerable boilerplate No, it's not boilerplate, it's actually functional. Type declarations in Lisp are optional (because they are there only to improve performance, not to change the semantics of the code). > > Is that what you want to see, a cleaner syntax for type declarations? > Of course, that's what I wanna see. Haven't seen it yet. OK, here is one possibility: (deftype u8 () '(unsigned-byte 8)) (deftype u32 () '(unsigned-byte 32)) (deftype array-of (type &optional size) `(simple-array ,type ,(or size '(*)))) (defmacro c-defun (name args &body body) `(defun ,name ,(loop for (var) on args by #'cddr collect var) (declare ,@(loop for (var type) on args by #'cddr collect `(type ,type ,var)) (optimize (speed 3) (debug 0) (space 0) (safety 0))) ,@body)) (defmacro c-let (vars &body body) `(let ,(loop for (var nil val) in vars collect (list var val)) (declare ,@(loop for (var type) in vars collect `(type ,type ,var))) ,@body)) Now you can write: (c-defun update-crc32-checksum (crc u32 buffer (array-of u8) end fixnum) (c-let ((cur u32 (logxor crc #xffffffff)) (table (array-of u32 256) (get-crc-table))) (dotimes (i end) (c-let ((index u8 (logand #xff (logxor cur (aref buffer i))))) (setq cur (logxor (aref table index) (ash cur -8))))) (logxor cur #xffffffff))) Better? > Show me and tell me all the reasons why that's not worse than just writing it in C. I didn't say it was better to write this code in Lisp. I said it was easier to make this kind of change in Lisp if you want to.

jstimpfle 7y ago
> Better? I can empathize with your enthusiasm that you can improve the situation a little on the surface, which feels like an achievement, but frankly, I think the code still sucks a lot... There's no way I could sustain writing the kind of code I like to write in this fashion. From an engineering standpoint, using this was probably a poor choice (again, think error messages, tooling, mindshare...) The metaprogramming code looks ugly and brittle to me, although I'm not in a position to judge.
- lisper 7y ago
  > I think the code still sucks a lot.. Why? How would you want it to be different?