Hacker News Reader

1: I really don't see how CL or Clojure are any more complicated than, say, Rust or C++. If anything, CL and Clojure are simpler, just different.

3: Most useful libraries are portable between different CL implementations. The choice is really "CL or Clojure or which Scheme implementation?" Not to discredit Picolisp or Shen, but those languages feel very much (esp. Shen) like a research language. Picolisp has more of a convincing productivity story, but doesn't seem like it has the momentum of existing competitors and I fail to see an advantage in using it. Depending on your goals, the choice between Lisps can be pretty simple.

5: Portacle is helping in this area by making it much easier for a beginner to learn CL without fussing with setting up SLIME and Emacs. Clojure also has an IntelliJ plugin, cursive. For Scheme, Racket seems like a painless way to start learning.

6. You can easily go multi-core in CL. It isn't as easy as Clojure, but it's definitely easier than C++ or Java (the language).

7: Clojure has access to all of Java's libraries. CL does struggle compared to Python in this area.

8: Lisp related books are among the best in CS. SICP, LoL, etc. are timeless.

The Lisp family of languages definitely have room to improve, but the ecosystem is healthier today than 20 years ago, for sure.

>Lisp related books are among the best in CS. SICP, LoL, etc. are timeless.

Lisp books also tend to have the characteristic where you have to find the "right" compiler for the examples to work. I've yet to pick up a book where all the examples "just work".

Land of Lisp worked well for me. Can't remember any major issues. (That said, I think I also used racket for most of the work, so I had to change some things consciously.)

Though, this is a bit of a hard problem for authors. Most code that can fit as snippets or short examples does not have what any code in real projects would have. To that end, the code is literally made mainly for you to try and simulate in your head. Running on a computer is a convenience and should be used, but the goal is to internalize it all. Right?

I wonder if LoL was not referring instead to Let Over Lambda which I'd call more timeless... For Land of Lisp there is some implementation specific code the author uses, but he points that out, points out that there are libraries that make a de facto standard for the behavior, but didn't want to introduce quicklisp. (It's a fun book but not the best if your goal is getting productive in a work environment fast, in which case learning about asdf and quicklisp early on is crucial...)

Lisp books in my experience have been the most reliable for running old code. I can take Lisp code from 1960 and almost entirely unmodified run it in a modern Common Lisp implementation because there's a direct line of heritage. If a book from the 90s says it supports Common Lisp, well hey, barring errata the code still works every time...

That form of stability is one that I really wish modern developers would aspire to. I love that I can still run code in some of the old books. Seems the newer my book, the less likely I am to be able to run its code. :(

"Lisp books also tend to have the characteristic where you have to find the "right" compiler for the examples to work."

Probably true of every programming book more than a couple of years old.

> building an mp3 database would be one line of code or two in python

You mean because of the availability of libraries, so that the code would be something like

  import some_database_library
  print("Look, I have a database:", some_database_library.connect())

?

Otherwise, how do you build a database (or anything involving MP3 files) in a few lines of Python, and how is it so much worse in Lisp?

I mean the 1/2 page code was basically a built in dictionary in Python...I felt it was a step backwards. And this is someone who was very open to Lisp...I still think it has value...just a steep learning curve.

You mean this exercise:

http://www.gigamonkeys.com/book/practical-an-mp3-database.ht...

This is building a rudimentary in-memory database supporting SQL like queries. I didn't realize Python dictionaries support schema definitions and "select" queries?

>3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new

You are mixing things into that list. Common Lisp, Racket, Clojure, and Shen are different languages, serving different purposes, etc.

"Franz", "Allegro", "ABCL", "SBCL" are implementations of Common Lisp, exactly the same language.

ALGOL-family languages are also "fractured" into Algol-68, Pascal, Go, Ada and others, that's not a problem, since they are really different languages that give different benefits/etc.

>"4.) poor windows support for SBCL"

SBCL works just fine on windows. But if you don't like, just use CCL (Clozure CL). I'm currently on a Lisp project which runs equally great in SBCL and CCL. CCL is professional quality software.

>6.) multi-core seems to only be in Clojure

False. There are many libraries to do all sort of concurrency and multiprocessing on Common Lisp.

>8.) learning resources are very hit or miss

