Live data from Hacker News

How to write Common Lisp in 2017 – an initiation manual

articulate-lisp.com

81–90 of 271 posts

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

#81
post #51

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. B…

The Common Lisp library ecosystem isn't as polished as it is in Python from what I know. Nor is the documentation for many libraries up to scratch, even the stellar ones. Some libraries merely document the functions provided and don't go into how to use the library. Even stellar libraries such as Hunchentoot do this, which I find rather annoying after using Python libraries which seem to make it an important point to tell you how to use things.

I love CL and the idea of Lisp in general, but its modern unpopularity makes it hard to ask questions (because chances are you won't get a response any time soon) and the library situation is a real downer.

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

#82

"Dear windows user, tell us how this is done for SBCL" Watch YouTube video from Baggers. It's a lot more complicated than your average windows user will want to go through. Than you have to setup EMACS, quicklisp...etc. I never really new what quicklisp was doing and it made me nervous (I trust VS nuget).

I've been telling people for years to just use Clozure CL on windows. It might be a bit slower, but it's still blazing fast and you don't have to deal with compatibility issues.

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

#83
post #55

Earlier quoted context omitted.

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.

A few remarks:

0. It's a hard problem. I have a deep respect for your trying to tackle it.

1. The hard part is that it all matters on day one and everyone will get a lot of stuff wrong for a long while and some stuff wrong always when attempting non-trivial projects. This is the rule whether it's Python or Common Lisp or Racket.

2. I'm a fan of polyglotting languages in general and Lisp's in particular. For a person really just starting out, I'd point them at the Racket ecosystem because it is designed to be newbie friendly with student languages and Common Lisp is designed for production programming on hard problems.

2. For people with some programming experience and simple curiosity, I'd just advise them to install SBCL and play around in the REPL. With an exercise of adding a script to wrap it in readline. And some exercises using the text editor of their choice to load and read and write files and such.

3. I don't think that there's a way to add training wheels to SLIME and Quicklisp and ASDF as the development environment. It just won't ever be DrRacket. At best it produces something like Aphyr's Clojure from the Ground Up...which uses Emacs; is more like a book; and definitely a labor of love. It also dives into the details at day one.

None of which means I might not submit a pull request. But I take what Norvig says seriously -- http://norvig.com/21-days.html

Again, kudos for taking it on.

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

#84
I started a big project at work using Common Lisp in 2017 and could not be happier. Sure, most nice features have trickled down to other languages, but they are rarely as nicely integrated. And Lisp still has many advantages that are not found elsewhere: Unmatched stability, on-demand performance, tunable compiler, CLOS, condition system, and Macros to name a few. It has its warts too but which language does not?

I found lack of high quality library documentation a bit annoying, but a non-issue, there were tests and/or examples included in practically all of the libraries I have used so far.

Lastly, this rarely gets brought up, but I think Common Lisp has some of the best books available out of any programming language. The fact that it is so stable means that most of material, and code, from the end of 80's and 90's is quite relevant today, and new stuff is being written.

The biggest downside is that it makes JavaScript and Python revolting to work with. But I can still enjoy SML for example.

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

#85
post #25

I'd replace the first few steps with "Install Roswell" - https://github.com/roswell/roswell Roswell will install a Lisp and QuickLisp for you, and give you a single point of entry to install libraries, create and run code, and launch en editor (Emacs with Slime of course). I can't recommend it highly enough (I'm nothing to do with the project, just a very happy user).

Neat. Does Roswell do all this without modifying your current lisp/emacs/slime/quicklisp if you already have them set up the way you like but want to play around with it?

And is there something like Roswell for Clojure?

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

#86
post #69
post #12

Earlier quoted context omitted.

Usually, people tend to see the following problems: * no native support, hosted language (js java) * unreadable (java) tracebacks * no tail call optimization These are not my problems with Clojure, but then things I often read. I am interested in Common Lisp because of the native support.

I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.

loop/recur handles only a tiny part of TCO.

TCO means all calls in tail position are optimised, not just the self-recursive ones.

Personally I find loop/recur ugly. It's a partial hack around the lack of TCO.

Though I prefer looping statements like Common Lisp's ITERATE, whose design I like a lot...

https://common-lisp.net/project/iterate/doc/index.html

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

#87
For people using macs, it's probably worthwhile to mention CCL's IDE, which you can easily build from within the CCL sources using (require :cocoa-application), or which you can get for free from the Mac App Store (it's called "Clozure CL").

It's a little bit bare bones and a little bit perpetually unfinished, but it works and it gives you a Lisp-aware environment for editingand running Lisp code, and even has a few handy tools.

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

#88
post #52

Earlier quoted context omitted.

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 d…

Virtually nothing requires reader macros. That doesn't mean they aren't useful. Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.

It has a reader as a library. It's entirely possible for you to change its lookup map to a defmethod and go to town altering s-expressions for arbitrary syntax if you wish. You're not hacking a new reader here, you'd refactoring something that probably should have been a generic method to begin with into one. Nobody has bothered with this because it's not useful to anyone, as far as I can tell. People who want non-data syntax write it with clj-antlr/instaparse (which are very easy to use) and use a macro when they want to interleave it into their code. These universally end up with a data-based AST that is readable and printable.

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

#89
post #85
post #25

I'd replace the first few steps with "Install Roswell" - https://github.com/roswell/roswell Roswell will install a Lisp and QuickLisp for you, and give you a single point of entry to install libraries, create and run code, and launch en editor (Emacs with Slime of course). I can't recommend it highly enough (I'm nothing to do with the project, just a very happy user).

Neat. Does Roswell do all this without modifying your current lisp/emacs/slime/quicklisp if you already have them set up the way you like but want to play around with it? And is there something like Roswell for Clojure?

I don't know about emacs/slime, but it can manage local quicklisp and local implementations (and even have e.g. multiple sbcl versions installed simultaneously).

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

#90

"Dear windows user, tell us how this is done for SBCL" Watch YouTube video from Baggers. It's a lot more complicated than your average windows user will want to go through. Than you have to setup EMACS, quicklisp...etc. I never really new what quicklisp was doing and it made me nervous (I trust VS nuget).

Everything should Just Work (TM) on Windows these days. SBCL provides reasonably fresh binaries to download. Quicklisp can be installed by entering the necessary commands into SBCL console. Emacs has a Windows installer. SLIME can be installed from Quicklisp. And so on. I develop in Lisp on both Windows and Linux machines, it works exactly the same (which cannot be said of some other languages).
Post reply on HN