
El Aug 8, 2015, a las 19:01, Hilco Wijbenga
On 8 August 2015 at 14:46, Brandon Allbery
wrote: On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga
wrote: So when is it okay? :-) Still, if proper tooling automates it, why not?
Because your tooling does not rewire people's brains and does not automatically run itself on other people's programs when you *look* at them.
I don't think we need to "rewire" our brains to accommodate a few language tweaks. The haskell-fix tool I had in mind would change the source code so you would look at the fixed code. But, yes, there would be a transition time. In my experience that is true for any change to your code base.
An analogy: Haskell's use of "::" and ":" are backwards. Most ML-style languages use ":" for types but iiuc it was assumed using cons would be so common that it should be the quicker one to type. Obviously that estimation was wrong -- we write a lot more types than conses. Annoying? Yes. Way too late and fundamental to change? Also yes. I also disagree with the better-ness (even for beginners) of the proposed changes, but point 1 supersedes that. tom
Because not everyone builds houses of cards and leaves them to collapse on their successor while they go chase the next cool thing, like certain modern "web programmers" who seems to have confused "agile" with "fragile" and therefore think Go rewriting its syntax every week is somehow sensible. And not everyone *can* do things the zero-memory-change-it-all-who-cares-it'll-all-be-different-next-week way; that does not fly on the business end, for example. (I've had people claim to me that they do that with accounting packages. I bet they've never faced an audit and will be learning the hard way why business does not work that way when the auditors *do* show up.)
You seem to be creating a whole mountain range out of a mole hill. :-)
I have to maintain a very low quality, legacy code base. So I totally sympathize with the "house of cards" and "fragile" part of your paragraph. But after that I have a hard time making sense of it.
Nobody is advocating changing Haskell to look like a completely different language. Or that we start making language changes every week. I really do not understand where you got that impression. Everybody is talking about tiny language tweaks that (hopefully) make the language better. If the agreement is that, yes, it does make the language better than the blanket counter argument "it breaks existing code" should not stop progress. If you don't make improvements now because of existing code then tomorrow there will be more existing code and thus even more inertia. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe