Hi Ertugrul,

Well, it is a rant, so you can just as well concede it. =)

By my standards that was a lullaby ;-) Everything you said is correct. Just like everything I said. The best policy lies between the two extremes. Your extreme would be fine if Haskell presented itself as a purely theoretical research tool. But it actually wants people to use it for stuff that peoples' livelihoods depend on. So there are some shiny new frameworks out there which unlike WASH didn't break yet. Thanks for the pointers. I tripped over blaze a moment ago (so no I didn't stomp back to PHP after all) which mentions something called Snap. I'll check out your other suggestions too. But what about two years from now? Will they still be working by then or will their developers have got just as sick of continually moving goalposts as those of WASH evidently did? Or would I be taking on the job of maintaining it myself? I guess you'll be telling me that Happstack is a bad habit of mine and I should rewrite my whole system in whatever the new thing is by then. I mentioned this trade-off that you talk about towards the end of my rantaby. It's true that we can't have the best of both worlds but perhaps a little restraint would be appropriate. I mean, are you saying that Haskell was really bad when it could make up its mind what "import Prelude" meant? If you really want to change something that basic, how about calling the new one Prelude2? I kinda liked Haskell even in 1998. I just don't see why switching new things on has to mean switching old things off. You can't have your cake and eat it, but I see no reason to shit all over one half of the cake just because you're more interested in the other half. Also, there's no real value in blaming these problems on the maintainers for retaining the "bad habits" that they learned from Haskell. The reality is that the forums are crammed with people suffering this kind of thing. It doesn't make a difference who you blame. Either way, the ecosystem looks untrustworthy, so fewer people will adopt it, and it'll be retreating from its original stated goal, which IIRC was to be a standard and widely used FL. It might be very rigorous and clever, but that's not much use if it's only being used by the people who have a full time job making it even cleverer. Not a lot of people in industry are using Haskell. More are using Erlang, Ocaml, XSL, J#, etc so it can't be just because they're scared of FP. If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it. Adrian.

Adrian May wrote:

[...] If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it.

I'm not saying that you are wrong, but you may be looking at it from the wrong angle: Unmaintained projects depending on one of the major web frameworks still compile today. The strong version constraints used by packages and taught by the package versioning policy makes this possible. When you install it, it does the right thing. WASH on the other hand is really a legacy from the stone age of real world development in Haskell. As said, I'm surprised that you could even compile it today. I consider it a proof of concept that web application development is very possible with Haskell and the community has moved on to implement real web frameworks made for production use. This happens for all languages, not only Haskell. You may find that one or the other C/C++ package breaks with GCC 4 when it compiled just fine with GCC 2. This is why we have the major/minor/patch-level split in the first place. You can't expect that nothing will break when you update from GCC 3 to GCC 4. The same holds for GHC and even for strongly keep-being-retarded language implementations like PHP. At some (quite recent) point in time the whole language was revised and is called Haskell 2010 now. You can still compile with Haskell 98 and many old packages should still work, unless they are broken by the new base library. With the new language it's simply that the type system has changed in an incompatible way. It's not that features have been removed, but simply that you have to express them differently now. This is most noticable for local bindings, but you will also find that the base library has undergone some breaking changes. This was the most legacy-breaking change I can remember, but it was necessary. We all suffered from bad decisions made in the old days. This is also likely the change that broke WASH. Other than this the Haskell ecosystem is actually comparatively stable. It is so stable that actually we run into another problem, which we refer to as the Cabal Dependency Hell. Semisolutions like cabal-dev are available, but we really need to do some work here. This is probably the weakest part of the Haskell ecosystem right now. However, it's also actually a very hard problem. Other languages have the same problem, but they fix it by ignoring it. Programmers in those languages just pretend that it's impossible to install multiple versions of the same package, but if operating systems like NixOS gain more popularity they will have to reconsider their philosophy when they face sudden segfaults. Haskell's Cabal would have warned them. They don't have such a tool. In other words, you are likely suffering from the one big breaking change made in Haskell's modern history (i.e. post 1998). Don't be discouraged by that and enjoy the improved language and base library. Enjoy an ecosystem that acknowledges the existence of problems and the tools you get to find a solution that fits you. You are going into the right direction now. =) Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

John Lato wrote:

I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity.

I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing.

Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake.

I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 "Ertugrul Soeylemez " FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/

If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. On May 2, 2013 6:33 AM, "Adrian May" wrote:

So WASH is ancient history. OK, lets forget it.

How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around.

Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way.

Adrian.

On 2 May 2013 19:57, Ertugrul Söylemez wrote:

...

John Lato wrote:

...

I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity.

I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today.

Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing.

...

Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake.

I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users.

With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone.

Greets, Ertugrul

-- Key-ID: E5DD8D11 "Ertugrul Soeylemez " FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Emphatic agreement on this point. Likewise, the strong type system and the often helpful type error messages make it really easy to update code to work with more modern libs! -Carter On Thu, May 2, 2013 at 9:39 AM, David Thomas wrote:

If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. On May 2, 2013 6:33 AM, "Adrian May" wrote:

...

So WASH is ancient history. OK, lets forget it.

How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around.

Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way.

Adrian.

On 2 May 2013 19:57, Ertugrul Söylemez wrote:

...

John Lato wrote:

...

I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity.

I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today.

Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing.

...

Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake.

I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users.

With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone.

Greets, Ertugrul

-- Key-ID: E5DD8D11 "Ertugrul Soeylemez " FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Thu, May 2, 2013 at 6:26 AM, Adrian May wrote:

How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC.

I think you're missing the point of the platform! It is an explicit set of versions, including GHC, that make a stable reference set of packages on which to build, test, and deploy. Each version of the platform explicitly states with equality constraints the exact version of each component so that it will be the same for everyone. You use the HP - with the GHC it comes with (or specifies) - as a set. You want to use GHC 7.4.1? Use HP 2012.2.0.0. Once installed you can install newer versions of the component packages if needed (though cabal-dev or cabal sandboxing is strongly encouraged in such a case to avoid "cabal hell".) And unless somebody can explain to me how I would rescue my business now if

I had opted for WASH

By patching it. Surely we are talking about minor changes here. - Mark

On Thu, May 2, 2013 at 10:36 AM, Adrian May wrote:

I think you're missing the point of the platform!

...

I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the

Having to build it already indicates that something is wrong, unless you're porting to an unsupported OS/hardware.

platform. As I say, the reason I was trying to build it was that I wrongly blamed the ubuntu package for

That said, may I point out that the Ubuntu packages *are* broken? They shipped a mangled Platform which can't be relied on for much; instead of a well-tested set of packages, they took a good Platform and replaced bits with minimal testing. Yes, this has actually caused problems for people. Yes there are times when something has to change. I acknowledged that in my

original post. But I see no evidence whatsoever that anybody in control of Haskell is holding fire even on things as innocent as getPackageId or as ubiquitous as the prelude. I'm not asking for the opposite extreme of conservatism, just a bit of common sense instead of this bloodbath.

You're assuming here that someone deliberately targeted your favorite pet. I don't know the details but I VERY STRONGLY doubt anyone said "oh, we should break that function". But I ALSO find it likely that it was the victim of something sufficiently pervasive that the options were "break it" or "live with something else being broken forever, just like Perl vs. cpanel!" This, sadly, is the real world. The holy grail of fixing bugs without breaking any program ever anywhere is impossible, and even "fix this bug without breaking many other programs" is extremely unlikely. Your choices are this, or Perl/PHP "we do not dare fix bugs or misdesigns because someone's pet program will die". (Other examples of this: - Python 3. Note how many existing Python packages still require Python 2. - The C and C++ standards are increasingly Byzantine due in large part to backward compatibility issues; but I'm guessing from your complaints that this is your ideal model because "old programs still work". Lucky you, you can happily pretend that it's because they have found some magical way to do the fundamentally impossible --- right up until reality bites back. ) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Thu, May 2, 2013 at 7:36 AM, Adrian May wrote:

I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the platform.

This is not for the faint of heart. Like *ALL* language distributions I know (C++ included), boot-strapping the next rev is never easy. Consider building the stdc and stl for version gcc x with gcc x-1 - Or trying to assemble and test packages for python 2.x with only python 2.(x-1) just a bit of common sense instead of this bloodbath. Now you're being hysterical. The changes don't rise to that level at all. Vast swaths of haskell code have continued to work just fine over the last many years of changes. And many more have continued to work with only minimal maintenance. The changes over the last several years are no more extreme than I see in other systems. Consider that Mac OS X ships with Python2.5 and 2.6 and 2.7 all installed because of incompatibilities in the base set of libraries. If you are comparing it C++ library stability you are being myopic: The situation in C++ system libraries was so complex that it spurred the monster that is autoconf! That the most common libs have settled into a very stable set that can be expected to work over several years and major releases, has only been true in the last decade. The prior three decades of C (and later C++) were filled with tons of this sort of versioning difficulty, compounded by multiple systems. - Mark

What's getPackageId? It does not appear in the WASH source.

It's in Setup.lhs, in WashNGo.

Which source of WashNGo are you using? It doesn't appear in either of these versions:

http://hackage.haskell.org/package/WashNGo-2.12 http://hackage.haskell.org/package/WashNGo-2.12.0.1

http://www.informatik.uni-freiburg.de/~thiemann/WASH/WashNGo-2.12.tgz

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I get a 403 FORBIDDEN on that. How did you get it?

I guess you just gotta know the right people ;-) I attached the tarball. Don't say you got it from me, OK.

