freenode/#lisp - IRC Chatlog
Search
18:10:58
_death
the same goes to all customizable software, including programming language implementations and their specifications btw
18:13:31
amerlyq
"personal customizable software" -- you fork whatever version you like and freeze it / customize yourself. If project looses "pulse of life" maintained even through adding maddening/unrelated changes, it stales. Changes attract new people despite losing some people -- you simply must not lose faster than you attract. Contradictory by itself, but people love "living" soft, not stale one. Therefore
18:13:31
pjb
madrik: very simple. The kernel forks the process ID 1 (hardwired or parameter to the kernel in the boot) /bin/init. The /bin/init program initialize some stuff, and runs the script /etc/rc (which runs the script /etc/rc.local), then it reaps orphaned children.
18:13:42
_death
stability is frequently underrated, but here in Lisp-land we have a more balanced view.. shame that some projects are affected by new blood bringing alien values
18:14:49
pjb
madrik: sysv added already some complications with /etc/init.d/rc.* and interdependent service rc files with boot levels…
18:15:55
pjb
madrik: you could install yourself a LFS for the fun. It'd take a rainy Sunday. You can do that in a VM…
18:16:24
_death
amerlyq: freezing is an extreme that is usually unnecessary in Lisp-land.. if someone wants to keep injecting software with changes, usually the way is to fork it (see slime vs. sly).. in this case, the stability profile of a project changed
18:16:38
pjb
madrik: also, have a look at http://informatimago.com/linux/emacs-on-user-mode-linux.html
18:16:40
amerlyq
_death: But... how your project will go on living, if you lose personal interest in maintaining it? Nobody will resurrect your code staled for 10+ years for them to continue -- they will better write their own, worse alternative. But if it still struggled through somebody's efforts in whatever form -- they would choose it and continue your project.
18:17:59
_death
amerlyq: not sure what you're getting at.. people "resurrect" Lisp code all the time..
18:18:40
pjb
Indeed. A big difficulty when you want to use old code, is to locate old compilers and old libraries to compile it…
18:19:41
amerlyq
People often has misconception of "obsolete code". Psychology, nothing more. Unrelated to tools and efforts.
18:21:00
amerlyq
By the way, on the lane of complexity: Is there any powerful language even more simple than Lisp, worth learning? I find myself dizzy from complexities of C++/Rust/Haskell/Erlang/J/Perl/Zsh and even Python and return to Lisp again and again despite innumerable years spent on them. Lisp is simple and nice, but I constantly miss... something intangible. Powerful static typesystem? Transparent debugging
18:21:02
amerlyq
facilities? System level integration? All languages are only disfigured compromises, even Lisp :(
18:22:49
amerlyq
yep, I catch myself thinking they aren't bad to try after all. But... is it worth it nowadays? At least for pet-projects? That's the question.
18:23:37
pjb
amerlyq: it's interesting to learn them, because when you're a lisp programmer, you can apply different programming paradygms in the same lisp program.
18:26:34
hsaziz
Also which debugger is easiest, and most intuitive to use? I realize they are usually attached to their individual compiler/REPL.
18:29:26
amerlyq
pjb: Mmm, it's more about "ultimate simplicity" or "intuitive reasoning", and not "even more paradigms to add to this boiling hell". I can reason for hours about monads and then restructure whole codebase in the name of pursuing intangible but important benefits, but... it isn't worth it for anybody reading my code -- because all these subtleties made it even harder to understand.
18:29:56
amerlyq
and then nobody can maintain/evolve codebase in the same way, I originally pursued.
19:39:55
pjb
amerlyq: an important idea of lisp programming is that you write your code in terms of the solution. Basically, you just write a sexp that "express" the solution in terms of the domain. Then, you implement the data types and operators needed to make this sexp run in lisp.
19:40:45
pjb
amerlyq: If a solution is a one-liner expression of monad, then just do that! If it's a one-liner APL, do it. If it's a one-liner prolog, do it. (or just a few tens of lines).
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