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

251–260 of 346 posts

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

#251

Post by SanderNL »

Sterm wrote: post #230
SanderNL wrote: post #218

Earlier quoted context omitted.

I think the times when your tech stacks mattered in the slightest are mostly behind us. Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

I always find it odd that people say this. If stack doesn't matter than why not start writing machine code again?

That's not a good faith interpretation given the near infinite amount of options for conjuring up your favourite moneyprinting system of choice besides "machine code". SBCL is about the most arcane option you can pick and even that can work, which I think actually proves the point: it doesn't matter to any significant degree (anymore).

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

#252

Post by aidenn0 »

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

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 blithely live as if QL does not exist and get that same experience.

1: Yes, there was asdf-install, but I think I managed to get that to work once with about half-a-dozen tries?

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

#253

Post by underdeserver »

SanderNL wrote: post #218
ilrwbwrkhv wrote: post #3

Steel Bank Common Lisp is the workhorse which led me to build profitable software companies. I don't think I would be as productive without it. The repl driven workflow is amazing and the lisp images are rock solid and highly performant.

I think the times when your tech stacks mattered in the slightest are mostly behind us. Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

If this were true then half the posts in HN would have no audience :)

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

#254

Post by aidenn0 »

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

When I started using CL 20 years ago, libraries were stored on cliki and any malicious user could put malware there. Any source you asdf-installed was generally GPG signed and the installer automatically checked signatures against your personal trust-chain. Learning CL back then was my first introduction to GPG (and Emacs, and Linux)

> When I started using CL 20 years ago, libraries were stored on cliki and any malicious user could put malware there. Any source you asdf-installed was generally GPG signed and the installer automatically checked signatures against your personal trust-chain.

Which, in practice, involved downloading GPG public keys from cliki because I didn't know every single CL developer.

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

#255

Post by aidenn0 »

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.

> LISP would be a more practical language if it included a trivial option to make that possible.

If you're using SLIME: M-x restart-inferior-lisp

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

#256

Post by foobarbaz33 »

dleslie wrote: post #138
Capricorn2481 wrote: post #100

Earlier quoted context omitted.

I'm confused. Why aren't you all just working on your own machines?

The classic lisp way is to build a runtime image by editing the image while running it, then dumping a binary. You never specifically need to load a source file. But you can't easily collaborate with that style of development.

With lisp you typically develop in source files, versioned with Git. The same as any other language. Source files and live development are not mutually exclusive. SLIME can send code snippets from your file over to the REPL for live development. You have your cake and eat it too.

The REPL (or scratch buffer) is typically used for testing/observing. Not the actual source code development. Although it is possible to never write your source code to a file if you're just playing around with a toy experiment.

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

#257

Post by aidenn0 »

realharo wrote: post #242
ColonelPhantom wrote: post #231

Earlier quoted context omitted.

In that case, can't you just restart the REPL? Or give the program a main function that you run?

Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation? E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc. That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak…

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.

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

#258

Post by AnimalMuppet »

tikhonj wrote: post #28
peanutz454 wrote: post #12

Earlier quoted context omitted.

This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)

Because language popularity is, at best, loosely correlated with any intrinsic qualities of the language itself.

I was going to disagree with you, until I re-read and noticed the word "intrinsic".

I would say that language popularity is highly correlated with the actual usefulness of the language. But "actual usefulness" covers far more than the "intrinsic qualities" of the language. It also covers the scope and quality of the standard libraries, the third-party libraries, the available tools like compilers, IDEs, and debuggers (which may be third-party), available documentation and training, and people available to hire who know the language. Of those items I listed, the only parts that could be considered "intrinsic" are the standard libraries and the tooling that comes with the language by default.

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

#259

Post by eadmund »

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…

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

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

#260

Post by dawnofdusk »

Sterm wrote: post #230
SanderNL wrote: post #218

Earlier quoted context omitted.

I think the times when your tech stacks mattered in the slightest are mostly behind us. Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

I always find it odd that people say this. If stack doesn't matter than why not start writing machine code again?

Agree. ThePrimeagen had something to say about this on one of his streams, responding to someone who said "The programming language doesn't matter, only the programmer." He said something like "If that were true, let's just all go back to writing C, it's pretty good. But then you'd say 'well not exactly...'"
Post reply on HN