libera/#lisp - IRC Chatlog
Search
21:46:39
skeemer
how rich is common lisp in terms of 3rd party libraries? i am going through SICP, i know it's scheme, but i think adopting a scheme implementation is frustrating because of the lack of libraries, is common lisp richer in this context?
21:48:56
wasamasa
while people have solved SICP exercises in other languages, it kind of defeats the point
21:52:46
skeemer
wasamasa, sorry i mistake in explaining myself... i wanted to say,, while i am reading SICP i would like a lispy language to do real-world projects...
21:53:51
skeemer
Lycurgus, oh really? ok thanks, i just thought this was a general purpose lisp channel and good idea to ask here
21:56:12
Lycurgus
as far as libraries there's the ones in quicklisp then there's a much large and generally more problematic set
21:56:25
edgar-rft
skeemer: needing lots of libraries usually means that the core language lacks most of things, or in other words: the more libraries required to make things work the shittier is the language itself
21:58:37
skeemer
edgar-rft, yeah i don't think making basic geometrical shapes or doing gtraphics should be included in the standard library... but with scheme is becoming a nightmare unless i use racket
22:03:16
Lycurgus
libs in cl means something generally different, functionality that is generally application oriented
22:04:30
Lycurgus
in practice both communities have greater implementation differences and diversity than say php or whatever
22:06:40
Odin-
Well, I'd argue that because of the non-updated nature of the CL spec, there are nowadays quite crucial libraries that aren't very application-oriented.
22:06:59
edgar-rft
The advantage of having a pretty-much specified language like Common Lisp is that it's very likely that your code still will run in ten or twenty years in the future with noo need of major rewrites or modifications. The disadvantage is that thing that worked poorly in 1994 still work poorly in 2021.
22:08:05
mfiano
Common Lisp has many non-application-oriented libraries. Things like MOP extensions and implementation portability libraries are common. Most CL projects are attempts at bending the language to do things that are normally extremely difficult in other languages.
22:08:25
skeemer
edgar-rft, the second principle applies in every language, something that worked poorlu in 1994 will not work at all in 2021
22:09:19
Odin-
mfiano: Ah, but where is the line between bending the language to a very specific domain and an application?
22:11:02
GreaseMonkey
sure it completely fails as a benchmark when it gets built this way but yeah, some stuff does run a hell of a lot better nowadays than it did decades ago
22:19:42
jcowan
skeemer: Less than you'd think. http://recycledknowledge.blogspot.com/2011/11/john-mccarthy-inventor-of-lisp-died.html is a Lisp theorem prover written in 1958 that still works fine in CL and Scheme today
22:31:37
moon-child
I don't find 'you can rewrite code (or make a shim to do it for you)' a compelling argument of stability
22:31:47
moon-child
beause, sure, you can _always_ rewrite code; or build a compiler from one language to another
22:32:45
moon-child
that doesn't mean lisp code written in the 60s _works_ in common lisp or scheme, any more than it means algol code _works_ in a c compiler if you're stephen bourne
22:34:30
moon-child
post-standardization cl tends to have a _fairly_ good compatibility story, but is hampered when it tries to communicate with the outside world
22:44:46
jcowan
moon-child: The quantitative difference is so small as to amount to a qualitative one. In any case, by th standard you are giving, code that depends on a compiler or library bug becomes unstable when that bug is fixed.
22:49:24
moon-child
the standard I am giving is a _practical_ one. Compiler bugs are rare; system apis change quite a bit
22:50:13
moon-child
this is not a knock on lisp fwiw. Outside of probably cl, c, and perl, you would never expect 25-year-old code to work _at all_
22:52:37
Odin-
Plenty, but there is a standard and surprisingly there was a bit of code that adhered to it.
22:53:40
Odin-
ACTION got thirty-plus year Pascal code from an article on computer vote counting to work a little while back, despite not actually knowing any Pascal.
22:55:18
jcowan
beach makes the point that stability is more likely when there is a standard with multiple implementations.
22:57:05
moon-child
hmm. It occurs to me that the advent of opensource probably reduces the stability of programming languages over time
22:57:36
jcowan
Ada, APL, Basic, C, C++, Cobol, Common Lisp, Forth, Fortran, ISLisp, Mumps/M, Pascal, Prolog, PL/I, Rexx, Scheme, Smalltalk, SQL.
22:59:16
jcowan
There are national and ISO standards for a few more, but no readily available implementations.
22:59:19
moon-child
hmm. My impression is that SQL, apl, forth, prolog, and smalltalk have been developed further and are largely incompatible across modern implementations. Mumps, rexx, pl/i, and basic are mostly dead
23:02:50
Odin-
moon-child: I think PL/I is the only one of these that you can't easily argue has been massively splintered by implementation extensions.
23:03:20
jcowan
APL has only two major forks, IBM and Dyalog, and two standards: the small, which is shared by both, and the large, which agrees with just one (I forget which)
23:03:41
Odin-
moon-child: But the Lisps have means of compensating for those that aren't widespread.
23:04:23
moon-child
jcowan: ibm is basically iso apl2. Dyalog does its own thing. But historically there were others dialects, notably sharp apl
23:07:05
Odin-
As for Forth, it doesn't help that its pitch is basically "I'm small enough that you can implement me from scratch for each project". :p
23:19:00
GreaseMonkey
i tried learning forth and i was thoroughly disappointed, and that was after being impressed and terrified from a short bout of learning Tcl
23:21:02
GreaseMonkey
(nowadays i tend to use Tcl mostly as a replacement for nontrivial shell scripts which aren't sufficiently nontrivial enough for me to do them in Python instead, honestly that language is a lot of fun to pick up even if its "everything is a string" approach feels so damn wrong)
23:48:33
mdhughes
I routinely reuse bits of C from old DDJ, and it compiles & runs with little change or errors. "int" may not mean what it used to.
23:50:48
mdhughes
Old Scheme is generally the same as current Scheme, but there's a lot of new stuff since. But I think all the old papers still work, at least post '() = NIL.
23:53:39
mdhughes
REXX has had two major forks since 1979, but the OG language still works and has users and a conference every year.
6:42:56
mishugana
Hello folks, back again with the sbcl-loading-quicklisp issue. I timed it, and it takes around 40 seconds for (load #P"~/quicklisp/setup.lisp"). Anybody else face that issue?
6:43:55
mishugana
`sbcl --no-userinit` is practically instantaneous, so I suspect the issue might be with quicklisp. I had a suspicion that it might be asdf, but loading asdf directly is superfast.
6:44:20
mishugana
Maybe some issue with some networking stuff that quicklisp might be doing inside `setup.lisp`?
6:45:01
mishugana
Anybody else face this issue? I don't think the OS matters, but I'm on macOS Mojave.
6:45:56
mishugana
As an aside, the only way to work without quicklisp is basically to download the dependencies myself and load via asdf, right?
6:46:34
mishugana
I took a look at clpm, but that didn't work either with some crypto issue that I'm too tired to debug, qlot uses quicklisp internally from what I've seen, so there are no options in the package space from the looks of it
6:46:59
mishugana
Shame, I really wanted to get back to CL, but if I can't make this work then I think I'll go with Clojure instead.
6:48:38
moon-child
mishugana: is this on a fresh quicklisp installation? Try wiping it out and reinstalling?
6:48:54
wasamasa
the existence of package managers is quite new if you take the sheer age of things into account
6:49:46
mishugana
moon-child: I uninstalled quicklisp and tried, same issue. I even tried installing the client and quicklisp directory from 2010 from the github site, but same issue (or maybe it didn't work correctly with versions as I expected).
6:50:11
mishugana
Initially I thought the problem was sbcl (since I'm building it from source), but that wasn't the case, apparently.
6:51:03
mishugana
wasamasa: I agree, that's true, but today working without one is almost unheard of.
6:52:13
mishugana
Which is strange indeed since when I last tried it, it worked fine (couple of seconds load at most), which was about a year back.
6:52:50
mishugana
Hence my suspicion that quicklisp's setup does some networking stuff (?) which might be causing issues with mirrors(?)
6:53:20
wasamasa
plenty of scheme projects just bundle the occasional dependency that's not satisfied by some SRFI
6:54:11
mishugana
Yeah, and I don't quite like Clojure all that much, but leiningen works fine as well.
6:54:12
amirouche
guile has guix (and the deprecated guildhall), chicken has eggs, chez has akku, chibi has snow, gambit has builtin package manager so it is becoming a thing
7:47:43
mishugana
The problem was not with quicklisp. The problem was that in my asdf config file (~/.config/common-lisp/;;(:tree "/Users/z0ltan/quicklisp")
7:48:33
mishugana
Sorry, ~/.config/common-lisp/source-regsistry.conf.d/projects.conf file, I had (:tree "<my home path>/dev"), and `dev` contained a whole bunch of nested directories
7:48:59
mishugana
I changed that to `dev/projects/common-lisp` which is where most of my CL projects live, and that fixed the bloody issue.
7:49:20
mishugana
I know it's mostly my fault, but that fucking configuration is ridiculous as well.
7:52:18
mishugana
Though this issue is more with the way that asdf locates projects. If there was a way to specify a metadata file in the local project that asdf could pick up, that'd be wonderful, but unfortunately not so.
7:57:55
mishugana
Anyway, thanks for the discussion. It motivated me enough to try and find out the root cause of this annoying issue.
7:58:13
mishugana
It is strange though that asdf still takes so much time for a moderately deeply-nested directory