On Fri, Mar 28, 2014 at 11:33 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
On Fri, Mar 28, 2014 at 11:00 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
Once it's accepted that ASDF will enforce the syntax variables decided
This seems more like an "if" than a "once" to me.
Then please argue that. I for one fully agree that the big question is not about the specific defaults chosen by Dan Barlow and me in the past, and possibly Robert Goldman in the future, but about whether ASDF should provide a default that system author can rely upon.
Will you argue against ASDF letting the system author fully control the file type of source files, rather than it depending on a global variable?
Will you argue against ADSF letting the system author fully control the encoding of source files, rather than it depending on a global variable?
Will you argue against ADSF letting the system author fully control the syntax of source files, rather than it depending on a global variable?
And since you're fond of C analogies: should gcc determine the syntax it uses to compile a file based on an environment variable or on information fully determined by the software author in his Makefile?
That's the high-order bit question. Let's argue it, with more than an ad hominem attack.
I do not want to see a system that relies on personal intercession to reduce the friction introduced by the things it breaks. Even if those things are not open source or free software projects, even if they use dirty, unhygienic techniques, even if they did not report promptly to you when a problem arose, even if they do not want your help, I do not think they deserve to lose.
If there is no clear way to get the effects you want without breaking code that works today, I would prefer nothing be done until such a solution is clearer.
I don't see how this argument applies specifically against this change. It's an argument against change in general: any change will tautologically break some things and is tautologically fixed by a person somewhere doing the work.
Now, mind that no one is forced to change. As far as software that I have been maintaining goes, QRes is still using CCL 1.8, because no one took the time to fix the concurrency issues that appear after upgrading to CCL 1.9 or 1.10 (probably due to sloppy code on the QRes side rather than the CCL side, but who knows - in the past CCL changes have notably revealed Linux kernel issues). janderson is reportedly using ASDF and libraries from at least 5 years ago. If someone is perfectly happy with the code he has, no one wants to force them to upgrade, and I encourage everyone to use source control and backups to keep their builds 100% reproducible, just like we did at ITA. If someone randomly upgrades libraries without having working versions in source control, maybe the problem is with their lack of proper source control, not with change happening. I promise I'm not going to hack into anyone's machine and upgrade half the software in their back while leaving bugs in the other half.
The question is what to do going forward regarding the change that WILL happen, and indeed how do we reduce overall future friction. Ten years from now, will there have been more or less friction if system authors control syntax, or if syntax depends on the values of variables that none of library authors, application programmers and end-users fully control? I argue that putting system authors in full control of their files' syntax will minimize overall friction, by A WHOLE LOT. Making the build totally unpredictable based on changes at the REPL and/or environment variables? Here's what causes a lot of friction. Once again, lisp file type and character encoding are cases in point.
Yes, there are transition costs, and yes, an overly eager transition would increase these costs. To assess these costs is exactly why we're having these discussions to begin with, and why Anton is running all those tests. It's obvious now that this is not a change to happen today, nor until all libraries in Quicklisp are fixed. And therefore, I'm not advocating for a change before ASDF release 3.1.1, as I previously and over-optimistically hoped. But the change needs to happen sometime, and the sooner the better - and I'm hoping to make it sooner, by sending fixes to each and every library that depends on *r-d-f-f*. Unless you want to document that the user is responsible for always ensure himself that *r-d-f-f* is bound to 'single-float before he compiles anything, which is as far as friction goes is HIGH.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He was a great patriot, a humanitarian, a loyal friend; provided, of course, he really is dead.