Live data from Hacker News

Answers from 2017 Common Lisp experts

blog.teknik.io

31–40 of 48 posts

Re: Answers from 2017 Common Lisp experts

#31
post #23
post #11

I really don't get the lispm's answer about cl21. What are the hidden treasures of the genuine Common Lisp we are ignorant of? In my humble opinion Common Lisp is the classic example of the kitchen sink syndrome, where many pieces taken from various dialects were put together in a hurry. The results is not that bad (like, say, C++) but we know, arguably, a much more refined versions of Lisp, such as the dialect from…

> What are the hidden treasures of the genuine Common Lisp we are ignorant of? Actually Common Lisp is in many places a very well documented and designed language. Other languages have copied its numeric tower, its macros, its object-system, its error handling, ... >In my humble opinion Common Lisp is the classic example of the kitchen sink syndrome, where many pieces taken from various dialects were put together in…

I think that a future Common Lisp could profitably default to lower-case instead of upper-case, and unify argument order. It probably shouldn't default to generic functions due to the performance implications. It could more-fully specify pathnames for current platforms. It could specify something like Go's channels & goroutines.

None of that's probably worth the bother of a new spec.

CL21 was, as you note, an interesting experiment, but I wouldn't run with it.

Re: Answers from 2017 Common Lisp experts

#32
post #20

Earlier quoted context omitted.

To add to this reply, interfacing in C with Common Lisp is pretty easy today. There are at least two portable libraries to do this. Also, you can also interface with Java libraries on the JVM by using the ABCL lisp implementation.

Are there performance implications using FFI ?

There can be, but they mostly have to do with moving things around in memory and garbage collection. An FFI has to marshall in-memory data structures from Lisp into the form C expects, and then move C's results back into Lisp's world. Sometimes your program will have to do this manually but the FFI usually takes care of simple cases like pointers and atomic types. Still, it's not cost-free because at minimum the removal and insertion of tags has to happen.

A related problem is word alignment; getting this right is important for passing data from Lisp to vector processors (and to a GPU I presume, but I haven't done that).

The other issue is GC: When the C function is running, it's important that Lisp's garbage collector not move the memory C is using. Some Lisp implementations do the laziest thing and just stop Lisp until C returns. Others are more sophisticated and keep C's heap separate -- but that requires more copying. Still others mark the memory C uses in a way that tells the GC "don't touch" but that can lead to pathological fragmentation in extreme cases.

The above makes it sound worse than it is. 99% of my use of a Lisp FFI has resulted in a performance increase because C is in general about twice as fast as CL for low-level stuff--which is one of the reasons to use an FFI in the first place.

Re: Answers from 2017 Common Lisp experts

#33
Author of the compilation here.

Sweet lords, I have made the front page of the Hacker News for the first time of my life! I had no idea that this would generate so much traction, especially as my own submission at https://news.ycombinator.com/item?id=15012678 went across HN rather unnoticed.

Re: Answers from 2017 Common Lisp experts

#34
post #7

Lots of interesting stuff in here. Feel like some people could probably say things with a bit less sass though... Replying to "I have a hard time finding good resources" with "everything is terrible" isn't super useful

The teknik.io gang is not known to be lacking in sass.

Who's the gang you're speaking of? I'd like to get to know them. The aforementioned quote is AFAIR from Reddit, not Teknik, so the credit goes there; you can trace the answers to individual comments inside the Reddit thread linked in the article.

Personally, I use teknik.io as a blogging service and Git hosting.

Re: Answers from 2017 Common Lisp experts

#35
post #9

That's a lot of Lisp experts

It's a play on the title of the original blogpost. Quoting myself from there:

It's somewhat baffling to say that "experts", whoever they are, have gathered to respond to this question - I simply assume that the people who have voiced their opinion on the topic - regardless of who they are - know what they are talking of, and therefore their comments should be, and have been, included here.

But, on the other hand, correct, Lisp ain't dead yet. At least not any deader than the usual.

Re: Answers from 2017 Common Lisp experts

#37

Author of the compilation here. Sweet lords, I have made the front page of the Hacker News for the first time of my life! I had no idea that this would generate so much traction, especially as my own submission at https://news.ycombinator.com/item?id=15012678 went across HN rather unnoticed.

It's somewhat hit-and-miss which submissions make the front page. A submission has only a few minutes to get several upvotes before it's pushed off the front "new" page, after which it's unlikely to recover.

Since you're here I'll add a little to my previous comment [0], which was very short because I didn't think many people would see it.

I don't advocate completely pure functional programming as one would do in Haskell, but I do think there are lots of places in most code where the functional style would be clearer and easier to understand and debug than the fully imperative style more common in Lisp. That's why I created FSet [1], a functional collections library. It has been my observation that having high-quality functional collections is often the most important missing piece to make it possible to write more code functionally.

[0] https://news.ycombinator.com/item?id=15077088

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

Re: Answers from 2017 Common Lisp experts

#38
post #26

Earlier quoted context omitted.

> In my humble opinion Common Lisp is the classic example of the kitchen sink syndrome, where many pieces taken from various dialects were put together in a hurry. Can you give a particular example? I have read many times about people speaking about the amount of "cruft" that was left into Common Lisp, but frankly i've yet to find any cruft. Some people use as an example the fact that there is "CAR " and "CDR", but i…

Its mostly about inconsistent naming, order of arguments and standard idioms. Obviously most of these are historical artifacts, like nconc and friends or the primitives for working with hash-tables. Car and cdr are small miracles because they give us of caddr or caadr and friends. It is beautiful accident which should be appreciated and preserved.

> Its mostly about inconsistent naming, order of arguments

Do you have some examples of inconsistent order of arguments? I'm not really doubting you, I just can't think of any examples.

Re: Answers from 2017 Common Lisp experts

#39

Earlier quoted context omitted.

The teknik.io gang is not known to be lacking in sass.

Who's the gang you're speaking of? I'd like to get to know them. The aforementioned quote is AFAIR from Reddit, not Teknik, so the credit goes there; you can trace the answers to individual comments inside the Reddit thread linked in the article. Personally, I use teknik.io as a blogging service and Git hosting.

Can you reach out to me via email? I don't necessarily want to post their haunts in public without their permission.

Re: Answers from 2017 Common Lisp experts

#40
post #27
post #25

Earlier quoted context omitted.

I remember reading the Symbolics manuals from bitsavers and how I have been impressed by clarity and unity of the language, and how they incorporated CL into Zetalisp just by moving their own stuff into packages. At least in the documentation everything looks wonderful. Compared to Symbolics CL looks like a mess at least from reading the books.

That does not make sense to me. Common Lisp provided lots of improvements over Zetalisp.

The major goal of Common Lisp was commonality, and that means incorporating forms from various dialects into one and to maintain compatibility, like you said. That goal has been accomplished.

I think that carefully designed dialects with emphasis on right principles and attention to details leading by people like David Moon would be aesthetically better than a good kitchen sink. It is no coincidence that Common Lisp took most of stuff from Zetalisp, according to CLtL2.

I think it is a general heuristic that a small group of disciplined devoties would produce better artifact than an vast assembly of... general public or passionate and productive but ignorant individual. Think of Python3 vs Ruby, Go vs early C++ or Scheme vs CL. Attention to details and perfectionism works - look at Haskell syntax and prelude. (All this just to illustrate validity of my heuristic).

Post reply on HN