Live data from Hacker News

Modern, functional Common Lisp: myths and best practices

ambrevar.xyz

51–60 of 161 posts

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

#51

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…

> Common Lisp as a language and ecosystem is so huge

This is not true IMO, when compared with the languages of today. Even if you include the numerous little details of MOP, the CL spec is nowhere near as confusing as say something like C++ 17.

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

#52
post #49

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…

I'm always curious when this comes up: which libraries in particular do you have in mind? If you love Lisp and they're really absent, a short list would at least provide a data point for something that would be desirable and ambitious newcomers could cut their teeth on. Anyway I don't think the library ecosystem is so dire... Lots of good libraries are distributed through quicklisp. It's pretty straightforward to wra…

Thanks for the links! I'll check them out. I like the "higher level" of Python libraries better than C or even Java, because I tend to write what most people would call prototype code. Small user base, small applications, and the really harsh constraint is development time from concept through validation.

No-doubt-unnecessary boilerplate: I understand that people have language wars, and it's possible you may have identified me as belonging to one side or another, but I'll pass. That whole state of affairs is just unfortunate.

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

#53
post #17
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 :))

ivan4th had the right answer. Use the "kubectl port-forward" command.

BTW, here's a k8s-hosted app I wrote using this approach: https://github.com/atgreen/red-light-green-light

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

#54
post #17

Earlier quoted context omitted.

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 :))

With k8s, you just create a service of type NodePort and it assigns a free external port for that service, which is mapped back to a specific port in the Lisp container.

Don't do this... You only need the connection for development purposes, so use "kubectl port-forward", which gives you the auth you'll need as well.

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

#55
On tools: note that the popular Atom editor has a great extension for interactive CL development, SLIMA, which has all the important features from Slime.

We can also use CL in Jupyter notebooks, see those good examples: https://gist.github.com/WetHat/a49e6f2140b401a190d45d31e052a...

And Vim, Lem, cl-repl, Eclipse (not so interactive)… https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

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

#56
post #12
post #3

I don't consider a language supportive of functional programming unless it supports tail-call optimisation, which is performed by some but not all implementations of Common Lisp. The article recommends SBCL, which does support TCO. An old (2011) survey of TCO support is at https://0branch.com/notes/tco-cl.html

That sounds more like an implementation detail, in most cases. By this metric Haskell wouldn't be a functional language.

[deleted]

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

#57
post #49

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…

I'm always curious when this comes up: which libraries in particular do you have in mind? If you love Lisp and they're really absent, a short list would at least provide a data point for something that would be desirable and ambitious newcomers could cut their teeth on. Anyway I don't think the library ecosystem is so dire... Lots of good libraries are distributed through quicklisp. It's pretty straightforward to wra…

In addition, check out py4cl: https://github.com/bendudson/py4cl

(And a Numpy clone: https://numcl.github.io/numcl/)

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

#58
Assuming that the subtext here is wanting to address potential reasons for Lisp's chronic underpopularity, I think that all conversations like this miss the mark. Lisp was never failing to attract many users because people hadn't experienced sufficient evangelism about all its advanced features. It fails to attract many people because it's not a fun language to get started in.

A year or so back I picked up a copy of Land of Lisp and burned through it for pleasure reading. And I was struck by how gross Lisp looks in that beginner-oriented treatment. Just this huge slog of car and cdr and let/letrec/let* and the 37 flavors of equals and the function namespace. . . and, all the while, you're being told that persevering in mastering this confusing minefield of subtleties will somehow enable you to write bug-free software. I doubt it's actually fun for most people, and the grandiose claims should beggar belief for everyone. I suppose I should count myself fortunate that I got to learn Lisp in college, where there was little attempt to make it fun, and plenty of graded assignments to keep me motivated.

Racket and Clojure are right to clean up some of the language's evolutionary history. That's a start. But even then, the treatment in beginner's guides isn't all that enticing. I've also skimmed through Realm of Racket and Clojure for the Brave and True, and, while both of them work hard at being entertaining (and were fun to just sit and read), they don't really succeed at dispelling the sensation that what you're mostly doing is wrangling with the language itself.

Compare with some of the more popular Python guides. They tend to be much more dryly written, but the actual flow of the guide tends to get you pretty quickly to

    from pypi import have_fun
    have_fun()

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

#59
post #35

Earlier quoted context omitted.

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.

I wonder if someone made an invert hylang.. a python->clojure transpiler

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

#60
post #12
post #3

I don't consider a language supportive of functional programming unless it supports tail-call optimisation, which is performed by some but not all implementations of Common Lisp. The article recommends SBCL, which does support TCO. An old (2011) survey of TCO support is at https://0branch.com/notes/tco-cl.html

That sounds more like an implementation detail, in most cases. By this metric Haskell wouldn't be a functional language.

It's a very important implementation detail. Explicit loops tend to imply mutation, which is contrary to idiomatic functional programming. Recursive calls don't require mutation but do require TCO to achieve equivalent space complexity. Constant-factor optimizations are one thing but failing to perform TCO turns constant-space algorithms into linear-space algorithms (or linear ones into quadratic, etc.). It's less a matter of "optimizing" the calls and more a matter of not wasting limited stack space on data which is clearly not required to execute the remainder of the program. One might as well label the practice of freeing stack frames when a function returns "Function Return Optimization" (FRO) and consider it a mere "implementation detail". After all, wouldn't it be much simpler to grab new memory every time the program needs some storage space and never bother with cleaning it up? It would certainly make debugging easier with all those old variables retained for the life of the program and not constantly overwritten by new data. However, programs written for a language without guaranteed "FRO" would look very different from normal programs, much as programs designed to compensate for the lack of guaranteed TCO look very different from idiomatic functional programs.

Haskell uses a different (data-centric, non-strict) evaluation model where recursive definitions don't result in recursive calls, so traditional TCO isn't as relevant. Recursion is used very heavily in Haskell—which has no first-class looping constructs—but the resulting programs generally do not require large stacks. It's not unusual to be able to run even large Haskell programs with a 1 KiB maximum stack size (+RTS -K1k). Space leaks are possible, of course, but they take place in the heap.

Post reply on HN