On 2 May 2013 14:33, Adrian May <adrian.alexander....@gmail.com> wrote:

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

There are 2 extremes: 1). [enterprise extream] do thing once - let it work
forever without changes, 2). [developer extreme] - change your applications
in a continuous way. Both extremes are not right: first hides a problem,
and when a problem got revealed everything is so terribly broken that you
need to start from the begining, second extreme require work on things as
soon as environment changes (dependencies updates, libraries changes, bugs
revealed and fixed). The correct way is scheduled upgrade and Haskell in
very close to it. If you see a bug or missfieature or improvement, and it's
better - deprecate old, and do changes, then give a time gap for others to
fix. That is a really good way, if you have to do changes it means that
smth have not done right. As for WASH it has extremely long gap to be
fixed, and it simply should be fixed without any philosophical letters to

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.

At least in Gentoo you can just use a wrapper for haskell packages there
are ~600-700 pkgs like in debian but with difference that they can be built
on ghc-6.1(not everytime), 7.4, 7.6, and some on HEAD, and we use frontline
versions (latest available+some more for quickly changing packages) is
used. All packages are patched accordingly if compatibility between them is
broken and we tries to send patches upstream.

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.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Haskell-Cafe mailing list

Reply via email to