On Thu, May 02, 2013 at 11:35:27PM +0800, Adrian May wrote:

...

I get a 403 FORBIDDEN on that. How did you get it?

I guess you just gotta know the right people ;-)

I attached the tarball. Don't say you got it from me, OK.

That tarball still doesn't contain the string "getPackageId". You're complaining that you can't build a package, which hasn't been maintained for several years, which you got from a secret source, and whose whose Hackage page specifically says it doesn't build beyond GHC 7.0. I don't think this is indicative of a serious failure of Haskell. Tom

I'm sorry: it was showPackageId. And the tarball came from this page: http://www.informatik.uni-freiburg.de/~thiemann/WASH/ which certainly isn't secret to Gooliath: I got it by searching for "haskell cgi html". I don't know why you can't download it. Anyway, I've noted your opinions but today I really need to get something done. Thanks for the discussion. Adrian.

...

Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel?

About 12 seconds, if you read http://www.haskell.org/platform/linux.html:

Download the source tarball for Unix-like systems: here

- *haskell-platform-2012.4.0.0.tar.gzhttp://lambda.haskell.org/platform/download/2012.4.0.0/haskell-platform-2012... * - SHA-1: 7976508c50305969f64c721a1d095ae22efff8b7

Get and install GHC 7.4.2 prior to building the platform:

- GHC 7.4.2 http://haskell.org/ghc/download_ghc_7_4_2.html

Finally, unpack the Haskell Platform source tarball, and run (possibly with 'sudo'):

./configure

make

make install

Also, the Haskell Platform ./configure step checks which version of GHC you have installed, and requires you to pass the option --enable-*unsupported*-* ghc*-version in order to compile it with anything other than GHC 7.4.2. Did you try an unsupported version? And now you're complaining?

On Thu, May 2, 2013 at 8:43 PM, Adrian May wrote:

