Backward compatibility

Please don't interpret this as a rant: I'm just feeling a bit disappointed about probably having to give up on Haskell.

Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails.

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 are my choices here:

1) Revert to GHC6 or put pragmas and compiler switches everywhere, switch 2010 off globally with cabal or even make an alias of ghc: That means I'll gradually clash with people who decide ...

2) Convert all my code and a lot of other peoples' to the new syntax, thereby exacerbating the problem that ruled out 1.

Either way, we're looking at a long period during which a large portion of the libraries will be incompatible with the other portion, and nobody will know which style to write. I don't know if or when WASH or any other library will convert, or even if I'd prefer that to happen sooner or later, because that would depend on when other libraries do and how I'd worked around it in the meantime. Altogether that means I can't sensibly decide to rely on any library, so I can't use Haskell. I'll just have to go back to fumbling around in XSL, PHP and the like. Is Haskell 2010 really so much better that it justifies this?

I just saw that movie "The Words": the moral of the story is that you shouldn't try to change your mistakes.

...

Apparently it's not only 2010. I now find that buildng the Haskell Platform wants GHC 7.4.2, not 7.4.1 because of the line "import Prelude" (if I remember rightly,) and even when I follow the rules precisely I still get several different deprecation warnings. The prelude is not exactly obscure. If you deprecate that you've broken everything. Is it really impossible to keep such a basic mantra meaningful from one minor version to the next? Java was fond of deprecating things in the early days, but when they said "deprecated" they didn't mean "switched off", let alone that it would lead to a syntax error. They just meant "not trendy anymore."

It's a very common illusion to believe that the central thing in your life is also the central thing in everybody else's. That's why things like Norton take over your whole machine: those guys believe that the only reason you bought the computer was to fight viruses, because that's what most of the machines in their office were bought for.

There seems to be something similar going on in the way Haskellers are expected to update all their code whenever GHC decide to issue an update. But in reality we have jobs of our own. I'd like to choose Haskell over XSL because I think it'll enable me to write web sites more efficiently, not because I want to forget all about my job and savour the brilliance of the latest Haskell version. But in reality I'm just sitting here waiting for the Platform to compile just in case it's the Ubuntu package's fault, but I know it won't help. I'll just get other problems instead. Reality is that the whole ecosytem is in disarray because of this lack of respect for backward compatibility. At least Rails can plead that it's relatively new, but Haskell has been around for over 20 years.

I understand that progress has to be made, and it would be nice if people did just update all their code quickly so you could switch off old stuff and move on. But it's not hard to survey the code that's out there and see how much stuff you'd be breaking if you did. If it's not a lot, then switching it off to wake them up would be an acceptable compromise. But it looks to me as if a lot of very important stuff is still failing on the GHC from November 2010, so clearly things are going too fast. Adding new stuff is great, and sometimes the new stuff clashes with the old stuff. But how much of that deprecated stuff really *needed* to be switched off, and couldn't the new stuff have been designed so as not to force that?

In principle this is the best language on the planet, but with all these version gotchas I don't know that I can use it anymore. What a tragedy. I can't even think of a suggestion as to how Haskell should try to get out of this mess now.

Re: Backward compatibility

Byron Hale <byron.hale <at> einfo.com>
2013-05-02 07:26:39 GMT

Hello, everyone,

I was just in the process of trying to get Haskell 7.6 installed.
First I surveyed all the current OSes that seemed to support it.
FreeBSD 9.1 seemed like a good candidate. However, FreeBSD 9.1
has many practical problems of its own. So far, I have 7.4
installed, but not 7.6. Would the MAC be better at this?
Anyway, it seems that much of Hackage will not be usable.
Perhaps I should just run it on Windows, as it seems likely to
install there and much of Hackage already didn't work there.

I welcome any constructive suggestions.

Best Regards,

Byron Hale

On 5/1/2013 10:27 PM, Adrian May wrote:

Hi All,

Please don't interpret this as a rant: I'm just feeling a
bit disappointed about probably having to give up on Haskell.

