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

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

Post reply on HN
Print view View original

311–320 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#311

Post by ristos »

aidenn0 wrote: post #252
ristos wrote: post #180

Earlier quoted context omitted.

This does keep coming up, and it's a few years old now. I think Quicklisp can easily still support https while supporting the older packages that are tar+http, which could easily be mirrored in a git repo. Quicklisp has unfortunately taken over the entire ecosystem, making it hard to use anything else, and you often need to depend on it to use a lot of tools in the ecosystem. It sort of reminds me of Systemd in that…

> Quicklisp has unfortunately taken over the entire ecosystem, making it hard to use anything else, and you often need to depend on it to use a lot of tools in the ecosystem. It sort of reminds me of Systemd in that way. This is a strange statement. What requires QL to work? In the "bad old days" you had to manually download the sources and drop them somewhere ASDF could find them[1]. This still works. You can blithe…

Ultralisp, Rowsell, Qlot, Quickdocs, etc. Virtually every modern project build/install instructions reference Quicklisp. You have no idea which dependencies you need to pull and from where, which can be a real PITA for a large project. A lot of project code I've looked at also has Quicklisp references in the actual code for whatever reason, usually for testing or building or whatever else, so to run those you need Quicklisp. It's really hard not to say it's taken over the ecosystem or that there isn't lock-in, I don't know what you mean to be honest. Quicklisp is also a curated list gatekept by one person, so whatever is on there isn't really representative of everything that's being worked on. You can publish on Ultralisp if you don't want to wait or if it wasn't accepted, but then you're still using Quicklisp under the hood. And it's hard to discover things on Github/Gitlab/etc because there's a lot of stub repos just trying things out, with little to no stars.

I'd love to see ecosystem support for other package managers. CLPM is still in beta and has been for a good while now. Quicklisp too. Quicklisp famously doesn't support HTTPS, version pinning, project locals, etc, which has really throttled any progress with the Common Lisp ecosystem. It's not like ASDF at all, which is become a standard that's built into a lot of the lisp compilers.

Re: It's 2023, so of course I'm learning Common Lisp

#312

Post by Sterm »

sireat wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

How does it look like in Python? In Lisp: CL-USER 43 > (+ 1 (foo 20)) Error: Undefined operator FOO in form (FOO 20). 1 (continue) Try invoking FOO again. 2 Return some values from the form (FOO 20). 3 Try invoking something other than FOO with the same arguments. 4 Set the symbol-function of FOO to another function. 5 Set the macro-function of FOO to another function. 6 (abort) Return to top loop level 0. Type :b fo…

Hmm, what advantage does Lisp offer here over Python? >>> 1 + foo(20) Traceback (most recent call last): File " ", line 1, in NameError: name 'foo' is not defined >>> def foo(a): ... return a + 21 File " ", line 2 return a + 21 ^ IndentationError: expected an indented block >>> def foo(a): ... return a + 21 ... >>> 1 + foo(20) 42 >>> Mind the hilarious indentation error, as I had not touched the old-school REPL in ag…

You're losing all the state since you're not being dropped in the closure where the error happened but in the end of the program.

To see the difference use some function counter() instead of 1 in the example.

Re: It's 2023, so of course I'm learning Common Lisp

#313

Post by anonzzzies »

TheOtherHobbes wrote: post #224
schemescape wrote: post #21

Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…

LISP continues to be a very interesting language. But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state. LISP would be a more practical language if it included a trivial option to make that possible.

I just create new / changed functions next to the others and eval the selected region, then clean up. When I think i'm done, I'll restart the repl and try if it all is fine or if I depended on something in the state. That doesn't often happen anymore. I use the repl to try out things I just written in files. I can't say I remember a moment when state was a/the problem.

M-x slime-restart-inferior-lisp

works fine.

Re: It's 2023, so of course I'm learning Common Lisp

#314

Post by joe-user »

eadmund wrote: post #259
koito17 wrote: post #79

Earlier quoted context omitted.

The reason for this is quite simple: portability. Quicklisp also uses plain TAR files to distribute dists. Why? Because quicklisp has a built-in TAR extractor written in 100% standard/portable CL. This allows Quicklisp to run on just about everything, from your computer to real LispMs and operating systems like Mezzano. TLS comes up every time someone discusses Quicklisp, but nobody bothers to go ahead and actually i…

Quicklisp doesn’t need to support TLS, but it does need to support authentication of some sort. Signing files would be good enough.

Are you proposing authentication over an insecure connection? If so, then the credentials could be compromised by a middle man. The same would be true for the signatures.

Re: It's 2023, so of course I'm learning Common Lisp

#315

Post by p_l »

LispSporks22 wrote: post #288
chlorion wrote: post #65

Earlier quoted context omitted.

I have some cons! Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I think not supporting encryption or authentication for something as important as fetching source code makes QL a non-starter for me and hopefully for anyone else who…

