I disagree (strongly) with your position here Brian. I’ll try to explain clearly why but first a little background…
At World Singles, we’ve always done multi-version testing against the stable version of Clojure that we plan to use in production and also against the very latest master SNAPSHOT. This gives us an early heads up when a breaking change is introduced. When the ns spec hit master, our build broke. We had three namespaces with incorrect syntax – based on the documentation and what all the books and tutorials show – so we simply fixed them (one was require, two were import). Luckily none of the libraries we rely on had similar breakages. Then we moved to Alpha 11 and found another namespace with require – clearly our tests don’t have sufficient coverage (duly noted, JIRA issue to follow I expect). Despite having to fix our code, we welcome the stricter compiler checking here. There are very few things in language design that frustrate me more than preserving bad compiler behavior in the name of “backward compatibility” on the grounds that “if we fix this, people who have code that we never intended to work will see breakages, and be forced to correct their bad code”. That’s what you’re asking for here: that Clojure/core preserve unintended behavior so that people who have code that works “accidentally” aren’t forced to modify their code to match what has always been intended. Why do I feel so strongly about this? A few things… I built one of the first ANSI-validated C compilers which focused on “the letter of the law” as far as flagging undefined, unspecified, and implementation-defined behavior. After that, I was on the ANSI C++ Standards Committee for eight years where we had to deal with this same sort of issue over and over again in terms of deciding what unintended legacy behaviors should be enshrined as standard vs outlawed (vs pushed to one of those three behaviors). After all that standards work, I then had to deal with Macromedia / Adobe ColdFusion on and off since 2001: a product that values backward compatibility so deeply that it repeatedly does exactly what you’re asking Clojure/core to do – it won’t fix any number of bugs because they might break unintentionally working code. You can’t begin to imagine what decades of that position does to a language – it’s a horrible, inconsistent, mess of a language, full of special cases, warts, and surprising behavior. I wouldn’t wish that on any sane developer. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org From: Brian Marick -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