Let's face it: this decision to change the default syntax
in GHC7 means that right now Haskell looks about as stable as
Ruby on Rails.

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 are my choices here:

1) Revert to GHC6 or put pragmas and compiler switches
everywhere, switch 2010 off globally with cabal or even make
an alias of ghc: That means I'll gradually clash with people
who decide ...

2) Convert all my code and a lot of other peoples' to the
new syntax, thereby exacerbating the problem that ruled out 1.

Either way, we're looking at a long period during which a
large portion of the libraries will be incompatible with the
other portion, and nobody will know which style to write. I
don't know if or when WASH or any other library will convert,
or even if I'd prefer that to happen sooner or later, because
that would depend on when other libraries do and how I'd
worked around it in the meantime. Altogether that means I
can't sensibly decide to rely on any library, so I can't use
Haskell. I'll just have to go back to fumbling around in XSL,
PHP and the like. Is Haskell 2010 really so much better that
it justifies this?

I just saw that movie "The Words": the moral of the story
is that you shouldn't try to change your mistakes.

...

Apparently it's not only 2010. I now find that buildng the
Haskell Platform wants GHC 7.4.2, not 7.4.1 because of the
line "import Prelude" (if I remember rightly,) and even when I
follow the rules precisely I still get several different
deprecation warnings. The prelude is not exactly obscure. If
you deprecate that you've broken everything. Is it really
impossible to keep such a basic mantra meaningful from one
minor version to the next? Java was fond of deprecating things
in the early days, but when they said "deprecated" they didn't
mean "switched off", let alone that it would lead to a syntax
error. They just meant "not trendy anymore."

It's a very common illusion to believe that the central
thing in your life is also the central thing in everybody
else's. That's why things like Norton take over your whole
machine: those guys believe that the only reason you bought
the computer was to fight viruses, because that's what most of
the machines in their office were bought for.

There seems to be something similar going on in the way
Haskellers are expected to update all their code whenever GHC
decide to issue an update. But in reality we have jobs of our
own. I'd like to choose Haskell over XSL because I think it'll
enable me to write web sites more efficiently, not because I
want to forget all about my job and savour the brilliance of
the latest Haskell version. But in reality I'm just sitting
here waiting for the Platform to compile just in case it's the
Ubuntu package's fault, but I know it won't help. I'll just
get other problems instead. Reality is that the whole ecosytem
is in disarray because of this lack of respect for backward
compatibility. At least Rails can plead that it's relatively
new, but Haskell has been around for over 20 years.

I understand that progress has to be made, and it would
be nice if people did just update all their code quickly so
you could switch off old stuff and move on. But it's not
hard to survey the code that's out there and see how much
stuff you'd be breaking if you did. If it's not a lot, then
switching it off to wake them up would be an acceptable
compromise. But it looks to me as if a lot of very important
stuff is still failing on the GHC from November 2010, so
clearly things are going too fast. Adding new stuff is
great, and sometimes the new stuff clashes with the old
stuff. But how much of that deprecated stuff really *needed*
to be switched off, and couldn't the new stuff have been
designed so as not to force that?

In principle this is the best language on the planet, but
with all these version gotchas I don't know that I can use it
anymore. What a tragedy. I can't even think of a suggestion as
to how Haskell should try to get out of this mess now.

Re: Backward compatibility

Byron Hale <byron.hale <at> einfo.com> writes:
> I was just in the process of trying to get Haskell 7.6 installed.
You cannot "install Haskell 7.6". Haskell is a language.
You can install a language implementation (compiler/interpreter).
There may be several. You can also install a set of libraries.
These may be bundled (one compiler with one set of libraries).
One such bundle is called "the Haskell platform".
Is this what you are trying to install? (But then the version is nothing
like 7.6, this looks more like a compiler version.)
Of course this naming error is directly suggested by haskell.org, where
we have the equally meaningless "Download Haskell" right on the front page.
- J.W.

