freenode/#lisp - IRC Chatlog
Search
16:49:02
Ukari
is cl-cont open source? i meet a wired warning which seems to tell that a argument's type is different from declared in cl-cont::lookup
16:49:26
Ukari
the message: "Derived type of CL-CONT::LOOKUP is (VALUES CONS &OPTIONAL), conflicting with its asserted type (OR FUNCTION SYMBOL)"
17:50:33
foojin
Maybe it's about "having something to show instead of simply complaining", but in the end I find the submission/review process itself too difficult and apply the fix locally.
17:59:07
foojin
Sometimes I just think I don't understand the codebase well enough to consider my solutions anything but hacks.
18:02:33
foojin
THe giflib one is most likely fixed by now, because it's about long filenames messing with an uninitialized structure field, which breaks the whole thing randomly.
18:08:17
foojin
The thing is, I'm not proud of what I do. Seeing how everything is so brittle and poorly understood even by its creators makes it hard to be proud of my small contributions.
18:08:20
pjb
foojin: it's not the little student card a university temporarily gives you that makes you a student.
18:17:43
foojin
pjb: Yes, that way I could hopefully understand the issue from a mathematical perspective.
18:17:46
foojin
I'm also interested in learning type theory to gain some insight into what I (for a long time) thought is true: that all of mathematics has a computational content to it.
18:21:19
foojin
Come to think of it, mathematics has already reached a level of complexity which can only be tackled by clever abstraction, so people _have to_ be clever about adding more to it.
18:24:27
foojin
But it doesn't help to harness the power of computers, to save oneself from mediocrity of not being able to intervene in, say, the process of interpreting someone's minified Javascript.
18:29:41
foojin
So I don't really know what to do in such a situation. BTW sorry for being off-topic and (possibly) being a nuisance.
18:33:12
foojin
The point is, even after learning enough to be able to fix broken stuff around me, it still feels like I'm not flying above the surface, but merely crawling out of an underground cave. It takes time just to stay afloat.
18:35:48
foojin
shka_: Yes, for a long time I thought that JS is actually a decent language. Not anymore, not after reading about its coercion rules and having stuff break silently because of _syntax errors_.
18:55:15
foojin
fe[nl]ix: I'm going to install Gentoo for that very reason, but the last time I tried to switch I couldn't find a way to make emerge print dependencies in a sane way.
19:01:45
foojin
Digging around in ebuilds just to understand why it installs X along with Y isn't fun. I think a package manager should do it for me, so I'll try it for real when I get around to patching it.
19:04:52
foojin
By the way, what do you guys think about Guix? It looks like someone finally tries to make a "uniform" (configuration language-wise) distro for people who aren't afraid of programming.
19:14:12
foojin
fe[nl]ix: The worst thing is that it's most likely true. "A distro for people with an \"optimal\" amount of free time to make it work like they want" looks like an unattainable ideal.
19:23:19
foojin
And that brings me to the main question: how to balance mediocrity (lack of control) and theoretical enlightment with perfect tuning and doing boring stuff like reading someone's C code / autoconf output / minified JS?
19:59:35
foojin
fe[nl]ix: Seems like the way to go. The question of having the right to do so is best asked somewhere else anyways.
19:59:38
foojin
Sorry for exploding all over the place with something completely unrelated to the topic.
20:01:23
foojin
If I didn't make everyone sick already, I have a programming language-related question that I've been pondering for a while.
21:17:00
foojin
What features can make programs written in a (hopefully not hypothetical) language easier to extend, given that
21:17:16
foojin
(3) the extensions should take advantage of further upstream improvements by augmenting existing things, not reimplementing them.
21:18:29
foojin
According to the history of Emacs, Stallman admitted to having used dynamic scoping for this very reason.
21:21:49
TMA
foojin: treat every interaction between parts of a system as an extension point; do not use the extension points internally
21:22:08
foojin
Lexical scoping is immensely useful, but anyone, who "fixed" a chunk of closure-heavy JS with a so-called "userscript", would surely admit to having had a hard time working around them.
21:23:35
phoe
CLOS itself is insanely extensible with its BEFORE/AROUND/AFTER methods and ability to define subclasses and new methods on same generics
21:24:29
TMA
foojin: a concrete representation of my advice is: use CLOS, but do not use :before, :around or :after methods yourself to let them be available as the extension points
21:33:06
foojin
phoe, TMA: I've heard a lot about CLOS and MOP, they're the main reasons (besides Scheme's lack of libraries) I once again picked up "On Lisp". But what about a more "fundamental" data type, functions?
21:33:59
foojin
What do you think about an operator that creates a function F as if it was defined where another function G (given as a value) is (yes, it will impede compilation and possibly hold onto objects that no one will ever use).
21:35:48
foojin
That could solve the problem of people stashing too much stuff inside closures, making their functions "unwrappable".
21:39:17
foojin
Bike: That is, in the same lexical context, to make it possible to replicate any closure.
21:40:06
Bike
so it would require having the point at which any function is defined have its entire lexical environment saved along with the function?
21:41:38
foojin
Nothing. I do think that CLOS is a more proncipled and general solution, so the last question isn't related to that.
21:41:48
phoe
instead of saving all the state in a lexical closure, save that state in a CLOS instance and use methods instead of functions
21:42:16
phoe
the "fundamental" data type that you describe will give you more PITA than a CLOS-oriented approach.