freenode/#lisp - IRC Chatlog
Search
22:08:52
arichiardi[m]
Hi there! I was wondering if anybody know whether CL bindings for LUKS functions (libcryptsetup)? No problem if not, just making sure I am not missing any :D
23:51:34
lotuseater
hehe I tried and it word: #1=(loop :for i :in '#1# :when (keywordp i) :collect i)
23:54:06
thmprover
Is there some way to check if a CL project name has been taken, or is currently in use? I have a horrible pun I want to use, but I don't want to steal it if someone else already has it.
23:57:01
lotuseater
yes! and writing LOOP words as real keywords is not only good for syntax highlighting but also something like DESTRUCTURING-BIND
23:58:34
lotuseater
thmprover: but for catching bigger area in the Venn diagram of names github would also be useful
23:59:06
no-defun-allowed
There aren't any other software projects called Netfarm, but there is an Italian open source consultancy named Netfarm.
0:00:06
no-defun-allowed
Prior to that, there was also GNU Nettle (a C cryptography library). So it's not just Lisp projects, and it's not just software projects either.
0:02:01
lotuseater
i wonder how difficult it is to realize good and safe cryptostuff in CL. someone told me two years ago the best is in deterministic aka direct assembly
0:05:08
no-defun-allowed
Ironclad makes an attempt to be constant-time IIRC, for example there is an equality operator that computes error |= x[n] ^ y[n], but it's really up to how the implementation handles things.
0:06:17
thmprover
My experiment with declarative theorem provers will henceforth occupy the CL-AIM project.
0:06:47
thmprover
CL-AIM will test my claim about the irrelevance of the choice for the foundations of mathematics.
0:08:16
lotuseater
thmprover: oh sounds interesting. i want to understand more how to work with ACL2, Coq and recently i read L∃∀N should also be good
0:09:26
thmprover
ACL2 looks fascinating. I have a love/hate relation with Coq, but my interest is in doing mathematics with theorem provers, not verifying software.
0:10:41
no-defun-allowed
ACL2 is very different. It does the theorem proving process automatically, but you usually need to steer it with lemmas, and it only does first order logic (no higher order functions).
0:11:20
lotuseater
yeah and my knowledge of category theory, dependent types is not deep enough yet. but Haskell drills me to widen it. but that's another story. and I know ACL2 is another approach than Coq
0:12:15
thmprover
Automath is a good way to learn dependent types, but it's quirky...it's not even in the lambda cube.
0:13:43
thmprover
no-defun-allowed: I thought that "wandering" aspect to ACL2 was particularly unique and intriguing.
0:14:29
thmprover
Wait, hypothetical question: CL is a lisp-2, so there are separate namespaces for functions and values, right?
0:15:36
no-defun-allowed
Yes, usually you would use a hash-table, and some accessor functions like FIND-THEOREM, (SETF FIND-THEOREM), ... to use the namespace.
0:19:10
thmprover
no-defun-allowed: that was my first instinct, too, but it is a "poor man's namespace" rather than a first-class namespace.
0:19:45
no-defun-allowed
I don't think there are first-class namespaces in Common Lisp. And if you implicitly FIND-THEOREM on some things, you wouldn't be able to tell the difference.
0:20:01
no-defun-allowed
eg (make-instance 'some-class ...) == (make-instance (find-class 'some-class) ...)
0:21:12
thmprover
Yeah, I was just curious if first-class namespaces were allowed. It seems like quite a niche thing, so completely understandable CL would not have it.
0:22:11
no-defun-allowed
And all the CL namespaces are just sets of accessors (occasionally with an environment object).
0:30:04
Bike
having an actual namespace would be most useful for when you want lexical bindings. not sure that's the case for theorems, though.
0:32:52
thmprover
I will have to study symbol-macrolet, I have a peripheral awareness of it, but haven't looked at it.
0:33:29
Bike
well, basically you can have your binding macro expand into (symbol-macrolet ((some-magic-symbol bindings)) ...), and then use (macroexpand-1 'some-magic-symbol env) to get the bindings.
0:36:23
thmprover
But you couldn't re-bind, say, 'let' (or some other builtin function) temporarily using symbol-macrolet?
0:37:09
Bike
let is a special operator, not a function. and symbol-macrolet deals with variables rather than operators. you can use macrolet to shadow operators.
0:44:30
Bike
oh, and you said CL was a lisp-2, but there are actually some more namespaces too, like the one for types and classes. doesn't come up immediately in the evaluation semantics though.
3:30:22
loke[m]
Imagine a list of "graphical objects" (because that's what they are in Climaxima), and there is a generic function called SAVE-STATE that, when called with a graphical object as an argument returns its configuration as a specially formatted list (a Maxima list actually, but that doesn't matter).
3:31:02
loke[m]
The caller has a list of these objects, and it collects the class name and the output of SAVE-STATE for each object.
3:32:59
loke[m]
Now, I need to write a LOAD-STATE that does the opposite. One way of doing that would be to take the class name, and call MAKE-INSTANCE on it with the values previously returned from SAVE-STATE as argument.
3:33:25
loke[m]
Another would be to have a big ECASE that knows about the object types and dispatch to the correct initialiser.
3:36:00
loke[m]
Bike: But that would add the requirement that whatever is returned from SAVE-STATE is in a form valid as argument to MAKE-INSTANCE. And it may be that some special internal state needs to be initialised that isn't visible from MAKE-INSTANCE. I'd like my solution to be as flexible as possible.
3:36:16
loke[m]
Another idea I had was to use ALLOCATE-INSTANCE and then call a generic function with this instance.
3:37:05
Bike
what make-instance does is call allocate-instance and then call initialize-instance on the result. initialize-instance can be customized with whatever keyword parameters for providing whatever state.
5:25:05
loke[m]
Bascially, you have: SBCL - Most common use. It's really high performance, everything is well supported on it and it has great error messages. ABCL - If you need to integrate with the JVM. ECL - If you are looking at integrating with C code, or if you are running on things like embedded platforms.
5:26:12
srandon111
thanks loke[m] you gave me a great overview about the different implementations, that's really what i needed!
5:26:15
loke[m]
zacts: Well, hasn't had a release in 10 years, and most software don't work on it anymore. It's supposedly still being developed but I wouldn't bother until they actually decide to release something.
5:26:35
zacts
loke[m]: ok, thanks. the reason I ask is I think it's what that land of lisp book uses.
5:27:14
loke[m]
The benefit CLISP had was that it was easy to port to new platforms. However, these days I think ECL fits that role much better.
5:27:50
loke[m]
Then of course there is Lispworks and Allegro. But those are commercial products and unless you're a commercial project there isn't much reason to look at them.
5:28:33
no-defun-allowed
Except for the networking code, you can run all the code in Land of Lisp in any Common Lisp implementation.
5:29:13
loke[m]
Did I miss anything? There is GCL. That one still exists and gets fixes once in a while. These days the only thing it's used for that I know of is some distributions still build Maxima using it.
5:29:53
no-defun-allowed
I am sure someone has ported it already, but a fun extension might be to look up the usocket documentation and have a go at porting the networking code to use usocket. From memory, the CLISP and usocket interfaces are very similar.
5:30:22
loke[m]
zacts: Yes, it can. Most JVM languages use some Java-compatible way of exposing API's.
5:31:00
no-defun-allowed
I'm also sure that interfacing Kotlin and Scala is basically the same as interfacing Java.
5:32:12
loke[m]
But ABCL has a huge benefit if you want to integrate will any of the billions of Java libraries.
5:32:39
srandon111
loke[m], i was searching for something similar to python scapy ... beware NOT scrapy, but scapy, which is a packet crafter
5:32:58
loke[m]
With SBCL I've had to turn to IOLIB quite a few times. IOLIB is OK, but its requirement on libfixposix is very annoying.
5:33:50
no-defun-allowed
Searching "common lisp packet crafting" comes up with https://github.com/mets634/packet-crafting/ which was added to Quicklisp recently.
5:34:32
loke[m]
srandon111: You might want to look at the BINARY-TYPES package, which is the first one I found while searching.
5:34:58
no-defun-allowed
srandon111: Quicklisp is some software you can use to retrieve Common Lisp libraries over the internet.
5:38:07
loke[m]
srandon111: Of course not. Sending packets is a different thing. You open a connection and WRITE them. These are different things, and handled by different libraries of course.
5:39:03
no-defun-allowed
"packet crafter" suggests that we are trying to fiddle with packets, and not normal network programming which doesn't explicate packets.
5:39:36
srandon111
no-defun-allowed, i see but i've seen generally that packet crafters generally also have functions to send/receive packets
5:40:05
srandon111
plokami... wow, this is the thing i was searching i think... now i only have to understand how to idgest lisp docs
5:45:49
srandon111
also RISC-V 64 architecture is not supported with DragonFlyBSD, well SBCL does not seem really cross-platform as i thought
5:46:25
loke[m]
srandon111: Well, the platform is very low-level, which is why it can be so efficient.
5:46:29
no-defun-allowed
I think you are the only person in #lisp that uses dragonflyBSD on PPC64le.
5:47:11
srandon111
no-defun-allowed, wow really? why? what you don't like about dragonflyBSD on PPC64le ?
5:47:44
moon-child
I don't think anyone dislikes that combination specifically; just, both components are somewhat obscure
5:48:20
no-defun-allowed
Now that you mention it, I don't really like Unix at all, but otherwise I think that most people don't use PowerPC machines, most people don't use BSD, and out of the BSD family, most people don't use dragonflyBSD [citation needed].
5:48:39
loke[m]
srandon111: I can't speak for others, but for me it's a combination of no access to the hardware, and that my BSD machines run FreeBSD which works fine for my use cases.
5:49:39
no-defun-allowed
"An operating system is a collection of things that don't fit inside a language; there shouldn't be one."
5:49:48
loke[m]
Various Linuxes. I try to run Qubes OS as much as I can, but I tend to need GPU support which means I'm on Fedora/Arch.
5:50:23
srandon111
no-defun-allowed, sorry what do you mean? i mean if you don't like UNIX what are you using? TempleOS or windows?
5:51:24
srandon111
loke[m], what's the meaning ? i mean if you run freebsd or MAC you still run some kind of UNIX
5:51:56
no-defun-allowed
No, I also put up with a Linux machine. Dammit, two of them. And the two Android phones on my desk, which sometimes count and sometimes don't.
5:52:01
loke[m]
srandon111: Unix isn't good. It's pretty awful really, but out of the systems one can practically run these days, there isn't anything better.
5:53:22
loke[m]
I don't fully agree with all of beach's opinions, but I'm mostly aligned, so I would recommend you read his paper on this topic.
5:53:28
no-defun-allowed
Ideally, I would have something closer to Genera, then closer to Mezzano or CLOSOS, but (supposing I can accept the slowdown) with some form of network transparency.
5:53:47
no-defun-allowed
I have network transparent and replicatable objects of some form in Common Lisp, now I just need CLOSOS.
5:54:45
srandon111
loke[m], no-defun-allowed you guys talk bad about UNIX just because I think you didn't have a real UNIX experience, that is DragonFlyBSD on a PPC64le!
5:55:22
beach
srandon111: We talk bad about Unix because we knew that there were better things before, and we know that we can do much better.
5:56:05
beach
srandon111: Unfortunately, many generations of software developers have been brainwashed to think that Unix is the best we can do, and the best we ever did.
5:56:40
loke[m]
Also, I have worked with different Unix vendors since the mid-90's. And I did spend many years working for Sun Microsystems, and my opinion is that the best C code base I've had the pleasure of working with was Solaris. I do believe I have quite a bit of Unix knowledge.
5:56:47
no-defun-allowed
In the introduction to the book I'm writing, I also have a few things to say about the "real" Unix philosophy, and the braindead programs it spawns. We pretend we have smaller and smaller machines, write programs targeting those machines, then simulate having smaller machines, and screw up inter-"machine" communication.
5:57:23
beach
zacts: Well, applications compensate for the horrible programming model, but the cost is huge.
5:58:10
loke[m]
Also, mac, windows and linux use pretty much the exact same programming model for the most part. They all have the same memory, the same concept of processes and threads, etc.
5:58:42
no-defun-allowed
ACTION will refrain from trying to guess the usage of a hardware × operating system combination next time.
5:59:50
loke[m]
What most of us consider "better" doesn't actually exist in a user-friendly package at this time.
6:00:06
srandon111
loke[m], well it's somewhat different, i advice you to try it on your laptop for a real experience... install it, it's cool! well i don't know how the experience is on non PPC64le
6:00:38
no-defun-allowed
Hm, looking at https://en.wikipedia.org/wiki/List_of_BSD_operating_systems there's quite a few BSD systems, and it appears they have less ABI compatibility than Linux distributions.
6:01:17
srandon111
well after that you cannot make phone calls, but you have a full fledged cli shell that rocks!
6:01:24
loke[m]
srandon111: Most of us are experienced enough that a new coat of paint on top of the same old isn't going to excite us very much.
6:02:05
no-defun-allowed
Damn, even my girlfriend used to maintain a BSD operating system. Kinda rude for me to forget then. Don't tell her that.
6:02:21
srandon111
there is also this project "Gentoo/DragonFlyBSD" that was interesting but unluckily does not seem to be ported to PPC64le
6:02:32
loke[m]
srandon111: Trust me, I know perfectly well what you're talking about. I was pretty happy to be able to install a proper shell on my Lego Mindstorms hardware so I could ssh into it and actually do stuff with it.
6:03:01
no-defun-allowed
But given the pains I have with a "fake" Unix, I don't want to know how a "real" one goes.
6:04:11
loke[m]
srandon111: But you have to understand that when we talk about a "better" operating system, we look at something way beyond just a new user interface, or getting rid of systemd.
6:05:08
fe[nl]ix
loke[m]: would it be useful to you if I distributed an SBCL image with libfixposix (an perhaps also openssl) statically compiled ?
6:05:12
loke[m]
I'm saying that the whole idea of a "process" is not necessary. It was based on ideas that would not be needed.
6:05:52
beach
zacts: Even Multics (that Unix attempted to copy as much as they could) did not have a kernel.
6:06:21
srandon111
no-defun-allowed, we make it entirely lisp but with the same user experience of drangonflybsd on ppc64le
6:06:57
loke[m]
fe[nl]ix: For me? No. I can personally deal with libfixposix. It's no big deal. I also have no issues with software distribution myself. The one issue with it that people download SBCL, ECL, ABCL, try to quickload a project that depends on IOLIB and it explodes because libfixposix isn't available.
6:07:09
srandon111
i mean why people should still use Win/Mac/Lin if they can have a dragonflyBSD experience?
6:07:51
loke[m]
fenlix: I think having libfixposix in quicklisp would be a solution. I think it would be possible, with the package including the C source code and it being compile das part of loading the ASDF package.
6:09:35
fe[nl]ix
loke[m]: I doubt that would be possible because the configure script needs to run first, then the library must be installed in a proper location for loading to work
6:09:56
loke[m]
srandon111: I think we're all having completely different perspectives. Even if you don't agree with it, could I ask you to watch this video showing what Lisp-based computing is all about. It doesn't mean that we all want exactly this, but it's an illustration of what used to be, and why we're looking at these concepts for inspiration?
6:10:12
srandon111
no-defun-allowed, let's strt it dude... like let's quit our jobs and start this project, we will become rich... i already all the people using our OS in schools and hacking with the DragonFly
6:11:07
srandon111
loke[m], i am not saying i don't agree with you... because my skill level is much lower than yours to have my own robust opinion on this topic, so surely, I will inspect the references you are sending me
6:11:26
loke[m]
zacts: Well, I'm not directly working on it. I'm trying to help out as much as I can though.
6:12:06
beach
zacts: I really need to get SICL into a good-enough state that others can start working.
6:19:07
no-defun-allowed
Quite frankly, I don't give a shit - you may get commercial success, but if I do that, I'm sure I've failed in my work.
6:20:27
srandon111
sorry for annoying you with the pings, it wasn't my purpose i was just excited for ADFICOS you know
6:21:39
zacts
I'm just having a difficult time wraping my head around not having a kernel+userspace.
6:22:26
no-defun-allowed
I'm not very excited about it - most of my problems with my work are because of serialization (and because people end up using data structures and the serialized representation as the basis for their protocols) and process boundaries.
6:24:18
no-defun-allowed
Instead of working with objects like normal people, we're writing lenses translating JSON documents and basing more protocols around "the schema" and whatever.
6:24:51
no-defun-allowed
srandon111: I have emotions, thankyou. And I have been depressed that wherever I go, there is not much imagination going around.
6:25:04
loke[m]
srandon111: I can telly you why I'm less interested. I've been excited about these things many times before, and after a while you get jaded. There really isn't much new here.
6:26:06
srandon111
no-defun as you can imagine, i am joking, i didn't mean you have no emotions... i hope you can solve your problem with the lenses anyway!
6:27:20
no-defun-allowed
And I said I didn't want to use lenses, but whatever I say doesn't seem to be sticking.
6:28:36
srandon111
no-defun i am really sorry, i mean it was just a joke to say "you are emotionless" i don't even know you, i mean it was just to joke, really I mean sorry! I really didn't have any reason to say that...
6:28:37
loke[m]
srandon111: I really don't want to try to extinguish your excitement. I used to be really excited about some of these things too. I used to be really exited about the prospects of GNOME, for example. How it promised to integrate applications in a really neat way, when it was based on CORBA (remember that one?).
6:29:14
loke[m]
In a way, GNOME did manage to fulfil some of its promised, but I see its true potential to be hampered by a lot of legacy.
6:31:32
loke[m]
So what me, beach, n-d-f and others are talking about here are ideas related to completely getting rid of a lot of this legacy. For example, why do we even have the concept of a "process" with different "address spaces"? Well, the reason is that once upon a time you wrote code in assember or C which translates directly to machine code where the code can access any memory address they want to.
6:31:51
loke[m]
The idea of a process serves to abstract this away at the machine lever to make execution safe.
6:32:57
srandon111
loke[m], so this is the resource i should read right ? https://web.mit.edu/~simsong/www/ugh.pdf
6:33:14
loke[m]
Well, what if you abstract things on a higher level? Most software already does this, for example Lisp, Javascript, Java, Python, etc. All of these use some form of "managed runtime". If we all do this already, why are we even restricting ourselves by thinking about resources in terms of processes?
6:35:00
loke[m]
srandon111: well, you could. It serves to illustrate that there used to be different (and sometimes, but not always) better solutions to Unix solutions. It reads like grumpy old men complaining abut how Unix ruined their favourite operating systems (Which usually is VMS), which is a style I don't like, because VMS is also not perfect.
6:35:06
srandon111
loke[m], ok so basically i can imagine a machine where the OS is an interpreter, let's say for the sake of this example a sort of python interpreter and then basically everything that gets created is a thread
6:35:37
loke[m]
srandon111: For that, I suggest you read beach's paper. It really explains exactly that.
6:35:55
beach
srandon111: Today, when you need to communicate between processes, you need to convert everything to a stream of bytes. That is not only silly and costly, you also lose identity.
6:37:34
beach
zacts: As loke[m] says, the idea of a process is to emulate a bare machine so that we can program the same way that we did some 70 years ago, but there is no profound reason why we would want that. So if you don't allow application code direct access to its entire address space, there is no need for a kernel.
6:37:35
srandon111
beach, what do you mean by identity ? ok sorry probably i will find that out in the paper
6:38:04
beach
srandon111: You can't send a pointer to an object from one process to another, and have that other process update it.
6:38:15
loke[m]
srandon111: Yes, vulnerabilities doesn't magically go away. However, process boundaries also doesn't magically _solve_ those problems.
6:38:55
beach
moon-child: Yes, there are kludges to get around it, but you can do that only if both processes agree on the addresses and such.
6:39:33
srandon111
it's crazy how the common OS are behind the state of the art o the research like decades
6:40:27
loke[m]
srandon111: It's not crazy at all. These systems became popular for the exact reason that they are old. It's stable platform on which people can develop solutions for decades without worrying about things changing underneath them.
6:40:28
beach
srandon111: Not quite. The technology existed 50 years ago. It is just that Unix became very popular and squashed what we had.
6:41:03
loke[m]
srandon111: In a way, yes. A lot of ideas in temple is embodying the same concepts as Lisp machines.
6:41:46
loke[m]
If you look a people talking about temple they are impressed by how objects are preserving identity across the system. Exactly what Beach is talking about.
6:42:04
loke[m]
However, it's of course hampered by all the crazy stuff. But there are neat ideas there.
6:54:21
zacts
so could a user extend the system kind of like on the hurd? a user could implement their own filesystem or device driver to use?
6:58:33
no-defun-allowed
Outside of technical issues like the isolation model, I dislike Unix because a. how you expect to use it doesn't correspond to how you should use Lisp - I read tutorials where the author wrote "Oh, SLIME and Emacs and all that shit? Don't need it. Just use vi to write the file, and then run 'sbcl --script file.lisp'", and I know that they have screwed over their readers; and b. it's presented as an improvement over
6:58:33
no-defun-allowed
Windows or macOS, and then you need a kick in the stomach to consider that you might want to improve on that, too.
6:59:18
no-defun-allowed
The former is often blamed on Lisp ("guis this is why Lisp isn't popular, we just need to take away the part that makes people want to use it"), but I choose to blame it on Unix.
7:00:45
beach
There is no file system because there are no files. But one could be written of course.
7:00:57
no-defun-allowed
The "converse" of that would be why I wouldn't write a Unix clone in Lisp; you lose the dynamics and the abstraction that Lisp facilitates with a kernel-userland split and processes, respectively.
7:02:54
moon-child
(It's probably worth noting that lisp vs unix is a flamewar that goes back decades, and that if I defend unix I'm mostly playing devil's advocate)
7:03:31
moon-child
zacts: so, not 'just' data structure; *more* data structure, a superset of those exposed by hierarchical FS
7:03:51
no-defun-allowed
Data isn't real, but objects are. For the purpose of avoiding another flamewar, that is a joke, but I'm otherwise dead serious with that statement.
7:03:52
zacts
moon-child: I'm not trying to argue lisp vs unix, but I'm just trying to understand this.
7:05:13
moon-child
no-defun-allowed: data is not well-defined in a vacuum, but can be real under some interpretation. (I guess maybe that's what you mean by object?)
7:07:13
no-defun-allowed
Yes, I mean exactly that. If you know how to interpret it, then you've cut down on the difficulty of {backwards, forwards, cross} -compatibility quite a bit. And I wish some of the people who write up articles translating bare data structures would find that out; but they probably wouldn't have much of a business if they did.
7:08:45
no-defun-allowed
The problem is then interpreting how those operations correspond to each other, which is also hard, but in my opinion more manageable.
7:12:44
zacts
moon-child: lisp sounds like a more natural medium for learning some of these concepts than C I'm guessing? but good to know.
7:14:20
no-defun-allowed
Oh, also b. makes for very stupid "experts" sometimes. Like an article I read where the author thought that Unix was the first operating system written in a high level language, and that Java is the only language where objects aren't represented as hash tables. But I don't think I can really pin that on Unix.
7:18:58
beach
no-defun-allowed: Yes, the book by Tanenbaum and Bos mentions that, and also that they consider it impossible to use a language with automatic memory management to write an OS.
7:20:00
no-defun-allowed
beach: Oh dear. I was referring to <https://matklad.github.io/2020/09/13/your-language-sucks.html>, which if I may paraphrase the title, "sucks and doesn't matter". But they probably fall for the same stuff at the end of the day.
7:23:59
zacts
beach: could sicl or closos make use of something like the netbsd rump anykernel to run on existing hw?
7:24:52
no-defun-allowed
(For reference for the comment on Java, the paper introducing "maps" in a Self implementation by Ungar, Chambers and Lee was published in 1991, as well as The Art of the Metaobject Protocol, which of course has storage vectors.)
7:26:01
beach
zacts: I don't see any reason for that. The "bare metal" aspect is fairly simple to realize, and not terribly interesting. The interesting part is the interface between an application and the system, and between applications.
7:26:42
beach
zacts: And SICL bootstrapping is just going to generate an executable, for Linux for now, since that's all we have.
7:31:01
zacts
so the "bare metal" aspect would be similar to how adding a new architecture to llvm is just an implementation detail, and it's not the overall system.
7:34:01
zacts
my point being, that porting sicl to a particular platform or whatever, would just be a particular implementation detail. it's not what makes the system interesting in itself.
7:37:50
zacts
anyway, lots to learn. I'm going to pick up this practical common lisp text for now I think.
8:00:13
adlai
srandon111: loke[m] forgot Clozure CL, an implementation that is quite portable, and has a compiler that runs quickly and produces reasonably fast code
8:01:01
adlai
ACTION usually recommends CCL for beginners because the compiler is fast enough that, for interactive programming at the repl, there is pretty much no noticeable compilation delay
8:18:24
adlai
it is amazing how an unexpected escalation of formality can be a wet blanket to one's hubris, although that is off-topic.
8:20:42
adlai
zacts: allow me to add an anti-recommedation for Godel, Escher, Bach, unless you are also a fan of classical music, douglas hofstatder, or even both
8:21:44
adlai
ACTION is a fan of Hafstadter's works -- that is how he first read about lisp! -- although there are excerpts from the book that give you an idea of the whole thing while leaving you precious hours free for, I dunno, reading CLHS?
8:22:23
Lycurgus
dumbass video games: lack of sophistication, human conversational agent, the opposite of that
8:23:26
adlai
apparently that book is considered a "cult book", similar to cult movies, where people tap out early if they are not hooked; which is a shame, since it is written as a book that expects the reader to read the entire thing, as opposed to e.g. a standards document.
8:26:47
ck_
his book of essays (Metamagical Themas) is more suited if you don't want a cover-to-cover experience. There's also more usage of lisp in it.
8:27:13
adlai
ACTION had just taken an entire semester of java, before reading Metamagical Themas over the summer and encountering lisp. life could have taken a severely different turn!
8:27:27
ck_
Oh look, it's on the Internet Archive: https://archive.org/details/MetamagicalThemas . I should donate extra to them this year.
8:27:44
flip214
I quite liked GEB... it's on my technical top-10 list, along with "Visual Display of Quantitative Information"
8:28:52
flip214
ck_: " The item is not available due to issues with the item's content. " when trying to download an ebook?
8:29:52
adlai
no-defun-allowed: that's understandable; one of the few long conversations I had irl about cl ended with the other person (also a programmer) concluding that learning such a powerful language is a bad life decision, because then most other encounters with human technology will consist of disappointment
8:30:32
no-defun-allowed
Well, sure, that describes it. And that you also may have standards for the presentation of the course that also are not met.
8:30:45
adlai
although, he seemed to be at the end of his active programming career, and thus able to make such a statement.
8:33:43
flip214
OTOH, especially in IT there's _so_much_ disappointment when dealing with other people's stuff... my own stuff I expect to break (or at least can guess when), but commercial software should behave better
8:33:51
ck_
I've watched a few older talks this year, one Keynote by Guy Steele (From 2013 I believe?) where he implores "can we please get tail calls in JDK 9?"
8:36:28
Lycurgus
https://github.com/fargonauts there is a lisp version but the main deal is pythong apparently
8:38:11
moon-child
ck_: I have found it an endless source of hilarity that guy sat on the design comittees for common lisp, scheme, java, and c
8:38:19
Lycurgus
the reason people burn out and have negative attitudes about software development (in comparison with other professionals fields)
8:38:42
adlai
beach: I think it is a common attitude among those who are seeking careers working as fungible programmers in a variety of enterprises, as opposed to those for whom 'career as programmer' could plausibly include a decade working alone, another decade doing academic research, etc
8:38:44
no-defun-allowed
adlai: Then make them not disappointing. How to do that is up to you, but you are likely as capable as as your colleagues to make the field better, and you may have a better idea of what would be better.
8:40:05
Lycurgus
which mode of society/production, determines the greater and lesser snake pits of industry/academe
8:41:46
adlai
no-defun-allowed: here's one impossible... I wish all the hi-tech managers got together and decided on programming practices that kept their employees as fungible cogs, without limiting the choice of programming language
8:41:47
no-defun-allowed
I won't say what exactly, but "just" invalidate the assumptions that your statement has.
8:46:14
adlai
in Earth, we've had a century of capitalism, communism, and hegelism, and it has given us Common Lisp, Racket, and most importantly, Stalin; whereas in the other planets, they've had five billion years of peace love and no complaints, and what do they have to show for themselves? not even a cuckoo clock, just a bunch of epicycles.
8:50:27
phoe
"in Earth, we've had a century of capitalism, communism, and hegelism, and it has given us Common Lisp, Racket, and most importantly, Stalin"
8:51:24
adlai
'stalin' is a scheme ~compiler~, not interpreter, supposedly one that reached new heights of whole-program optimization.
8:55:34
adlai
back to more productive topics, what is the best overview of the new package naming conventions?
8:56:01
adlai
ACTION keeps seeing references to [a] package-local nickname library[ies], and never bothered studying this
8:58:23
adlai
ACTION reads phoe's article https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3
9:00:22
adlai
... although there is also local-package-aliases, and phoe's article does not appear to mention this library: https://quickref.common-lisp.net/local-package-aliases.html