Re: Backward compatibility

Adrian May <adrian.alexander.may <at> gmail.com> writes:
> this decision to change the default syntax in GHC7
what decision? what syntax? here's the release notes (7 vs. 6)
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html
I guess you are referring to hierarchical module names?
(import List => import Data.List)
Indeed, I cannot build
WASH http://hackage.haskell.org/package/WashNGo-2.12.0.1
on ghc-7.6.3, and I don't see how it could have worked on 7.0,
as hackage claims it did.
(building the executables:
when using base and haskell89, "import Prelude" is ambiguous;
when using haskell98 only, modules like System.Exit are not available.)
I think this could be fixed in a straightforward way,
but that "fixing it" is necessary at all, just proves your point.
- J.W.

Re: Backward compatibility

Ertugrul Söylemez <es <at> ertes.de>
2013-05-02 09:30:12 GMT

Adrian May <adrian.alexander.may <at> gmail.com> wrote:
> Please don't interpret this as a rant: I'm just feeling a bit
> disappointed about probably having to give up on Haskell.
>
> [rant that update broke stuff]
Well, it is a rant, so you can just as well concede it. =)
The Haskell community and its descendants (Agda, Disciple, Idris, ...)
differ from all other developer communities I know in one point: We
don't fear change. There is a reason why other communities do:
Non-downward-compatible changes will break stuff. We are aware of that.
Occasionally things will break, when they worked perfectly before an
update. Does that mean that Haskell sucks? Not really. It means that
some library developers will have to get rid of their old bad habits.
This is unlikely to happen for unmaintained projects like WASH. So the
question you should be asking yourself is: Do you really want to use
WASH? I'm surprised that you could build it with any GHC 7.x at all.
If you don't like this experimentalism and the rigor with which we get
rid of old problems (which isn't even that rigorous -- Functor and Monad
are still independent classes even today), then Haskell may indeed be
the wrong choice for you. However, you should always ask yourself: Who
is the one with bad habits?
Consider PHP: It was broken since the beginning and is still broken
today. The developers carefully make sure that it stays broken, because
fixing it would break applications. They don't want them to break.
That means that you can rely on all of your old bad habits, keep your
SQL injection vulnerabilities, your broken program logic, etc. Is this
good or bad?
Consider Debian, the PHP of Linux distributions: Their philosophy is
never to touch a running system, so instead of employing architectural
changes they keep the old code bases as long as possible and follow a
rigorous backporting policy. They don't want you to have to rewrite
your configuration files or update your shell scripts or whatever
at-most-five-minutes steps would usually be necessary after an update.
It should Just Work. Is this good or bad?
To express this question in a broader context: Are you leaving a broken
tool and replacing it with a new shiny one? Or are you really just
replacing a small problem by a big one? Haskell's change policy is a
small problem that prevents you from big problems. PHP is a big problem
all by itself. Do you really want to leave this wonderful realm just
because of one setback? Keep in mind that this setback is an integral
part of why Haskell shines where PHP sucks.
Think about it. ;)
> In principle this is the best language on the planet, but with all
> these version gotchas I don't know that I can use it anymore. What a
> tragedy. I can't even think of a suggestion as to how Haskell should
> try to get out of this mess now.
We all have to deal with these gotchas. However, I'm still much more
productive with Haskell than with any other language. When I go to a
new GHC major version I always expect some old packages to fail, and I'm
often surprised by the small number of packages that actually do.
So my closing comment is: Haskell is one of the best languages, but
that greatness comes at a price. Deal with it. Going back to PHP is
not the answer.
Instead you should recognize that now is the time to look into one of
the big three web frameworks of today: Happstack, Snap and Yesod. The
tool that is broken and needs to be replaced is WASH, not Haskell.
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.

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.

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

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.

Re: Backward compatibility

Ertugrul Söylemez <es <at> ertes.de>
2013-05-02 11:29:59 GMT

Adrian May <adrian.alexander.may <at> gmail.com> 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.

