
A new version of Common-Lisp.net has been launched - kamaal
https://common-lisp.net/
======
serialdev
This really makes me excited, there is no reason why we cannot implement a
thorough type-system like qi and shen on top of common-lisp for massive teams,
the repl experience is still unparalleled, and I for one would love more
libraries popping up, so maybe more people can make a business case for it.
Machine learning in python is nice, but I would definitely enjoy common lisp
for it too!

~~~
lisper
> there is no reason why we cannot implement a thorough type-system like qi

The SBCL compiler actually has a type inference engine built in to it.

~~~
rayiner
(I feel sheepish even saying this to you), but when people say "type
inferencing" I think these days they tend to mean "inference of static types
that are enforced at compile time within a rich static type system." SBCL
infers static types within a (mostly) dynamic, permissive type system. It can
enforce certain constraints at compile time, but it’s ad hoc (there is no
well-defined model of what properties it can prove at compile time on any
valid code).

~~~
ken
Is there an alternative term which has arisen for what Lisp traditionally
calls "type inference"?

~~~
rayiner
SBCL calls it type propagation, which is fairly descriptive. (At least in
SBCL, it's implemented as a data flow analysis that propagates constraints on
the types of lexical variables: [https://www.pvk.ca/Blog/2013/11/22/the-
weaknesses-of-sbcls-t...](https://www.pvk.ca/Blog/2013/11/22/the-weaknesses-
of-sbcls-type-propagation)).

------
lisper
Also worth noting if you're on a Mac then in addition to PortiCL there is also
Clozure Common Lisp which has a very nice Mac-native IDE:

[https://www.clozure.com/ccl/](https://www.clozure.com/ccl/)

CCL itself is multi-platform but the IDE is currently Mac-only.

~~~
kamaal
As someone new to Lisp. The following thing has always fascinated me. I've
read some older posts on comp.lang.lisp and people insist on buying a 'high
performant' Lisp. I think what they mean is Allegro CL or Franz Lisp.

But why is it 'high performant' compared to other implementations? Like say
CMU CL(now SBCL).

For example, in this case why would one use Clozure CL instead of SBCL?

~~~
lisper
> Allegro CL or Franz Lisp.

Same thing. Franz is the company. Allegro Lisp is the product. Like "Apple
Macintosh computer."

> But why is it 'high performant' compared to other implementations? Like say
> CMU CL(now SBCL).

Somewhat better compiler, but mainly lots of extra features (better debugging,
graphics, better libraries).

> why would one use Clozure CL instead of SBCL?

I use CCL because 1) I like the IDE and 2) its compiler is _fast_ so you can
always compile everything essentially for free. In other CLs you have to
choose between running in compiled or interpreted mode, and that can sometimes
cause problems. CCL doesn't have an interpreter at all. It always compiles
everything and that makes it easier to use.

~~~
kamaal
What resources would you recommend one read to understand more about debugging
facilities in Common Lisp?

~~~
lisper
Debugging facilities are not standardized so you'd need to consult the
documentation for whatever implementation you are using. e.g.:

