26 ms·
Becoming Productive in Haskell
- IanCal 11y agoI really liked this article, in particular the sections around learning things like Functor and Monad (if you haven't read the article, don't worry, it's not a list of new explanations that's why I like it). A minor wording recommendation: > better in every measure(lower complexity, speed, readability, extensibility) Apart from a missing space before the parenthesis, this reads like there was lower complexity, lower speed ...
- danneu 11y agoCould just change "lower complexity" to "simplicity".
- solaris999 11y agoThanks for this, I really appreciate the section at the end on a suggested learning process. Looks like I've got my weekend planned!
- lmm 11y ago> So, I started calling it Mappable. Mappable was easy for me to remember and was descriptive of what it did. A list is a Functor. A list is Mappable. I wish there was a language or library that was willing to take the Haskell functionality and just give it all names like this.
- tormeh 11y agoA fork of Haskell with descriptive names and operators could be really popular, I think.
- dons 11y agoActually wouldn't be a fork. It's just an alternative Prelude library. People do this occasionally. The result tends to be idiosyncratic.
- peteretep 11y ago> I wish there was a language or library that was willing > to take the Haskell functionality and just give it all > names like this. I don't think this helps understanding that - for example - Either is also a functor.
- lmm 11y agoThat Either is Mappable is, IMO, both clearer and more informative than that it's a Functor.
- punee 11y agoMaybe someone can correct me here, but that kind of approach seems ill-founded to me when after a couple examples, people are already talking about different things using the same terminology. The article says "A list is a Functor". Now you're saying "Either is a Functor". But those two things don't have the same nature. Maybe what the author meant "The [] list constructor is a Functor"? I'm not sure what is gained by garbling abstractions and reducing them to a subset of their potential interpretations.
- mundacho 11y agoI think the problem here is terminology. A functor is the abstract concept and it implies having the map operation with the right signature and obeying the right properties. The best way to say it is "The list type 'forms' a functor" or "The Either type 'forms' a functor". The fact that they form a functor implies that their map operation has a fixed set of properties, and these properties are independent of what exactly the data structure does and how it works.
- lmm 11y agoThere's no subset, no garbling; Functor literally has one member, map (fmap in Haskell but that's a historical artefact).
- dllthomas 11y ago
- DanWaterworth 11y agoThis is actually possible with the ConstraintKinds extension in GHC. type Mappable = Functor type NotScaryFluffyThing = Monad This makes Mappable a synonym for Functor and likewise for Monad. (This is not necessarily a good idea; it goes against the principle of least surprise, but it'll work).
- TazeTSchnitzel 11y agoIsn't aliasing types a core language feature?
- lclarkmichalek 11y agoFunctor and Monad are technically not types but type classes (i.e. interface vs an implementing class), hence why simple/naive type aliasing is not enough.
- AnimalMuppet 11y agoMy code definitely needs more NotScaryFluffyThings in it.
- tormeh 11y agoIn Scala there aren't any names for functors that I'm aware of. I just though one day that "wouldn't it be practical if I could map an option instead of match-casing the meaning out?" and lo and behold it worked. Maybe we just don't need that much terminology.
- lmm 11y agoYou need a term for "thing that I can map" if you want to be able to write a function that takes a generic "thing that I can map". Which I do.
- whateveracct 11y agoThat's because the Scala stdlib doesn't abstract over things that can be mapped over. If you want to do that, then you need a typeclass. Scalaz has a typeclass for mappable things and it's called Functor.
- wyager 11y agoThat would be wrong. Functors also describe things that aren't necessarily "mappable". The actual definition of functor is more general than that.
- deleted 11y ago[deleted]
- julian_perrott 11y agoNice article, i've been learning Haskell for about a month solving kata on http://www.codeswars.com/ http://www.codeswars.com/ using https://www.fpcomplete.com/ https://www.fpcomplete.com/ as my IDE. I'm finding it quite a learning curve understanding what library functions there are and how to use them. The code I write often ends up being quite different to the other solutions on codewars. I'm missing Visual Studio, are there any realy good Haskell IDEs out there? for example ones which allow debugging.
- grp 11y agoHaskell with Emacs is awesome! There's a few modes available to have a powerful IDE. I don't remember which ones as xmonad + yi (or vi) is enough for me now.
- gallabytes 11y agoHow've you liked actually using yi? My only experience with it was rather frustrating.
- grp 11y agoMy main reason of change is because emacs was getting too slow and buggy. After trying a few hacks in 'init.el' and co, it was getting worse... Suddendly Yi! As I code only in haskell, it's perfect fun for me. Now, maybe a good way to start is using/practicing their Vimgolf client. [0] In emacs, as I didn't use any others modes (except haskell-mode ...), I don't need their wonderful package managers any more. [0] https://yi-editor.github.io/pages/vimgolf/ https://yi-editor.github.io/pages/vimgolf/
- pjmlp 11y agoI have used Leksah and EclipseFP a few times, they are ok. I don't remember how good they are debugging code. http://leksah.org/ http://leksah.org/ http://eclipsefp.github.io/ http://eclipsefp.github.io/
- mercurial 11y agoUnfortunately, the state of debugging in Haskell, last time I checked, was pretty dismal. Vim + ghcmod + syntastic has a useful subset of the functionalities of an IDE.
- estefan 11y agoNice article. I find FP incredibly elegant and I'd like to learn Haskell, but every time I search, there are never any jobs in it, so it seems like Scala is the better choice for where I live... Speaking of which, I found "Functional Programming in Scala" excellent for teaching someone with an imperative background how to "think functionally". Monads are explained in an easy to understand way. I can imagine that without reading that book I'd have been looking at a couple of years of coding before I started to see the abstractions, etc. By contrast "Learn You a Haskell" lost me part way through both times I tried to read it...
- akurilin 11y agoWe used functionaljobs.com for hiring our very latest Haskell developer (ex Scala guy) at Front Row, check it out, it should at the very have a few interesting openings on it. Also, companies actively using and recruiting for Haskell are now starting to join the Commercial Haskell SIG, so if you want to poke around, you can find them here: https://github.com/commercialhaskell/commercialhaskell#readme https://github.com/commercialhaskell/commercialhaskell#readm...
- mightybyte 11y agoIf you wait for the jobs to come, you'll be late to the party. Very few people will want to hire someone who doesn't know Haskell for a Haskell development position. Learn it now so you'll be up to speed when more jobs start appearing. Or better yet, learn it and then create the Haskell jobs yourself.
- cies 11y agoGreat article. I do think a better "Getting started with Haskell" guide is Chris Allen's: https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell OP's article is still a great way of wetting appetite, and sharing insights; but moving on from there is better facilitated by Chris Allen's recommendations. There is also the IDE issue; FPComplete has a web-based IDE that is good for beginners, and it is possible to setup Emacs to be a very helpful IDE (though this is by no means simple). With Haskell an IDE is really helpful: see the errors as you type, and resolving them before running into a wall of compile errors. Anyway: go Haskell. I'm looking forward to a less buggy future :)
- octatoan 11y agoI think you meant "whetting". :)
- cies 11y agoThanks.. Lol! Maybe I've never read that word so far, and only heard it spoken.
- AnimalMuppet 11y agoI don't know about that. Haskell can be rather sink-or-swim... ;-)
- harry8 11y agoI don't think I have ever used a haskell program written by someone else that wasn't ghc. Is that usual? Are there now a bunch of .debs for useful things other than writing haskell that are actually written in Haskell? I'm not trolling, it's just a good test of what something is useful for when it's been around a while is to ask "Well, what has it actually been used for?"
- grp 11y agoI daily use Xmonad, hledger and sometimes pandoc.
- IanCal 11y agopandoc is probably the one I see discussed the most without people knowing it's written in haskell.
- icebraining 11y agoThere's git-annex, which is a relatively complex software, runs on multiple platforms (Linux, OS X, Windows and Android) and is definitively useful.
- tobias2014 11y agodarcs version control (http://darcs.net/ http://darcs.net/) (what most people should use instead of git).
- deleted 11y ago[deleted]
- madez 11y agoFor what we have learnt from the history of mathematics, you might have to give it some hundred years before people realize usefulness. As a practical note, the fact that educated people use it is an indicator that it is useful.
- lucozade 11y ago> As a practical note, the fact that educated people use it is an indicator that it is useful. Possibly. It could also be that they use it because it's interesting and informative rather than useful per se. It could also be that it's useful in particular contexts in the same way that Feynman diagrams are useful.
- david-given 11y agoThe author's comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haskell terms of art? What I'd really like, I suppose, is a complete overhaul of Haskell syntax to modernise and clarify everything: make it use actual words to describe things (foldl vs foldl'? BIG NO). Put in syntax redundancy and visual space to avoid the word soup effect: typing is cheap, understanding is expensive. Normalise and simplify terminology. Fix the semantic warts which make hacks like seq necessary --- if I need to worry about strictness and order of evaluation, then the language is doing lazy wrong. etc. Basically I want language X such that X:Haskell like Java:K&R C. This will never happen, of course; the people who have the knowledge to do such a thing won't do it because they are fully indoctrinated into the Haskell Way Of Life...
- 1971genocide 11y agoIts interesting, I know one Cambridge theoretical physicist who is immensely successful in his field. I found it really odd how he worked 5 years as a proffesional writer between working in university. He thinks of good writing as his "secret weapon" that made him successful in academia. He is one of the most well spoken person I have met and has instilled new respect for being a good writer which I didn't think about before ( I like the HN crowd think programming is everything ). Its also interesting that pg is such an accomplished writer. I think programmers need to think about code and well written document as having the same importance. Just my two thoughts.
- sordina 11y ago> sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they're completely unrelated to Haskell functors. Really, this should be considered as C++ perverting the existing terminology from category-theory for Functors. > I really like the author's suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haskell terms of art? I think that there is a great deal to be said for leveraging intuition. But who's intuition? Who was Haskell designed by/for when Functor was first defined in the standard library? > What I'd really like, I suppose, is a complete overhaul of Haskell syntax to modernise and clarify everything: make it use actual words to describe things (foldl vs foldl'? BIG NO). The intention is admirable, but what does it cost to do it, and what is gained by doing it? It seems that the implication is that certain functions become immediately intuitive to people (what kind of people?) in certain contexts, and that possibly-by-analogy, these context can be extended (how far?). I'm not saying that this is a bad goal, but rather than try to compromise in this manner, the Haskell community has often adopted terminology that is precise instead of intuitive. Functors could have been Mappables, but how far would that analogy hold, and who is already familiar with maps in this context? Better to use an accurate term, and when someone unfamiliar with it learns it in this context, they will be able to apply it to many other contexts. > Put in syntax redundancy and visual space to avoid the word soup effect: typing is cheap, understanding is expensive. Normalise and simplify terminology. On the surface, I've always supported this - if only for the reason that I would always like to be able to pronounce a combinator when I'm talking to someone. The downside would be the combinatorial explosion of different subsets of names that people would learn for even one library. I'm not sure weather it would be a net plus or minus. > Fix the semantic warts which make hacks like `seq` necessary --- if I need to worry about strictness and order of evaluation, then the language is doing lazy wrong. etc. I think you will find that this is an unsolved problem. Better to allow people to be explicit when necessary instead of making the language totally unusable. > Basically I want language X such that X:Haskell like Java:K&R C. I think I understand the sentiment, but the analogy feels too shallow. For instance, I would make the following predictions from your analogy - Do they hold? * Runs on a virtual machine instead of being compiled * Extraordinary measures taken to make the language and binary-formats backwards compatible. * More type-safe * Less primitives * More automated memory-management > This will never happen, of course; the people who have the knowledge to do such a thing won't do it because they are fully indoctrinated into the Haskell Way Of Life... Indoctrinated is obviously a loaded term. I think you will find that nearly all Haskell programmers in any position to influence the development of the language are very open-minded when it comes to new ideas. Part of the reason why Haskell looks the way it does today is because it was intended to be a platform for experimentation.
- cies 11y agoFind more discussion on this article over at /r/haskell: http://www.reddit.com/r/haskell/comments/33mnlc/becoming_productive_in_haskell_coming_from_python http://www.reddit.com/r/haskell/comments/33mnlc/becoming_pro...
- kitd 11y ago> After writing a parser with them, I began to understand other code that used them. I then started to understand the abstract nature of them…but that abstractness was a lesson for another day, not for starting out. This definitely helped me too. I started out looking at functions and monads as 2 'types' of function that could only be mixed in certain ways, and didn't bother with the gory details at first. IME It's only when you experience monads and their effects that the gory details make perfect sense.
- __Joker 11y agoKind of agree with refactoring with python. While prototype building was easier with python, I used to have lot of changes and always has this nagging problem that something is not right.
- musername 11y ago> Composing functions out of other, smaller functions offers a big reduction in complexity. If they’re named well, this allows you to write functions that are easy to read. there are only two problems in CS, cache invalidation and naming things - phil karlton
- pubby 11y agoWhenever I try to be productive in Haskell I end up taking the research phase too far and end up over-my-head in category theory that I don't understand. I'm never productive in Haskell.
- boothead 11y agoYou might not be productive in the traditional sense of "delivering business value". However over the years of letting Haskell change my brain a little piece at a time, the results have accumulated. I wouldn't swap that deeper understanding for all the productivity in the world. :-)
- glutamate 11y agoHaskell is a great language for delivering business value. The typed FP paradigm encourages reusable code much more than any other paradigm I have tried.
- boothead 11y agoYes, absolutely agree with you. I wish I was writing Haskell day to day. My point was that it takes a long trivial amount of time to learn Haskell during which you might feel "unproductive" by that measure. I feel that it's during that period that the magic happens :-)
- agrafix 11y agoHaskell allows very "deep" abstraction - but what I find is that you should not overuse it. Abstract where practically useful, otherwise don't go for it. :-)
- marcosdumay 11y agoStart by coding. Be prepared to rewrite your first big project once or twice (good thing is that you'll realize it needs a rewrite sooner, rather than later - anyway, don't start with something too big), but start coding. You won't learn it by reading.
- QuantumRoar 11y agoScripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it's a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with "easy" scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination. While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think "Well, what is it that I'm actually trying to do here?" It let's you recognize and apply common patterns and implement them in abstract ways without having to think about what kind of values you actually have at runtime. In that way Haskell is the most powerful language I know. Have a tree/list/whatever? Need to apply a function to each of the elements? Make your tree/list/whatever an instance of the Functor type class and you're done. Need to accumulate a result from all the elements? Make it foldable. Something depends on some state? Make it a Monad. You either get a result or you don't (in which case any further computations shouldn't apply)? Use the Maybe Monad. You need to compute different possible results? Use the List Monad. Need to distinguish three different possible values that are different compositions of elementary types? Make yourself your own type and pattern match the behavior of applying functions. Need to output in a certain way? Make it an instance of the Show class. Most concepts that are used every day have some kind of idea behind them that is abstract and implementation independent. Haskell kind of forces you to reference those ideas directly. The downside is that you actually have to know about those concepts. However, knowing about the such concepts makes you also a better programmer in other languages, so it's not like it's a bad thing.
- kaeluka 11y agoIIRC, the Show class is supposed to be the reverse of the Read class -- so you should not use it to pretty print stuff.
- sordina 11y agoIt's not a pretty-printer. It's fine for printing stuff when you don't care what it looks like most of the time. Pretty printing is a vague term though. There are certainly many ways to pretty-print in Haskell, some of which are bi-directional pretty-printers/parsers.
- TheSmoke 11y agoexcellent article, thanks. it's comforting -for me- to see that almost everybody is going through the same phases while learning haskell. i believe that should say something to haskell community. i've recently started learning haskell. it's been 25 days. (so says cabal) i was reading a book and struggling to build a web app. (why web app?) i was so close to quitting. later i decided this is not the way to learn haskell. one simply does not read the book and try stuff. that was not enough. at least for me. so i changed my method. my new method of learning haskell is: - read the book. - find one or more mentors (i have two) that are really good at haskell and can answer all kinds of impatient questions you have. - watch people doing and explaining haskell stuff. - join #haskell-beginners on freenode and ask your questions. - create something small first that you can turn into something big later. online haskell resources are surprisingly deficient however #haskell-beginners community is awesome when it comes to helping n00bs like me and "learn you a haskell" book is an excellent book. one more resource that i use as reference material is the "haskell from scratch" [0] screencast series by chris forno (@jekor). before you begin, make sure you checkout chris allen's (@bitemyapp) "learn haskell" [1] guide. we'll get there people, we'll get there. :) [0] https://www.youtube.com/playlist?list=PLxj9UAX4Em-Ij4TKwKvo-SLp-Zbv-hB4B https://www.youtube.com/playlist?list=PLxj9UAX4Em-Ij4TKwKvo-... [1] https://github.com/bitemyapp/learnhaskell https://github.com/bitemyapp/learnhaskell
- LukeHoersten 11y agoI've been programming Haskell for quite a while now and find that many of these types of articles don't capture what I really value in the language. The author really captured what I love about Haskell excellently! It's super terse, (really) readable, and the barriers to entry people worry about are more in their minds than in reality. It's a great language and a great article!
- outworlder 11y agoGot sidetracked by this: > "We store memories by attaching them to previously made memories, so there is going to be a tendency for your brain to just shut off if too many of these new, heavy words show up in a sentence or paragraph." That has always been my belief. I don't have anything else to back it up, only that my own speed of learning seems to increase for new subjects with time. The more I know, the easier new concepts seem. Very few things are completely new, unless I start delving into subjects I'm completely unfamiliar with. Say, Quantum Mechanics. With most programming languages, I (and probably many here) can learn enough to start creating something useful in a weekend. Haskell always gave me trouble because it seems to take longer than that. Then again, so does Prolog. I'll try yet again.
- prajjwal 11y agoAs someone who recently groked some of the higher order Haskell concepts, I found myself nodding at everything this says. An RSS feed would be great. Also, does anyone know what colorscheme this is using for the code samples? Looks nice.
- michaelochurch 11y agoOP: Thanks for this. I'm teaching a class on Haskell for my company's interns this summer and I'm trying to come up with a syllabus and a plan for it. This really helped.
- windlep 11y agoI really like Haskell, but one of the main problems I've had (that I don't see many people cite) is that the libraries just aren't made for use under serious load/concurrency. Many of the people that have written these libraries, and use them are not using them in high-performance, memory-sensitive areas (production use at companies). There are Haskell libs of course that are used in these environments, and the companies usually end up fixing them such that they're quite good. Most libs used by pandoc are likely to be great, and there's a few dozen others of the same caliber (its useful to search around and see what libs are used by the other few companies using Haskell since they have likely been vetted as well). The other largest issue to actually using Haskell is that all the knowledge your ops team has of running a production system are essentially null and void. All your existing knowledge of how to fix performance issues, null and void. Learning Haskell and becoming productive in it almost starts to look like the easy part compared to effectively running a Haskell (dealing with space leaks, memory fragmentation issues, and ghc tuning for stack sizes, allocations, etc).
- bsummer4 11y agoCould you name some of these libraries? IME, most of the libraries that are needed for common things are very mature.
- windlep 11y agoI tried to write a Haskell websocket server, the library is quite nice, but it leaked memory (space leak? fragmentation? some of both?): https://github.com/jaspervdj/websockets/issues/72 https://github.com/jaspervdj/websockets/issues/72 The author helped me narrow it down to some issues with how ghc by default allocates a stack space that is rarely enough, and once it starts growing the stack space the RAM per connection gets pretty ridiculous. Using higher default stack space helped remedy this some, but the per-connection RAM cost was still way higher than Golang/Python which I was comparing to. So... separate project, I write a load-tester in haskell for a websocket server. I need to issue some HTTP requests, and I see Brian O'Sullivan made a nice library, wreq. I use it as described and quickly discover it uses ridiculous amounts of memory because it doesn't mention that you should always re-use the Session (the underlying http-client emphasized the importance of re-using the Manager): https://github.com/bos/wreq/issues/17 https://github.com/bos/wreq/issues/17 (I am sorry that this issue prolly came off as a bit whiny there, I was very frustrated that such a gap was omitted from the docs) So, my program is working pretty nicely, until I discover that its not actually sending multiple HTTP requests at once (even though the underlying http-client lib has a thread-safe TCP connection pool). After browsing some code, I see the problem: https://github.com/bos/wreq/issues/57 https://github.com/bos/wreq/issues/57 The solution that was so far implemented seems equally weird to me.... letting different requests stomp over the Session's cookie jar... I forked it so that I could have multiple wreq Sessions use the same Manager, and now it finally works as it should. I won't even go into how some of these libs have occasionally wanted conflicting dependencies which leads into its own 'cabal hell' (googling for that is entertaining unless its happening to you). I've only been writing Haskell for a bit over a year now, but everytime I write code with it, despite my love of the language, the libraries and run-time end up frustrating me.
- pjungwir 11y agoI've got a side project webapp I'd like to use to learn some Haskell. What is the most mainstream Rails-like web application framework out there? By Rails-like I mostly mean convention-over-configuration, with a strong ecosystem of plugins so I don't have to re-invent the wheel for auth, file uploads, etc. So far I've seen: - Yesod - Snap - Happstack - Scotty - Spock Right now I'm learning Yesod, but I don't feel confident that's really what I want. Which of these are closest to Rails? Which are closest to Sinatra?
- creichert 11y agoYesod would be the closest to Rails. Scotty would be closer to Sinatra and Flask. Spock is similar to Scotty but comes with a few more built-in features like type-safe routing, sessions, etc. I recommend Yesod but there are certainly some advanced metaprogramming features (routing, models). Have you checked out the Yesod scaffold site? https://github.com/yesodweb/yesod-scaffold https://github.com/yesodweb/yesod-scaffold
- kyllo 11y agoYesod is the closest thing to a Haskell version of Ruby on Rails. Scotty and Spock are both Sinatra-like. There's a lot of good info here: https://wiki.haskell.org/Web/Frameworks https://wiki.haskell.org/Web/Frameworks
- akurilin 11y agoYesod's great. There's a bit of a learning curve, but it comes with a LOT of batteries.
- x0054 11y agoCould you guys explain to me what Haskell would be mostly useful for. For instance, can it be used to make a web app backend or a GUI app? Or is it mostly for mathematical calculations and such. I tried to pick up Haskell once, but I guess I just couldn't get it. I mean, I got the core concepts, wrote a bunch of starter code, like prime checker and the like. But after going through several tutorial chapters, I still could not figure out how I would use Haskell in the real world. I don't mean to criticize or anything, just mean to understand. There are so many people who are very passionate about Haskell that it makes me think that it must be worth while to learn. But I just don't get how it would be useful for things that I do most with programming: writing Web/Desktop/Mobile apps in Swift, Python, and PHP. Also, can you recommend a good book or resource that uses real world examples to teach Haskell?
- arbsn 11y agoWhat confuses you about using Haskell for writing Web/Desktop/Mobile apps? System.IO exposes all the primitive input/output functionality one would expect in Swift, Python, or PHP, and there is an abundance of higher-level libraries for networking, parsing, graphics, etc. Haskell even has a fairly usable C FFI. Haskell is a general purpose programming language.
- djur 11y agoA popular introductory text like Learn You A Haskell doesn't introduce IO until chapter 9. It never gets beyond simple toy programs and the only further resource suggested (in the FAQ) is Real World Haskell. RWH is well-written and covers some real-world tasks, but some of its examples are outdated enough that they don't even compile anymore (at least, I encountered that scenario a year ago or so) and Haskellers will frequently warn people that parts of it are out of date (see elsewhere in these comments). I actually think one of the shortcomings of Haskell's approach to new developers is that it _is_ very much a general purpose programming language and sold as such. Other languages have extremely popular frameworks or applications which serve to attract newcomers. People teach Swift or Objective-C to write iOS apps, Java for Android apps, JavaScript to do web apps, Ruby to write web backends in Rails, C# to write games in Unity... hell, people learn Java to make Minecraft mods. The closest thing I can think of for Haskell is Xmonad, which doesn't exactly have mass appeal. Someone else suggested "Write Yourself A Scheme" as a good practical introduction, and that in itself says a lot about who Haskell appeals to -- people who are interested in programming languages. The MLs and Haskell remind me of Brian Eno's line about how the first Velvet Underground album only sold 30,000 copies, but "everyone who bought one of those 30,000 copies started a band".
- kwindla 11y agoLearning enough Haskell to feel "productive" is an incredibly good way to deepen your understanding of programming, even if you've been programming for years. Two things, in particular, stand out for me when thinking about Haskell this way (as a "tool for thinking" language). First, unless you're a mathematician, you probably haven't thought very deeply about algebraic data types, and how useful and expressive it is to build up a program representation from a collection of parameterized types. The article touches on this a little bit in noting that Haskell teaches you to think about data types first. But it's more than just "data first," for me, at least. Grokking Haskell's type system changed how I think about object-oriented programming. Classes in, say, Java or C++ or Python are a sort of weak-sauce version of parameterized abstract types. It's kind of mind-blowing to make that connection and to see how much more to it there is. Second, monads are a really, really powerful way of thinking about the general idea of control flow. Again, the most useful analogy might be to object-oriented programming. When you first learn to think with objects, you gain a flexible and useful way of thinking about encapsulation. When you learn to think with monads, you gain a flexible and useful way of thinking about execution sequencing: threads, coroutines, try/catch, generators, continuations -- the whole concurrency bestiary. I think monads are hard for most of us to wrap our heads around because the languages we are accustomed to are so static in terms of their control flow models, and so similar. We're used to thinking about control flow in a very particular way, so popping up a meta-level feels crazy and confusing. But it's worth it. For example, if you do much JavaScript programming, and are ever frustrated translating between callbacks and promises, having a little bit of Haskell in your toolkit gives you some mental leverage for thinking about how those two abstractions relate to each other.