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

81–90 of 161 posts

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

#81

Post by AnimalMuppet »

abrax3141 wrote: post #61
mumblemumble wrote: post #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…

First off, Lisp is chronically POPULAR not unpopular. (It is critically unpopular.) Secondly, Lisp is the most fun you can have programming, yeah from the start. You apparently had either a very poor teacher, or taught yourself Lisp ... same thing.

Chronically popular? Unless you're using some weird definitions, I would expect to see Lisp used more if you were correct.

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

#82

Post by Ambrevar »

vindarel wrote: post #78
patrec wrote: post #63

I hate the "lists of myths" (that aren't) genre. > Common Lisp does not have compile-time type checking. Nothing in the standard mentions compile time checking requirements and there is no useful de-facto standard that you (or tooling!) could seriously build upon either. I'd be suprised if python did not have better "compile-time type checking" for all practical purposes. Yes, SBCL gives much better type warnings at…

web development: kind of agree, but that didn't prevent me and two other colleagues to build a commercial website last year, for 1,5 month. It receives tens of thousands of visits a month and has a small admin panel for a three persons team. Job done, rent paid CLI utils: it's simple to use cl-readline. There are a couple libraries for ncurses. The Lem editor is a good example. mobile: nope. For the adventurous, see…

Thanks for the list! :)

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

#83

Post by bibyte »

lispm wrote: post #75
bibyte wrote: post #72

Earlier quoted context omitted.

Isn't Common Lisp's save-lisp-and-die roughly analogous Pyinstaller? I mean they both work but nobody seems to be using them. In my experience Common Lisp code is most commonly deployed with an interpreter.

Most Common Lisp is actually compiled, not interpreted. If one compiles code or loads compiled code to something like SBCL and dumps an image, you can both run it directly from that image AND have still have the development tools included. Some Common Lisp implementations also have delivery tools which create applications without development tools. Some applications though include the development tools, because they…

Of course many implementations do compile to machine code but there are also a few that don't (clisp, ecl, abcl). It is really complicated to talk about languages that have multiple implementations. That is why I went with "interpreter". That was pretty lazy of me :).

But you didn't say anything about the original question. Have you seen Common Lisp code deployed as an executable or as source code?

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

#84

Post by AnimalMuppet »

mumblemumble wrote: post #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…

> It fails to attract many people because it's not a fun language to get started in.

Interesting. Nobody is born knowing any computer language. Languages therefore are popular (among other things) in proportion to their ability to convert "those who don't know the language" into "those who know", and "those who know" into actual users. A gentle introduction to those who don't know anything is therefore a good start. I suspect that both Lisp and Haskell suffer from this.

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

#85

Post by Scarbutt »

tombert wrote: post #73

I really need to learn CL one of these days; I know Clojure reasonably well, and enough Lisp-Flavour-Erlang, Chicken Scheme, and Racket to be dangerous, but for some reason I seem to have completely avoided CL. Based on the blog posts I've read, it seems like CL occupies the kind of space I want to be in: sort of the halfway point between theoretical and engineering. Is that a fair conclusion to draw?

Just mentioning it for historical reasons (someone correct if this is wrong), Rich Hickey was enlightened by CL after doing lots of Java/C#/C++, after doing much CL he created Clojure.

To answer your question, the JVM has wide acceptance in the industry and a big ecosystem of libraries, from a business and practical point of view, it seems the most adequate choice for a Lisp?

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

#86

Post by AnimalMuppet »

mumblemumble wrote: post #71
kick wrote: post #68

Earlier quoted context omitted.

The above post didn't say unpopular, they said 'underpopular'. While that's a bit of a neologism, it just implies that it's less popular than it should be. Also: "Lisp is the most fun you can have programming, yeah from the start," while subjective, is by most accounts, wrong. Especially when referring to Common Lisp; there could hardly be a more convoluted Lisp than Common Lisp.

Yes, thanks for putting it so concisely. Personally, I do think Lisp is fun, and was having fun pretty much from the start. But, with how many people I've watched just bounce off of it, I simply can't bring myself to imagine that my experience is anything but unusual. Nor am I inclined to console myself with self-congratulatory stories about Blub.