Re: Backward compatibility

To express this question in a broader context: Are you leaving a broken
tool and replacing it with a new shiny one?

So I read the original post, and it really wasn't clear to me what exact changes were causing the issues; I don't think I'm alone in thinking the OP could have been a bit more explicit about the nature of the problem. Also, at least Flippa is explicitly unmaintained (according to the first hit googling "Flippa Haskell"), and I hadn't seen mention of WASH for a year or more. And of course, ghc-7.0 was released 2.5 years ago, ghc-7.6 is the current version, and there's been ample time for incompatibilities to accumulate.

Despite those issues I'm rather sympathetic to the OP, in part because most of these "breaking changes" aren't replacing a broken tool. If the Functor/Applicative/Monad hierarchy were fixed it would cause a lot of breakage, and I (like many of us I'm sure) would have to update a lot of packages, but I wouldn't mind because that would be a clear improvement. But replacing "import List" with "import Data.List"? That's not even a problem. Consider another breaking change, requiring newtype constructors be in scope for foreign imports. This required a lot of code churn, especially as IIRC the CDouble constructor wasn't exported previously (for reasons of "abstraction", which I can also rant about), so of course it wouldn't have been in explicit import lists. At least this has some marginal utility if you care about Safe Haskell.

I did a lot of work to get packages compilable with ghc-7.6 and submitted patches to probably a dozen different repos. Aside from one exception (related to the FFI), every breaking change was either related to namespacing/import issues, or bumping versions in .cabal files (I consider the whole try/catch mess to be an import issue, although at least in that case the benefit is more obvious). Two pragmas existed that duplicate functionality, one was deprecated in the last release and now the other one is deprecated while the first has been un-deprecated. It's just rearranging deck chairs. It doesn't feel like a significant improvement, and it's even harder to bill as one.

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

(Unfortunately I'm not really sure what we can learn from this particular case, but maybe somebody wiser than me could point the way)

Re: Backward compatibility

Ertugrul Söylemez <es <at> ertes.de>
2013-05-02 11:57:01 GMT

John Lato <jwlato <at> gmail.com> 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 <es <at> ertes.de>"
FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/

Re: Backward compatibility

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.

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

Re: Backward compatibility

David Thomas <davidleothomas <at> gmail.com>
2013-05-02 13:39:09 GMT

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.

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.

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

Re: Backward compatibility

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.

Not necessarily. Let's take Flippi as an example. What seems to be happening there is that Text.Html is incompatible with CGI.Html, or something like that. Those are both vanilla modules that would not be under my control. If somebody else decides to make them incompatible, there's nothing I can do. Not without a total rewrite, but by then I might have 20 man-years invested in it. Nobody is gonna do a big project in a language with this attitude.

What if Android were written in Haskell for instance. At the famous 10:1 ratio there'd be roughly 5 million lines of it. "Nice update guys - we only had to rewrite 100,000 lines this time." Then you'd be afraid of change cos it would be your own phone you were breaking.

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.

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.

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

Re: Backward compatibility

On Thu, May 02, 2013 at 09:26:15PM +0800, 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. Not 7.4.1 but 7.4.2.
I'm uninformed in such matters, but from
http://www.haskell.org/platform/changelog.html
it looks like GHC 7.4.2 is *part* of Haskell Platform 2012.4.0.0, so it
doesn't make sense to talk about the latest Platform without 7.4.2.
I know that sounds like a technicality, but I don't think it actually is!
The important question is whether *your* old code breaks with the latest
Platform, not whether the latest Platform breaks with GHC 7.4.1.
Tom

Re: Backward compatibility

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

Re: Backward compatibility

I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the platform. As I say, the reason I was trying to build it was that I wrongly blamed the ubuntu package for WASH not working. But that was not dumb unless you consider it obvious that 7 year old code would be broken, in which case it would be obvious that nobody would trust this language in production.

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

Yeah but how many minor changes? This trigger-happiness is rife.

And that's the first time anybody suggested the necessary changes to WASH should be minor. Everybody else thinks I was nuts to expect anything from 7 year old code. I don't know because I couldn't get past the install. Somebody had deleted getPackageId.

Please would somebody explain to me what getPackageId did to incriminate itself? I'm sure there's something much groovier now, like getting it inside a monad in case it changes during the installation itself (pretty likely AFAICT) but it's really just a package id. Can we honestly philosophise about the mathematical rigour of getPackageId?

It was needlessly assassinated. For all I know WASH might be just fine apart from that, and maybe I would have liked it, even if it is from the dark ages.

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.

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

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

Re: Backward compatibility

On 3 May 2013 01:04, Brandon Allbery <allbery.b <at> gmail.com> wrote:
> On Thu, May 2, 2013 at 10:36 AM, Adrian May <adrian.alexander.may <at> gmail.com>
> 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.
Or you have a source-based distro, or you prefer building it yourself
rather than using distro packages (as they might be out of date or
b0rked), etc. ... --
--
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com

Re: Backward compatibility

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.

Re: Backward compatibility

On Thu, May 02, 2013 at 10:36:18PM +0800, Adrian May wrote:
> Please would somebody explain to me what getPackageId did to incriminate
> itself?
What's getPackageId? It does not appear in the WASH source.
Tom

Re: Backward compatibility

Ertugrul Söylemez <es <at> ertes.de>
2013-05-02 15:51:09 GMT

Adrian May <adrian.alexander.may <at> gmail.com> wrote:
> I attached the tarball. Don't say you got it from me, OK.
That's a weird thing to demand in a public mailing list with public
search-engine-locatable archives. =)
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.

Re: Backward compatibility

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

Re: Backward compatibility

<at> Adrian May if you want that much backward compatibility you probably need to move to an operating system that suports it.

NixOS, already mentioned by another commentator, would be my recommendation if you really need the backward compatibility I just finished compiling both Flippi and WashNGo with ghc-7.0.4.

I do not want the GHC maintainers to be tied down by maintenance concerns any more then they already are, there time is more productively spent on concerns other then increasing backward compatibility.

For anyone who works on GHC thank you for helping support such a great ecosystem that enables this level of experimentation and rate of new features.

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

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.

GHC is up to 7.6.

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?

Re: Backward compatibility

Alexander Solla <alex.solla <at> gmail.com>
2013-05-03 02:28:52 GMT

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?

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.

Re: Backward compatibility

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

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

I'm also a big fan of the error messages, but it's nice to know if I caused them or somebody else did.

Re: Backward compatibility

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.

Re: Backward compatibility

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.

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

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. 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. One of the ways I keep codebases alive is by telling people not to assume that somebody else is following the instructions in their heads. If anybody in my team wants to assume anything about the versions of anything they interact with, they'll need a very good argument as to why they can't make their bit more flexible. But I never had to be scared of upgrading any compiler, except python that is.

Is anybody in the Haskell community still interested in attracting new users? If so I suggest you go play with Ruby on Rails. Then you'll know what it's like to approach a complex and unfamiliar system where every crumb requires a precise version of every other. If you had my job, you'd find out what you needed to know within half an hour.

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?

I think we all know that package management is tricky and ubuntu are struggling, but that would be another topic.

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.

Well now you're just playing with words. I've already explained how it happened.

Re: Backward compatibility

Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails.

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?

I'm going to give you the flip side of this one.

I've been active in the Perl community (admittedly in something of an off and on fashion for health reasons) for years. Perl 5 is in some ways the epitome of "maintain backward compatibility": there is a lot of Perl code out there that was written under Perl 4 or earlier. (cpanel, I'm looking at you. Among others. I recently got to debug some code related to someone's RADIUS server that looked like it hadn't been touched since perl3.)

