As a side note to this conversation, I hit this (require) vs (:require) thing almost a year ago when porting a file to CLJS. ClojureScript has been enforcing these keyword regulations for some time, as well as only allowing a single :require, not allowing anything but :require, :use, etc.
On Sat, Aug 20, 2016 at 4:26 PM, <s...@corfield.org> wrote: > 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 <mar...@roundingpegs.com> > *Sent: *Saturday, August 20, 2016 7:58 AM > *To: *clojure@googlegroups.com > *Subject: *Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11 > > > > > > On Aug 20, 2016, at 9:03 AM, Alex Miller <a...@puredanger.com> wrote: > > > > We discussed this before releasing the specs and decided to start on the > strict side. That said, this is still an alpha and there is plenty of time > to change our minds prior to official release of 1.9 if that ends up being > a catastrophic decision. > > > > I urge you to change your minds. Whose life is harmed, and how, by > continuing to allow `require` as well as `:require`? > > > > -- > 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. > > > > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