I suspect that certain styles fit the way certain people think, and don't fit the way that other people think. If Lisp fits the way you think, then learning it is a revelation - it's like being let out of prison. But if it doesn't fit, it's really hard. And those who find Lisp to be "the right way" (for them) expect that if everyone else really understood Lisp, they'd have the same magical experience. When everyone else does not have that experience, they assume that those people just haven't really understood Lisp yet.

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

#87

Post by e12e »

ohithereyou wrote: post #28
simiones wrote: post #20

Earlier quoted context omitted.

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.

What sort of encryption and authentication can I expect if I do that? Can anybody who guesses the port dump code into my running Lisp instance?

This is entirely to hard to find the answer to in the kubernetes/kubectl documentation. Apparently the forward is done via socat over tls:

https://stackoverflow.com/questions/50645059/is-kubectl-port...

And socat is mentioned in:

https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/po...

I didn't actually manage to find out what or how socat is called - but I'm also on mobile, so it's a little convoluted to browse source code.

Anyone know where the call to socat happens, after kubectl port-forward?

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

#88

Post by vindarel »

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

Generally, here's how to connect to a remote running lisp image, and send changes from one's comfortable editor: https://lispcookbook.github.io/cl-cookbook/debugging.html#re...

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

#89

Post by lispm »

bibyte wrote: post #83
lispm wrote: post #75

Earlier quoted context omitted.

Most Common Lisp is actually compiled, not interpreted. If one compiles code or loads compiled code to something like SBCL and dumps an image, you can both run it directly from that image AND have still have the development tools included. Some Common Lisp implementations also have delivery tools which create applications without development tools. Some applications though include the development tools, because they…

Of course many implementations do compile to machine code but there are also a few that don't (clisp, ecl, abcl). It is really complicated to talk about languages that have multiple implementations. That is why I went with "interpreter". That was pretty lazy of me :). But you didn't say anything about the original question. Have you seen Common Lisp code deployed as an executable or as source code?

Interpreted in Lisp usually means 'executing s-expressions by a Lisp interpreter'.

ECL and CLISP also use compilers. ECL usually compiles to C, which then is compiled to native code via a C compiler. CLISP has its own virtual machine, which is the target of its compiler. Don't know what ABCL does, would have to look it up - but in the end it usually would execute JVM code, which gets compiled by its JIT compiler.

Question of code deployment. I have seen deployment as an executable, deployment as an executable with also loads compiled code (for patches) and deployment as source code. Especially commercial applications and/or end-user applications tend to deploy as executable. For example ScoreCloud is a LispWorks application as an executable and can be bought on Apple's Mac app store.

My Lisp Machine at home boots into a Lisp image which contains a whole operating system as compiled Lisp code. That's exotic, but many other Lisp development environments already come as compiled Lisp executable. For example on the Mac and on ARM64/Linux I use LispWorks. On the Mac it is the usual Mac application bundle, where the executable already contains much of the IDE and then loads some code on demand from compile code files.

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

#90

Post by vindarel »

vindarel wrote: post #78
patrec wrote: post #63

I hate the "lists of myths" (that aren't) genre. > Common Lisp does not have compile-time type checking. Nothing in the standard mentions compile time checking requirements and there is no useful de-facto standard that you (or tooling!) could seriously build upon either. I'd be suprised if python did not have better "compile-time type checking" for all practical purposes. Yes, SBCL gives much better type warnings at…

web development: kind of agree, but that didn't prevent me and two other colleagues to build a commercial website last year, for 1,5 month. It receives tens of thousands of visits a month and has a small admin panel for a three persons team. Job done, rent paid CLI utils: it's simple to use cl-readline. There are a couple libraries for ncurses. The Lem editor is a good example. mobile: nope. For the adventurous, see…

addendum: for iOS, Android and mac: possible MOCL (proprietary) https://github.com/CodyReichert/awesome-cl#implementations
Post reply on HN