And this is the direct cause of the Perl ecosystem being a sewer. Nobody is willing to take the step of making Perl default to the eminently sane behavior of checking for invalid inputs, because it will "break" too much existing (already horribly broken, in reality) code. Nobody will risk disabling the walking security hole and encouragement of sloppy, buggy code that is Perl's 2-argument open(). (If you ever wondered why Perl 6 decided to throw out source compatibility, here's your reason.)

The Haskell98 ecosystem wasn't nearly that bad, but maintaining compatibility with it did prevent fixing various flaws in things like exception handling. Between the two, I'd rather see older code broken in the name of current code actually working correctly. And in Haskell I get a lot of help from the compiler to bring that older code up to date.

Re: Backward compatibility

Hi Adrian
I don't want to argue against your rant for the sake of it, but
Haskell is a fairly conservative language. The Glasgow Haskell
Compiler supports it's own dialect "Glasgow Haskell" which is fast
moving, but the developers of GHC do work hard to maintain
compatibility with standard Haskell 98 and Haskell 2010 (optionally
enabled with compiler flags). Afterall Haskell now is fairly widely
used as a teaching language which befits stability as course
textbooks, lecture plans etc. can't be in hock to a language that
changes every year.
Best wishes
Stephen

Re: Backward compatibility

Niklas Hambüchen <mail <at> nh2.me>
2013-05-03 16:44:34 GMT

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/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
Had to delete 5 imports and convert one time value.
Took me around 3 minutes.

