In this episode, Matti and Wouter are joined by John Hughes. John is one of the authors of the original Haskell Report and talks about why functional programming matters, the origins of QuickCheck testing, and how higher order functions and lazy evaluation is the key that makes functional programming so productive, and so much fun!
Great point about Haskell seemingly becoming less and less easy to learn for beginners around 15:00. I hope some day we get a language levels system where you can start with a very simple subset and slowly expand to the full language.
@jaror Haskell 2010 is pretty simple. What do you imagine is the simpler starting point, if any? If Haskell 2010 is a good starting point, aren't language pragmas / extensions effectively the same as your "language levels"?
Type classes are a big cause of confusion among newcomers, and even parametric polymorphism.
If you want to see how simple a language can really get you should check out Hedy: https://www.hedycode.com/. It even removes string quotes (let alone variables) at the simplest level. Although it is too imperative for my taste.
@jaror@BoydStephenSmithJr Type classes have been in Haskell since forever. There’s no Haskell “level” that would avoid them while being a level of Haskell instead of some vague/generic “functional programming”.
If you want to teach Haskell - you teach Haskell, with its staples like type classes and laziness.
I'm not suggesting you should never explain type classes. I simply want to avoid having to explain type classes before I can explain how to add two integers. And more importantly, I don't want error messages to mention type classes until they have been understood.
@jaror@dpwiz I think without the type of polymorphism that Haskell uses type classes for, the language can never be more than a toy.
But, that doesn't mean it can't be didactically useful. A "Haskell--" with a JS-style Number for all numeric literals and replacing all numeric type classes with top-level operators on that type could be useful, for a bit.
Once you want to do indexing (e.g. Array) you need to distinguish between numbers like sqrt 5 and suitable indexes, tho. Enter polymorphism
There are so many options to work around type classes. As you say, we could be looser with our types and have one general number type that includes integers and floats. (And I don't even think array indexing is much of a problem, it could just throw an error or automatically round to an integer.)
Another option is to just have separate number types with separate functions for addition and multiplication etc. For example OCaml has + and +..
Perhaps more of a stepping stone towards full type classes would be a limited system where only a few pre-defined classes and instances exist. Then you'll never run into the dreadful could not deduce Num (a -> b) error message, but you can still use a nice overloaded + for both Int and Double.
@jaror@dpwiz Your first proposal is to sacrifice type safety. I reject that option; avoid success at all costs.
Your second actually increases complexity through semantic bifurcation . I reject that as a way to make a simpler language, even for didactic purposes.
No, discarding type classes without adopting something else worse (interface inheritance) is not easy, and may actually be impossible.
I'm not sure which options you are referring to, I had three options: a JS-style number type (with two suboptions for indexing: throwing errors or rounding), separate types, or a fixed set of classes and instances.
Your first point seems to be against the error throwing approach to array indexing with a JS-style number type. I kind of agree, but then we should also handle out of bounds indexing in a type safe way. I still don't see the problem with rounding to an integer, I think that's also what beginners intuitively expect if they write e.g. xs !! (length xs / 2).
Your second point seems to be against having separate types and separate instructions like + and +.. I think I'd agree that semantically it is not much simpler, but programming is more than just semantics. For example, error messages will be much simpler if there's no Num type class involved (at least the error messages that GHC gives). Perhaps it is possible to develop a better error reporting mechanism for type classes, but that would require more research.
@jaror I absolutely disagree that error messages would be better if we didn't have type classes. Languages with the other popular ad-hoc polymorphism (interface inheritance) have similarly opaque (initially) error messages of approximately the same length OR promote the failure to a run time error, a much worse situation.
@jaror Implicit rounding or other conversion also undermines type safety, though if the conversion is total, not in the strict sense of "well typed programs don't go wrong" but in the sense of safety is when our expectations align with the results, something easily violated by allowing floating point indexes.
@jaror@dpwiz Your third option has been tried and failed multiple times, most recently in Elm. Programmers that need that kind of extension route around the denial and produce a (sometimes limited, often more awkward) library solution and then ship adaptors for all the primitives in the language, replacing the native (but non-extensible) name overloading.
This ends up making for a more complex ecosystem, and frustration when learners are taught native, but everyone uses library.
Anyway, I didn’t encounter much problems with type classes while teaching Haskell, not even as a first language. May all of my students were okay with some suspense 😅
Add comment