
Resigning from the Haskell Platform - enigmo
https://mail.haskell.org/pipermail/ghc-devs/2015-October/010068.html
======
ptype
Would anyone be able to give more background on the controversy?

~~~
moomin
Let's describe this in a way that makes sense to me, a C# programmer. In C#,
there's a function called Sum. It takes an IEnumerable<int>. There's an
overload for IEnumerable<double>. There's no way to express "is a number" in
C#, so it's just special cased. In Haskell, however, there is:

sum :: (Num a) => [a] -> a

Which means: for any a which is a number, sum can be used to add up a list of
as.

However, going back to the C# example, you'll note we said IEnumerable<T>, not
List<T>. In C#, the container is general, but in Haskell it's specific. And
since IEnumerable is an interface, this actually means "any type that is
enumerable". Haskell has an analogue of IEnumerable called Foldable.

So, what we _really_ wanted sum to say was "sum is a function that, for any
container f that is foldable, for any type a that is a number, takes an f of a
and gives you an a".

sum :: (Foldable f, Num a) => f a -> a

This is the AMP style version of sum. Some people hate it, I love it.

However, there's another piece of background to this that the email doesn't
mention: the Haskell Platform is under attack itself. There's a new solution
called stack which is, to my mind, easier to use and less likely to bite you
with version conflicts. And whether HP should continue to be the "default"
recommended way of starting with Haskell is, at best, controversial.

In short: there's plenty of people who won't miss his work on Haskell
Platform, but losing Mark himself is a loss.

~~~
tinco
Another hint of intuition for C#'ers out there. Foldable is like IEnumerable,
and Traversable is a bit like ICollection. Some are a bit unhappy with the
names too, even though they really make sense from the category theory sense.

A thing about Foldable is that you can fold over it (obviously) but you can't
necessarily map over it because in Haskell the general map (fmap of the
Functor typeclass) has the law that `map (f1.f2) enum == ((map f1) . (map f2))
enum` but for example for Set this law won't hold because the intermediate set
might drop elements identical elements that would not have been identical
would the f1.f2 been applied in direct succession. See [0] for an example. Why
fmap has this law I don't know, but Functor is super fundamental in Haskell's
types so you can bet it's there for a good reason.

Note that this Foldable-Traversable-Functor introduction into Prelude is not
complete yet. For example the map in prelude is: `map :: (a -> b) -> [a] ->
[b]`. If this movement continues it will possibly be `map :: (Functor f) => (a
-> b) -> f a -> f b`. People are super scared of the name Functor, so I think
that's why it's not been adopted yet. It should possibly be renamed to
Container or Mappable to be more in line with what general developers expect.

Would prelude's map be made equal to fmap however, it would make prelude super
powerful. It would suddenly work on _any_ Functor type, not just List.

[0] [https://www.fpcomplete.com/user/chad/snippets/random-code-
sn...](https://www.fpcomplete.com/user/chad/snippets/random-code-snippets/set-
is-not-a-functor)

p.s.: if you don't grok typeclass, call it classclass instead, i.e. class of
classes. And then think about how C#'s Interface also defines a class of
classes.

~~~
kqr
> Why fmap has this law

The law is the only law of fmap, which is the "structure preserving law". It
means that if you apply a function to each element of the structure, you
cannot change the shape of the structure.

This structure preserving property means you can safely apply any function
(even ones you don't know what they do) and you can be safe you're not losing
information beyond what the function takes away.

> It should possibly be renamed to Container or Mappable to be more in line
> with what general developers expect.

Mappable would be a truthful name. Container is not a good name because far
from all Functors are containers. You can map over a lot of things (I/O
actions, functions among others) which are not intuitively "containers",
unless you revise your intuition of "container" to mean "mappable". :)

The good thing about calling it for what it is – Functor – is an argument
commonly lifted by Edward Kmett: when you're honest about what you're dealing
with, you instantly give people access to 80 years of collective knowledge
about the thing.

------
paulsutter
Can I ask a question about Haskell? I see a lot of excitement about it, but,
honestly it seems a bit over my head and I'd love to understand.

Deep learning, for example, has opened the door to some pretty incredible
advances, I'm astonished monthly at least by what people are accomplishing.
Stuff that's getting close to the uncanny valley.

I see equally smart people enraptured with Haskell. And, maybe it's just over
my head, but so far no practical advance is apparent. To me at least. So, for
the sake of the nonbelievers, it would be grand to share some of the hopes
that merit the great energies that go into languages like Haskell.

(ps. thanks to Scrollaway for asking, below)

~~~
moomin
Haskell is, frankly, hard to learn. But the interesting thing about learning
Haskell is that you feel like you're actually learning more about coding and
computation, whereas most languages just feel like you're learning a new
syntax for doing the same thing.

In general terms, Haskell has an unparalleled ability to be both precise and
flexible at the same time. At least, that's why I like it.

~~~
paulsutter
I like that description, it conveys a sense for what can be appealing about
it.

But, if I look at Deep Learning, I see a freight train to the future. If I
look at Haskell, I see a lot of... well, debating about... things.. well I
just don't see where it's going. I get the sense that it's a gleeful little
clever club that exists as an alternative to doing actual work.

And, where's the counterexample, Haskell is a freight train to where? What's
the future that Haskell brings?

