[Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=`

Hilco Wijbenga hilco.wijbenga at gmail.com
Sat Aug 8 23:01:35 UTC 2015

On 8 August 2015 at 14:46, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Sat, Aug 8, 2015 at 5:27 PM, Hilco Wijbenga <hilco.wijbenga at gmail.com>
> 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.

> 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.

More information about the Haskell-Cafe mailing list