Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fullstacklisp.com

Post reply on HN
Print view View original

81–90 of 110 posts

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

#81

Post by wtbob »

Elrac wrote: post #76
haspok wrote: post #73

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?

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

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

It is definitely highly mature, rock solid and the choice of most professional Lispers. It anticipates many problems one doesn't even know one will have, and solves them.

In the negative column, it's a bit crufty for historical reasons (e.g. (aref ARRAY 1 2) vice (gethash KEY HASH-TABLE)) and made some choices which in retrospect were foolish (upcasing symbols being a huge one). The former doesn't really matter, and the latter can be solved with a simple (setf print-case :downcase).

For a long time, there were few good resources for learning Lisp. Fortunately, that's changed. Peter Seibel's Practical Common Lisp (http://www.gigamonkeys.com/book/) is a must-read: it explains a little of why Lisp is so relevant for modern development. Edi Weitz's new book Common Lisp Recipes (http://weitz.de/cl-recipes/) is worth its weight in gold.

Quicklisp (https://www.quicklisp.org/beta/) is a great place to find a lot of great packages.

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

#82

Post by wtbob »

cadr wrote: post #22

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!

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.

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

#83

Post by wtbob »

e12e wrote: post #55
pavelludiq wrote: post #26

Earlier quoted context omitted.

I plan on covering par, but mostly the name came from an attempt to explain the current state of lisp libraries, the "stack".

Interesting book. Your introduction covering toolsets, choice of lisp etc was enough that I bought a copy! I've been seeing (common) lisp everywhere lately, from talks on clasp to the recent(ish) work on (really) fast http parser for lisp etc. It really feels like cl, with the help of a few, but very much needed tools and libraries (like quicklisp) and mature implementations that compile down to machine code could ha…

> Ok, I admit, I still want "sweet expressions"

There's a Common Lisp library on Sourceforge: http://readable.sourceforge.net/

I've been thinking of using it to make a Lisp interface palatable to non-Lispers. We'll see though.

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

#84

Post by pavelludiq »

haspok wrote: post #79
junke wrote: post #75

Earlier quoted context omitted.

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…

Let me try to rephrase my question: I know what I can use Clojure or LFE/Erlang for and what their strengths/weaknesses are. I don't really know anything about Common LISP other than it is a LISP, so I would love to hear some factors that led some people to prefer Common LISP to anything else out there (other than personal preference, which is always a factor). Is it good at number crunching (which is not Clojure's a…

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general purpose implementations. They're fairly performant, especially SBCL, properly optimized code can compete for C-like performance. ABCL gives you Java integration, not as nice as clojures for example, but perfectly usable IMO. ECL has a fairly small footprint and is good for embedding, it can also compile down to C I think. Clasp is a newcomer to the Common lisp world, it compiles to LLVM and provides C++ integration. It's creator uses it for chemistry and nanotech simulations, so he has many C++ libraries he wants to use with Lisp, so he wrote an implementation. There are also commercial offerings(LispWorks, Allegro CL) that come with additional support and their own graphical IDEs.

When I switched from Clojure to Common lisp a few years ago, mostly I really like using multi-paradigm languages. Clojure code wants to be functional. Common lisp code has no such preference, and with the excellent OOP support it's a pleasure to use. Basically it's generic function based, rather than class based, which means that your methods are owned by your generic functions, rather than your classes. This gives you much more flexibility and power than "standard" OOP. I can write software in the style that best supports the problem I'm trying to solve. Other great features include the condition system, basically exceptions on steroids. Very few languages have something similar.

Another one of my favorite features is that the standard has been stable for decades. The core language hasn't changed since 1994, so the ecosystem continues to evolve constantly, but the core stays stable and it isn't unheard of for code written in the 80's to run with little or no modifications. I like the idea that my code might have that kind of longevity.

I could go on, but you get the general idea of having an extremely mature and stable language with many implementations that all try to solve different problems, with sufficient portability that fragmentation doesn't tend to happen(like in the scheme world for example). And personal taste of course, It's just a pleasure to use for some reason. I don't know why, but I'm just having way too much fun playing with it and trying to explain it to others.

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

#85

Post by kazinator »

EuAndreh wrote: post #69
aidenn0 wrote: post #56

Earlier quoted context omitted.

named-readtables has largely solved the packaging issue of read macros.

Yep, named-readtables do a pretty good job on packaging read-macros. You've probably missed it.

Packaging means "better than just loading something and having it pee in the global readtable". It doesn't solve the problem that read macros compete for the same characters and clash.

Documentation for merge-readtables-into:

"If a macro character appears in more than one of the readtables, i.e. if a conflict is discovered during the merge, an error of type READER-MACRO-CONFLICT is signaled."

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

#86

Post by haspok »

pavelludiq wrote: post #84
haspok wrote: post #79

Earlier quoted context omitted.

Let me try to rephrase my question: I know what I can use Clojure or LFE/Erlang for and what their strengths/weaknesses are. I don't really know anything about Common LISP other than it is a LISP, so I would love to hear some factors that led some people to prefer Common LISP to anything else out there (other than personal preference, which is always a factor). Is it good at number crunching (which is not Clojure's a…

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general purpose implementations. They're fairly performant, especially SBCL, properly optimized code can compete for C-like performance. ABCL gives you Java integration, not as nice as clojures for example, but perfectly usable IMO. ECL has a fairly small footprint and i…

Thank you for the detailed answer, I think you could expand on it and include it in your book as an introductory chapter, or even as a blurb (especially the second paragraph).

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

#87

Post by mark_l_watson »

Elrac wrote: post #76
haspok wrote: post #73

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?

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

Some advice for Clojure that applies to all lisps: write code bottom up in small pieces making heavy use of the repl for development. Really understand what your small piece of code does, clean it up, put it in a separate small file, and once you have confidence in it think of it as a library that just works.

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

#88

Post by eggy »

PeCaN wrote: post #35
shoover wrote: post #25

Earlier quoted context omitted.

+1. Kenny Tilton's blog is also great for that kind of thing. "You know Lisp is the perfect language precisely because it lost its momentum (died) and lives on. Other languages need their Next Big Thing momentum." http://smuglispweeny.blogspot.com/2013/08/wow-even-lispers-h...

I think the journey of a Lisper inevitably ends up with realizing that Common Lisp is not an acceptable Lisp. Then you start searching for an acceptable Lisp. You look at Tcl, at Prolog, Io, Rebol, and Icon; you learn Shen, try Scheme and Racket, appreciate Smalltalk and Self and Slate, wrap your head around Forth and Joy and Factor… and the whole time you write Common Lisp. Because there is no acceptable Lisp.

I fit this description minus a few of the PLs you listed, and added Extempore's xtlang, PicoLisp, and LFE (Lisp Flavored Erlang), but I am hacking in CL again this week!

I still think Shen has lots of potential.

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

#89

Post by marcosdumay »

sharmajai wrote: post #20
TimJRobinson wrote: post #17

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.

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.

Unfortunately, that book is dated. It's not even that old, but it's already dated.

Haskell has a discoverability problem, and a good modern book might be the best way to solve it. But it may be moving too fast for that currently.

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

#90

Post by dang »

lispm wrote: post #68
dang wrote: post #63

Earlier quoted context omitted.

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…

Why not remove that obviously trolling comment?! It has no value and the list of stuff does not need to be preserved. The Lisp community has already good pointers to resources. This is another troll who calls others 'retarded' to stir up controversy and have fun with it. Please remove it.

We don't do that as moderators, short of banning the account. I'm not banning that account because its other comments are fine, and it's better to assume that people are willing to improve.

HN's mechanism for dealing with individually bad comments is user flags, and the two bad comments in question have indeed been flagkilled.

Post reply on HN