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

151–160 of 161 posts

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

#151

Post by patrec »

vindarel wrote: post #148
patrec wrote: post #147

Earlier quoted context omitted.

CLI utils: you're missing the point. Of course you can write some simple terminal apps with common lisp, but can you name a single one that anyone who is not a lisp fanatic uses? If not, ever wonder why? GUI: would you develop a commercial app (to pay your rent) in any of these apart from CAPI? ML: You are joking, right?

I can name one :) pgloader https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas... I'd use Electron with Ceramic, not the GUI bindings. Or maybe Nuklear. But I would build personal projects with them. ML: yeah, yeah. Just to show there have been work on it, that (of course) the platform is capable.

Yup, pgloader was also the one example I could think off; I was wondering if you'd name it :) Amusingly I have not been able to get the non-docker version to work due to some bogus openssl problem.

Anyway, I completely agree that Common Lisp is capable, my point also isn't that it's impossible to do things like GUIs, or write something cool and successful with it – just that the eco-system is not general-purpose language quality. If you want to make something that's successful commercially or as a well-adopted open-source project you have to be much more careful what problems you tackle than with a genuinely general purpose language.

Blog posts that claim otherwise really rub me the wrong way; I think it's possible to present CL in a favorable light without distorting reality and no one is gonna thank you later for joining the rank of people who missed out career-wise for making non-viable technology choices.

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

#152

Post by patrec »

yellowapple wrote: post #142
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 has no eco-system to speak of for machine learning, https://www.cliki.net/Machine%20Learning > web development, https://www.cliki.net/Web https://en.wikipedia.org/wiki/Viaweb https://en.wikipedia.org/wiki/Reddit#Technology_and_design (though it admittedly got rewritten into Python) > command-line utilities, https://github.com/TeMPOraL/hju , among, like, hundreds of other examples > games programming, ht…

If you think spamming random links to old toy/dead/in-house projects you found on Cliki and that contained words like "machine learning", "Games" or "GUI" (mcclim – really?[]) constructs an effective rebuttal to "no ecosystem to speak of", I'm not sure I know what to say. But I'll go through your list in more detail if you want me to.

[] For the record CLIM had interesting ideas, but last I looked, calling McCLIM's implementation of them a toy would be charitable.

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

#153

Post by nybble41 »

lispm wrote: post #132
nybble41 wrote: post #126

Earlier quoted context omitted.

Macros would need to specify whether any expressions will be evaluated in tail position. However, expressions in macros don't look like they should be subject to TCO, so the default assumption should be that they aren't unless declared otherwise. Do you have any examples of cases that would be likely to cause confusion—in particular where a function call appears to occur in tail position in the code but can't be TCO'…

For example I see sometimes macros which generate code with compilation quality (speed, ...) declarations for all or parts of their code. Depending on the combination of qualities TCO might be enabled or disabled in code sections.

If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings. Debug builds are no more tolerant of stack space leaks than release builds. The fact that TCO isn't guaranteed is the problem here.

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

#154

Post by vindarel »

patrec wrote: post #151
vindarel wrote: post #148

Earlier quoted context omitted.

I can name one :) pgloader https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas... I'd use Electron with Ceramic, not the GUI bindings. Or maybe Nuklear. But I would build personal projects with them. ML: yeah, yeah. Just to show there have been work on it, that (of course) the platform is capable.

Yup, pgloader was also the one example I could think off; I was wondering if you'd name it :) Amusingly I have not been able to get the non-docker version to work due to some bogus openssl problem. Anyway, I completely agree that Common Lisp is capable, my point also isn't that it's impossible to do things like GUIs, or write something cool and successful with it – just that the eco-system is not general-purpose lang…

> not general-purpose language quality.

= not top-notch in all areas? Yeah, there's room for improvement. Buuut, given CL's features and stability, I will very much consider it for a commercial project in the future instead of, say, Python. I'd reject Python, for sure, for GUIs or web dev (except a small website maybe where admins would use the Django admin). Now I must find another language, and it's difficult. Many things drive me back to CL, including its state of libraries, actually pretty good compared to other languages, newer or older. No kidding.

> If you want to make something that's successful commercially or as a well-adopted open-source project

maybe. Reading you, it seems one should avoid using CL altogether. But there's a lot of room for a successful use of CL before falling into these categories: one-off scripts, quick GUIs at work, personal tools? Commercial websites (with adequate requirements), like I did? yes, it's possible to use CL for that. Yes, it is possible to do web development for a job with CL (what kind of sites? We have to ask the few redditors that do it). My point is that CL is general-purpose enough so that it could be more used in the wild (because it is used in the wild).

Anyways. Just trying to be positive :)

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

#155

Post by kazinator »

reikonomusha wrote: post #80
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?

It’s a practical language that sometimes chooses less elegant ways to do things in favor of a complete, robust engineering experience. For instance, the fact defined functions sit in a different namespace than values creates mostly aesthetic ugliness where named functions and named values have different treatments. (defun f (x) (* x x)) (setq g (compose f f)) (g 5) This is wrong in Common Lisp on many levels: f must…

Programming with a lot of higher order functions won't feel as clean in Common Lisp due to the #' and funcall.

Basic Lisp programming with lists is a lot cleaner in a Lisp in which the empty list is false, and in which accessing nonexistent parts of a list (including the empty list) is a safe no-op that yields nil.

Ashwin Ram's (cdr (assq key a-list)) almost works in Common Lisp in the form of (cdr (assoc key a-list)). See: https://ashwinram.org/1986/01/28/a-short-ballad-dedicated-to...

