[Haskell-cafe] Backward compatibility
Ertugrul Söylemez
es at ertes.de
Thu May 2 13:29:59 CEST 2013
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130502/1de07a5f/attachment.pgp>
More information about the Haskell-Cafe
mailing list