...

Also, the Haskell Platform ./configure step checks which version of GHC you have installed, and requires you to pass the option --enable-* unsupported*-*ghc*-version in order to compile it with anything other than GHC 7.4.2.

Did you try an unsupported version? And now you're complaining?

This is getting into minutia now, but yes I tried the unsupported flag and as I already explained it barfed about the prelude.

How is it minutia that you expect an unsupported version of GHC to work? Yes, I try it out sometimes. And if it works, great. If not, too bad, I'll wait until the next Haskell Platform. I don't whine about it in public.

So I installed 7.4.2 from source but that confused cabal because my attempt to uninstall the ubuntu package with 7.4.1 in had failed with dependency-hell. Figuring out why (or even that) my packages weren't being seen was the puzzle I was referring to.

So the complaint is about Ubuntu?

The point is that we wouldn't have to be talking about this at all if people didn't move the furniture around all the time.

That's not a very good point. It sounds as though you're the one who moved furniture around, considering that you managed to mix up Ubuntu's GHC package with your hand-built ones.

On Fri, May 3, 2013 at 6:48 AM, Adrian May wrote:

May I venture a guess that you never tried to manage a 5-10 million line project?

I build a project a couple orders of magnitude bigger than that dozens of times every day. Similar stories are not uncommon among people who inhabit this list. But thanks, citing that figure as an excuse to be condescending to that person was really worth a giggle this morning. :) That's what I do. I'm not a programmer, I'm a manager. I run teams of a few

dozen people on subprojects within huge telecom-related projects, and my job is to try and keep it all from collapsing in a heap of bugs.

If you had any experience of that you'd run a mile from any technology with this hit and miss attitude.

You keep saying things like this. Actually, you're in this situation because one or more people within your organization have made a succession of very bad choices. Haskell is not to blame. Personally, I almost can't believe you're taking this tack on the list now that the details of your situation are apparent: you've let a 5-10 million line project spiral out of control without putting the necessary software engineering infrastructure and controls in place.

I can't tell people what version they should be using because half of them work for a completely different company. They have their own dependencies coming from other projects that I'm not even allowed to know about.

... and the truth emerges. This issue you're having reflects a lot more strongly on your technical culture than it does on any instability in GHC. Listen: someone within your organization decided to build a product based on a very old library which is no longer maintained by anyone. If this library were actually critical to your business, you would fork it and either get someone in-house or pay a contractor to fix bugs and keep it up to date. (And there are plenty of people here who might be interested in a contract gig to fix this for you if you asked). Repeatedly claiming in the most histrionic terms that GHC ought to freeze forever and never deprecate anything again so that you can avoid doing your job properly is simply not realistic, especially given Haskell's social culture (newsflash: it's a research platform), and is not going to garner you any sympathy on this list, either. You could practically be the poster boy for why we have the motto "avoid success at all costs". You have two options: stay on GHC 6.x (the bits didn't get deleted from the internet), and if that isn't practical, fix Wash (or pay someone to do it if you don't know how) and get on with your life. G -- Gregory Collins

On Fri, May 3, 2013 at 4:37 PM, Simon Peyton-Jones wrote:

One of the great things about the Haskell mailing lists is the supportive, respectful tone that is the dominant mode of discourse. I sense that things are getting a little out of control in this particular thread. Even though this particular issue is clearly extremely frustrating for those involved, it would be great to turn down the emotional temperature.****

I don’t know why Haskell folk tend to be so generous and helpful, but they

really are. (Maybe it’s the hylomorphisms.) Anyway, let’s keep it that way. ****

Agreed, the thing that surprised me the most when I started reading this list was how nice people were, even when faced with some pretty hostile people. I think we all agree that dependency management is hard in any system, especially with a lot of generally unmaintained pieces. And the fact that 100% backwards compatibility doesn't seem to be a directive in the language committee like it might be for languages like C++ might frustrate people. I'm pretty sure most of us have experienced some issue with dependencies breaking , and its probably the most frustrating problem we can have have in any language. It's hard not to take this all a bit personally. Maybe if we think more about how to solve this (getting people to maintain their stuff, for example) we can make the world a better place instead of bickering about issues that are more or less language-agnostic really. On a side note is there a place where we can see what packages have broken on recent releases?

Simon****

** **

*From:* haskell-cafe-bounces@haskell.org [mailto: haskell-cafe-bounces@haskell.org] *On Behalf Of *Gregory Collins *Sent:* 03 May 2013 08:27 *To:* Adrian May *Cc:* Haskell Cafe *Subject:* Re: [Haskell-cafe] Backward compatibility****

** **

On Fri, May 3, 2013 at 6:48 AM, Adrian May wrote:****

May I venture a guess that you never tried to manage a 5-10 million line project?****

** **

I build a project a couple orders of magnitude bigger than that dozens of times every day. Similar stories are not uncommon among people who inhabit this list. But thanks, citing that figure as an excuse to be condescending to that person was really worth a giggle this morning. :)****

** **

** **

That's what I do. I'm not a programmer, I'm a manager. I run teams of a few dozen people on subprojects within huge telecom-related projects, and my job is to try and keep it all from collapsing in a heap of bugs. ****

** **

If you had any experience of that you'd run a mile from any technology with this hit and miss attitude. ****

** **

You keep saying things like this. Actually, you're in this situation because one or more people within your organization have made a succession of very bad choices. Haskell is not to blame. Personally, I almost can't believe you're taking this tack on the list now that the details of your situation are apparent: you've let a 5-10 million line project spiral out of control without putting the necessary software engineering infrastructure and controls in place.****

** **

****

I can't tell people what version they should be using because half of them work for a completely different company. They have their own dependencies coming from other projects that I'm not even allowed to know about.****

