[jgw]

I enjoyed skimming over this again -- I happen to be the guy who wrote the first comment on it.

I'm pleased to say that I've stuck with CL, and I'm glad I did. I've managed to use it at work, and have been using it to build something I can't picture doing (easily?) in any other language. I've managed to pique the interest of a few coworkers, too.

Much of what the article says is indeed true, but I just don't feel they're as problematic as they're made out to be. There are some ugly corners of the language, but they're, in my opinion, vastly outweighed by a fearsome arsenal of tools at your fingertips. I'd contend that it's warts are "warts in the small" -- some weird naming, some inconsistencies in usage. Other languages -- even pretty good ones -- have problems in things as basic as their scoping rules. I believe that by comparison, CL is actually pretty reasonably designed.

[S4M]

> I've managed to use it at work, and have been using it to build something I can't picture doing (easily?) in any other language.

Could you expand on that? I'd love to know what you built and why you think it would be some hard work to do it in any other language.

[jgw]

Sure, s/built/are building/g.

Without going into too much detail, I basically am subsuming another language (statically-typed, Algol-ish) wholesale into Common Lisp. It replaces that language's syntax with an s-expression syntax, but also provides a way to embed its native syntax. So you can use CL macros to build syntactic abstractions, and use them as low-ceremony wrapping around native code. It also makes many of the primitives of that language into first-class objects in Lisp, so a REPL for the embedded language is emerging (or expressed another way, you can evaluate the embedded language in the CL REPL). I don't think Clojure would do as good a job (gut feeling; I'm not a Clojurist). Racket would probably be a decent choice, but not sure if I'd get good performance (again, not a Schemer).

One of the more arrogant things I've heard Lispers claim of their language is "a superset of all other languages". While that's not entirely true, this work has made me feel that there's more than a kernel of truth in that hyperbole. Warts and all! :)

[jwdunne]

That's pretty amazing. What sort of tools and features did you use to do that? Genuinely interested as CL is a language I always keep in the back of my mind for the "next project" and this is giving me a big push to use it.

[jgw]

Programmable syntax (reader macros), programmable printer are 2 big ones. Also regular macros are key, manipulating code as structures not text, having both lexical and dynamic variables, closures and all the other nuts and bolts stuff. Type and compiler-optimization declarations help keeping things fast (well, not fast enough, but I'm trying!)

[jwdunne]

Thank you :)

I think you were correct about Clojure. I read recently reader macros are not an available feature.

[arohner]

Yes, mostly. reader macros are not extensible by the user. The compiler has and uses reader macros.

Rich Hickey has said he hasn't seen an implementation of reader macros that is compose-able across libraries. i.e. two different OSS libs using a two different incompatible macros.

[S4M]

If I understand well, you wrote/are writing a macro that parses your algol-ish language, so you can do, if your language is java, something like:

    (let ((my-java-class  
           (java public class MyClass {
                   public MyClass() {}
                   public myMethod() {System.out.println("hello");}
                  })))
          (myMethod (my-java-class)))

And it shows on the REPL:

     hello

That's quite impressive, and I can see how it opens new horizons.

[jgw]

Bit late replying to this, so I hope you see it, but as I noted elsewhere, the key here is something called a "reader macro". This is a mechanism by which you can control the behaviour of the Lisp reader (i.e., the READ function), and occurs before regular macroexpansion. I use [] to denote s-expressions in the embedded-language domain, and {} to introduce native syntax, which passes its contents through to an actual parser - which returns s-expressions. I can print the resulting forms in native syntax, embedded-s-expressions, or plain Lisp. It's a neat demonstration of the superficiality of syntax.

Perhaps another interesting observation is that what I'm building today is not actually what I originally set out to do, which was more limited in scope. Perhaps another weakness of CL is its tendency to seduce you into feature-creepism. :)

[nickpsecurity]

Author's point wasn't that Common LISP couldn't do such a thing. It's whether Common LISP's issues and troubles are justified in process vs examples like Racket cited. How hard would it have been to do your project in Racket which seems to be able to do whatever Common LISP can do and with more consistency in language?

[jgw]

Haven't spent enough time with Racket, but my understanding (correct me if I'm wrong) is that you won't squeeze as much performance out of it, and performance is quite important. I'm also quite partial to Lisp's condition system -- I don't believe Schemes can support something that comprehensive (a trade-off for having nice things like call/cc, I think?)

[tbirdz]

Chez scheme was recently released as free software. Not sure how it compares to SBCL, but it blows all the other scheme implementations out of the water: https://www.nexoid.at/tmp/scheme-benchmark-r7rs.html

https://github.com/cisco/ChezScheme

[jgw]

Interesting! I'm wide open to more Scheme in my life - so thanks for the pointers.

[nickpsecurity]

It's not just an impressive Scheme that I plan to try but it's history from 8-bit to modern implementations was a fun read. Many clever tradeoffs made. See here:

https://news.ycombinator.com/item?id=10210931

[nickpsecurity]

Hmm. That's a good point. It didn't benchmark as well as Common LISP last I looked. Another time, Racket developers updated the compiler and improved a benchmark on a spot due to complaints on a forum. I rarely see that haha. It would still have to be tested to ensure performance is within what you need.

"I'm also quite partial to Lisp's condition system"

You're not the only one. Many like that. It's been a while since I used Common LISP. Here's Racket's condition system or a brief intro to it below. Is there anything specific that it seems weaker on?

https://docs.racket-lang.org/r6rs/r6rs-lib-std/r6rs-lib-Z-H-...