freenode/#lisp - IRC Chatlog
Search
20:04:13
amerlyq
pjb: you have a point. A strong point for CS-educated workforce, which knows subtleties why from 1000 funcs/vars you must prefer this hundred over that hundred, or optimize cache lines for x86_64 arch performance, or etc. But then you deal with... not so educated or highly opinionated deluded people. And they are looking into the same codebase but don't see what you see. They see smth different, and
20:08:30
amerlyq
By any means I'm not justifying even more verbose language to declare everything explicitly. And maybe Lisp is the closest and cleanest thing we can get to express nested abstractions and their intuitive transition on code evolution. But vaguely it still feels... not right there.
20:16:02
amerlyq
Maybe... the main problem we don't have an "single abstract language to describe abstractions" like Math does, so everybody could speak the same language and naturally "learn" new things on the foundations of previous ones. Instead we have memorized patterns, idioms, cool hacks, dirty hacks... We call some bunch of lines as "AAA idiom" and we can spot it in code (but others cannot). There is no way
20:16:04
amerlyq
to teach the language itself to have it (Lisp has the least problems here, actually). And therefore everybody is forced to learn multiple languages at the same time -- Lisp, Math, CS, "common sense", etc. resulting in fragmented and incompatible comprehension.
20:17:24
p_l
I'd argue that Math doesn't have single abstract language either, but there's enough of commonly accepted one that people can get through to the point of defining new ones
20:19:00
Odin-
I don't think lambda calculus makes much sense to mathematicians who haven't encountered it before, for instance.
20:21:13
amerlyq
Oh, in continuation to the topic of handling the complexity: how your cognitive load fares on large Lisp systems over >100 classes and >1000 functions?
20:24:06
amerlyq
What I mean is: it's easy to prove each small function is correct in Haskell by using typesystem, and it's easy to prove it's correct by playing with it in Lisp interactively. But to prove the system as whole is still doing what you expect (vaguely fantasize) it to do -- how hard it actually is?
20:26:03
amerlyq
I often observe myself being slightly lost and only 99% sure I know how my 50+ functions in module actually interact. With Haskell I top it by 99.9% sureness -- depending on correct (and verbose) types. But this remaining 1% is unnerving.
20:26:15
pjb
amerlyq: wrong. It's not easy to prove a function is correct in Haskell. What the type system is an easy way to prove it's NOT correct in some specific way.
20:26:31
pjb
amerlyq: it cannot prove it's NOT correct in important other ways, and it definitely cannot prove it's correct.
20:28:46
amerlyq
at least it helped immeasurably to spot "accidentally broken" things on scale of practicality.
20:29:16
pjb
amerlyq: 100 classes, 1000 functions is nothing. Android was 3500+ classes, * 1000+ methods ten years ago. Imagine the size of it now!
20:30:04
pjb
amerlyq: have a look at ACL2 (theorem prove written in CL and embedded in (a subset of) CL.
20:30:30
pjb
amerlyq: you can write algorithms and ACL2, and see how it feels to use a more abstract programming system.
20:33:53
pjb
amerlyq: you could implement one such AI for Lisp programs, and fear not anymore to break anything which you forgot…
20:34:06
amerlyq
I would liked to see how it will debug concurrently smashed stack under Java/JNI coredump
20:38:41
amerlyq
Question is more about "human cognitive load" and how everybody cope with it. When I write several large functions, I can "control" how these functions interact between themselves, but all "chaos" is hidden inside these functions and break their contracts occasionally. When I write large amount of very small functions -- each one is crystal clear, but now "chaos" is hidden in-between all these
20:38:43
amerlyq
functions, it's ephemeral and even harder to debug when something is wrong. If you use optimal size of each function and their amount... you simply convert complexity to maintaining fragile stability.
20:41:44
amerlyq
Maybe systems in the time of InterLisp were less complex, less concurrent and less multi-functional~ ? :)
20:43:19
pjb
May be AI had much less resources in the time of InterLisp, and nowadays you could tap the resources of Amazon, Google, Internet and the cloud to make something way more intelligent!
20:43:45
pjb
amerlyq: there's also code generation AI, so you don't even have to write the code yourself! Just describe your domain.
20:51:31
amerlyq
you meant "write even more complex and uncontrollable mess" :) I somehow relate to V.Vinge "A Deepness in the Sky" vision of future of "broken layers over broken layers of software". Ok, lets wait until AI will consolidate everything and salvage everybody... in some unacceptable ways :)
20:54:30
amerlyq
Yep, it's exactly what I meant by "consolidate everything". And as humans are the main factor for creating more and more chaos inside resulting system... there is the obvious way to fix it for AI.
21:00:24
amerlyq
Is there any small but nice example of extensive use of typesystem in Lisp? Most libs I see are fit into two extremities -- very weak typesystem usage, or very complex by itself to see through.
4:28:20
madrik
It seems to me that Racket and the group behind it may be somewhat what amerlyq is looking for
4:34:31
aeth
It's hard to find a good example of type system usage because the syntax is a bit awkward in vanilla Lisp, so pretty much anyone who heavily relies on types will use a macro, probably their own.
4:36:08
aeth
And e.g. (unsigned-byte 32) is pretty verbose, even though it's the most general purpose way to do it, so if you have a bunch of integer sizes in your code, you're probably using shorthand names (and the only conventional one is octet for ub 8)
5:06:05
pjb
aeth: the CL type system is a good example of a type system: (+ 1 "42") #| ERROR: The value "42" is not of the expected type number. |#
5:28:24
aeth
pjb: CL is one of the most typed dynamically typed languages because (1) it's not a coercive language like you said and (2) it's not particularly duck typed either