Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern, functional Common Lisp: myths and best practices

ambrevar.xyz

Post reply on HN
Print view View original

31–40 of 161 posts

Re: Modern, functional Common Lisp: myths and best practices

#31

Post by tom-thistime »

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need.

EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.)

I care 10x as much about libraries as about all these red herrings (EDIT: or myths, as you like) combined: " * Common Lisp does not have compile-time type checking. * Common Lisp is for imperative, object-oriented programming. * Common Lisp is too specialized, it’s not for general-purpose development. * Common Lisp applications are hard to deploy. "

Re: Modern, functional Common Lisp: myths and best practices

#32

Post by TurboHaskal »

thsealienbstrds wrote: post #26
pfdietz wrote: post #13

Earlier quoted context omitted.

It's a matter of not modifying things once constructed. CL has hooks to help do that, although a user can always get around them. A package I've been involved with lately is fset, which is available through quicklisp, or at https://github.com/slburson/fset It has some interesting features, including "functional setf expansion". This would turn something like (setf (fcar x) y) into something equivalent to (setf x (con…

Are you aware of any memory-leak issues with fset? I once used it in a game where I updated an fset sequence in real-time. I let it run for a while, after coming back I noticed my computer was completely frozen (out of RAM).

It's inspired by Clojure after all. The language of choice for users that don't care about performance.

Re: Modern, functional Common Lisp: myths and best practices

#33

Post by pjmlp »

Ambrevar wrote: post #18
pjmlp wrote: post #8

Very nice overview, I failed to see references to LispWorks and Allegro, though.

I've never used them myself, so in all honesty I have nothing to say about them! :p That said, I support free software and I believe a proprietary compiler is not a good idea :(

The FOSS experience is a poor imitation of Lisp Machines.

Re: Modern, functional Common Lisp: myths and best practices

#34

Post by Ambrevar »

Jach wrote: post #30
Ambrevar wrote: post #22

Earlier quoted context omitted.

Thanks for the fset link. I understand your comment as a bit judgmental, if not rude. Please keep the tone friendly, it helps if we want to have constructive discussions. I'd be happy (as well as everyone around here I'm sure) to discuss what you find questionable.

I agree with GP about refraining from "best practices" type advice -- at most leave it as "I prefer doing it this way". (Example: There was no mention of qlot for a form of version pinning, which would be considered a "best" or at least "standard" practice in other ecosystems, but while I use it I'm not going to insist other Lispers I don't work with do so too. They can keep doing things how they like. Common Lisp is…

Right, maybe "best practices" was poorly worded. I'll think of something better.

Regarding the visual aspect: Very nice link, thanks for sharing! I was also thinking of showing off the macro-stepper.

Regarding the lack of libraries: well, Quicklisp is strong of some 1500 libs, which is rather poor compared to most popular languages out there. So yes, it goes both ways!

I'll check out the other libs, thanks!

Re: Modern, functional Common Lisp: myths and best practices

#35

Post by slifin »

tom-thistime wrote: post #31

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…

If you're interested in lisps and python's ecosystem you might enjoy lib python from Clojure: http://gigasquidsoftware.com/blog/2020/01/24/clojure-interop...

https://run.nextjournalusercontent.com/kommen/parens-for-pol...

Re: Modern, functional Common Lisp: myths and best practices

#36

Post by TurboHaskal »

mark_l_watson wrote: post #16

Thanks for writing that up. Common Lisp as a language and ecosystem is so huge that we all have our own view of what CL is and how to use it to build applications. I have been actively using CL since around 1982 for prototyping and also building applications and tools but I feel like I use a small part of what is available, mostly because I prefer to use what I am used to. I should should probably spend a little less…

Can you elaborate why is it a better fit?

Have you evaluated CAPI? Have you looked into building Cocoa applications with Clozure CL?

Re: Modern, functional Common Lisp: myths and best practices

#37

Post by TurboHaskal »

Ambrevar wrote: post #18
pjmlp wrote: post #8

Very nice overview, I failed to see references to LispWorks and Allegro, though.

I've never used them myself, so in all honesty I have nothing to say about them! :p That said, I support free software and I believe a proprietary compiler is not a good idea :(

Ideology aside, most proprietary compilers (mostly for Forth, Pascal and Lisp) I have used are of _excellent_ quality.

A lot also provide you the source code once you pay. AllegroCL is one of them I think.

Re: Modern, functional Common Lisp: myths and best practices

#38

Post by ivan4th »

lvh wrote: post #17
atgreen wrote: post #2

Common Lisp is also a pleasure to use for k8s-hosted services. Just deploy your Lisp-based service to k8s, forward the sly/slime port to your local system, and continue to work on it interactively with emacs and sly/slime. It's really the most interactive development approach for k8s-hosted services. See https://github.com/container-lisp/s2i-lisp

How do you do the forwarding? (That’s an interesting question to me by itself, but I ask because it seems like that feature is just as good outside of k8s too :))

kubectl port-forward my-lisp-pod 4005:4005

then M-x slime-connect localhost 4005

Re: Modern, functional Common Lisp: myths and best practices

#39

Post by tom-thistime »

slifin wrote: post #35
tom-thistime wrote: post #31

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…

If you're interested in lisps and python's ecosystem you might enjoy lib python from Clojure: http://gigasquidsoftware.com/blog/2020/01/24/clojure-interop... https://run.nextjournalusercontent.com/kommen/parens-for-pol...

Thanks! Nothing would be more awesome than Lisp (or Scheme, I don't care) with easy transparent access to modern libraries.

Re: Modern, functional Common Lisp: myths and best practices

#40

Post by phoe-krk »

tom-thistime wrote: post #31

This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need. EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.) I care 10x as much about libraries as…

These four things are common myths. It says so in the very line above them. This article is literally about debunking these myths.
Post reply on HN