Haskell Communities and Activities Report, May 2015
haskell.org
haskell.org
Haskell is backed by a truly amazing community. A lot of effort has been put into making Haskell more "beginner" friendly or production-ready. There is obviously still a long way to go and things to improve (cabal?) but what has already been achieved is something that Haskellers can be immensely proud of.
I am certain that this will pay off on the long term. Haskell will continue to inspire people to build better, safer software and contribute to make the line between software engineering and mathematics blurrier.
From a sociological aspect I hope that the values of tolerance, respect and benevolence that most of the Haskell community is supporting will also contribute to make tech a more friendly and equal place for everyone.
Throwing a beginner head first into recursion and restricting all their programs to be a singular composite of expressions is the, unfortunately, best way to turn away a beginner.
But damn, it'd be an awesome future if I'm wrong.
The alien-ness is what makes it difficult, not the actual design. Less design surface area makes it considerably easier to learn in that respect. That doesn't mean Haskell is easy to learn in general, for now. There's a huge difference in jumping from Ruby->Python->JS vs. learning how to program in terms of a foundation built on lambda calculus.
"singular composite of expressions" - this doesn't mean a lot, and doesn't really fit, I think. You can hand-wave do syntax and pretend you're writing imperative code in IO. A lot of people do that when first starting out so they can get the hang of things. SPJ (OG Haskell honcho & compiler hacker) likes to say that Haskell is the nicest imperative programming language to use. I'd tend to agree :)
Takes practice. You need exercises.
If you haven't already seen it, I'd recommend taking a look at the guide I've maintained on how to learn Haskell: https://github.com/bitemyapp/learnhaskell
I meant like beginner as in a beginner in programming in general. I feel the only reason why I was able to pick it up really quickly and like it was because I wasn't a beginner.
Here[0] is an interesting blogpost by somebody who learnt Haskell as their first programming language. Mutation and regular imperative programming are as alien to her as immutability and functional programming would be to somebody who has exclusively programmed in an imperative language.
[0]- https://superginbaby.wordpress.com/2014/11/18/learning-haske...
In other words, it is easier to think of something as a series of repeating steps then it is to think of something as a self referential entity.
I think the only time I use recursion in Haskell is when I need to mutate some parameters over a set of items (which is often) but I don't have to think about the fact that the function is recursive - I only have to ask myself "how do the parameters change while traversing the set?"
Lastly, if you don't like the idea of recursion you can often do the same with a fold by keeping your parameters in the accumulator as a tuple or other such sum type.
My main point being that none of these things (programming patterns and strategies) are intuitive until you have some background.
That's my point. I'm saying in addition to this, loops are by far one of the easier patterns and strategies to become familiar with.
think about it. By knowing what a function is... recursion can be taught as a logical next step without introducing any additional language primitives. Yet most computer science classes will still teach looping syntax before even touching upon recursion. Why? Because looping is way easier to grasp then recursion, theoretical elegance be damned.
Linked individual is my coauthor. She finds recursion far more intuitive than loops and mutation, so - don't doubt.
It's also easier to write recursion out on paper in a way that is faithful to the program semantics. Loops require tracking state off to the side.
Debating this point is useless. Operating a crane is not more natural than picking a pile of dirt up in your hands and carrying it. It's more efficient anyway.
Actually, while the presentation here was perhaps overstated, I think there is an issue here. The fact is that other languages split things into expressions and statements, such that the combinations of these things is more limited. This has a downside, in that you are not as free to cut things in the way that best fits your domain or your solution. But it has an upside in that where you cut becomes more obvious, and learning the appropriate size for chunks (particularly as you come back and repeatedly modify the same pieces of code) is an additional thing one needs to learn in Haskell that isn't entirely obvious (at least, it wasn't for me, and I feel I could still do much better than I do).
Critically, however, one does not need to be good at abstracting out code in Haskell to be happy and productive using Haskell.
We need to be careful not to move on the goalposts on our beginners, it's deeply unfair and frustrating if we make them think they can't do anything at all until they can do it perfectly.
Simple effect-free loops in an imperative language translate directly to a recursive function, which is just a labeled loop that makes explicit what/how state is manipulated each loop iteration.
(Edit: For effectful loops, it's common practice in imperative languages to interleave the effects with the program logic. (Un?)fortunately, Haskell discourages this practice and encourages you to refactor the pure parts of your program from the effectful parts. This might make your program more reusable and testable, but it's an obstacle if you are just writing a fancy Hello World and want to get stuff done.)
The singular composite of expressions is not a necessity, but to avoid it you have to give names to all your intermediate states, whereas a typical imperative language reuses the same name repeatedly.
Interesting way to put it.
I like to tell people that they program in languages where every type signature is "Any -> IO Any". It's technically true, but it gets some weird looks.
Fewer weird looks when you make that joke surrounded by Haskellites and Scalaistas.
But if they're completely starting from scratch, I'm not convinced it's really harder.
After all, apparently a ten year old can learn Haskell: https://superginbaby.wordpress.com/2015/04/08/teaching-haske...
No more than imperative languages do. Speaking from experience, if you wanna slap IO on the arse of all your types, no one can stop you. Our friggin' project/dependency management tool is written like this. Yes, Haskellers usually prefer something nicer but nobody's going to steal your compiler if you don't.
We should avoid mistaking our discomfort with a language or idiom with what it does or does not encourage, can or cannot do. Chopin's nocturne op 48 1 is not difficult because pianos discourage it, it's difficult because it's difficult. In fact, it would be extremely hard to translate to a less expressive instrument. Similarly, writing programs in a well-factored design that separate actions from the computations that decide what happens from the datatypes that model them takes effort and practice, whether you use Haskell or not. I would submit that using a less expressive language will not make the task itself easier any more than trying to capture all the notes of Chopin's 48/1 on something less expressive than a piano would be easier.
My coauthor has her 10 year old learning Haskell from our book. This stuff does not have to be hard.
I can do whatever I want in Haskell.
Prelude> map (+1) [1..5]
[2,3,4,5,6]
Prelude> mapM_ (print . (+1)) [1..5]
2
3
4
5
6
Prelude> let x num = print num >> return (num + 1)
Prelude> :t x
x :: (Show b, Num b) => b -> IO b
Prelude> mapM (x >=> x >=> x) [1..5]
1
2
3
2
3
4
3
4
5
4
5
6
5
6
7
[4,5,6,7,8]
One of the nice things about Haskell is you can always replace a function with its contents, or factor something out into a function and call that function by name and the result never changes.
-- You could inline the definition of foldr
-- and make mapM_ loopy-woopy, but why would
-- you want to repeat yourself?
mapM_ = foldr ((>>) . f) (return ())Scala and Clojure proved that far better languages than Java could actually be practical, even in "the enterprise" where Java reigned, but there are a lot of reasons why it's even better to be off-JVM and Haskell seems like a natural step. Also, as programmers get further along and more experienced, they tend to prefer static typing because dynamic typing simply doesn't scale on multi-developer projects unless you have a very disciplined and competent team-- which is not all that rare, but it's hard enough to make happen that the (perceived) negatives or difficulties of static typing are a rounding error in comparison.
That's all very well, until you look at a few Java programs in the million line range, and it turns out the source code for most of them also includes a million lines of XML, and the reason for that is Java's type system doesn't really match the problem domain, so people resort to XML basically as a way around the type system. And if you're going to be effectively writing a large chunk of your program in XML, you'd be better off using something like JavaScript or Python that is actually designed to be a dynamic programming language.
Now you could make the counterargument that this is because Java's type system isn't very good and if you used a language like Haskell with a better type system you'd have better results. Maybe, but then the objective isn't so much 'use a static type system' as 'make Haskell palatable to a decent percentage of programmers'. I'm not saying it's impossible to do that, just that it's a different challenge and needs to be understood for what it is.
To be pedantic about it, Java has two type systems. It has a bottom-up, mostly static, ALGOL-inspired type system with primitives and arrays (e.g. int, char[], double[][]) and a top-down, semi-dynamic type system for object types.
Maybe, but then the objective isn't so much 'use a static type system' as 'make Haskell palatable to a decent percentage of programmers'. I'm not saying it's impossible to do that, just that it's a different challenge and needs to be understood for what it is.
I agree. What would you suggest?
The issue, I think, that Haskell has is not that the language is hard to use, but that the type signatures can be anywhere from obvious to counterintuitive and, to a beginner, horrifying. The issue is that the "best" (most general, most mathematically accurate) type signature isn't always the one that gels with what we want from it.
An example would be the Lens type signature. It takes some on-paper, figure-it-out work to understand why this is the right type signature. It's this Rank-2 beast:
type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t
type Lensish s t a b = L {get :: s -> a, set :: s -> b -> t}
Then there are the names. Personally, I don't find "monad" or "functor" to be that bad. They're new concepts that must be learned, but they're a lot easier (and more useful!) than OOP's 23 design patterns, most of which are horrible.
I actually think there are two big wins there, one of which is somewhat overlooked.
First, it's great to be able to be able to read math papers and see how it touches your programming with less translation.
Second, and I think less noticed, it changes the form of some arguments. If we called Monoid "Appendable", then we would have to consider whether a new and different thing jived with our notion of "append". These arguments still happen in Haskell ("is container a good way to think of functors?") but it's recognized that what you're talking about is pedagogical. The question of whether something is a valid instance of Monoid or Functor or Monad is simple: does it abide by the laws? And since those laws are clear, we know what we can rely on, and if someone uses our code with an invalid instance that's their own fault.
I'm fairly new to Haskell and the type system is still a little scary to me, but learning it feels like a much better use of my time than memorizing the GoF patterns of Java.
I wonder sometimes if it was already on his mind or if it was because people were complaining about Platform at Bay Hac.
Bob is awesome :)
What beginners want is a "QuickHaskell" -- an out-of-the-box working Haskell environment with all batteries included -- in the sense of QuickLisp, for all platforms (not only OSX). I know FP Complete but this is a web service. It would be nice to have an instantly working environment for offline programming.
Why did the Haskell community not promote EclipseFP? It is (was?) such an awesome beginner's IDE. The maintainer has quit due to lack of support.
http://jpmoresmau.blogspot.de/2015/05/eclipsefp-end-of-life-...
There's more information in the linked Communities Report.
[1] https://www.fpcomplete.com/business/haskell-center/overview/