Re: Backward compatibility

Bardur Arantsson <spam <at> scientician.net>
2013-05-03 17:12:24 GMT

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/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
>
> Had to delete 5 imports and convert one time value.
>
> Took me around 3 minutes.
>
+1

Re: Backward compatibility

On 3 May 2013 09:44, Niklas Hambüchen <mail <at> nh2.me> 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/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
>
> 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...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Backward compatibility

Nicolas Trangez <nicolas <at> incubaid.com>
2013-05-03 17:52:27 GMT

On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
> On 3 May 2013 09:44, Niklas Hambüchen <mail <at> nh2.me> 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/5e2fa93f82b4123d0d5b486209c3b722c4c1313d
> >
> > 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Backward compatibility

Niklas Hambüchen <mail <at> nh2.me>
2013-05-03 18:21:53 GMT

On 04/05/13 01:52, Nicolas Trangez wrote:
> On Fri, 2013-05-03 at 10:40 -0700, Hilco Wijbenga wrote:
>> 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?
Yes, I proposed that.
It seems to be already in the making by some, but seems to need more
concentrated community effort/support/contribution.
It would also *hugely* reduce the time spent on what my next email is about.

Re: Backward compatibility

Niklas Hambüchen <mail <at> nh2.me>
2013-05-03 18:33:36 GMT

All right, here you go: https://github.com/nh2/WashNGohttps://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29
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?

Re: Backward compatibility

Well I'm enormously grateful to Niklas for fixing those two things. Simon was right that people are very supportive around here.

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.

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.

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?

Re: Backward compatibility

Niklas Hambüchen <mail <at> nh2.me>
2013-05-04 10:15:23 GMT

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 <es <at> ertes.de
> <mailto:es <at> 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 <mail <at> nh2.me <mailto:mail <at> nh2.me>>
> wrote:
>
> All right, here you go: https://github.com/nh2/WashNGo
>
> https://github.com/nh2/WashNGo/commit/08010e7404219470a827f3e4172004f9d2aedc29
>
> 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?
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Backward compatibility

You might want to check out FPComplete, 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."

You might want to check out FPComplete, 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."

Re: Backward compatibility

> What pray tell are those missing pieces? Aren't they mostly building a browser based ide > plus doing training courses ?

Sure, and I believe they plan to have that browser-based IDE talk to a virtual server, with a compiler and set of libraries they maintain. That'd solve Adrian's problems, no? So long as he can bring himself to use Yesod over WASH?

Perhaps more importantly, they're well-spoken and business-savvy, and they can persuasively promise that they'll make a risk-averse corporation's (overblown) worries go away. If he's in a management battle, he ought to know where to hire some mercenaries.

You might want to check out FPComplete, 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."