Watching: Brent Yorgey On Diagrams and Typeclassopedia
A few sections caught my eye.
"I think to be really successful with Haskell, you need to understand at least some of the materials on the Typeclassopedia..."
From here. I agree when Brent speaks on understanding the common abstractions. I've found that the more I learn to read and understand the abstractional conventions >>=, >>, <-, fmap, <*>, <$>, runThing, and more, the more sense reading Haskell APIs makes to me.
On design patterns, and how they're fundamentally a manifestation of an anti-pattern in software design. I found this ironic, but I understood the why of it. Design patterns exist because the languages that we've been using today fail to capture the abstractions that we want to use. Iterators, facades, etc. - it all connected pretty strongly with me.
"Design patterns are just libraries that your language isn't expressive enough to write."
The next section that got me thinking was on Teaching Haskell.
"Was there a consistent hurdle?".
Applicative functors and monads seemed to give trouble. This has been my experience so far with the little bit of programming I've been able to do so far. Sometimes, I'll get stuck trying to get something out of a Context, and what conventions exist for that. For example, using Data.Random and finding out how to plug the results of generating a RVar [ByteString] into a function that expects a [ByteString] was tricky.
I love the thoughts on teaching students how to move between different levels of abstraction. This is something that I missed while going through school, and had to more or less rough it out while working on my CS degree.
"What do you think about Haskell as a general purpose language for teaching...?"
It seems that reasoning about time/space usage in Haskell is tricky. I can understand this. It would probably be difficult to convey some basic concepts on estimating the complexity of an algorithm in Haskell.
On the other hand, I think an unfortunate trade-off is made here. Haskell makes it easy to understand how to cleanly express algorithms and programs. I think this sacrifice in delaying the introduction of algorithmic complexity and space usage is worth it. I've also heard that Chris Okasaki does a great job of introducing how to reason about complexity in a lazy setting in his Purely Functional Data Structures.
Agree? Disagree? Fork this ThoughtStream or catch me on @cppcabrera. Share your thoughts!