libera/#commonlisp - IRC Chatlog
Search
9:52:17
unixlisp
Alfr: "3.2.2.3 also says that, apart form the listed exceptions the new definition takes precedence" That is "about minimize the observable differences between compiled and interpreted programs".
10:00:19
beach
Alfr: Frequently unixlisp seems to make statements without any context, and sometimes without any stated purpose. I think you need to get used to it.
10:03:27
Alfr
unixlisp, but what are you trying to say with those quotes? Or what's the problem/question?
10:04:24
beach
I think unixlisp now realizes that the page that was cited before as being about redefining functions, in fact is not. But I already said that.
10:05:44
Alfr
beach, I cited that, and I still think it's relevant. As it defines what conforming programs can expect, thus conforming implementations must arrange for.
10:07:55
empwilli
EdLangley[m]: hm, given that GCs really are notorious sources for performance bottlenecs (at least my understanding, I mostly don't do GC programming, so please correct me): Moving around members in memory would really add a large amount of overheads
10:11:03
Alfr
beach, (okay for the other case where it simply happens during runtime, DEFUN's documentation already specifies the behavior as replacing.)
10:13:59
beach
empwilli: So if you are avoiding GC for performance reasons, you may be doing the wrong thing.
10:14:32
empwilli
no worries there :) I'm avoiding it just for the convenience of the languages I feel comfortable in
10:15:22
empwilli
I'm currently working on adding common lisp to my repertoire, but I'm far from fluent in it
10:24:56
beach
empwilli: It is too bad, though, that people seem to think that automatic memory management is a "notorious source for performance bottlenecks". They are then doomed to program in a way that makes it extremely hard to get both performance and modularity in their code.
10:27:51
empwilli
this sounds as if there were design patterns to program in favour of the GC. Is this the case? Can you point me to some resources?
10:30:17
beach
I had no design pattern in mind. I am just making a general observation that "liveness is a global property" [from Paul Wilson], so not a "modular" property. If your program is modular, you either need to copy all your objects, or use reference counters if you don't have automatic memory management.
10:30:39
seragold[m]
I think it was David Ungar back in early nights who showed that no sort of reference counting and its variants overall performed as well as state of art GC then. So why would you want such in your way of whatever the most efficient and elegant patterns are it is possible to come up with in a language that gives you all the power?
11:06:22
unixlisp
beach: early about (setf (symbol-function 'foo) newdef), you said "It could be defined behavior only if the function is currently undefined". but in clhs about symbol-function entry, "setf may be used with symbol-function to replace a global function definition"
11:44:18
beach
unixlisp: Yes, notice the word "could" in order to explain to masinter that the existence of that operator doesn't necessarily mean that the behavior is always defined. But as it turn out, it is.
11:50:02
loke[m]
beach: Take your average C programmer: malloc and free "feels" free in terms of performance impact. So when someone suggests that a GC will run automatically and search for all the memory to be released, that feels "obviously" slower, since now it has to do stuff when before it didn't have to.
11:50:59
unixlisp
beach: I noticed the word "could". In clhs defun entry: "defun can be used to ... redefine an already-defined function", that word is "can".
11:51:03
loke[m]
Any argument that malloc/free are actually slow falls of deaf ears since their microbenchmarks all use stack allocation, which indeed is free.
11:54:58
flip214
loke[m]: not in terms of cache misses... alloca()te a few KB and you're out of your L1
11:55:56
loke[m]
flip214: Well sure, but that applies to all allocations, regardless of whether they are heap or stack. Unless I misunderstand your point?
11:57:17
beach
loke[m]: Yeah, but it's disturbing to me that so many decisions in the software industry are based on "gut feeling" rather than research. And I can only imagine the amount of money wasted that way.
11:57:35
flip214
empwilli: one example favoring a GC: https://people.eecs.berkeley.edu/~fateman/papers/cachelisp.pdf
11:58:11
flip214
loke[m]: no, you're understanding me correctly. My point is that stack allocation is not completely free either.
12:01:24
flip214
empwilli: and ELS2018 (https://www.european-lisp-symposium.org/2018/#programme) had "Dynamic Optimizations for SBCL Garbage Collection" which would switch a load balancer around before doing GC, so the equivalent to free() would be free here
12:01:51
beach
unixlisp: Do I really have to spell this out to you? I mean to say "masinter, you are right that there is an operator (setf symbol-function), but you say that its existence is proof that redefining functions is defined behavior. However, it COULD very well be the case [but it isn't] that this operator is defined only when the symbol does not already have a function defined, in which case definition is OK, but REdefinition is not
12:01:56
beach
unixlisp: ... So the existence itself does not guarantee that redefining a function is defined behavior. However, redefining a function IS defined behavior, as the Common Lisp HyperSpec specifies".
12:05:48
unixlisp
beach: oh. "redefining a function IS defined behavior", acording to "defun can be used to ... redefine an already-defined function"?
16:27:47
phoe
In case of (loop for sym being the symbols of :bar collect sym) - is it possible that the list will contain duplicates?
16:33:28
Bike
phoe: do-symbols can hit symbols multiple times if they're inherited from multiple pa- right.
16:34:09
specbot
The for-as-package subclause: http://www.lispworks.com/reference/HyperSpec/Body/06_abag.htm
16:34:17
Bike
well, according to the description in 6.1.2.1.7, "the symbols" means it will iterate over symbols accessible in the package
16:49:42
mfiano
It has things like positive-fixnum, non-negative-fixnum, etc. Seems like it should have that
16:53:07
phoe
but only during compilation! and it usually happens in between tons of other packages too, so it's possible to miss it
16:53:29
EdLangley[m]
Also, if you do alex:dim-in-bounds<TAB> for complete, like I do, SLIME will put in the -2
16:55:48
dim
BTW has anyone tried shipping a software built with ECL: a C-core and some APIs exposed to a Lisp part of the application? -- I am thinking about doing that for pgloader, allowing me to use the existing C drivers for database sources etc
16:57:32
jackdaniel
dim: I've shipped a C application linked against ECL that allowed connecting via swank medling with a running C application (i.e recompiling functions), the api was available to the lisp world to test things out
16:59:25
dim
jackdaniel: sounds a good starting point ; in the case of pgloader I would do the basic boring stuff in C (copy data around) and the interesting bits in Lisp (merge catalogs, parse commands, all the advanced / user-friendly stuff) ; would you have an opinion?
17:00:07
dim
I mean I would like to both simplify the build process and also have an eye to better perfs for the inner loops when written with the official database drivers in C
17:00:46
jackdaniel
dim: core written in C and linked against ECL sounds like a good fit for that, yes
17:01:01
dim
more important than perfs is also full protocol support even with new versions, including auth and encryption
17:01:23
jackdaniel
you could also write your own lisp libraries and compile them to shared objects (you may inline C code in Lisp functions too)
17:01:55
dim
it's either that or porting to Clojure to benefit from all those JDBC drivers out-there
17:02:15
jackdaniel
the only limitation is that if you want to recompile functions that have inline c code, then a c compiler must be available on the system
17:02:24
dim
maintaining qmynd for MySQL and patching Postmodern for Postgres SCRAM authentication and all those things, I believe it's too hard an ask for just maintaining pgloader
17:03:00
dim
yeah well I would like to ship a copy of pgloader that's all static built in the ideal world
17:03:25
dim
I like the dynamic aspects, but I prefer the “just works” story for end-users that don't even know lisp is involved in pgloader, and when they do, don't understand why
17:03:27
jackdaniel
ecl may be linked in statically, but you need to keep in mind that the license of the implementation is lgpl-2.1+
17:04:08
dim
well I mean I can also build dynamically, my focus is easy-to-build, easy-to-ship, easy-to-use, don't need to know anything about lisp
17:04:23
jackdaniel
sure; the application I've mentioned earlier had ecl mostly for debugging, live patching and such, the end user was not concerned with any programming languages
17:04:36
dim
and to be fair the current pgloader story doesn't provide these when using either SBCL or CCL
17:05:48
dim
I have no problem getting a debian package included in debian and apt.postgresql.org for pg_auto_failover and the latest tool I wrote, pgcopydb, that are written 100% in C...
17:06:36
dim
I have tons of problems with pgloader where I bailed out and the current maintainers each time want to orphan it and find a way to update bits here and there and continue to maintain it but spend hours and hours on the package building and maintenance
17:10:00
etimmons
dim: ECL is probably great for this, but you can also link C code into the SBCL runtime. You can even deliver a fully static executable (I've got some patches floating around for that. I really need to work on getting them upstreamed)
17:11:16
dim
I have heard and keep hearing about that capability each time I bring the topic up, but I never got a clear documentation using maintained APIs to do that in pgloader myself, unfortunately
17:11:50
dim
rewriting the inner core of pgloader in C looks the easiest way around for me nowadays :/
17:18:37
mgl
jackdaniel: In ECL, (let ((*print-pretty* nil)) (princ '(function foo))) prints #'FOO. Is this compliant? Is there a way around this?
17:22:11
etimmons
I actually don't think CFFI's manual is great here. That static linking it talks about is really only for CFFI generated wrappers, not system libraries like OpenSSL
17:23:39
etimmons
I use a homebrewed system to build my static executables. But it's definitely not fit for others to use at the moment
17:25:13
etimmons
The current best (and I believe supported) way is to build SBCL with :sb-linkable-runtime option. Then link your libraries with sbcl.o to make a new runtime that has all your C libs already present
17:31:41
dim
remember that I need something that builds on machine I have never seen and will never see, it needs to be built in debian systems and by users when they want to, most of them using a Docker image of some sorts...
17:31:52
fitzsim
etimmons: with that sbcl.o approach, is it possible to get a REPL on the running binary?
17:32:44
dim
anyway a C application that uses ECL to implement some of the higher form logic (decision making, etc) in Common Lisp sounds a good approach for my delivery needs here
17:33:58
Shinmera
Not really, SBCL has quite specific requirements about the runtime (such as catching a bunch of signals)
17:34:41
etimmons
fitzsim: Shinmera's right. It sounds like you want the relatively recent additions to SBCL for producing a dynamic library
17:36:25
fitzsim
SBCL is "in charge" in the current iteration, but the idea is to create a linkable libsbcl.so so that the C-based runtime can be in charge
18:14:08
seragold[m]
<dim> "remember that I need something..." <- I am confused. If it is run from docker image then the OS environment is already controlled by that image regardless of environment of machine the image in run on, right?
18:15:44
seragold[m]
<jackdaniel> "right, eql5 is a very cool..." <- I don't trust the Qt company folks enough to invest much here. Starting to look at CLOG
18:26:24
seragold[m]
tyson2: too early in my journey to say so far as day job eating too much energy. more to say in about a month.
18:37:23
White_Flame
I had built a few flash & html based GUIs, but not a general library yet. I tend to believe that having a desktop metaphor _inside_ a webpage isn't necessarily the most useful
18:38:04
White_Flame
but having multiple tabs/windows be part of the same lisp application (or server) context is quite important
18:43:09
Shinmera
I'm *also* sad that I've so far been unable to procure any real contributors for Alloy
18:48:55
Shinmera
Ime most elements are positioned in a way that does not require feedback from the text renderer.
18:50:24
dim
seragold[m]: I mean I have seen too many recipes/how-tos with manual fiddling or worse interactive adjustments along the years, and finding the so files for cffi and more generally in common lisp has always been a problem when I had to
18:54:27
seragold[m]
<Shinmera> "I'm sad that Clog is completely..." <- So what makes it so? Might be good information for the fond dreams of many of us.
19:08:28
White_Flame
the other thing is that a browser-based frontend means you automatically have remote access and multi-user
19:09:06
White_Flame
the browsers tend to have nicer looking rendering for plain fonts & layout, and easier "make it look good" options than native UIs
19:09:48
White_Flame
but their legacy-laden languages are kinda clunky and beg for a nice declarative lisp abstraction on top of them
19:10:54
EdLangley[m]
The downside is there’s a whole class of side-channel attacks that are ubiquitous now
19:11:19
EdLangley[m]
Because browser apps have to communicate any persistent data over the network.
19:11:47
EdLangley[m]
https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/
19:16:45
White_Flame
EdLangley[m]: sure, and if somebody is snooping on your local machine, who knows what they can find
19:17:01
White_Flame
but those sorts of leaks in that link seem to be around centralized services where lots of statistics can be gleaned
19:18:31
EdLangley[m]
By observing things like packet size and timings you can essentially decrypt information about a specific user
19:19:20
EdLangley[m]
And I don’t have to think at all about whether the middle boxes can run this sort of attack against me.
19:19:53
White_Flame
and that local app can use browser technologies to offload tons of really nice rendering & interactivity features
19:20:39
White_Flame
and if using SSH tunnels to your own applications elsewhere, someone would have to be severely intimate with what you're doing on both ends to be able to gain anything, assuming you're not pouring multiple links of thnigs over such channels
19:21:21
EdLangley[m]
But, my main issue with non-native toolkits is that it ruins the cohesiveness of my desktop
19:21:48
EdLangley[m]
Cocoa on macOS has all sorts of nice stuff built in that the developers of these apps don’t know and/or care about
19:22:02
White_Flame
there isn't that much cohesiveness anyway. copy/paste/drag is basically just used for text and files across applications for the most part, and browsers support that
19:23:13
seragold[m]
Can I do electron like things with CLOG. I thought I saw that in some post I can't put my finger on. If so it might close some of the browser objections.
19:24:48
seragold[m]
yeah it is heavy but to get something that looks runs the same everywhere I am not sure I have a strong objection.
19:25:37
White_Flame
native widgets change between OS releases, too, so there really isn't a singular goal for a portable system
19:25:46
seragold[m]
I am sad desktop UX has largely been greatly lost to web and mobile UX today compared to a couple of decades ago.
19:26:22
EdLangley[m]
The solution to this is to stop using technologies that increase fragmentation
19:28:04
seragold[m]
even my recent Mac OS desktop looks like candy colored mobile BS to a degree I find offensive
19:28:13
Shinmera
Cohesive LAF is overrated. It's really not important to users, and it's not like it ever really was very cohesive at all. There's always been tons of apps on any platform that break LAF either in small ways by using other icon sets, or in big ways by using completely custom styling.
19:28:25
White_Flame
I, for one, like reusing solutions for complex problems, instead of reimlementing simpler hacks
19:29:26
EdLangley[m]
There are a ton of them in macOS that don’t reliably work in non-cocoa UI toolkits
19:29:45
seragold[m]
along with a whole lot of constraints on kinds of UX you can even consider and constraints based on browser security needs that leak through
19:30:42
EdLangley[m]
Also, the other issue I have with browsers is that the development model prioritizes what the developer wants the app to look like over the user
19:31:18
EdLangley[m]
By having all these advanced layout features, etc. it takes LAF out of the hands of users and the desktop developers
19:38:41
seragold[m]
Used to dream the good dream of "objects" that included how to render them in some generic rendering language that any machine with graphics capabilities would do the right thing with. Instead of the extraction of data from logical objects and separate creation of some rendering stuff in something completely different to talk to quite primitive base web browser tech. SIGH. Cohesiveness of data/code bodies lost. Local to data/code
19:38:41
seragold[m]
body rendering control not possible. Endless ugly hacks and specializations of wasted imho effort to make it sort of work.
19:40:43
White_Flame
of course, that's the opposite of EdLangley[m]'s wish, too, if the rendering is encapsulated in the ojbect instead of controllable by the user, I think
19:41:28
White_Flame
and the OO model of tightly coupling code & data is not very appropriate for managing complexity, IMO
19:49:10
seragold[m]
OS should not own widget sets imho. If you think about WIMP non-multi-touch UI there aren't that terribly many fundamental concepts and visual bits. Make a good base DSL for that (no, HTML + CSS + JS in NOT that). HLL composes UI rendering/interaction using that. HLL language if serializable (like Lisp) is send between servers and clients and indeed P2P. Yes some OS renders the base DSL more prettily than others.
19:52:56
seragold[m]
Mac GUI programming btw contains some of the worst spaghetti coded travesties I have run across.
19:53:31
EdLangley[m]
The OS (or desktop environment) should own the widget set because that way all the applications will use the same widgets
19:53:49
EdLangley[m]
And what you learn about interaction in one app will automatically transfer to the next app.
19:54:59
seragold[m]
And why the heck is it OK for OS to dictate what widgets you can and cannot use? Why is it that this making portable rendering across devices and OSes impossible a good thing? This has been a plague on application development for decades.
19:56:59
EdLangley[m]
Because the user picks the OS or Desktop Environment based on the experience they want
19:57:42
moon-child
seragold[m]: the premise is not that the os dictates what widgets may be used, the premise is that it provides certain widgets. You are not required to use those widgets, and you may mix those widgets with widgets of your own devising
19:58:18
EdLangley[m]
The thing I dislike the most about web apps is that every app developer thinks they can reinvent "dropdown list" or "button"
19:58:58
seragold[m]
but I am a heretic. I think UI/UX is just a face/exposure/manifestation of some computational/world subparts. Hell I think appliacations are just a temporary grouping and interaction paradigm on some subparts that may be parts of very different "applications" as well. So many artificial boundaries that are less porous than I dream of
19:59:42
White_Flame
the base model of the browser doesn't have enough vocabulary of elements, so people have to invent trees etc, and thus end up inventing the base ones, too
19:59:48
seragold[m]
True, CSS makes it trivial to change the style in whole or part on such things.
20:02:34
seragold[m]
nothing against libraries of effective widgets as long as they are not a trap for thinking about and implementing best UI/UX possible or proprietary to one OS.
20:04:41
seragold[m]
Then that seems a fault of the walled garden platforms to some degree and a fault of how we look at these things.
20:11:40
masinter
the browsers have managed to be consistent with the platform and users expectations
20:16:06
jackdaniel
nothing beats good old pen and paper for ui, who cares about computers anyway :)
20:20:45
masinter
the hardware, firmware, driver, OS, (browser), emulator, lisp "terminal table", readtable
20:23:07
jackdaniel
whether this is #ui-opinions or #commonlisp this gets offtopic, please move to #lisp or #lispcafe
20:38:48
Shinmera
etimmons: regarding your blog post, the lack of a proper "community" is distressing to me as well, mostly because I maintain a *lot* of projects, many of which I just do not have the life-force to properly maintain anymore, and so far nobody has wanted to step up either. There's also many big projects that I have been almost wholly unable to find contributors for. Now, granted, these are
20:38:50
Shinmera
certainly very selfish reasons for being distressed, and I understand *why* there is no proper community -- there's few people spread all over the globe, all mostly doing things "for fun" and "in their way" because CL is very malleable. The piles upon piles of testing frameworks is, to me, a parallel to this. There keep being more made, either because people don't see the alternatives because
20:38:52
Shinmera
the ecosystem is too fragmented, or because they just want to do their own thing and don't want to bother contributing. Aside from just increasing the mass of people using CL, I don't know if there is a "fix" for this issue, and doing so brings its own problems that I personally am not very interested in solving. I'm happy, as many are, to just do my own thing for my part. I suppose that also
20:47:57
EdLangley[m]
There’s always this hard question of whether to shave a yak or put up with the hairy yak
20:48:27
EdLangley[m]
I’ve generally been happy to use other people’s libraries that are good enough and contribute back as best I can.
20:51:38
morganw
Would someone be able to link me to the blog post? (sorry to appear and ask mid-conversation)
20:51:39
Shinmera
The testing framework thing is personally stinging me, because I tried to solve the issue by making something that should be malleable enough to easily make it fit whatever personal aesthetic preferences you may have
20:51:51
Shinmera
Unfortunately it seems I was almost entirely unsuccessful in the attempt. OH WELL.
20:53:20
EdLangley[m]
But, it has (or had) some (safety 0) stuff in its public interface that’ll give you a bad time
20:53:41
Shinmera
Jonathan managed to crash my SBCL fully when I ran it for a test one time and I haven't tried it since :v
20:53:53
EdLangley[m]
(If you search the logs circa 2015 in the freenode channel, you’d fine details)
20:53:59
etimmons
Yeah, these are certainly hard issues, probably well above what any single person can tackle
20:55:05
phoe
well, if we ever *hypothetically* wanted to settle for a single test framework used everywhere, we'd piss off like 80% of project owners no matter which one we choose
20:55:06
etimmons
And I've done my share of making new projects instead of trying to modify existing ones as well.
20:55:15
semz
The thing is that since many libraries are not all too complete, it's often much easier to just roll your own instead of first understanding the library and then fixing it up.
20:55:54
phoe
semz: I actually root for jzon since it was designed with correctness from the very start, and it's one of the few libraries which have 100% test coverage for the JSON scenarios from the main test suite
20:56:42
semz
this one has (safety 0), that one doesn't handle errors properly, that one only parses objects and not literals
20:57:14
phoe
well, it's easy to roll your own in Lisp; the only real solution that's left is to make it infeasible to do so
20:57:32
EdLangley[m]
I’m a fan of yason because I’ve used it for years and have more or less figured it out
20:57:57
EdLangley[m]
And I like that it makes some of the “wrong” decisions but lets you adjust its behavior when it matters
20:57:58
Shinmera
I'm a fan of forgetting whichever it was I used last time and then getting confused and frustrated every single time
20:58:04
phoe
and the only way of achieving that that I know is to choose the best™ one(s) and promote it(them) in a somewhat aggressive way
20:58:27
EdLangley[m]
I think turning false into nil, for example, is the right thing to do by default
20:59:15
White_Flame
I decoded json arrays into cl lists, and false->nil is wrong in that scenario :)
21:00:40
_death
so what if there are a zillion libraries to do one thing in different ways.. some may see it as "inefficiency", others may see it as "diversity".. if you want to put effort into a single project, there's nothing stopping you.. the asdf problem is almost the opposite one.. a single implementation, where there should be a single specification and many implementations
21:00:49
phoe
and the worst thing is that [] is true in JS, which is at the same time acceptable, terrifying and off-topic here
21:00:55
EdLangley[m]
In a lot of cases you’re just trying to get the data into lisp and you don’t actually care too much
21:02:08
phoe
_death: that's the opposite problems, yes - in Lisp it's hard to make very hard things (like system loaders) and trivial to make hard things (like JSON parsers)
21:02:10
_death
to me the etimmons was half weird (why drag this issue on and on? stassats already added maintainers who merged the patches) half worrying (the "let's break things" vibe)
21:02:42
phoe
hence people go for the easy and not the hard, and we have ten json libraries and one ASDF (I'm rooting for CPLM)
21:05:26
_death
actually we have more than one asdf.. there's the asdf that's bundled with sbcl and there's the asdf that continues to change.. personally I like the fact of the former one and don't care for the latter one, so my worrying about etimmons's breakage is a bit abstract
21:05:46
semz
my point being that even if you were to replace asdf, you'd end up reimplementing the existing one quite a bit
21:06:00
phoe
the main issue with the current CL world I see is that different people in it want two different things
21:06:42
phoe
and you simply *can't* have both without effort that is impossible to maintain with the few hands that are here
21:06:53
yitzi
I fail to see how reducing the number of JSON or testing libraries would achieve either.
21:06:54
moon-child
the _language_ is not going to progress either way. So as I see it, the people who want stability are not affected by the people who progress
21:07:08
_death
I don't think it's an issue.. that's why "no single community" is a good thing.. everyone join the subcommunity (or not) that cares about the things they care about
21:07:26
EdLangley[m]
Yeah, I like CL because it’s the opposite of the JavaScript world I have to deal with professionally
21:08:00
White_Flame
"the JavaScript world" sounds like an underworld if programming was a fantasy setting
21:08:26
_death
because there aren't many people writing CL, sometimes it can seem lonely.. and survivorship bias results in people who don't mind
21:09:12
Shinmera
_death: What pains me is that I see it as wasted effort, at least if the project is published (if you just do it for yourself, whatever). Esp. for the testing frameworks, there's so many, and many of their differences are miniscule, that I can't help but think it would have been better to just improve an existing one instead.
21:09:14
White_Flame
but there is also the lisp curse side of things where stuff is quite easy to write yourself
21:09:37
Oladon
I coded JS for a long time... and stayed as far away from any kind of "JS world" as I could (which was pretty far).
21:10:19
Oladon
Consequently, I was able to enjoy JS as the functional-inspired Lisp derivative that it is. :)
21:10:29
EdLangley[m]
My professional life is continually fixing my app when a dependency breaks things
21:10:58
Shinmera
My professional life is continually fixing my app when I run into a bug I also wrote in the long line of shaven yaks.
21:11:05
_death
Shinmera: right, it may seem inefficient, especially if viewed as a collective.. but the people who wrote the test frameworks probably knew of the others and made the choice to write their own rather than fix and be dependent on others (why did you write parachute?)
21:11:31
phoe
_death: I don't believe that the only possible alternatives are the extremes of JS hellhole and the current CL situation
21:11:53
Shinmera
_death: I wrote parachute because I wanted to write one that could usurp them all. The specific goal was to write something that would be flexible enough to trivially extend to what people typically make a new one for (surface syntax changes)
21:12:41
_death
phoe: but why do you think CL is at an extreme? there are still PRs going on.. it's just that many CL people are conservative and the language is stable so there's no pressure to break things fast
21:12:47
EdLangley[m]
I think the attitude “I want to replace all the alternatives” doesn’t reflect why the alternatives exist
21:13:30
theothornhill
to me it looks a little like the CL world needs to open up to maintainers. Surely there are many folks wanting to help. But seeing issues at GH lingering for years with no answer does not inspire for someone to help/take over, I think
21:13:35
drakonis
scheme has reports every dozen years that serve to ratify a baseline of sorts and srfis for libraries
21:13:44
aeth
drakonis: you can't write many meaningful CL applications without using de facto standards that are portably handled through libraries that deal with the differences
21:15:09
Shinmera
_death: I'm just saying that was the goal, and it is not a goal I have seen other testing frameworks take, neither before I wrote it, nor now.
21:15:16
_death
Shinmera: anyway, personally I use parachute in my recent projects.. and the testing "frameworks" I wrote, I didn't publish.. so maybe I'm doing my part :)
21:15:44
drakonis
the portability matrix is basically "sbcl is the main implementation, everyone else barely exists"
21:15:47
aeth
drakonis: yeah, but the Scheme reports aren't ISO/ANSI/ECMA/etc. standards, either. Just non-authoritative PDFs. So an equivalent literally could just be someone specifying bordeaux-threads, CFFI, etc., in a PDF and "requiring" implementations to include that library instead of going through Quicklisp for them
21:16:45
Shinmera
The problem is nobody really cares, so the only way to make it work is by literally doing all the legwork yourself
21:16:46
phoe
and there's still people longing for the CDR process (multiple people, multiple times)
21:16:57
drakonis
isnt it commonly held that spending millions on it is wasteful and therefore there shouldnt be sequels to ansi cl?
21:17:23
Shinmera
drakonis: The money isn't the issue. The issue is that most are complacent and there's no real problem to solve at the moment like there used to be.
21:17:27
etimmons
_death: I definitely don't want to "break things." I would love it if every library everyone wrote is always backward compatible. And yes, CL gives us tools to add new features while maintaining backward compatibility in most cases. But sometimes breakage is the best way forward. And I think that deserves to be acknowledged, especially when it's done right with a very long notification time.
21:17:34
semz
"sbcl is the main implementation, everyone else barely exists" <- this has not been my experience
21:18:05
aeth
the only thing stopping someone from "R7RSing" the CL standard and coming up with an "authoritative" PDF is that the author wouldn't own the copyright on the spec to start building off of. So you can't just do CLHS+CDR like you can do R5RS+SRFI for R7RS
21:18:49
theothornhill
Shinmera: but if someone wants to contribute to/fix/remake hunchentoot or something else, I'd be surprised if they were allowed within two feet of the source code
21:19:36
aeth
Shinmera: in particular, many major Schemes seem perfectly fine with staying on R6RS instead of going to the more R5RSish R7RS
21:20:24
moon-child
they build up communities around specific implementations (chicken, gerbil, chez...)
21:20:59
aeth
drakonis: importantly, they're divergent in a way that makes it hard to rectify, in how they do libraries
21:21:36
aeth
CL has DEFPACKAGE, ASDF, and Quicklisp to work off of at various levels of abstraction, as well as a culture that encourages you to do it this way
21:22:13
etimmons
theothornhill: I agree about opening up to maintainers. (Sorry, I had to step out for a moment and am working through the scrollback)
21:22:17
aeth
drakonis: and, yeah, it looks like a huge chunk of snow-fort is just (chibi something), which just means that chibi was written in a portable enough way that someone could extract it as an R7RS package
21:23:00
theothornhill
etimmons: Yeah, it just seems so futile trying to make an attempt, IMO. At least for less experienced people
21:23:13
Shinmera
Clearly this frantic discussion is going to lead to a revolution in the Lisp community and encourage hundreds to start contributing and helping out with existing efforts :)
21:24:18
Catie
thothornhill and etimmons: I can't speak for anyone else, but this very much resonates with me. The idea of maintaining an existing project is very intimidating as someone who is new to Common Lisp
21:26:25
phoe
defclass/define-condition/deftype/defmacro/define-symbol-macro/define-compiler-macro too!
21:26:45
aeth
to me, what seems bad in CL is inconsistent APIs e.g. (nth index list) or (gethash key table) VS (elt sequence index) or (aref array &rest indices) ; etc
21:26:51
theothornhill
Catie: Yeah, this was one of the things I really liked about starting contributing to emacs. There was always someone responding to my stupid emails when I first started out. To me (from reading lots of cl issues) it seems like newbies often gets either pushed away, or ignored
21:27:12
etimmons
Catie: theothornhill: an example: I was shying away from Dexador for quite a while. But now that fukamachi has added at least one more maintainer that seems motivated, I'm more likely to keep using it.
21:28:59
etimmons
Catie: Yes. It had well known bugs that I didn't have time to fix and prior experience showed that even if I did, the PR would languish for a while
21:29:45
semz
I don't think these minor annoyances really have any effect. Look at the inconsistencies in stuff like Python or JS that people put up with. Or hell, PHP.
21:30:23
etimmons
Catie: But it now seems there's someone else with commit bits that is more active. Even if things don't get merged ASAP, having some activity or acknowledgement of issues keeps despair from setting in
21:30:27
aeth
semz: well, Python has its own problem in that it took its language's landmines, broke compatibility, and set the language adoption back a decade as the community fragmented in two
21:30:53
theothornhill
etimmons: Yeah, I can understand that problem, especially because forking most likely is not the solution