Comment by armitron | Hacker News Reader

Comment by armitron | Hacker News Reader

Parent Full thread

(Mostly talking about SBCL)

Mature native code compilation (including runtime assembler), type declarations that lead to optimizations in generated code, SBCL compiler can use declared types for compile-time type checks, read/compiler macros, extremely easy interface to C (JNI is a pain in the ass), multi-paradigm and doesn't prematurely optimize like Clojure (I have no need for STM or immutable data structures in 99% of the things I do), very powerful and flexible debugger, CLOS, more sophisticated interactive development.

Clojure is a no-go for me primarily because it's tied to the JVM (or worse, Javascript) and the Java ecosystem but also because it prematurely optimizes with the sort of decisions it has made in the design space (immutability, STM, crippled reader, not Lispy-enough debugging and so on).

Common Lisp is much more flexible in the sort of problems it allows you to explore and attack. Even the special features of Clojure (STM, immutable data structures) can be used in Common Lisp via existing libraries.

Finally, for me Lisp == Lisp Machines and Clojure is a big step back in that regard (and not really modern at all) since it de-emphasizes (by lacking things that Common Lisp has) the interactivity that made Genera so iconoclastic and powerful.

Clojure was my first lisp; I use it every day at work, especially on JavaScript. ;) The (semi-)joke is that the reason Clojure targets the JVM and JS runtimes is so we can get paid to write it.

However, I have started playing with Lisp (SBCL) a bit in my off time and am finding it interesting. I have a desire to write some CLI applications and think Lisp might be a better fit than Clojure. I was drawn to it for a lot of the reasons you note:

1. Native compilation

2. Reader macros

3. C FFI

4. Debugger

But it's also a bit like learning how to write with my left hand; my brain has been warped by Clojure to eschew place-oriented development and reduce mutability to a pinpoint. Lisp is completely, unabashedly mutable (which gives a lot of room for improved performance vs. immutable) and I'm struggling with it.

One way to use Common Lisp with a more immutable flavour is to use the folio2 library.[0]

I have enjoyed exploring it a great deal. The project's readme, explains it better than I can:

"folio 2 is a collection of small libraries that provide support for functional idioms and data structures in Common Lisp and a common set of APIs for working with them.

"It's a direct descendant of the older and simpler folio library, with a greatly expanded and reorganized API, and support for more data structures and procedures.

[0] https://github.com/mikelevins/folio2

If you want to use functional (immutable) collections in Common Lisp, try FSet [0]. (It's QuickLisp-loadable.) FSet greatly expands the space of programs that can naturally be written in a functional style in CL.

[0] https://github.com/slburson/fset

I have looked heavily at FSet :). I'm at a cross roads now with whether I try and push the Lisp block into the Clojure hole in my brain, or whether I should try and learn Lisp as it is and it's idioms.

FSet is really cool and I'll probably end up using it in conjunction with https://github.com/fiddlerwoaroof/cl-edn

