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

Alright, controversial opinions time. (Before you downvote me out of spite, consider if this elaborates on why Lisp is still a much better language. That said, I fully realize this is an angry rant… and yes, I did call you a shit programmer.) Oh, and Common Lisp is one of the best languages for graphics programming around, so if you wade through the rant you'll see how stupid and ignorant it is to claim things haven't improved in 12 years….

Anyone who thinks "Perl, Ruby, Python give you everything good from Lisp anyway" has either never learned any Lisp or is an utterly helpless imbecile who entirely missed the point of Lisp. About the only good thing from Lisp those languages have is anonymous functions (except Python, which apparently decided anonymous functions are much too powerful to include in a programming language—after all, someone could potentially write confusing code with them).

Python gives you nothing. Python is the new Java is the new COBOL. Shit language. Avoids anything remotely powerful or useful at all costs. Funny thing is, it could be pretty expressive if the community didn't discourage the use of the powerful features. Languages like Python are for shit programmers who avoid features like macros and metaprogramming. Python is for people who think "readable code" means explicit code, not code that models your problem domain. Python both failed to learn anything from languages that came before it AND failed to keep up as languages developed. It's rather impressive how big a steaming pile of shit Python has become, and how the people stuck wading through it seem not to notice. Blub in a nutshell.

Perl and Ruby are much better, as at least both of them embrace their power. Arguably Perl and Ruby are very Lispy, actually. They're both inelegant, butt-ugly Lisps, but at least they're Lisps. Why not just use a real Lisp, though?

> environment and packages that can talk to the real world

Maybe if you're stuck in 1990, but the so-called "library problem" has hardly been an issue. There are a _lot_ of Common Lisp libraries out there, and they talk to the real world just fine. Speaking of which, OpenGL is quite usable from Common Lisp¹ (as is Vulkan², if that's your fancy). Heck, there's an interactive OpenGL REPL for Common Lisp³. AND there are mature SDL bindings⁴ AND a Processing-like tool that uses them to enable rapid prototyping⁵. There's also a nifty game engine that updates live as you code⁶. Fun stuff. Common Lisp somehow became a really really good language for graphics programming.

Oh, and there are a number of high-performance HTTP servers⁷ ⁸ ⁹, if you like to write web applications in Common Lisp. Nice PostgreSQL bindings too¹⁰.

Heck, the "real world" includes bare metal hardware, so why not write an OS in Lisp? ¹¹ ¹²

You can use GTK3¹³ or Qt¹⁴ for GUIs, if you prefer that over OpenGL or a webapp.

Other useful libraries:

Crypto:

libsodium https://github.com/orthecreedence/cl-sodium

Databases:

Redis https://github.com/vseloved/cl-redis

CouchDB https://common-lisp.net/project/clouchdb/

Math:

Linear algebra https://github.com/blindglobe/lisp-matrix

GNU Scientific Library https://common-lisp.net/project/gsll/

And for the grand finale, you can use all your beloved Python libraries from Common Lisp:

https://github.com/metawilm/cl-python

Time for the extra potshots at your ignorance, sorry, I couldn't resist:

> macros and metaprogramming are massively overrated and a danger in almost any hands that touch those features.

And that's when I realized you're either a troll or massively fucking retarded. We really mustn't let those devilish programmers use any powerful features to adapt the language to their problem at hand. Yikes. I'm definitely calling bullshit on you ever having used any Lisp. (Or then again, maybe you did and you're braindead, which is looking more likely. Don't let that extra chromosome get you Down!)

--

¹ https://github.com/3b/cl-opengl

² https://github.com/3b/cl-vulkan

³ https://github.com/cbaggers/cepl

⁴ https://github.com/lispgames/cl-sdl2

⁵ https://github.com/vydd/sketch

⁶ https://github.com/BradWBeer/clinch

⁷ https://github.com/edicl/hunchentoot

⁸ https://github.com/fukamachi/woo

⁹ https://github.com/vii/teepeedee2

¹⁰ https://github.com/marijnh/Postmodern

¹¹ https://github.com/whily/yalo

¹² https://github.com/froggey/Mezzano

¹³ https://github.com/crategus/cl-cffi-gtk

¹⁴ https://github.com/commonqt/commonqt

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 have a bit of a renaissance.

I think a lot of people simultaneously realized that one didn't have to code old style lisp, just because the cl spec has been written. Like the project to reimplement cl in cl. There's no need to rely on old broken crutches, just take the good parts of cl, combine with 40 years of experience from system and language engineering, and reduce back down to cl. And suddenly you have something very elegant and efficient and powerful.

Ok, I admit, I still want "sweet expressions"[1] -- but I think just a simple thing like acknowledging that global variables with * earmuffs * , are still global variables - and generally a bad idea -- and that cl is much more than some small "functional" language goes a long way. I remember I came to lisp rather late, and was confused by how un-functional a lot of the code was. There was just a lot of messy examples with detached functions for manipulating ad-hoc data structures that didn't seem properly motivated at all. And it all seemed terribly brittle.

But if one ignores all of that (and a lot of the classic lisp books), what emerges is that the "good" parts of cl are really great, and there's really no reason not to use those parts. And the warts in moderation (as with any other language).

[1] http://srfi.schemers.org/srfi-110/srfi-110.html

Actually the entirety of Common Lisp's parser except for numbers, symbols, and the consing dot are implemented as read macros.

It's just a macro. It's pretty much exactly like a #define in C