top | item 11823902

Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

338 points| pavelludiq | 9 years ago |fullstacklisp.com | reply

100 comments

order
[+] auvi|9 years ago|reply
I really appreciate the author taking the time to write this book. I have read his previous book Lisp Web Tales and learned many things from it.
[+] zeveb|9 years ago|reply
Best of luck!

I like how you mention first thinking Common Lisp was archaic, and then realising how advanced it really is.

BTW, you might want to wrap your text lines:-)

[+] mark_l_watson|9 years ago|reply
Very nice, I love seeing new Common Lisp books being written. (BTW, I also have a Common Lisp book on leanpub.com - a great company to work with if you are a writer).

It is especially good to see a complete caveman2 application developed in the book.

[+] eggy|9 years ago|reply
I am in the middle of reading Adam Tornhill's 'Lisp for the Web', and I just stumbled on this book.

Yes, Lisp seems to me to be getting more exposure, but that may be my 'Lisp-colored sunglasses' ;)

Is caveman2 a lot easier, or what other advantages does it have over piecing stuff together?

I have always liked and programmed in Lisp, but not for the Web, so I need to get up to speed with Web frontend/backend programming again for personal use, not a job.

OT: Mark, I am on your 3 edition of 'Loving Common Lisp', and I really appreciate the Networking chapter update, and your smooth writing style!

[+] haspok|9 years ago|reply
I'd love to read a chapter about why would someone choose Common Lisp instead of, say, Clojure (with all the JVM ecosystem behind it) or LFE (with the Erlang ecosystem behind it). What are the use cases in which CLISP stands out and offers a benefit?
[+] junke|9 years ago|reply
First, you should not abbreviate Common Lisp as CLISP: this is confusing because CLISP is one of the many implementations of CL.