... and the truth emerges. This issue you're having reflects a lot more strongly on your technical culture than it does on any instability in GHC. ****

** **

Listen: someone within your organization decided to build a product based on a very old library which is no longer maintained by anyone. If this library were actually critical to your business, you would fork it and either get someone in-house or pay a contractor to fix bugs and keep it up to date. (And there are plenty of people here who might be interested in a contract gig to fix this for you if you asked).****

** **

Repeatedly claiming in the most histrionic terms that GHC ought to freeze forever and never deprecate anything again so that you can avoid doing your job properly is simply not realistic, especially given Haskell's social culture (newsflash: it's a research platform), and is not going to garner you any sympathy on this list, either. You could practically be the poster boy for why we have the motto "avoid success at all costs". ****

** **

You have two options: stay on GHC 6.x (the bits didn't get deleted from the internet), and if that isn't practical, fix Wash (or pay someone to do it if you don't know how) and get on with your life.****

** **

G****

-- Gregory Collins ****

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Isn't this a problem of timescale? Nothing can be backward compatible for ever (or at least nothing that is being developed or maintained) There will be, in the life of non-trival length project, change. We rely (and I mean rely) on Haskell s/w that was written over 10 years ago - we accept that when we want to recompile it (about every 2/3 years as the systems it interacts with are updated) there will be a cost of change to bring it up to latest libraries etc. But the joy is that (combined with the regression and property tests around it) we can have very high confidence that once the "old" stuff recompiles it will operate the same. And as it is key to our business that is a nice feeling - let's me sleep soundly at night. The beauty of the Haskell ecosystem is that such change is nowhere as hazardous as with other approaches. Therefore its total costs are less. The experimentalism in this community is to be applauded and encouraged - it is spawning robust solutions to the "real" underlying problems of constructing a society that can actually support the technical infrastructure it is creating. Don't forget the motivation for Ada was that the projected costs of supporting the US defence infrastructure was projected to exceed the projected GDP of the US by 2012. Maintaining essential safety critical systems isn't an optional extra. We see that the same Ada-like scenario is working its way out in companies today - large Telcos, Goverment projects etc - I also see that formalism, such as embodied in Haskell, is the ONLY hope we have to contain the costs of maintenance complexity. Yes, the underlying issue is a human one - but it lies in the low value given to medium to long term sustainability of organisations (e.g Telcos) compared to the relative high value that is given to novelty. Perhaps this is an inevitable by-product of a marketing driven, short term driven business culture? Neil On 3 May 2013, at 10:04, Ertugrul Söylemez wrote:

Raphael Gaschignard wrote:

...

I'm pretty sure most of us have experienced some issue with dependencies breaking , and its probably the most frustrating problem we can have have in any language. It's hard not to take this all a bit personally. Maybe if we think more about how to solve this (getting people to maintain their stuff, for example) we can make the world a better place instead of bickering about issues that are more or less language-agnostic really.

The problem can't be solved technically. It's a human problem after all and it's amplified by the experimentalism in this community. I think the best we can do is to acknowledge its existence, which places us way ahead of mainstream programming communities.

We don't pretend that type X in lib-0.1.0 is the same as type X in lib-0.2.0. What we need to work on is the ability to actually combine multiple versions of the same package conveniently, i.e. we shouldn't view this combination as an error.

Greets, Ertugrul

-- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Dependency breakage is certainly an unavoidable problem. However, I think Haskell is also in a much better position for having a technical solution to the frustration of breakages. Barring issues with changing datatypes / class instances, we can already express many of the API changes you'd want to make to some library [1]. Now, no one actually does what this proposal suggests - it's a lot of work, and it doesn't work in general. However, the fact that Haskell makes something like this seem reasonable is heartening. Of course, even if we had good tools that automatically refactored code to use new APIs, it wouldn't be possible for any non-superficial changes. Even so, if a good enough refactoring tool existed, and it was popular with both authors and users, a lot of the annoyance of dependency breakages could be removed. -Michael [1] http://haskellwiki.gitit.net/The%20Monad.Reader/Issue2/EternalCompatibilityI... On Fri, May 3, 2013 at 2:04 AM, Ertugrul Söylemez wrote:

Raphael Gaschignard wrote:

...

I'm pretty sure most of us have experienced some issue with dependencies breaking , and its probably the most frustrating problem we can have have in any language. It's hard not to take this all a bit personally. Maybe if we think more about how to solve this (getting people to maintain their stuff, for example) we can make the world a better place instead of bickering about issues that are more or less language-agnostic really.

The problem can't be solved technically. It's a human problem after all and it's amplified by the experimentalism in this community. I think the best we can do is to acknowledge its existence, which places us way ahead of mainstream programming communities.

We don't pretend that type X in lib-0.1.0 is the same as type X in lib-0.2.0. What we need to work on is the ability to actually combine multiple versions of the same package conveniently, i.e. we shouldn't view this combination as an error.

Greets, Ertugrul

-- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

How about this: can you guys give me a detailed example of a justified deprecation: one so extremely obviously called for that even I would agree. I just want to understand the kind of logic that's applied over these things.

Changes already made in the base library or in one of the platform libraries:

So could you pick the most unassailable and tell me more about it please?

On 3 May 2013 18:56, Ertugrul Söylemez wrote:

Adrian May wrote:

...

...

Changes already made in the base library or in one of the platform libraries:

So could you pick the most unassailable and tell me more about it please?

I'll just pick a random example: Eq and Show are no longer superclasses of Num. I'm the author of the Netwire library, a library for functional reactive programming. Before that change you would write the following code to express a clock that runs twice as fast as the real time clock and oscillates up and down while gradually increasing:

liftA2 (\t o -> 2*t + sin o) time (integral_ 0 . v)

Thanks to the change you can now write it as:

2*time + sin (integral_ 0 . v)

I never doubted that people add new stuff for valid reasons. What I'm interested in is whether or not it could have been done without breaking anything. But having thought about it for a while, I'm tending to think that version controlling all the standard modules is the only general solution. You'd have them all in a git ... ahem ... darcs repo which every dev would clone the entire history of. Something prominent in the project would say which version you want. (We could brainstorm about hierarchies of that but it probably wouldn't work anyway.) GHC would just switch its internals according to that number and fetch the right version of the module out of darcs as part of the compilation process. If you really wanted to protect people from future changes, you'd make it obligatory to tell ghc which version you want, but seeing as I seem to be more worried about this than anybody else around here, I might as well assume you'd default to the latest, but please, at least issue a warning so that people know this offbeat system even exists. ) I could have my project source in a completely different source control system cos this darcs interaction is internal to the compiler. This ain't gonna mean I don't have to maintain stuff, but having the choice about when to do so would be a great help. Better still, I could take a fifty year old codebase, build it out of the box, and nudge the version along one step at a time so I have some kind of chance, which would render my original post completely redundant. But best of all, I'd no longer care which dev had which Haskell Platform version. They'd just get nagged into upgrading ghc whenever it saw a too racy module version. That would mean I could let them finish what they were doing on their own branch, check it into the old-style mainline and then tell them to merge it onto the new-style mainline, expecting a few puzzles along the way. For their next feature they'd branch off the new mainline and in a few weeks the old one would be history. (I'm not sure you've all figured out that those few weeks are necessary.) Seeing as you guys like theoretical rigour so much, maybe I should put it this way: if you show me a lump of text and call it source code for a program, I'll think you mean that it contains all the information I need to turn it into one. If it fails to specify which versions of which external libraries it assumes are hanging around somewhere, then it hardly meets that definition. Looking at it that way, compiler errors are not the worst thing that could happen: it might build an entirely different program. I've seen two huge projects hit the trash can because of build system vagueness, and that's what I learned out of it. Just imagine never having to negotiate with the backward-compatibility whingers anymore! Adrian.

