I recently gave up Lisp for Clojure instead because of the dearth of "batteries," so this book is very important and timely.
Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
71–80 of 110 posts
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#72Is 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).
Lisp is a better language than Clojure. People only use Clojure out of force.
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#73I'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?
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#74Can you include a good description of reading macros? I'm still looking for good explanation with examples of their power.
It's just a macro. It's pretty much exactly like a #define in C
This is pretty much wrong. C macros have a simple substitution language. But all Common Lisp macros can run arbitrary common lisp functions to compute the macro expansion. That means, you are not limited to pattern matching, but can write a program - in the same programming language you are using for your application - to compute the expansion. Of course there are simple cases which are just syntax rewrites, but there are also complex cases, like the loop macro. The loop macro allows you to specify looping constructs in an almost natural language.
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#75I'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?
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.
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#76I'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 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.
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#77I'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…
>"... with the JVM is superbly seamless (it leaves Scala in the dust in this respect) ..."
Uh, what?
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#78Earlier quoted context omitted.
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…
>"... with the JVM is superbly seamless (it leaves Scala in the dust in this respect) ..." Uh, what?
I would say "mud" instead of "dust".
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#79I'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?
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 and definitely not Erlang's forte)? Is it good at low level systems programming? Is it good for computers with low memory resources? Etc. In your words, I am looking for the context.
Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps
#80I'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…
Clojure seems to be a natural choice for microservices, but I never used it for anything on a larger scale. Good point, if it is something Common LISP gets right it is definitely worth a look!