How to write Common Lisp in 2017 – an initiation manual • Hacker News Board

Re: How to write Common Lisp in 2017 – an initiation manual

#51

Post by pnathan » Tue, Mar 28, 2017, 8:13 PM UTC

AlexCoventry wrote: post #27

Can someone point me at an argument for why I'd want to write CL in 2017, given all the great alternatives available now?

It's a seamless dynamic programming language, which can, with care, be given excellent performance and a high level of abstraction. In my opinion, it's miles better than the other dynamic languages out there, by nearly every factor. It rewards investment and development very well; it's a tool for mastery, not for quick and easy starting.

If you're looking for statically typed languages, it's not going to win there. But my experience writing a lot of Perl and Python, with a certain amount of helping with Clojure and Ruby experience, strongly indicates that Common Lisp is very very competitive there outside of the 'library' front.

Re: How to write Common Lisp in 2017 – an initiation manual

#52

Post by emidln » Tue, Mar 28, 2017, 8:13 PM UTC

SomeHacker44 wrote: post #24

sigjuice wrote: post #8

Earlier quoted context omitted.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.

If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader.

I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using data literals or tagged literals. There might be some random place where I need syntax beyond clojure's data literals, but I'm far more likely to use a combination of data literals + tags. If absolutely required (it hasn't been yet in 5 years of daily production usage), I could simulate custom grammar using clj-antlr and a macro. If, for some unknown reason, I needed a custom non-sexp grammar embedded in my lisp that I wanted to serialize exactly and then read back in the same syntax (probably because I hate myself and/or my team), I could hack it tools.reader.

tldr; you have reader macros if you want them. Nobody wants them who uses Clojure day to day. If they did want them, they could trivially extend tools.reader themselves.

Re: How to write Common Lisp in 2017 – an initiation manual

#53

Post by pnathan » Tue, Mar 28, 2017, 8:14 PM UTC

agentultra wrote: post #3

If you're so inclined I'd make it a "living document" that gets updated as the state-of-the-art evolves. Writing CL in 2017 is not likely to change rapidly in the next decade but even compared to what writing CL was like 8 years ago it has changed enough. Nice job.

Yes, send in PRs if things significantly change! It's a stable ecosystem, but things do improve over time. Things like examples would be quite useful.

Re: How to write Common Lisp in 2017 – an initiation manual

#54

Post by _19qg » Tue, Mar 28, 2017, 8:15 PM UTC

brudgers wrote: post #45

sigjuice wrote: post #8

Earlier quoted context omitted.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants. There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as…

> lists and other seq's as functions in the function position of an x-expression.

Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.

Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.

Pays back it code maintenance over time...

> but generally reads cleaner in the same way one might say a font reads cleaner.

I think it reads cleaner in the way PERL code is read cleaner.

Re: How to write Common Lisp in 2017 – an initiation manual

#55

Post by pnathan » Tue, Mar 28, 2017, 8:15 PM UTC

brudgers wrote: post #17

ntdef wrote: post #6

Ah yes this is exactly what I needed. I was recently trying to start a CL project but I had trouble wading through all the outdated material, especially with regards to including external packages. Thanks for putting this together!

I'm going through a similar process. My caution is that 'package' has a very technical meaning in Common Lisp that is at odds with how 'package' is used in other languages (and a bit at odds with how the author uses it in their tutorial). A package in Common Lisp is a set of interned symbols. In Common Lisp, systems are more in keeping with an ordinary understanding of packages...but combined with the idea of a build…

Hmmm. I tried to convey the idea, without getting too bogged down in the details that don't per se matter on Day 1.

I would be interested in any PRs you have to clarify the matter adequately for people just starting out.

Re: How to write Common Lisp in 2017 – an initiation manual

#56

Post by pnathan » Tue, Mar 28, 2017, 8:16 PM UTC

macco wrote: post #36

If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: https://atom.io/packages/atom-slime It doesn't replace emacs, but it works as a first Lisp ide.

Really! Do you use it? Would you feel comfortable submitting a PR explaining how to set it up? I HATE recommending emacs as the IDE for Common Lisp if it's not something people are comfortable with already.

Re: How to write Common Lisp in 2017 – an initiation manual

#57

Post by pnathan » Tue, Mar 28, 2017, 8:19 PM UTC

quickoats wrote: post #19

i do not know how to message the guy "Scott" author of page, so i am putting this here. in the "LispWorks CL" page, under "Implementations", the "Notes" section elicidates a mystery about the Personal Edition not recognizing the lisp init files. This is actually a limitation in LispWorks Personal Edition which is described on the link provided to retrieve said edition.

Ah, interesting! I don't remember reading that when I wrote it.

I'll go back and correct it after my current project wraps up (but PRs are also accepted!).

Re: How to write Common Lisp in 2017 – an initiation manual

#58

Post by sedachv » Tue, Mar 28, 2017, 8:27 PM UTC

znpy wrote: post #46

Some notes based on my (brief) experience toying with Common Lisp: * Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem. * The relation between the various native data-types were quite unclear to me. * dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got aba…

> Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec

I mostly access the HyperSpec using Erik Naggum's hyperspec.el while programming in Emacs, configured to bring up Lynx. A lot of other people probably do something similar, so there has not been much interest in adding CSS.

Re: How to write Common Lisp in 2017 – an initiation manual

#59

Post by _delirium » Tue, Mar 28, 2017, 8:32 PM UTC

yarrel wrote: post #29

lenkite wrote: post #11

I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?

I like Go and Guile. I love Common Lisp. It's an expressive language with a powerful development environment in the form of the REPL plus Slime. I love using Lisp for exploratory programming, as it's so simple to write something that both works now and makes sense later. It has a wider range of built-in programming paradigms more fully realised than Go or guile. In comparison to CLOS, all other object systems are jus…

> In comparison to CLOS, all other object systems are just kidding.

I almost agree, with the exception, oddly enough, of Perl (either Perl6 or Perl5+Moose). It's just about as full-featured as CLOS, complete with a usable MOP.

Re: How to write Common Lisp in 2017 – an initiation manual

#60

Post by brudgers » Tue, Mar 28, 2017, 8:33 PM UTC

_19qg wrote: post #54

brudgers wrote: post #45

Earlier quoted context omitted.

If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants. There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as…

> lists and other seq's as functions in the function position of an x-expression. Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp. Common Lisp was designed such that for the programmer and for the compiler the first el…

Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.

Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.