On Fri, May 03, 2013 at 09:34:21PM +0800, Adrian May wrote:

I never doubted that people add new stuff for valid reasons. What I'm interested in is whether or not it could have been done without breaking anything. But having thought about it for a while, I'm tending to think that version controlling all the standard modules is the only general solution.

I think you may be overestimating the severity of the "breakage" that applies to the WashNGo package. In Haskell2010 a number of module locations were renamed in order to reduce clutter. For example, IO became System.IO, List became Data.List and Monad became Control.Monad. I'm pretty sure that updating all of these module names will fix the problem. No one has bothered because the package is very old and there are more suitable alternatives these days. Tom

On Fri, May 03, 2013 at 01:23:55PM +0300, Guy wrote:

That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much boilerplate because of the Functor => Applicative => Monad mess. Float/Double being Enums is ridiculous. None of this gets fixed because of the fear that new GHC won't compile old code.

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

This kind of "breaks everything" changes would require something similar to what Python is doing with the 2 -> 3 transition, and considering how painfully slowly it is progressing there, I understand perfectly well why people don't want to go there.

On Fri, May 03, 2013 at 03:35:08PM +0100, Ozgur Akgun wrote:

Hi,

On 3 May 2013 11:43, Tobias Dammers wrote:

...

...

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

This kind of "breaks everything" changes would require something similar to what Python is doing with the 2 -> 3 transition, and considering how painfully slowly it is progressing there, I understand perfectly well why people don't want to go there.

There is one very big advantage in the Haskell-world though. Most of the struggle will be at the compile time. The biggest headache caused by the Python 2 -> 3 transition is how you get a runtime error 2 weeks after you think you've fixed everything!

(Yeah, I know code coverage analysis is an option when you don't have static type checking, but ...)

Well; this is an additional problem that comes with the pragmatic choice for a language that doesn't believe in type checking and compile-time guarantees, but I think it is largely orthogonal. At least theoretically, you could have 100% test coverage, which would put the Python project in the same situation as the Haskell one (except that the tests themselves would also have to be converted...) The problem I'm talking about, though, is that such a change would split the ecosystem in two (say, "Traditional Haskell" and "Functor-Correct Haskell"), just like the 2/3 separation is all over the Python ecosystem and causes all sorts of headaches. "Should I be using Python 2 or 3" is not a question that has a simple answer, and that *is* a problem.

Cheers, Ozgur

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

"Tantamount to a new language" to fix a minor detail in a typeclass hierarchy? That is just histrionic. *No* language is that stable. Scala makes dozens of changes like that between *minor* versions, and while I hardly hold up their development practices as the best in the industry it is still somehow seen as enterprise ready. -Edward On Fri, May 3, 2013 at 6:52 AM, Adrian May wrote:

...

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

I think that should be fixed as well, but it would be tantamount to a new language.

I guess you need some kind of versioning system for the libraries. Why not put them all in a public source control server and have ghc force people to say which snapshot they wanted. That would be your final breaking change, and it's a one-liner in the Makefile. Then you could thrash around as much as you liked and people like me would have nothing to complain about. Naturally, the compiler itself should keep supporting old modes.

Adrian.

...

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where. The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that). This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces. On Fri, May 3, 2013 at 3:23 AM, Guy wrote:

Ertugrul Söylemez wrote:

...

Often demanded changes that may or may not happen in the future:

* base: Make Functor a superclass of Monad. One of the two most commonly demanded change to the base library. Will break lots and lots of code. Reason: Would greatly simplify a lot of code.

