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

61–70 of 161 posts

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

#61

Post by abrax3141 »

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.

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

#62

Post by fiddlerwoaroof »

mark_l_watson wrote: post #48
TurboHaskal wrote: post #36

Earlier quoted context omitted.

Can you elaborate why is it a better fit? Have you evaluated CAPI? Have you looked into building Cocoa applications with Clozure CL?

CAPI is great, very well designed and implemented. The advantage of Swift and SwiftUI is that my application can run on both a MacBook and iPad, sync data with iCloud. The advantage of LispWorks is that I could fairly easily support both Mac and Windows (and Linux). I spent two evenings last week playing with Clozure CL and its Cocoa support. It has low level APIs and I had a peculiar issue with sometimes not being e…

I haven’t used it myself, but EQL5 is attempting to make it possible to use ECL to iOS and Android apps

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

#63

Post by patrec »

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 compile time than python, but for python you have mypy and it's A Thing, and still a joke compared to a proper type system like Ocaml's.

> Common Lisp is too specialized, it’s not for general-purpose development.

Common Lisp has no eco-system to speak of for machine learning, web development, command-line utilities, games programming, mobile development, GUI programming, embedded development or pretty much anything real general purpose languages do. If you have something for which Common Lisp is a good fit, you can still be commercially successful using it because not everything requires a super rich eco-system and for some problems what Common Lisp has is in fact highly competitive. But if you want to use common lisp effectively you definitely need to pre-select the problems you want to work on accordingly to an extent that's not true of python, C, C++, Rust, javascript, Go, Java, and half a dozen other languages.

> Common Lisp applications are hard to deploy.

No server or desktop or web-browser comes with common lisp pre-installed. Building common lisp is a pain, because packaging/ASDF is terrible and you don't easily get a nice and small statically linked executable out either. Compared to exactly what language is common lisp not hard to deploy?

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

#64

Post by TurboHaskal »

fiddlerwoaroof wrote: post #62
mark_l_watson wrote: post #48

Earlier quoted context omitted.

CAPI is great, very well designed and implemented. The advantage of Swift and SwiftUI is that my application can run on both a MacBook and iPad, sync data with iCloud. The advantage of LispWorks is that I could fairly easily support both Mac and Windows (and Linux). I spent two evenings last week playing with Clozure CL and its Cocoa support. It has low level APIs and I had a peculiar issue with sometimes not being e…

I haven’t used it myself, but EQL5 is attempting to make it possible to use ECL to iOS and Android apps

LispWorks also has offers an iOS/Android runtime, but no CAPI unfortunately.

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

#66

Post by lispm »

nybble41 wrote: post #60
pdexter wrote: post #12

Earlier quoted context omitted.

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…

Common Lisp was designed without requiring TCO because:

* various platforms don't support TCO. It was designed such that it can be implemented by a simple non-TCO interpreter, transpiled to a non-TCO C compiler, compiled to a non-TCO Lisp Machine CPU, or to a non-TCO virtual machine (like the JVM). Many languages don't support TCO on the JVM and may only implement explicit tail recursion or have a compiler detecting tail recursion - which is far from supporting TCO. Thus a portable conforming Common Lisp program will run in ABCL (a full Common Lisp implementation on top of the JVM) - because it will not depend on TCO to not blow up the stack, or similar.

* another reason was that Lisp has a bunch of features with don't work that well with TCO. For example Lisp always supported various dynamic scoping constructs and made extensive use of those - something which Scheme in its core does not, but provides via libraries or language extensions. Using dynamic scoping constructs makes TCO more difficult, may require a different language design, etc.

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

#67

Post by michaelanckaert »

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…

>> Common Lisp applications are hard to deploy.

>No server or desktop or web-browser comes with common lisp pre-installed. Building common lisp is a pain, because packaging/ASDF is terrible and you don't easily get a nice and small statically linked executable out either. Compared to exactly what language is common lisp not hard to deploy?

I'm not here to defend all of the flaws in CL, but I really enjoy the SBCL feature that allows you to compile to a binary. Yes it may not be as small as a pure C/C++/Rust executable, but it's very useful and I've used in various projects with great success.

My heart still goes out to Python but I was I could just as easily create a Python executable as I can with SBCL.

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

#68

Post by kick »

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.

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.

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

#69

Post by Scarbutt »

TurboHaskal wrote: post #45
mikelevins wrote: post #43

Earlier quoted context omitted.

It probably isn't. The initial public release of Clojure was in the fall of 2007. Scott Burson has been working on FSet since at least 2004. He himself says it's inspired by Refine.

I stand corrected. I still maintain my point about (idiomatic) Clojure being terribly slow though.

And terribly beautiful ;)

Just personal preference and enjoy programming in it. Programmers give too much importance to programming languages.

Clojure can be made to run very fast (it compiles to the same bytecode as Java after all) for the hot paths at the cost at writing less idiomatic Clojure.

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

#70

Post by vindarel »

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…

Heliohost or Platform.sh come with CL pre-installed (https://github.com/CodyReichert/awesome-cl#deployment).

In my experience, deploying a CL app is muuuch less a pain than a Python one: you build a self-contained binary, you run it and voilà, you can access your web app from the internetz. The binary is ±20MB in size (compiler, debugger and all included). With Python, there are so many ways to fail (and even because a dependency of a library didn't pin its dependencies well enough. Gosh.).

Building a self-contained app is 1 line in the .asd project declaration.

https://lispcookbook.github.io/cl-cookbook/scripting.html#bu...

Post reply on HN