At least for Common Lisp, there are books that are arguably some of the best books on programming ever written, like "Practical Common Lisp", or PAIP. For Scheme, "Structure and Interpretation of Computer Programs" is already a high-rated classic.

>notice how many people equate lisp with personal projects?

Except when it's used by Rigetti for quantum computing, or Grammarly for the core server of their core business.

You quoted two companies using Lisp when there are millions of Java devs. That's like a boxer with a record of 1-500. I love Lisp, but c'mon...I guarantee it has far more hobby users than professional users.

ABCL, FRANZ, ALLEGRO, SBCL, CLISP, GNU CL, Clozure might all be common lisp, but they are different implementations with different tools that will confuse a new person and several cost money.

Practical Common Lisp isn't very good in my opinion, that was the example i actually used. SICP is great for a mind-opening experience, but not super useful on how to write modern software and is why the creators dropped it at MIT.

For multi-core I'd rather it be core than a library, but perhaps that is petty of me.

I think Lisp is great, but why it isn't popular shouldn't be a mystery to anyone.

"they are different implementations with different tools that will confuse a new person and several cost money."

Right, just like all of these stop developers from learning Java:

https://en.wikibooks.org/wiki/Java_Programming/Java_IDEs

"SICP is great for a mind-opening experience, but not super useful on how to write modern software and is why the creators dropped it at MIT."

Bullshit.

Anyone who can understand and apply the lessons in SICP will be far more productive developers than someone who just memorized some git commands and knows how to bang their head against Spring Boot until something almost useful eventually comes out.

Outside of those two points, I mostly agree with your general thesis.

How many times have you written a metacircular evaluator in production? How many people code just fine without knowing Maxwell's Laws of Software as one popular blog post describes? Peter Norvig's review on Amazon agrees with you, I just think it is a bit overrated with infinite respect to Norvig as he could probably force choke me with his mind from 5 miles away :)

>You quoted two companies using Lisp when there are millions of Java devs.

So what? I was a Java dev myself. What does this mean?

There are even more millions of Javascript users. What does this mean, really?

>ABCL, FRANZ, ALLEGRO, SBCL, CLISP, GNU CL, Clozure might all be common lisp, but they are different implementations with different tools that will confuse a new person and several cost money.

Fear, Uncertainty and Doubt.

They all implement ANSI Common Lisp.

Right now i'm doing a project (not personal, it is for a company) and it runs on SBCL and CCL without any change. It would probably also run on ABCL straight away. It uses software transactional memory, bridges to C libraries and other stuff that isn't on the ANSI standard, yet it can also be written, very easily, in a portable way.

So, what you write is FUD.

>and several cost money.

More FUD. From your list, only Allegro CL (= Franz) costs money.

>Practical Common Lisp isn't very good in my opinion, that was the example i actually used. SICP is great for a mind-opening experience, but not super useful on how to write modern software and is why the creators dropped it at MIT.