* base: Fix the numeric type classes. The other most commonly demanded change. Will break lots and lots of code, including most of the base library. Reason: Would make numeric code much more sensible and algebraic.

That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much boilerplate because of the Functor => Applicative => Monad mess. Float/Double being Enums is ridiculous. None of this gets fixed because of the fear that new GHC won't compile old code.

Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm more than happy to do it in return for a better language/library.

PS The proposal to fix Functor => Applicative => Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code.

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

That's approximately what I was describing, yes. Thanks! On Fri, May 3, 2013 at 7:54 AM, Guy wrote:

David Thomas wrote:

...

I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where.

The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code.

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

That's approximately what I was describing, yes. Thanks! On Fri, May 3, 2013 at 7:54 AM, Guy wrote:

David Thomas wrote:

...

I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where.

The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that).

This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces.

http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances

I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code.

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, May 3, 2013 at 5:30 AM, Adrian May wrote:

How about this: can you guys give me a detailed example of a justified deprecation: one so extremely obviously called for that even I would agree. I just want to understand the kind of logic that's applied over these things.

This might not be possible because your notion of a justified change may not align with other people's. IIRC the removal of the Show constraint on Num was driven by type level natural numbers? which matter to the type hackers but not to someone whose main concern is getting an unmaintained web interface running. (OTOH it also may not have any effect on said web server, since it mostly affected people who take the somewhat risky action of defining their own Num instances; I suspect the exceptions change would have more impact on web stuff.) As for the exceptions stuff, that was a multi-step change. Exception handling was somewhat unprincipled and came in two forms, which used the same function names but in different ways. There was support for IO exceptions in the Prelude and conflicting support for general exceptions, which behaved somewhat differently when handed an IO exception, in Control.Exception. One key behavior was that you had to handle all exceptions or none at all; the only way to choose specific exceptions was to handle all of them, inspect the exception object, and rethrow if it wasn't one you wanted to handle. And inspecting the exception object to see what it had in it could be tricky at times, because there wasn't much guidance with respect to user defined exceptions and some library exceptions did things slightly differently from the ones in the base. The exception cleanup made IO exceptions and other exceptions behave consistently and got rid of the conflicting definitions. This did require source changes, as anyone relying on the Prelude exceptions had to add an import of Control.Exception and anyone using old-style exceptions generally had to add a type annotation to their handler; more ideally, they'd rewrite their exception code to handle specific exceptions or exception classes instead of poking at the exception object to determine whether it was one they cared about or not --- but this was not necessary to get older code running again, only the added type annotation was necessary. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Adrian May wrote:

I really don't know why somebody can't make a simple and well intentioned point without getting attacked by people who feel threatened over every little thing.

It's because we're failing to see the problem. I mean, if you can pinpoint the source of your problems we could work on a solution, and we would be happy to do that. However, it is important to keep in mind that Haskell is very active and things change a lot. This is not a problem, it's the mindset of this community. If you are turning it into a problem, feel free, but then the only suggestion I can make here is that Haskell is probably not the right choice for your particular development strategy. In other words, for Haskell it's simply wrong to assume that you can use legacy code that hasn't been maintained for many years. Regardless of whether you like it, this is the way to go. If you want to use Haskell, be prepared to maintain your code. This usually boils down to making small adjustments. When the big breaking change in the base library came I had to adjust a number of type signatures in my projects and I was done. These adjustments become necessary from time to time, and you should be ready to perform them.

I said from the start that I think Haskell is cool.

Unfortunately that doesn't really help. What you are trying to achieve is a shift in our fundamental philosophy, which is very unlikely to happen, even if the shift is small. Using Haskell is great, but does require you to keep up to date. The other option is to go with old compiler and library versions. They are all available, if you need them for your project, but this is a bad solution.

I'd just like it to pay a bit more attention to practical issues whilst making progress with its theoretical ones.

It's very difficult to combine those. Communities solve these problems differently. Most communities try to keep compatible at the expense of eliminating much of the potential for innovation. The Haskell community prefers to go the innovation route and is prepared to repair occasional breakages. They do occur, and we fix them.

Why don't you just put it in the forum rules that nobody is ever allowed to criticise anything?

Because that's wrong. I criticize things a lot, sometimes with a much stronger tone than you did. =)

At the end of the day, I'm just a typical manager who's atypical in wishing he could tell his programmers to study a bit of Haskell without making it a synch for the manager next door to knife him in the back for suggesting something that looks this unstable. This is the real deal on how Haskell looks out there in the mass market. You can lead a horse to water...

If it's your decision, you shouldn't be afraid to make it. You are the manager of your team! Don't let yourself be stabbed by another manager. Recognize that your choice can lead to higher productivity, if you don't let yourself be distracted by this pointless matter. And yes, it is pointless. If you simply move on and get to productive Haskell work, you will find that this is a non-issue. In particular, you want to make educated decisions, which means that you should probably research the current standards in the Haskell community. If you would have performed that research from the beginning, you would have come to the conclusion that WASH was a bad choice to begin with, which leads me to another very important point: I have worked in many SCRUM-based teams. While I could question the general usefulness of this paradigm, I have to say that it has taught me a number of very important things, and one thing in particular: Programmer choices should be made by programmers. You shouldn't have made the decision about the web framework in the first place. Get a team of Haskell programmers and let them choose the best tool for the job. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

On 05/03/2013 06:44 PM, Niklas Hambüchen wrote:

While I certainly enjoy the discussion, how about addressing one of the original problems:

On 02/05/13 13:27, Adrian May wrote:

...

I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change.

I just fixed that in https://github.com/nh2/flippi (note that I have never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313...

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

+1

On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:

On 3 May 2013 09:44, Niklas Hambüchen wrote:

...

While I certainly enjoy the discussion, how about addressing one of the original problems:

