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

91–100 of 346 posts

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

#91

Post by schemescape »

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 doesnt ever use this and instead constantly pushes latest of everything from git repositories

Yeah, I didn't recall off hand, but this was one of my main complaints with Quicklisp vs. other package managers I've used (for other ecosystems--not CL).

> whereas some MITM from plain HTTP connection to Quicklisp would require so much coordination (and specificity of target) that it's just not in my threat model at all

I hope you're right, but it still seems like an unnecessary risk. Even if I can't imagine a scenario where someone is able to MITM me (or, more likely, a server I'm deploying code to), there's still the lingering feeling that it's possible. I certainly wouldn't download an executable over HTTP and run it, and downloading library code is fairly similar (although easier to inspect, at least).

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

#92

Post by opportune »

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting.

My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and is instead “program that starts, reacts to input from user, then gets closed by the user” or “program that starts, then responds to network or other automated I/O (to serve web pages, to monitor something, to emit logs, etc) then stops when the other software tells it to”. This is a lot harder to do in a purely functional style, or at least it is in most opinionated functional programming implementations I’ve used, because you’re no longer “just” evaluating some expression but instead initializing state, reacting to I/O, then updating state and/or performing further I/O potentially while using parallelization to perform monitoring/listen for other things/perform further I/O and state updates.

Of course it’s not impossible to do these things with Lisp but from my couple of semesters of exposure of FP in undergrad and use of FP features in C++ and Scala professionally to solve these kinds of problems… it seems quite hard to get FP to work for these applications, and that lack of suitability is what discourages me from diving more fully into FP

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

#93

Post by schemescape »

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

SBCL supports static builds by saving core with runtime into an executable file you can then copy around at will.

Do they work across glibc verisons or musl libc? My understanding is that they do not.

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

#94

Post by atgreen »

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

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!

Try ocicl instead of quicklisp. System tarballs are hosted in an OCI registry, and are downloaded via TLS connections (obeying proxies). Tarballs are signed and signatures are stored in the sigstore rekor transparency log for later inspection. https://github.com/ocicl/ocicl

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

#95

Post by xedrac »

10g1k wrote: post #56

There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.

I hear this a lot, but have never once seen a COBOL job posting.

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

#96

Post by manicennui »

10g1k wrote: post #56

There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.

It's not as though the company that bought the consultancy that employs many of the core Clojure people runs a bank with Clojure.

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

#97

Post by manicennui »

xedrac wrote: post #95
10g1k wrote: post #56

There are plenty of old business systems which are critical, can't be removed or turned off, and use LISP, COBOL, etc. Meanwhile, nothing important uses Clojure or other trendy flash-in-the-pan language. If you want an interesting project, sure, use Clojure or something. If you want money, learn COBOL.

I hear this a lot, but have never once seen a COBOL job posting.

I think a lot of these jobs go to former employees who now contract.

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

#98

Post by [deleted] »

mathisfun123 wrote: post #86
LispSporks22 wrote: post #85

Earlier quoted context omitted.

In TFA, go to the “Try this in your favorite repl”, try that in your “repl” and that would be the fine distinction you’re missing.

>The answer to that question is the differentiating point of repl-driven programming. In an old-fashioned Lisp or Smalltalk environment, the break in foo drops you into a breakloop. do you want me to show you how to do this in a python repl? it's literally just breaking on exception...

[deleted]

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

#99

Post by vippy »

opportune wrote: post #92

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and…

It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.

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

#100

Post by Capricorn2481 »

dleslie wrote: post #19
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)

Eventually you need to work with other people, and using a common time-shared or multi user session is unlikely. Now consider that lisp images generally can't be easily diff'd or merged. And with that the edit-and-continue paradigm loses much of its value. If you have to commit changes to a shared source file anyhow then you'll be not much worse off with debugging a core dump.

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