[https://franz.com/support/documentation/10.1/doc/debugging.h...](https://franz.com/support/documentation/10.1/doc/debugging.htm)

[http://www.sbcl.org/manual/#Debugger](http://www.sbcl.org/manual/#Debugger)

------
TurboHaskal
I like this one more [https://lisp-lang.org](https://lisp-lang.org)

~~~
muraiki
As someone with glasses, that default text size is much more readable for me.

------
chicagoscott
I'm very glad to see this. I'd also like to see a new Lisp book, with an
animal on the cover:

[http://www.andrewlangman.com/articles/the-missing-lisp-
book....](http://www.andrewlangman.com/articles/the-missing-lisp-book.html)

~~~
lispm
This is a good one:

[http://weitz.de/cl-recipes/](http://weitz.de/cl-recipes/)

~~~
chicagoscott
Thank you, it does look good. I still want one with an animal on the cover!

Or, more seriously, I think an O'Reilly book on common Lisp would go a long
way toward promoting the language. As would one from the Pragmatic
Programmers.

~~~
lispm
[http://shop.oreilly.com/product/9781593272814.do](http://shop.oreilly.com/product/9781593272814.do)

Though it is an alien...

Btw., for a decade or so O'Reilly actively refused to publish Lisp books -
which did not make them very liked in the community.

~~~
vram22
>Btw., for a decade or so O'Reilly actively refused to publish Lisp books -
which did not make them very liked in the community.

Interesting, any idea why? I would have thought they would have been happy to
publish Lisp books, since they have published books on so many other computer
subjects. I used to be a huge buyer and reader of their books. Only reason I
can think of for them not wanting to publish Lisp books is perceived small
market size - do you think that was it? But on the other hand, they did
publish books on topics like XML-RPC, which was probably not very much used
even when they published a book on it. I had that book, it was about using
XML-RPC from multiple languages [1].

[1] Programming Web Services with XML-RPC:

[http://shop.oreilly.com/product/9780596001193.do](http://shop.oreilly.com/product/9780596001193.do)

~~~
lispm
O'Reilly then:

We're NOT looking for:

Books that overlap too heavily with our existing books. Books on proprietary
technologies that don't have a huge user base. Books on miniscule (i.e.,
personal or nascent) products, even if they are open source. Books on topics
that have dismal sales despite quality books being available. (If you're
addressing a topic where good books have sold dismally in the past (for
instance, LISP, LaTeX, or Web-based training), you have a much higher
threshold to clear with your proposal. Convince us why there is a revival of
interest in your topic, or why your approach to a deadly topic will provoke
interest nonetheless.) Books that have been rejected by other publishers, in
most cases.

~~~
vram22
Got it, thanks.

~~~
lispm
Note the nested parentheses in that paragraph.

~~~
vram22
Nice. (Got defun :)

------
gibsonf1
Very nice site - well done!

There are some very good lisp libraries on github that aren't in the project
list, such as many of the web libraries I use every day like
[https://github.com/fukamachi/caveman](https://github.com/fukamachi/caveman)
or
[https://github.com/fukamachi/dexador](https://github.com/fukamachi/dexador)

I've also started a new library for creating a Solid Pod host
[https://github.com/gibsonf1/cl-solid](https://github.com/gibsonf1/cl-solid)

Is there a way to elegantly link to github projects as well?

~~~
vindarel
Hey they are on the libraries page: [https://common-
lisp.net/libraries](https://common-lisp.net/libraries) (taken from
[https://github.com/CodyReichert/awesome-
cl](https://github.com/CodyReichert/awesome-cl))

~~~
gibsonf1
Excellent!

------
village-idiot
It’s interesting seeing lisp try and make a comeback, I wonder if it’ll work.

As one of the few programmers who has worked in CL commercially in this
century, my general analysis is that the language has way too much rope. The
code base I worked on wasn’t too clever by half, it was too clever by leaps
and bounds. I’d genuinely never start a multi engineer project in Lisp ever.

~~~
TeMPOraL
As one of those few who also worked in CL commercially in this century, I
disagree. The amount of rope is fine. There's just a big library and
documentation problem. You can find a library for anything these days, but
quite often it's only half-done, and you need to write the other half
yourself.

The way I see it, all the power and flexibility of CL is what keeps it alive;
any other language would have died off with so little people working on the
libraries. I used to not mind this that much, but recently I also started
working on Clojure code, and the difference is like night and day.

~~~
kamaal
Clojure has this advantage of Java Interop. So even if you didn't find native
Clojure libraries, you can always find Java libraries. And you will find Java
libraries for pretty much everything under the Sun. Sure they had to sacrifice
a lot for that, but ultimately its worth it.

Any language that has to compete and be acceptable to the larger programming
community today needs libraries. So it kind of becomes a Chicken/Egg problem.

I don't think anything today will ever reach the levels of Java usage. Partly
because no company is likely to spend on a new language as much as Sun spent
on Java.

So you are pretty much well off building on their ecosystem than fight it.

Having said that, TCO is the only thing I missed in Clojure compared to CL.

~~~
village-idiot
Interestingly enough, I actually worked in both CL and Clojure professionally.

Clojure for certain feels much more modern. They actually have modern build
tools, logging systems, and testing frameworks, which is nice. The emphasis on
more data types than just linked lists was amazing, sometimes you just need a
hashmap, and Clojure's worked great. The rate of progress on the build tools
was frankly spectacular, and some of my favorite libraries in the world are
available in Clojure (core.logic anyone?)

The Clojure community has an approach to libraries that is utterly unique in
my experience, and I miss it in other languages. Clojure libraries are the
most lightly coupled libraries I've ever seen, as they use data as the API (a
very Clojure and very Rich Hickey thing to do), which makes tying libraries
together a trivial and reliable thing to do. They also have a habit of
_finishing_ libraries and not arbitrarily creating competitors for whatever
reason. The result is that there are a lot of Clojure libraries that are
narrowly scoped, feature complete, and trivial to upgrade if necessary. I
really miss that.

Clojure also had some downsides however, both for how we used it and in
general. The team that I worked on with it is now mostly Java these days.

Domain specific issues. If you have a bunch of objects that are similar
syntactically, but vary semantically, you do not want to use Clojure. Clojure
has very poor structures for handling this kind of stuff, and it's very very
easy to accidentally go from your pretty record type back to a regular
persistent hashmap on accident. Basically Clojure encourages (although does
not strictly enforce) hashmap oriented programming. There are some domains
where this is _fine_ , but ours was decidedly not one of them.

Guidance wise, interacting with Clojure maintainers was rough. It's their
project and they can guide it how they want, and we just got the feeling that
they couldn't give a rip about what anyone else wanted. That's their right,
but it was super annoying as an end user of the products that they were
pushing so hard. We never really had any luck getting any of the bugs or
issues that we found dealt with by the core team. We got the distinct
impression that they were running the code we submitted and then deciding
post-facto that what the code did was exactly what they'd wanted in the first
place, but proving that is of course impossible. It's been a few years since I
last tried to talk to them, so it's entirely possible that this has turned
around since then.

I quit that job before Spec was released, so I cannot really comment on how
effective that is in bullet-proofing a Clojure code base. What I can say is
that the core Clojure libraries are _wildly_ type unsafe, to a degree that's
really only beaten by PHP. There are a ton of core functions that'll change
output types without warning, sometimes in several different ways. Nominally
this is fine because all the collections are built on top of the seq
abstraction, but in reality that abstraction is as leaky as they get. The
result is that our code base was littered with "(map identity x)" and "(vec
y)" and "(into {} z)" to handle all these little weird edge cases. My
suspicion is that Spec is a tacit admission that these little type errors
really get out of control in a larger Clojure code base, and they're trying to
fix it without having to revamp the entire core library.

That being said, between the two I would start any modern project in Clojure
rather than CL. Access to Java, modern libraries for web development, and a
much much larger pool of developer talent to access are absolutely killer
features for that language over CL.

~~~
flavio81
This is the best criticism of Clojure i've read.

>That being said, between the two I would start any modern project in Clojure
rather than CL. Access to Java, modern libraries for web development, and a
much much larger pool of developer talent to access are absolutely killer
features for that language over CL.

While I agree with the "larger pool of developer talent", I am already working
with ABCL which has pretty easy Java interop.

As for developer talent, What's difficult to find, is to find developers who
really grok macros and the "code is data" feature.

When you find one, he/she will have it very easy to jump from CL <\--> Scheme
<\--> Clojure, so i'm not too worried about that.

------
yawn
When I saw the stark red banner at the top, I thought my browser was showing
me a warning about the site.

~~~
yawn
Update: they changed the color. Looks great!

------
tarboreus
This site has the biggest, fattest annoyance sticky bar that I've ever seen!

------
nikki93
Really wish SBCL ran on iOS. :( It's the only one with the perf I want. But
like compilation at runtime on iOS is a no go so ... yeah. LuaJIT in
interpreter mode is p fast tho.

~~~
newcup
If you don't mind paying, LispWorks has an iOS runtime:
[http://www.lispworks.com/products/lw4mr.html](http://www.lispworks.com/products/lw4mr.html).
I'm not sure of the perf part on iOS, but on x64 it's pretty good.

~~~
lispm
Actually the performance is pretty good. My iPad Pro is basically running
LispWorks as fast as my 2015 Macbook. It's faster than other ARM systems I've
seen, too.

~~~
nikki93
Interesting. I might give this a shot. Do you know if CFFI stuff works -- so
that I could use eg. cl-opengl or cl-sdl2 -- if you somehow statically link
stuff together? That's what I do w/ LuaJIT for example. Or maybe LispWorks has
its own OpenGL bindings, not sure.

------
systems
if i may make a suggestion, please add a forum

i personally prefer forums for help, support and learning from the community,
over any other option (mailing lists, irc, stackoverflow, etc .. )

most programming languages websites nowadays includes a discourse based forum
and it works greats

i strongly recommend adding one

------
rataata_jr
The site looks amazing

------
mruts
I like Lisp (I used to love it, but I'm more in the static typing camp
nowadays;Typed Racket is good though) but Common Lisp honestly is an
abomination. I can't really think of a situation in which CL is a good choice
for a new good base.

And calling CL "modern" is... ironic at best.

~~~
dang
Can you please keep programming language flamewars off HN? This comment is a
classic flamewar-starter, and we're hoping for higher-quality discussion here.

