find :: (a -> Bool) -> [a] -> Maybe a
find :: Foldable t => (a -> Bool) -> t a -> Maybe a
The obvious beginner question looking at this code is "what's `t a`?", and now you have to explain type classes to someone who just wanted to find an element in a list.There's a list of arguments against FTP compiled on the Haskell wiki: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List
Instead of explaining that [a] is a List of a's, and then explaining what a list is, you explain that t is a container that is foldable which contains a's.
Does he really need to know the exact details of what a typeclass is?
I'm guessing you have experience with languages that have generic types. The issue with the new Haskell prelude is that not only do you have to grok generic typing in order to write the most basic of Hello World introductory programs, you also have to be able to make sense of the Haddock docs. And that now requires knowledge of the type class syntax as well as basic understanding of generic programming. Whereas previously you could have softened the blow by teaching the special case of "[a] means a collection of a" first, and ramping up to more precise definitions later.
Overall, I'm supportive of the FTP initiative. But I can't shake the thought that the vast majority of people who voted for FTP have long passed the point where they can fully understand the downsides of the change for others.
If someone want to compute lists, it could use a spreadsheet program. It's just better!
It was at that time thought that by keeping prelude simple (pure FP 101 style) it was more accessible to new programmers.
Apparently that mindset was reconsidered recently.
So the big downside is that now if you teach Haskell and want to use Prelude, you'll be forced to almost immediately teach typeclasses.
In my opinion that's not a bad thing at all. Typeclasses put Haskell (and FP in general) right in league with big feature languages like C# and Java. All big features of Haskell are implemented using typeclasses (such as the reputable IO monad). Not teaching that as a fundamental feature right at the beginning only makes the next hurdle of the more category theory heavy advanced features of Haskell that much higher.
In practice, I think #2 was a fairly uncommon case, and the fixes were trivial and backwards compatible, so the cost was deemed pretty acceptable. #1 is a point of debate, because 'beginner' needs context (perhaps experienced programmers that are Haskell beginners would get over it quickly, but non-programmers would be substantially more confused, etc). Unfortunately I don't think we have a lot of truly empirical evidence on #1.
- I can fold a list, but what about other types? Which of the similarly or identically named functions dispersed among a bewildering number of library modules is the right one? Are they any different?
- I can fold a Foldable? What is it? Let's find a tutorial about Foldable. Ooh, nice! That takes care of folding anything that can be folded! If I'm not folding a list I only need to find where the relevant Foldable instance is (very easy) or to write one myself (reasonably easy).