This is really a sincere question. I've been programming long enough to feel
the limitations of existing tools. But, will humans even be coding in 30
years?

~~~
pjc50
_will humans even be coding in 30 years?_

Yes. People will probably still even be writing in C and C++ in 30 years. The
same predictions were made about "4GLs" 30 years ago and have not come to
pass.

~~~
seanmcdirmid
Deep learning wasn't advancing at a 2X rate/year 30 years ago. Past
performance does not indicate future performance.

~~~
kqr
But it does give a strong hint. I personally don't prophesise somethings
demise in a shorter timespan into the future than it has existed for. I find
that to be a good rule of thumb.

High-level programming has been around for 50ish years, so we probably won't
get rid of it for at least another 50.

~~~
seanmcdirmid
It is a heuristic that assumes no disruption. If someone figured out how to
approach human-level intelligence in the next 30 years, then programming will
die then. Are we certain? No. But it is a definite possibility. There is also
a possibility of a cybernetic hybrid between programming and machine learning
that also doesn't really resemble today or yesterday's HLLs.

------
FrankenPC
Hmmm... Is F# a good alternative? I already have a ton of experience with .NET
and C#. I'm thinking about doing a deep dive into functional programming and
don't want to waste my time with something that has a major fundamental flaw.

~~~
spuz
That's quite a rash conclusion to jump to. Every language has its
controversies and quirks. I would recommend deep diving both into F# and
Haskell - you certainly won't be wasting your time either way.

~~~
glogla
How is F# on unix? I can imagine F# being nice on Windows, but can people with
Linux or Mac OS use it? How dependent on visual studio it is?

I would guess that Ocaml might be better in unixy environment while sharing
similar features to F#?

~~~
spuz
Well F# from the very beginning has always had a bit of a rebellious nature
seeing as it was brining ML style programming to the traditional OO platform
of Microsoft's .NET. Because of that, many F# people do not use Windows and F#
is very much built to be as independent from Microsoft as possible. See here
for various ways to use it on linux:

[http://fsharp.org/use/linux/](http://fsharp.org/use/linux/)

------
grp
I think it's sad to resigning like that but the newcomer argument is misused
in this controversy.

I started learning haskell 3 years ago with no background in CS nor in
mathematical expertise. So I feel like I'm still a noob toying with ghc until
late.

But I welcome that change with a big smile! In my opinion it resolves the
_list problem_ (who can be a jail sometimes). As a newcomer I always started
with lists which often ended as a bad choice but I learned it that way...

Like: "Oh, wait.. those lists were cools but... WHAT? I need to change
_everything_ because just now there are too limited? Fffuuuhh..."

------
kolme
I don't know anything about Haskell other than the basics. I've played around
with it, but the most "complicated" things I made with it was Fibonacci and
factorial functions.

I'm pretty curious, can someone summarize for me, what was the deal with FTP?
What are the pros and cons, and why are people upset about it? That'd be
really nice, thanks.

------
rkrzr
Is there going to be a backwards-compatible version of Prelude then? Maybe
called something like SimplePrelude which could be imported to keep all old
code working without any changes (it could also be used for teaching purposes
then, because the old Prelude really is much easier to understand for
beginners, I think). Or does this change break something fundamentally that
makes this impossible?

------
Confusion
Erik Meijer has been railing against this change on twitter, saying he won't
use this version of Haskell for future sessions of the FP101X EdX MOOC. It
seems to me that a change that is so divisive among experts is not likely to
be a good idea. Disagreement is one thing, but this seems more than just
disagreement...

~~~
skimpycompiler
The irony is that this change has nothing to do with expertise. It is entirely
subjective.

Scala has awful types. GHC 7.10.2 change is still elegant.

------
_Codemonkeyism
The arguments look a little bit like the CanBuildFrom in Scala, which makes
container methods really nice (return same container type that you gave it)
but method signatures harder to read, with the argument that it makes Java
developers go away.

------
codeisawesome
Cool, genesis of a fork.

------
paulsutter
Hey, Haskell wouldn't be cool if /everybody/ used it. Some guys are totally
down with bringing "the Foldable and Traversable typeclass to Prelude" and
making "the existing function of Prelude more polymorphic", while others feel
that just synergizes the wrong paradigm.

If you, like me, have no idea what this is about, just go back to coding in
one of those subtheoretical languages for feeble minded norms, like me.

I'm sure these guys are doing some REALLY IMPORTANT WORK with a language as
obscure as that. Way over my head, I'm sure.

EDIT: Scrollaway, thanks for asking. I don't really have a beef with Haskell
itself, I just think its tragic that so many smart people are drawn to
something that has .. well.. let's just say, I'd love to hear the practical
aspects of Haskell.

~~~
chriswarbo
You mean those "subtheoretical languages" with "practical aspects" like
deciding whether to use an abstract base class, which allows implementation
inheritance for friends but violates encapsulation; or putting static final
methods in an interface and using reflection to dynamically dispatch via a
meta-object protocol to the contra-variant constructors of a private inner
class?

All languages and paradigms can be obscure to outsiders. Just take a look at
[http://programmers.stackexchange.com/questions/tagged/object...](http://programmers.stackexchange.com/questions/tagged/object-
oriented)