SICP is not for writing modern software, is for understanding fundamentals. If you develop without having a solid grasp of the fundamentals, you become a "CODE MONKEY" (caps intentional), and this is what MIT is in danger of producing now (i'm not the only one to criticize the MIT for dropping SICP...)

My point is simply that niche languages are harder to hire for and find a job in. Most people aren't okay with that. There is a feedback loop here as less people use it and less libraries are written. That doesn't mean the language is inferior to Java in any way, but a new developer has to stay relevant by learning languages and frameworks that people use in-house. This is a major reason it isn't popular. I have 300 people in my IT department. They've all heard of Java & C#, but I've never run into anyone who has even heard of Lisp (maybe that is marketing).

You don't have to hire for Lisp, or any language for that matter. Picking up a language is way easier than fundamental skills (statistics for AI for example). IIRC Dan Weinreb of ITA fame said they gave their new hires a copy Practical Common Lisp and two weeks. You know, the book that you dissed earlier in the thread w/o an argument.

> less libraries are written.

Given that Sturgeon was an optimist[0], that is hardly a problem. The only reason why most OSS libraries are using is because people don't do the due diligence of vetting their dependencies. There are more than enough libraries of adequate quality for common tasks.

[0]: “And folks, let’s be honest. Sturgeon was an optimist. Way more than 90% of code is crap.” – Al viro

Once again, you quote isolated incidents when I'm talking about the entire programming industry. I never said it wouldn't work for some people.

It might have been Tarver talking about the Lisp curse. Lisp is so powerful that everyone kind of does their own thing while devs of C++ and Java have to band together and make massive libraries. This is a different argument, but I think your discounting the usefulness of some of the gargantuan libraries and frameworks out there. I'm not saying fundamentals aren't good, but a data scientist doesn't need to know about homoiconicity...they need Numpy/Scypy.

> ABCL, FRANZ, ALLEGRO, SBCL, CLISP, GNU CL, Clozure might all be common lisp, but they are different implementations with different tools

That's better than having different languages with different tools: Python, Ruby, Perl, ... share nothing - though they are in a similar coding domain.

Fair enough argument here, although you could probably still argue that it is easier to setup most of those languages than use emacs. That's a non-starter for a lot of devs who aren't open to the long-term benefits.

True. You probably mean GNU Emacs and (not so popular right now) XEmacs.

Even I usually prefer to use other Emacs variants for Lisp programming: Fred, Zmacs, LispWorks, CCL, ... I prefer embedded Emacs variants which are written in Common Lisp.

With Lisps without embedded Emacs variants, usually GNU Emacs / SLIME is the best option. I can understand that this is for people used to other editors (like Eclipse, Intellij, Atom, ...) not very tempting.

GNU Emacs is especially used because that's the most widespread programmable editor, which can be extended in Lisp itself. For a non-lisp programmer that's initially not very important.

Yea, I was talking about GNU Emacs + Slime. I'm with y'all that Lisp is an extremely powerful and frankly astonishing piece of engineering. It just seems to cater more to those on the fringes and those willing to put in the work to achieve enlightenment.

I've read a few Lisp books and have written a bit of Lisp code and understand code is data is code, but haven't put in enough time to really reap the rewards. I think my above posts were taken as an insult to the language rather than some observations over several years of playing in the community. One day I hope to join your ranks, but most of my current needs involve needing lots of built in language constructs for data analysis and scientific needs.

No, I think such observations are valid. I mainly tried to add that even for me, a long time Lisp user, GNU Emacs / SLIME is not the primary tool. There are a few groups and a large and visible group is using SBCL + GNU Emacs + SLIME. But there are other groups.

Ah thanks! I recall you work for one of the commercial lisp vendors. I assume you use their IDE environment that is similar to emacs? How do you describe using it?

I don't work for a vendor, but I use commercial and non-commercial Lisps with other editors.

Typically they are simpler to use, better integrated into the platform, have less features (no games, no latex modes, no org mode, ...), have simpler key commands, are multi-threaded, are directly integrated into the running Common Lisp, don't implement all tools as editor buffers, ...

Thanks for the synopsis as I don't see a lot of information on the Lispworks and Allegro sites.

They have tryout versions.

Editor User Guide of LispWorks:

http://www.lispworks.com/documentation/lw71/EDUG-M/html/edus...

IDE User Guide for LispWorks:

http://www.lispworks.com/documentation/lw71/IDE-M/html/ide-m...

None of them will confuse an old person armed with Vim and a command line. :)

Just they have different IDE's and REPLs.

That's like saying Visual C will confuse someone used to Turbo C. So C is bad.

6 - what about https://common-lisp.net/project/bordeaux-threads/

lparallel[0] is a higher-level abstraction built on threads. I use it for spawning threads which execute OS commands and wait for the results, without blocking the main thread. Works very well.

And anyway, if you want concurrency and/or paralellism, just go for OTP (Erlang, Elixir, LFE).

[1] https://lparallel.org/overview/

... or STMX, which provides software transactional memory on Common Lisp in an ultra-easy-to-use way.

I'll definitely take a look at that, thank you!

These things all exist, but a lot of them seem like a library from one author as opposed to what is built-in to Java or .NET and had lots of people and money thrown at it. I'm sure the author is a wizard, but how good can the quality be? I don't have any proof here, but my suspicion is bugs and sparse documentation.