<div dir="ltr">So WASH is ancient history. OK, lets forget it.<div><br></div><div style>How about the Haskell Platform? Is that ancient history? Certainly not: it doesn&#39;t compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that&#39;s rapid maintenance, but it&#39;s still version hell because you&#39;ve got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven&#39;t. You&#39;ve probably got the one from the linux package which hasn&#39;t been maintained since, ooh, must have been at least a week ago, so you install the new one and you&#39;ve trashed cabal. How long is that puzzle gonna take to unravel? That&#39;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&#39;s not Haskell&#39;s fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it&#39;s better not to keep moving the furniture around. </div>
<div style><br></div><div style>Why was I trying to build the Haskell Platform at all? Because it wasn&#39;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&#39;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.</div>
<div style><br></div><div style>Adrian.</div><div style> </div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 2 May 2013 19:57, Ertugrul Söylemez <span dir="ltr">&lt;<a href="mailto:es@ertes.de" target="_blank">es@ertes.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">John Lato &lt;<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>&gt; wrote:<br>
<br>
&gt; I don&#39;t think there&#39;s anything wrong with moving at a fast pace, nor<br>
&gt; do I think backwards compatibility should be maintained in perpetuity.<br>
<br>
</div>I think this statement pretty much covers the mindset of the Haskell<br>
community and also explains the higher breakage rate of Haskell packages<br>
when compared to other languages, in particular non-static ones:  We<br>
move at a very fast pace.  Innovations are made all the time.  Without<br>
this feature we wouldn&#39;t be where we are today.<br>
<br>
Of course Haskell, being a rigorously static and correct language and a<br>
community that equally rigorously insists on correctness of design<br>
patterns we have to live with the fact that we need to fix the breakages<br>
we introduce, and we do that.  This is a good thing.<br>
<div class="im"><br>
<br>
&gt; Unfortunately this leaves a lot of scope for migrations to be handled<br>
&gt; poorly, and for unintended consequences of shiny new systems.  IMHO<br>
&gt; both have caused issues for Haskell developers and users in the recent<br>
&gt; and more distant past.  This is an issue where I think the community<br>
&gt; should continually try to improve, and if a user calls out a<br>
&gt; difficulty we should at least try to learn from it and not repeat the<br>
&gt; same mistake.<br>
<br>
</div>I think we do that.  The most severe breakages are introduced by new GHC<br>
versions.  That&#39;s why there is the Haskell Platform.  If users decide to<br>
move to new versions sooner they should be prepared to handle the<br>
breakages.  In particular a Haskell beginner simply shouldn&#39;t use<br>
GHC-HEAD.  Our type system makes us aware of the breakages we introduce<br>
and gives us the opportunity to fix them properly before exposing them<br>
to the users.<br>
<br>
With this in mind I don&#39;t think there is anything to learn from this<br>
particular case.  You wouldn&#39;t use WASH today for the same reasons you<br>
wouldn&#39;t use Linux 0.x.  It&#39;s a legacy, and the ideas from it have<br>
inspired the more recent web frameworks, which are more convenient,<br>
faster, more real-world-oriented.  In fact I totally expect a new<br>
generation of web frameworks to pop up in the future, more categorical,<br>
even more convenient and less error-prone.<br>
<br>
<br>
Greets,<br>
Ertugrul<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Key-ID: E5DD8D11 &quot;Ertugrul Soeylemez &lt;<a href="mailto:es@ertes.de">es@ertes.de</a>&gt;&quot;<br>
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11<br>
Keysrv: hkp://<a href="http://subkeys.pgp.net/" target="_blank">subkeys.pgp.net/</a><br>
</font></span><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>