1. 21
  1. 9

    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.

    The undeserved smugness of this guy…

    Reminds me of why he got banned

    1. 6

      Well, that, combined with the title is “Beating C with Common Lisp,” and the post unless I’m missing something is “how to be only five to six times slower and also not actually produce a binary.”

      1. 4

        Are we sure it’s him? there’s no instance of the phrase “and whatnot” in the text ;)

        1. 3

          His comments were the only ones greyed out when I saw the article on Hacker News. A conversational approach that failed miserably on one site will surely go better on another site with even more people to piss off. Must have been what he was thinking.

      2. 3

        But can you do a static portable binary from that Lisp code, comparable to C version in terms of file size?

        1. 13

          You absolutely can, on a system that has Lisp based runtime instead of C based runtime.

          1. 6

            Well-put. Probably still could with a Lisp designed for no-overhead interoperability with C compiled with a zero-runtime profile kind of like Ada/SPARK do. I don’t know if one like that currently exists, though.

            1. 4

              Not sure if Embeddable Common Lisp (ECL: https://common-lisp.net/project/ecl/ ) fits the bill but I guess it might?

              1. 2

                I forgot about ECL. Found this in its docs:

                “ECL (ECL for short) uses standard C calling conventions for Lisp compiled functions, which allows C programs to easily call Lisp functions and vice versa. No foreign function interface is required: data can be exchanged between C and Lisp with no need for conversion.

                ECL is based on a Common Runtime Support (CRS) which provides basic facilities for memory management, dynamic loading and dumping of binary images, support for multiple threads of execution. The CRS is built into a library that can be linked with the code of the application. ECL is modular: main modules are the program development tools (top level, debugger, trace, stepper), the compiler, and CLOS. A native implementation of CLOS is available in ECL. A runtime version of ECL can be built with just the modules which are required by the application.

                The ECL compiler compiles from Lisp to C, and then invokes the GNU C compiler to produce binaries.”

                That’s exactly the kind of design I’m talking about. It even matches the calling conventions for easy interoperability like I suggested for every language trying to [incrementally] replace C. Thanks for mentioning it.

          2. 4

            Not without packing the runtime with it, which is what a Lisp image does. Even after stripping unecessary stuff from the image, the binary is quite big.

            I’m a big Lisp fan, but let’s be honest.