When learning new languages I think it's always beneficial to drink the kool-aid and go as full idiomatic as you can, then step back and reflect once you're competent enough. (That may take a while with CL if you're not doing it professionally, there's a lot in there! I'm still on my own plodding journey to CL competence...) My reasons are for the personal side that doing so should help maximize the "learn new language to change how you think about programming"¹ side-effects and on the social side doing so should help understanding and interacting with other users and code in that community. It can be really frustrating to me when I read Python code written by a career Java developer who never bothered to understand what "Pythonic" is. I don't want to be that guy for someone else.

¹Incidentally this http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h... is my favorite high-level article around one of those potentially mind blowing differences that is Lisp's condition system, written by someone who has spent a lot of time considering fundamentals of programming like what it means to be in an exceptional situation and how to handle it.

It is illuminating to read the output of such minds as Kent Pitman, Dan Weinreb, David Moon, Richard Gabriel, Rodney Brooks, Guy Steele and what they have to say about Common Lisp and the standardization process, in places such as comp.lang.lisp (the entire archive can be found online) and elsewhere. The depth and clarity of thought, the foresight, the attention to detail and the guiding principle of trying to find the "right" vs the "easy" solution (this is beautifully illustrated in "worse is better" by RPG).

Compare and contrast with the designers of today's popular programming languages. There is something severely lacking in the minds behind PHP/Javascript/Python/Ruby and other languages where projected popular appeal and "easy" is the prime design consideration.

Are we worse off? I think so, not just for technical reasons, but because we have lost something greater that can not be easily put into words.

Yes, the evolution of Lisp was guided by brilliant people. I regret throwing out so many of my old Computer Science related books over the years (e.g. the Interlisp Reference Manual) because the few that remain remind me of the history of programming that has occupied so much of my life.

While being nostalgic about the early days of programming languages, I am not as pessimistic about the current state of the art. There were plenty of old programming languages that have faded away despite being important in their day (IBM's PL/1) and lots of work on new languages is pushing in interesting directions (Haskell, Idris).

Common Lisp has hung on and perhaps survivor bias has made it seem special, but to me, it is special. While working with it I feel that I am working with a language of the future from the past.

The landscape of calculation is much bigger than it was half a century ago, when I started programming. It is populated by an enormous ecosystem of processing units from tiny to enormous, embedded to networked across the planet, with single processors to high performance multiprocessors. All of this is controlled by programming and the programmers that wrestle the world of computing into submission. In this Hobbesian ecosystem some languages have prevailed for many years, like Java and C, others have survived even longer like FORTRAN and LISP, and some have simply proliferated rapidly, like Python, all for reasons that are complex and involve human abilities and computer architectures. Not all of them are beautiful, Lisp is, but all of them have a place even if only to reveal what does and doesn't work.

> mind blowing differences that is Lisp's condition system

It's similar mind-blowing when you think about this: that people wrote and used an operating system in the 70s/80s in Lisp, where the condition handling system was in full effect throughout the whole user experience (for example when using the file system, the network, the development environment, etc). With all the pros and cons...

I do like Clojure for some of its opinions (immutable by default, strong encouragement of functional programming, convenient abstractions for collections, tasteful syntactic sugar).

But, I too am not necessarily a huge fan of the ecosystems that Clojure is presently tied to. I'd love to see an SBCL implementation of Clojure or (especially) an LLVM based Clojure. I'm grateful when Clojure offers me an out from writing Java, but I also feel like I need to understand both the Java and the Clojure.

The Rackjure dialect of Racket is pretty nice by my estimation (adds some of the conveniences of Clojure, isn't tied to / the beneficiary of an ecosystem like the JVM or Javascript). But I suspect it would frustrate people who like aspects of the CL ecosystem like long-lived system images, and a very neutral disposition toward immutability and functional programming.

Clojure isn’t really worth anything without the jvm/js ecosystem.

It’s a glue language for assembling components, most of which are written in Java.

Timothy Baldridge wrote a python based language heavily inspired by clojure called Pixie. That gives a feel for what clojure is like without the ecosystem. Basically it means reinventing many many wheels.

I don’t know—there are certainly some interesting / different things in Clojure as compared to other lisps. Even if you can technically do much of what Clojure can do in other lisps, idiomatic Clojure has a feeling that is distinct from CL, Scheme, or even Racket.

If Clojure offers nothing without the large JVM/JS ecosystems, then we could say the same about most languages (that aren't the size of Java/JS).

If it’s that the distinct cocktail of features and ideas in the language aren’t worth anything, then I’d respectfully disagree. But at that point we’d simply be arguing aesthetic preferences.

Well that's the problem isn't it.

Any new language today has little to compete with existing languages in terms language features, the competition is in terms or the library ecosystems, online help and overall ecosystem. That takes time and money to build.

Given how large the Java ecosystem is, and what it took in terms of money and time to go there is not easy or even possible to match in any relative comparison.

So it makes sense to make sacrifices(if needed) to re use all that Java work that has been done and has been going on over the years.

Clojure is the best thing that has happened to Lisp in years.

Agreed, regarding the effort required to compete on completeness. However, somewhere in between “fad language of the week” and “let’s use nothing but C, because nothing will ever compete” I do think there’s room for new languages.

I’m old enough to remember a time when Java and JavaScript didn’t exist. They, for better or worse, climbed Mt. Improbable to become widespread. Ditto Python. I’d sure love to believe that a better set of languages could also climb that mountain.

Clojure has certainly gotten a leg up by grafting itself onto Java’s ecosystem, but as you point out, there are sacrifices (stack traces, and inability to support things like TCO for two). Ultimately, I’d love to see a combination of two things happen:

- More libraries that work across all implementations of Clojure

- At least one or two implementations of Clojure where the mismatch between the host platform and Clojure is minimized to useful effect.

On the last point, I’d love to see Clojure hosted on Common Lisp. I don’t hold much hope for this given the toxic reaction that many Common Lispers have for Clojure, but I can see benefits in both directions.

For Clojurists, CL has the benefit of running in lots of different contexts with some useful performance characteristics in some cases (SBCL, I’m looking at you). I also believe a Clojure-on-CL implementation would have the possibility of good stack traces.

For Common Lisp, rather than Clojure just being a mindshare theif, pure-Clojure libraries would become usable to the CL community.

Sadly, I think we’ve already achieved peak collaboration between the Clojure and CL communities. The people who liked what Clojure was about already enthusiastically left, and the remainder seem to mostly harbor sour grapes.

> Clojure is the best thing that has happened to Java in years.

FTFY

Reply on news.ycombinator.com