As for comparisons, this is a Gorilla vs Shark problem (https://blog.stackoverflow.com/2011/08/gorilla-vs-shark/), without context you can choose anything you prefer.

LFE is not really Lisp, it is more like Erlang with parenthesis, so it is hardly comparable. Erlang offers a very specific, and useful, model of computation: if you need that, use Erlang or LTE.

In CL vs. Clojure, I suppose CL looks riskier to use than Clojure, w.r.t. all those JVM libraries (and the coolness factor). I think this is false, because you can access Java/Clojure/C libraries from CL with ABCL/CFFI, whereas you cannot access the Common Lisp ecosystem from Clojure easily.

But in the end, which programming language you use depends on many factors.

[+] Elrac|9 years ago|reply
Disclaimer: Amateur's blundering travelog.

I've been dabbling in Clojure for about 4 years now, off and on, and it works very well for small-ish projects. The integration, as others have mentioned, with the JVM is superbly seamless (it leaves Scala in the dust in this respect) and this opens up most of the Java ecosystem. Also, the STM model of concurrency management is super cool. So far so great!

But every time I try to build something more substantial than a Project Euler submission, I end up with something blowing up in my face. Recently, I was a bit annoyed to discover that the set of keys of a map doesn't have the same semantics (including sequential access) as other sets, and on another occasion I was debugging something and the contents of some variables that displayed valid data in "print" statements showed as "null" in my debugger. None of this is show stopping but when I'm just playing around I have a low frustration threshold. My impression is that Clojure is a good Lisp with many fantastic new features but not all of the batteries are included (yet).

Meanwhile, I have zero experience with CL but I keep hearing that it's highly mature, rock solid, the choice of most professional Lispers, and the platform of choice for Peter Norvig's book on AI programming. In my imagination, that means everything works exactly as expected and there is a wealth of useful libraries - which would be sweet, from where I stand.

[+] zelcon|9 years ago|reply
I recently gave up Lisp for Clojure instead because of the dearth of "batteries," so this book is very important and timely.
[+] avmich|9 years ago|reply
Can you include a good description of reading macros? I'm still looking for good explanation with examples of their power.
[+] martinflack|9 years ago|reply
You probably mean reader macros. Here are a few resources:

Hyperspec reference for predefined sharpsign reader macros: http://www.lispworks.com/documentation/HyperSpec/Body/02_dh....

A blog post where Vsevolod Dyomkin creates a reader macro to notate list comprehensions to his liking: http://lisp-univ-etc.blogspot.com/2013/01/real-list-comprehe...

A blog post where Inaimathi mentions using CLSQL reader macros to facilitate reading SQL expressions in code: http://langnostic.blogspot.com/2011/03/clsql-and-nothing-els...

Let Over Lambda chapter 4 which has various examples: http://letoverlambda.com/index.cl/guest/chap4.html

[+] junke|9 years ago|reply
A reader macro is not a kind of macros [0].

It is a way to customize the Lisp reader by associating a custom function to an entry in the readtable.

So you can say that character '[' will be tied to a custom reader function, which reads from a stream and produces a Lisp object, at readtime.

The standard sharpsign[1] character is used to read different kind of structures: complex numbers #C(0 1), structs #S(tree :left nil :right nil), and so on.

In particular, you can have sharpsign-dot, which reads a lisp form, evaluates it at read time; the result is the form being read.

Also, you can use #1= and #1# to affect parts of your code to reader variables and reuse them in other places.

If the PRINT-CIRCLE (there are earmuffs around it, but I can't format it here) variable is set to true, here is a quine:

     #1=(print '#1#)
[0] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...

[1] http://www.lispworks.com/documentation/HyperSpec/Body/02_dh....

[+] baggers|9 years ago|reply
I found them useful when I looked at clojure and saw their shorthand syntax for lambdas where #(* % %) is a lambda that takes one argument and squares it. You can get some tidy things that are similar with regular macros but to make it actually equivalent your need to hook into the reader..and that's what reader macros are for. So within the hour I had something that let me write λ(* _ _)

The best bit though, is that this isn't some nasty hack. This is supported by the spec, so I can package this up and let other people us it just like any other functionality we care to ship around.

That's my favorite thing really, being able to treat approaches to writing code in the same way we treat the functionality we make using code.

[+] xenophonf|9 years ago|reply
Do you mean reader macros? Those are used to implement new kinds of syntax within Common Lisp's parser, the READ function. Even standard parts of Common Lisp syntax are defined this way, such as quote (') or backquote (`).

For more examples, see http://lisper.in/reader-macros/.

[+] xyience|9 years ago|reply
A diagram helps when you start getting into read/compile time discussions, see slides 13 through 17 of http://www.slideshare.net/adorepump/clojure-an-introduction-... to see how the evaluation model for Clojure (which is similar enough to Lisp) differs from most other languages. One of the many differences between Clojure and Lisp though is that Lisp supports user-defined reader macro definitions, so you can add things like the nice persistent map literal syntax of Clojure to Lisp if you really want to.
[+] sedachv|9 years ago|reply
Read macros are great because you can use them to turn the Common Lisp parser into a parser for any language you want (no restrictions on the grammar), so you essentially get compilers for free. I wrote a one-pass C preprocessor and parser in just under a thousand lines of code: https://github.com/vsedach/Vacietis/blob/master/compiler/rea...
[+] jonathankoren|9 years ago|reply
It's just a macro. It's pretty much exactly like a #define in C
[+] cadr|9 years ago|reply
Just a nitpick, but I find the code part hard to read. Not sure if it is the colors or what. You might get some other feedback on it. Good luck!
[+] wtbob|9 years ago|reply
Agreed. I think that the line numbers and machine-inserted hard breaks make it difficult to read. For the first issue, maybe the line numbers could be smaller and/or greyer, and offset more? For the second, I think human editing of the lines is probably required.
[+] tropo|9 years ago|reply
It's just the language. Everything looks the same.
[+] TheMagicHorsey|9 years ago|reply
Is it full stack Lisp in the sense that Lisp is running on both the server and in the client (browser/mobile)?

If it is the latter, that would be quite compelling. Clojure/Clojurescript is quite compelling from a developer point of view, since you don't have to switch mental context to develop your server and client code (as you would have to do if you develop Go on the server and JS in the browser).

[+] lokedhs|9 years ago|reply
In Potato we did exactly this. The server side is written in Common Lisp and the client side is implemented in Clojurescript.

While I have to say that it has worked pretty well, Lisp and Clojurescript are different enough that it really isn't much of a benefit to use both together. Even the S-expression format of the two languages are so different that we need to use JSON when sending messages from the server to the client (and vice versa, of course).

Please feel free to look at the code if you want to learn more about how it's done. I'll be happy to answer any questions: https://github.com/cicakhq/potato

[+] pavelludiq|9 years ago|reply
I plan on covering par, but mostly the name came from an attempt to explain the current state of lisp libraries, the "stack".
[+] zelcon|9 years ago|reply
Lisp is a better language than Clojure. People only use Clojure out of force.
[+] TimJRobinson|9 years ago|reply
I'd love to see more books like this for less common languages (Haskell particularly), as I've found there's generally plenty of resources for learning the basic commands and code structure but there's little information for going from those first steps to creating an actual useful application.
[+] sharmajai|9 years ago|reply
I believe this is one of the major goals of http://book.realworldhaskell.org/read/

With this book, we want to show you how to use functional programming and Haskell to solve realistic problems. This is a hands-on book: every chapter contains dozens of code samples, and many contain complete applications.

[+] deckard1|9 years ago|reply
or you realize Perl, Ruby, Python give you everything good from Lisp anyway with an environment and packages that can talk to the real world, and that macros and metaprogramming are massively overrated and a danger in almost any hands that touch those features.

Ask me how long I spent banging my head against the wall trying to get OpenGL working in CMUCL with Alien. Jesus jumping-jack Christ. I can only hope things have improved in the past 12 years or so. But I highly doubt it.

[+] dang|9 years ago|reply
We detached this subthread from https://news.ycombinator.com/item?id=11825955 and marked it off-topic.

We gave you the benefit of the doubt originally, despite the nasty embers burning in your comment, but then you went full flamewar downthread. We don't want that on HN, so please don't do it again.

[+] pjmlp|9 years ago|reply
> Perl, Ruby, Python give you everything good from Lisp

So where are the:

- AOT compilers to native code

- REPL environments with GUI debuggers, with fix-and-continue?

- Ability to do systems programming without having to use an external language?

- Macros

[+] pavelludiq|9 years ago|reply
I did python professional y for a few years and I missed lisp every day. There is much work to be done, but lisp has improved tremendously in the last decade.
[+] nilkn|9 years ago|reply
I don't think that's true. For instance, Python has traditionally been really bad for concurrency but Lisp can be best-in-class (see Clojure's STM). Python is good for single-threaded concurrency now with coroutines and libraries like asyncio, but it still can't compete with something like STM for multithreaded concurrency.
[+] PeCaN|9 years ago|reply

[deleted]

[+] dang|9 years ago|reply
Scott is right: you can't comment like this here. Personal attacks and name-calling will get your account banned from HN, so please don't do it again.

You obviously know quite a bit. Please make your posts valuable to others by being civil and substantive, especially when others know less than you do. Then we all learn.

I like Common Lisp too, and agree with most of the substantive parts of what you've said, but that is less important than preserving this community. We detached this subthread from https://news.ycombinator.com/item?id=11826768 and marked it off-topic.

[+] ScottBurson|9 years ago|reply
Personal attacks are not welcome here.

And as a big fan of Common Lisp, I have to say, this is the kind of evangelism we don't need. (Well, the list of libraries is nice, but the bigotry we can definitely do without. It is possible to express strong opinions without calling others ignorant, or worse.)

[+] crispytx|9 years ago|reply
Why is this on the front page of Hacker News? Isn't this an advertisement?
[+] dang|9 years ago|reply
Work in progress is a fine thing to have on Hacker News as long as there's a way for users to check the work out. In this case there's a sample chapter, which more than clears that bar. In fact we've added "Show HN" to the title, because this is the kind of thing that Show HN is for: https://news.ycombinator.com/showhn.html
[+] mordocai|9 years ago|reply
It's free online and has a github repo under MIT license as well... so yeah it's an advertisement but for something that you can get for free.
[+] taranw85|9 years ago|reply
Isn't everything an advertisement in that case? This is something cool and technical and useful.