freenode/#lisp - IRC Chatlog
Search
11:48:38
p_l
madrik: some systems can be run with just evaluator, but Common Lisp requires "minimal compilation" (expansion of macros etc.)
11:49:11
p_l
technically some implementations skirt this literally but preserve the required semantics, like LW which uses evaluator when tracing macros
13:39:41
beach
no-defun-allowed: The default would be to create a method like (defmethod some-reader ((x some-class)) (slot-value x 'the-slot-name)), but there are ways of making it faster. When the effective method is created, it is often possible to use standard-instance-access instead, which is much faster.
17:03:52
hsaziz
After removing a distro installed version of SLIME, my MELPA (stable) installed SLIME version still insists on accessing the old system wide swank-loader.lisp.
17:14:29
pjb
MacLISP forked in 1966 from LISP 1.5. So it probably included macro from the start. Perhaps it was the first one to have macros exactly like our defmacro. I've not read the AIM 57 yet, but it looks like they hacked macros over FEXPRs…
17:18:42
_death
don't use melpa for slime.. quicklisp-slime-helper is acceptable, or clone the repo and config yourself
17:20:20
madrik
_death: Should we not use either MELPA or the distribution's repositories in any circumstance?
17:22:57
phoe
for slime use either (ql:quickload :quicklisp-slime-helper) or the one from melpa (e.g. bundled in spacemacs), and don't mix the two
17:25:51
_death
madrik: melpa is ok for emacs packages (although personally I hacked things so that I can easily diff changes and roll back if needed) but when it comes to CL, quicklisp or DIY package management is the way
17:26:29
hsaziz
I am being daft! I am typing this on Ubuntu 1910 and therefore had this in mind. I am actually having this issue on an ancient machine running Trisquel 8, which is also Ubuntu based. I think 16.04.
17:27:57
madrik
_death: I am aware that most languages today opt for and encourage the use of their own package management systems. But then, why do the maintainers of distributions spend so much time and effort integrating things?
17:29:02
_death
madrik: you'll have to ask them why.. maybe they just think "I'm a dist maintainer, I need to do my job"
17:30:02
_death
madrik: whereas a language user cares more about his particular niche working without pain
17:34:39
_death
madrik: maybe the difference is between "users" and "developers".. a dist maintainer sees "users" and tune to their perceived interests, while a "developers" are a fickle bunch that don't really form a homogeneous group of users, each subgroup can have different forces shaping its interests and values
17:35:27
madrik
I tend toward the distribution's view because when I obtain my software from my (distribution) vendor, I almost always get a managed, stress-free, well-put-together environment. The upgrades and security updates are taken care of, and the different components are made to work with each other.
17:36:44
amerlyq
madrik: maintainer thing is all about "fit all things together in global namespace" -- to actually reduce complexity and unavoidable context fragmentation
17:36:56
madrik
The objection to the distribution's view is that old software may have unfixed bugs dealt with in the newer versions.
17:37:28
_death
madrik: sure, I update some software via distribution, but when it comes to CL my method of "updating" is a git-fetch-all script and skimming new commits, putting more scrutiny into libraries I actually care about
17:39:24
madrik
In managing things yourself, you get control, but you also must exercise more responsibility. Whereas you can delegate a sizeable chunk of administration to the distribution on the other view.
17:39:26
amerlyq
I think the main point is splitting steps of "I'm ready to update all my software and deps" .vs. "I'm ready to do dev work". It's easy with distributors soft, but somewhat tiresome and opaque with quicklisp
17:40:39
madrik
amerlyq: Just to tee off, notice that the split in Python -- 2 v 3 -- was already painful. And then they have two different versions of each piece software.
17:42:19
jackdaniel
as name indicates, that are two differen languages -- that does tell how instable is the ecosystem ;)
17:42:22
amerlyq
it's only the question of pushing the responsibility to update all old soft, which will break on update. Either way somebody must do it
17:45:30
amerlyq
When you developing one project and use dynamic package manager -- you are somewhat ~ready~ to fix everything which breaks on each update in any deps API. When you periodically develop many projects... you are not so ~ready~, and do it rarely, after gathering great willpower.
17:45:42
_death
as a developer you are responsible for your dependencies and working environment.. there are conflicts that are resolved by taking more responsibility away from the distro
17:46:03
madrik
In connection with the discussion about SETQ v SETF the other day, I noted that symbol macros were mentioned. Where would they be used? What problem do they solve?
17:47:20
_death
madrik: I believe originally they were introduced to make WITH-SLOTS (and WITH-ACCESSORS, I guess) possible
17:47:41
hsaziz
makrk: THANK YOU!!! That worked! I actually wasted 2 1/2 hours yesterday wrestling with this.
17:48:19
madrik
_death: The main argument I read is that now each developer has to keep in step with security updates. This may seem undesirable, globally taken.
17:49:03
madrik
hsaziz: Glad to help. Just to cement this, read about removing and purging in apt/apt-get/aptitude/.
17:49:33
_death
madrik: either way you have to keep up with those.. you are responsible for your dependencies.. bad programmers think that by using a third party's update mechanism they are no longer responsible
17:50:54
pjb
"Distributions" of which the "package manager" is an essential component, are canned administration. It's the way we've found to let end-users user computer systems that need to be sys-administred (this includes the mere installation of an application).
17:51:49
madrik
jackdaniel: I imagine a lot of consumer-grade firmware in routers/appliance-type devices is left to fend for itself after release.
17:52:33
pjb
50 years ago, this administration was performed by people near the users (the *local* sysadmin). But 40 years ago, when Linux started and distributions appeared, this administration became (pre-)performed by distribution makers, for remote users/customers.
17:53:13
_death
personally I disable all auto-update functionality.. it would not work for my grandmother, but it works for me. auto-updates are also prone to abuse, breakage, and can be a source of uncertainty
17:53:42
pjb
My mother called me yesterday because her iPhone was dead. It was actually auto-updating…
17:55:04
amerlyq
_death: Actually, I find myself more and more disillusioned and tired from configuring system for myself as time passes. It was fun very-very long ago, and now it's simply painful. I glad somebody can do it for me so I could focus on problem at hand, despite shedding bloody tears from all the distro bugs which I fixed myself in the past.
17:55:15
_death
as a developer you want to maintain a controlled environment and not have changes suddenly appearing without your own knowledge
17:56:25
madrik
I do wish that more people understood computers, if only to better do their own work, but I see that a lot of people just are not technically inclined.
17:58:36
amerlyq
Yep, "Security of your device was enhanced". You got to download 1GB of Samsung bloatware updates.
17:59:09
_death
on mobile devices, auto-updates have been used to remove features, add malware (ads, tracking, etc.), and generally further exploit an established user base
18:00:06
_death
but even simple look & feel changes make auto-update a bad idea.. this is by the way why I no longer update my stumpwm
18:00:29
_death
angry commit message https://github.com/death/stumpwm/commit/f18f826890eecc1154c541d2de25bdd27bedbe4c
18:00:39
amerlyq
like broken google speech synthesis on Android9 when your screen is off despite whitelisting the app
18:01:10
pjb
_death: amerlyq: yes, but the contradiction, is that you also want up-to-date software, with bug, and security bugs removed as soon as possible. Hence the need for perpertual sysadmin, hence the need for canned sysadmin. Hence macOS/iOS….
18:01:50
pjb
The only question is whether you accept a locked system, or if you want to be able to do your own sysadmin on the parts that matter to you.
18:02:11
madrik
And here I was under the belief that everyone deployed pi-hole or equivalent, ran Firefox on desktop and mobile with an artillery of extensions like NoScript and uMatrix, used DuckDuckGo, etc.
18:03:21
_death
amerlyq: it used to be.. then some other dudes started developing & using it.. but recently one of the new dudes started making weird changes and the other dudes merged his changes..
18:05:01
amerlyq
madrik: the more I got tired from complexity of literally broken world, the more I think to go the https://suckless.org way and use bare kernel plus 10 apps ~2000+ lines compiled from sources, which I know absolutely. Simply don't accept madness of external world into your own small isolated paradise for retired geeks.
18:06:30
pjb
10 apps you're counting large. I use basically 2, a web browser and emacs. Ok, add 2 or 3 more apps, and the rest is basic unix CLI stuff I compile myself.
18:07:15
pjb
Well, not Genera. Genera I guess was more like early PC, where the sysadmin was performed by sophisticated users.
18:07:28
amerlyq
It's a pitiful, but the only way for FOSS to exist. Evolve or die. ZeroMQ/P.Hintjens books and nanomsg postmortem are nice read on topic.
18:08:19
pjb
amerlyq: the assumption of FOSS is that users are developers that will inspect, modify and compile themselves their program from sources. Or hire a developer to do it for them.
18:08:28
_death
amerlyq: this is wrong.. stumpwm is meant to be customizable software.. this means there's no need to change the default look & feel for everyone, every time you feel like something's wrong
18:09:25
pjb
(even if RedHat CEO became IBM CEO, but that's more the fault of IBM than anything else).
18:09:45
_death
amerlyq: those recent changes should belong in someone's ~/.stumpwmrc or maybe his own fork, but they should not belong to upstream
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.