Imperative programming is better supported in Common Lisp because the evaluation of the arguments of most forms, including function calls, is ordered, mainly left to right, so side effect embedded in expressions will show stable, portable behavior. Scheme function calls have unspecified evaluation order, much like C. (In Common Lisp, the only unspecified aspect is whether the function cell is sampled before the arguments are evaluated, or just before the function is called. It's extremely rare for the arguments of a function call to be redefining the function cell, needless to say.)

Common Lisp forms return a predictable value. If it doesn't make sense for a form to return a value, its value is not "undefined", but either just nil or else "no values". When a value returns no values, and an attempt is made to use its value anyway, then nil is produced as the value. You will not see some annoying # in a Lisp REPL coming from a procedural construct.

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

#156

Post by lispm »

nybble41 wrote: post #153
lispm wrote: post #132

Earlier quoted context omitted.

For example I see sometimes macros which generate code with compilation quality (speed, ...) declarations for all or parts of their code. Depending on the combination of qualities TCO might be enabled or disabled in code sections.

If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings. Debug builds are no more tolerant of stack space leaks than release builds. The fact that TCO isn't guaranteed is the problem here.

> If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings

https://www.gnu.org/software/kawa/Compatibility.html

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

#157

Post by yellowapple »

patrec wrote: post #152
yellowapple wrote: post #142

Earlier quoted context omitted.

> Common Lisp has no eco-system to speak of for machine learning, https://www.cliki.net/Machine%20Learning > web development, https://www.cliki.net/Web https://en.wikipedia.org/wiki/Viaweb https://en.wikipedia.org/wiki/Reddit#Technology_and_design (though it admittedly got rewritten into Python) > command-line utilities, https://github.com/TeMPOraL/hju , among, like, hundreds of other examples > games programming, ht…

If you think spamming random links to old toy/dead/in-house projects you found on Cliki and that contained words like "machine learning", "Games" or "GUI" (mcclim – really?[ ]) constructs an effective rebuttal to "no ecosystem to speak of", I'm not sure I know what to say. But I'll go through your list in more detail if you want me to. [ ] For the record CLIM had interesting ideas, but last I looked, calling McCLIM's…

The claim was "no eco-system to speak of". There is clearly an ecosystem to speak of. It might not be a healthy ecosystem, and we might speak of it poorly, but it exists nonetheless, and in fact exists in a greater capacity across that whole range of categories than what a lot of other "popular" languages can claim.

"Machine learning" is a perfect example of how out-of-touch that claim is considering that Lisp was the language for AI research until very very recently.

> mcclim – really?

I guess you didn't see the link right below it with the dozens of other bindings to other popular GUI toolkits.

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

#158

Post by patrec »

vindarel wrote: post #154
patrec wrote: post #151

Earlier quoted context omitted.

Yup, pgloader was also the one example I could think off; I was wondering if you'd name it :) Amusingly I have not been able to get the non-docker version to work due to some bogus openssl problem. Anyway, I completely agree that Common Lisp is capable, my point also isn't that it's impossible to do things like GUIs, or write something cool and successful with it – just that the eco-system is not general-purpose lang…

> not general-purpose language quality. = not top-notch in all areas? Yeah, there's room for improvement. Buuut, given CL's features and stability, I will very much consider it for a commercial project in the future instead of, say, Python. I'd reject Python, for sure, for GUIs or web dev (except a small website maybe where admins would use the Django admin). Now I must find another language, and it's difficult. Many…

> Buuut, given CL's features and stability, I will very much consider it for a commercial project in the future instead of, say, Python[...]My point is that CL is general-purpose enough so that it could be more used in the wild

Yeah, I'm not arguing against that at all. I just hate articles which encourage people towards doomed efforts rather than building out existing areas of strengths or address things that are real obstacles towards using them. I'd like CL to be around for at least long enough till all it's important ideas have made it into other programming languages ;)

For example, one core strength of CL is that it's the about the only really interactive/malleable/live language that can generate pretty performant code, and for sbcl you can hook deeply into the machine code generation as well. Luajit is nicer in some ways (e.g. much smaller footprint in every possible way) but CL has a much more sophisticated interactive development experience (restarts, powerful debugging, pretty-printing etc. etc.). So tooling for automation of binary rewriting, refactoring and hardening like GrammarTech seems to be working on (see https://github.com/GrammaTech?utf8=&q=&type=&language=common...) seems like a much more promising area to work on with common lisp to me than e.g. generic web development.

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

#159

Post by nybble41 »

lispm wrote: post #156
nybble41 wrote: post #153

Earlier quoted context omitted.

If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings. Debug builds are no more tolerant of stack space leaks than release builds. The fact that TCO isn't guaranteed is the problem here.

> If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings https://www.gnu.org/software/kawa/Compatibility.html

Your point? The page you linked to specifically says that Kawa only implements a subset of modern Scheme—by which I mean R5RS or later. Early versions of the Scheme language standard didn't require TCO, but all the recent ones do. This doesn't affect the core point that if TCO is guaranteed by the language standard, as in modern Scheme, then it cannot be selectively disabled because doing so would break perfectly compliant code.

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

#160

Post by [deleted] »

nybble41 wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

> If TCO is guaranteed at the language level, as in Scheme, then it will always be enabled regardless of compilation settings https://www.gnu.org/software/kawa/Compatibility.html

Your point? The page you linked to specifically says that Kawa only implements a subset of modern Scheme—by which I mean R5RS or later. Early versions of the Scheme language standard didn't require TCO, but all the recent ones do. This doesn't affect the core point that if TCO is guaranteed by the language standard, as in modern Scheme, then it cannot be selectively disabled because doing so would break perfectly com…

[deleted]
Post reply on HN