On 02/05/13 13:27, Adrian May wrote:

...

I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change.

I just fixed that in https://github.com/nh2/flippi (note that I have never seen this code before nor even known about it).

https://github.com/nh2/flippi/commit/5e2fa93f82b4123d0d5b486209c3b722c4c1313...

Had to delete 5 imports and convert one time value.

Took me around 3 minutes.

It seems fair to say that Haskell's designers lean more to evolution than maintaining backward compatibility. This reminds me of "Go" (the programming language). The approach chosen by Go's designers was to create a tool (gofix) that would automatically fix one's code to comply with the latest standard. See [http://talks.golang.org/2012/splash.article#TOC_17.] (yes, include that last period).

Given the apparent simplicity of the changes needed to keep one's Haskell code up to snuff and the strong typing inherent in Haskell code, would it not be possible to create something similar? If there is a tool that moves (most of) one's code from Haskell version n to n+1 then making breaking changes would be even less of an issue.

Just an idea, I have no clue about its feasibility...

I mentioned the same on #haskell today. Something like Coccinelle (http://coccinelle.lip6.fr) "semantic patches" could be really useful to automate (some) API & language changes. Somewhat like (but better than) the Python '2to3' tool. I think some message about a GSoC project regarding an AST-based refactoring tool was posted to this list. That might be a useful building block for such tool? Imagine one day whenever a new HP release is made, GitHub pull-requests are created automatically based on a automatically-generated patch verified through a compilation&test-cycle on TravisCI for GH-hosted packages published on Hackage. Nicolas

I think you missed my point. My point was to show that what you understand as "backward compatibility" here is totally delivered by Haskell and its environment, and how easy it is to be "conservative" (where "keeping it running" as it is is only a matter of renaming a few imports).

it seems important to fix that stuff

It is not. I did not "fix" Flippi nor WASH; it is the same unmaintained code that you should not use. If there's a security hole or it just doesn't work, nobody will fix it, nobody will even mention it or care, because it is clear that this is code from the past.

it's a liability to Haskell to have broken code kicking around where people might find it.

There really is no reason to delete open-source code.

and there's nothing on the WASH page to warn anybody.

The fact that it doesn't build and that the last change is from 2007 the *is* the warning that it is completely unmaintained and not the way to do things today. (One could even say that by making it build on 7.6, I have removed this warning and given the illusion that everything is fine.) Of course I agree that it would be better if there were warnings on their web sites that said "sorry guys, this project is dead now". I would even be happy with newhackage sending every package maintainer a quarterly question "Would you still call your project X 'maintained'?" for each package they maintain; Hackage could really give us better indications concerning this. Still I'd say that in this case, the fact that it did not build, hasn't had a single change in the last half decade, and that you cannot find any recent discussion about it anywhere on the Internet, make it pretty clear what is going on here, even for non-technical people.

Please don't say that it's my culture's fault.

From your story it sounds like you have a problem with developer simplemindedness and management wars idiocy.

I believe you that that's how it goes in many large organizations. Nobody is forcing you to be part of that. There are a lot of places that would care about you trying to get software development right (it sounds like you do) and, surprise, the chances that they use something like Haskell are much higher. Not because they like research platforms, but because it's one of the reasons for their success. On 04/05/13 16:06, Adrian May wrote:

Even though I've been advised against WASH already, it seems important to fix that stuff because it's a liability to Haskell to have broken code kicking around where people might find it. I found flippi just by googling for "haskell wiki engine", in fact I think I was pointed there by wikipedia, and there's nothing on the WASH page to warn anybody. So it's great that Niklas fixed it, thereby preventing impressionable people from having a Rails-day like I did.

But is it correct to extrapolate from the fact that people like you can fix it in 5 and 75 minutes, that everybody else can and that's how industry should calculate its maintenance costs? You guys all know a hell of a lot more about Haskell than I do, but I've been playing with it for a few years now, and I never met anybody independently of Haskell who had even heard of it.

On 3 May 2013 16:44, Ertugrul Söylemez mailto:es@ertes.de> wrote:

If it's your decision, you shouldn't be afraid to make it. You are the manager of your team! Don't let yourself be stabbed by another manager. Recognize that your choice can lead to higher productivity

Middle management in big companies isn't really about minimising maintenance costs, or even getting anything done. It's about building yourself a botnet of colleagues you can trigger to DDoS one another. You don't need much of a trigger: it's the timing that counts: every bot has to perceive the attack to be already underway and successful by the time you trigger them. Then they'll be grateful that you pointed out something they hadn't noticed before, after all, they wouldn't want to screw up with any other bot. The main reason you'd want to DDoS somebody at all is so that all your bots know the network is operational and that they're safer on the inside. That's why most managers spend more time trying to sabotage one another's projects than doing anything useful themselves, and why the most useless of them always wind up at the top.

It's in that context that I'd like you to try and imagine why my priorities might be different from yours. Please don't say that it's my culture's fault. That would be true, but it wouldn't be helpful because if nothing improved in the last 3000 years it probably won't in the next 3000 either.

Whether a manager wants to behave in this Machiavellian way or not, he'd better assume that he's surrounded by botnets that want him on the inside. If he has any aspirations to keep both his job and a modicum of autonomy, he wouldn't want to give them a trigger on a plate. Backward compatibility is a very potent trigger because everybody knows what it means, and it would be potty to imagine you could convert somebody else's botnet into mutinying against the controller with the notion that backward compatibility doesn't matter. Referential transparency is not a very good defence because nobody knows what you're talking about.