> Last time I checked on it, QuickLisp doesn't support fetching packages over anything except for plain http, with no encryption and no verification mechanism in place to detect files that may have been tampered with during transmission. I know it's not an excuse, but it was fun as heck booting up "capital M" MacOS (9.2.1) and loading Quicklisp into MCL without any trouble. I'm not even sure that's a supported platfo…

I think there might have been bits and pieces somewhere to run Quicklisp on lisp machines... or at least ASDF, which is the core dependency

Re: It's 2023, so of course I'm learning Common Lisp

#316

Post by chlorion »

koito17 wrote: post #79
schemescape wrote: post #77

Earlier quoted context omitted.

Quicklisp doesn’t use TLS or signatures? How have I not heard this before? That would be unbelievably irresponsible. Has this really not been addressed by the CL community? Edit: here’s the issue: https://github.com/quicklisp/quicklisp-client/issues/167 Thanks for bringing this up!

The reason for this is quite simple: portability. Quicklisp also uses plain TAR files to distribute dists. Why? Because quicklisp has a built-in TAR extractor written in 100% standard/portable CL. This allows Quicklisp to run on just about everything, from your computer to real LispMs and operating systems like Mezzano. TLS comes up every time someone discusses Quicklisp, but nobody bothers to go ahead and actually i…

I don't really buy this argument at all.

There is no technical reason why quicklisp couldn't use the systems libcurl and openssl when its available and fallback to fetching with its portable http implementation when they aren't available.

Every other languages package manager has managed to solve this issue!

If the issue is that nobody has actually had time to work on it, that's fair, but I don't believe that optionally supporting libcurl would cause QL to be less portable.

Re: It's 2023, so of course I'm learning Common Lisp

#317

Post by db48x »

pjc50 wrote: post #287
db48x wrote: post #265

Earlier quoted context omitted.

Yes, and whose advertisements do you think show up in every single one of those magazines? Which implementations get mentioned by every single C++ book? Which organization sponsored every single C++ conference? Don’t forget that they had stiff competition from the advertising budgets of other large companies, such as Oracle and IBM. Also, don’t forget that Lisp machines were once the most coveted development machines…

> But Symbolics had to develop not only the language and IDE, but also the OS, the hardware, the microcode, and everything else all at once This was forty years ago . Doing LISP advocacy like this just makes people sound like they're that Japanese guy who refused to surrender until the 1970s. The world has moved on; there have been other opportunities; and LISP has not won them either.

The timeframe doesn’t matter. What matters is that C++ triumphed not because it was a better language, but because it was sold better. It had better advertising.

Re: It's 2023, so of course I'm learning Common Lisp

#318

Post by aidenn0 »

ristos wrote: post #311
aidenn0 wrote: post #252

Earlier quoted context omitted.

> Quicklisp has unfortunately taken over the entire ecosystem, making it hard to use anything else, and you often need to depend on it to use a lot of tools in the ecosystem. It sort of reminds me of Systemd in that way. This is a strange statement. What requires QL to work? In the "bad old days" you had to manually download the sources and drop them somewhere ASDF could find them[1]. This still works. You can blithe…

Ultralisp, Rowsell, Qlot, Quickdocs, etc. Virtually every modern project build/install instructions reference Quicklisp. You have no idea which dependencies you need to pull and from where, which can be a real PITA for a large project. A lot of project code I've looked at also has Quicklisp references in the actual code for whatever reason, usually for testing or building or whatever else, so to run those you need Qu…

Before QL, you looked at the .asd and searched cliki for each name. You can still do that if you like (and can use Google as well). Sometimes the readme had better instructions, but often they didn't work.

In fact, each project in the QL repository includes a link to upstream, so you can use that to find your sources if you like

I literally once rewrote the 20% of a library that I personally needed because it was faster than tracking down all the dependencies.

Your original comment reads like there used to be all these awesome package managers, and QL came around and squashed them, but there was rather a giant vacuum that QL quickly filled.

Re: It's 2023, so of course I'm learning Common Lisp

#319

Post by aidenn0 »

realharo wrote: post #267
aidenn0 wrote: post #257

Earlier quoted context omitted.

And with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation? Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.

My point was, having an actual example of data in front of you, instead of only definition of the structure/schema/interface/type of the data could push people more towards relying on things specific to that example. Especially in dynamically typed languages, but also for things like trying to take the first element of a list that might be empty (in languages where that doesn't return an `Option`), etc. And I wonder…

I see what you were getting at now

I've not personally observed that, fwiw.

Re: It's 2023, so of course I'm learning Common Lisp

#320

Post by aidenn0 »

agumonkey wrote: post #301
TheOtherHobbes wrote: post #224

Earlier quoted context omitted.

LISP continues to be a very interesting language. But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state. LISP would be a more practical language if it included a trivial option to make that possible.

I wish there was some, even theoretical, effort to fix this. It's a crossdomain issue, even react in a way deals with that.

There's a practical way to do that right now in CL; in most implementations it's cl-user:quit, but UIOP defines a portable wrapper for it
Post reply on HN