libera/#lisp - IRC Chatlog
Search
17:46:43
mishugana
Hello folks, using SBCL 2.1.9.83-c0a8e0749 on macOS Mojave (10.14). Starting sbcl on the terminal takes around 15-20 seconds now (used to take just a couple before, last tested around a year back). Is this a known issue, or is there something I can test out locally? Anybody else face the same issue?
17:50:08
mdhughes
Hm. SBCL 2.1.8 takes <2 seconds on Big Sur. So that narrows it down to two variables…
17:51:09
mishugana
mdhughes: yitzi on #sbcl suggested trying out "--no-userinit" while launching sbcl - that make it instantaneous, so probably an issue with quicklisp(?)
17:52:48
mishugana
mdhughes: thanks for the response though :-) - will try reinstalling quicklisp and see if that helps.
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.