Take a guess how fast I can hire programmers here in Taiwan: about once every 3 months. I turn down 90% of applicants cos I know they'd waste more of my time than they save. I'm talking about the kind of people who can spend a whole week wondering why the bug never changes before I come along and ask them if they're even editing the right file. It's not obvious to people in my position why writing a coding standard that says "nobody is allowed to write anything that a monkey wouldn't understand" is a bad idea.

Hopefully I've now shown that I must be nuts to be interested in Haskell at all. So why am I? Well I described my OP as a lullaby, not a rant. If you want to hear a rant, ask me what I think of imperative programming. Last time I saw an 8 million line project land in the bin, I could have said that I'd told them so 2 years earlier, but instead, I actually shed tears for all the developers who'd been stuck in that office til 11 every night, chasing bugs around in circles that could never be fixed. For the guy who was publicly humiliated for giving a presentation about how to track a bug down through all that spaghetti and then fix it by wrapping "if (p!=NULL)" around the crash instead of wondering what was null or why, when in all fairness, that was the only thing any of them ever did. For that whole quirky culture that refers to bugs by a six-digit ID beginning with 3, and that doesn't lose it's cool even after two months unable to even build the thing, followed by another two when it can't make it to the idle screen without crashing. Of course I knew it would be pointless to ask those self-satisfied architects if they'd finally figured out that it wasn't smart to riddle the build system with cyclic dependencies so the testers didn't even know what they were testing, or to chop the whole thing into a guzzillion separate pseudo-processes so every debugger would spend 90% of his time trying to single-step over those asynchronous interfaces. Did they fail? I'm afraid not. The controllers just rounded up their best bots, found another venture capitalist and proudly boasted about how they'd turned 2 million lines into 8 in only two years. How would the VC know to ask why they needed all those lines if no new features were coming out?

You thought I was pissed off with Haskell? Oh no. That's not what I'm pissed off about.

But I'm still not crazy enough to start a project at work in Haskell: what I'm debating is whether or not to give people a few presentations and a few hours in the week to study your language in the hope that it will improve their imperative code, plant a seed of suspicion that OO might not be the last word, nurture a healthy fear of data, and perhaps one day take over Haskell stuff that I might foolishly dare to write for the company. This language has got an important message for the world, and the reason I'm trying to tell you guys this stuff is that I want it to get through.

Once they sent a security consultant to lecture us about how to avoid writing vulnerabilities through which people could jailbreak their phones from the network. Towards the end of the day when he'd explained how buffer overflows work, he dropped "using a language other than C/C++" into his list of possible remedies. The whole room was immediately filled with uproarious laughter. I have to go at this gently and ensure that the carrot looks bigger than the stick at all times. And I can't make myself vulnerable to easy pot-shots about backward compatibility or anything else.

So what would their first impression be? They'd be dazzled but scared. ***Please bear in mind that if I scare a report by making him feel that his job security depends on him learning something new or taking more responsibility, then he's liable to throw a tantrum and plot against me in self defence.*** If most of his colleagues also think I'm crazy to be going on about this offbeat language, then I'm toast. At the beginning they'll spend a lot of time feeling humiliated by it always saying No, and there'll be a strong tendency for them to say:

"It's not my fault: none of the examples on the web work either, and not even Adrian can make them work."

At that point I look like an idiot and Haskell at that company will be caught in the crossfire of my assassination. That's why breaking old code is best avoided (as long as it doesn't conflict with progress) especially in a world where lots of unmaintained stuff is still on the web.

That's why I'm very grateful to Niklas for fixing that prehistoric code. And why I think it's better only to deprecate things if you really need to. Does that make me ultra-conservative? Where I work, conservative is when you're still worried about how long it takes to dereference a virtual.

Do you finally see where I'm coming from? If you want this language to catch on, you have to think about programming the people, not just the computers. You could also just soldier on as a brilliant microculture until you get swamped by something like F# that's not even where you were in 98, and one day people will tell you "Haskell? Monads? That's not what I mean by FP. FP is something like F#." (Apologies to anybody who works on F#: my issue with it is that nobody I know is likely to figure out the functional way to do something if it's that easy for them to bottle out and do it the imperative way.)

Maybe that is the new plan. Maybe Haskell already gave up wanting to be anything but a research platform. Maybe you guys calculate that if I really want to push FP I should be pushing some hybrid like F# or Ocaml. Remember how C++ succeeded where Smalltalk failed because it sneaked the changes under the table instead of calling for revolution. If that is the plan then I'd appreciate somebody putting me in the picture. Otherwise, please try to understand that the problems I'm up against are not about whether Num is derived from Eq or whatever.

mfG, Adrian.

On 4 May 2013 02:33, Niklas Hambüchen mailto:mail@nh2.me> wrote:

All right, here you go: https://github.com/nh2/WashNGo

https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc...

Took me around 75 minutes.

Think about it a bit:

I just ported thirty thousand lines of code that I have never seen before and that has bit-rotted for over six years to the latest programming environment.

It being Haskell, I am pretty confident it does *exactly* what it's supposed to do.

I want to see anyone do that with an equivalently sized + outdated Ruby / Python project.

On 02/05/13 13:27, Adrian May wrote: > I just tried to use Flippi. It broke because of the syntax change so I > tried WASH. I couldn't even install it because of the syntax change. I > persisted for a while but gave up because getPackageId doesn't exist in > any form at all anymore. This was only the install script: what would > WASH itself have in store for me to get my brain around?

What pray tell are those missing pieces? Aren't they mostly building a browser based ide plus doing training courses ? On May 4, 2013 1:42 PM, "Ben Doyle" wrote:

You might want to check out FPCompletehttps://www.fpcomplete.com/page/about-us, if you haven't already. They're far more focused on making it easy for organizations to adopt Haskell than the community can be. As they say: "Where the open-source process is not sufficient to meet commercial adoption needs, we provide the missing pieces."

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe