Scripting 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.
Ability to fiddle isn't tied to static or dynamic programming, it's just every static language platform I've seen including The Haskell Platform neglects making it easier to fiddle.
When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle. This is definitely possible. Not compiling is great for production, but not while developing.
Software is built in pieces, if I'm working on one piece, another statically unrelated piece shouldn't prevent me from working. In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it's not intrinsic.
I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check. Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn't mean the code works. Automated testing is still more useful for writing software that works. Haskell isn't as safe as many people think [1].
Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc.
But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.
I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off.
Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.
Absolutely, Haskell has a richness of concepts to it that's entirely in a class of its own... but that being said, Haskell is to programming what sex is to life (for a woman... because men's natural enjoyment of sex throws off my following analogy). Granted there is richness and joy in finally discovering it, one needs to realize it's important that one isn't forced into it too early. Haskell demands a lot of thinking up front and therefore requires a programmer of a certain logical / organizational maturity in order for the process not to be frustrating and painful (or even traumatizing). Haskell (like C, Lisp, and the arcane slog known as Erlang) should rarely be someone's first language.
And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.
After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.
>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?"...
Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results.
So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....
And what makes the model of haskell any more superior to models developed in any other field like accounting, physics or chemistry ?
I am sorry, haskell is just a huge roadblock to get things done in the real world.
In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !".
I need to juggle between json, matrix, html, etc.
Each of them have hundreds of expections.
You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes !
I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell !
I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My !
I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe.
my anecdotal experience.
((
btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell
The 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...
As others pointed out, the way Haskell uses the term "functor" is related to the way mathematicians had been using it for at least a decade before cfront.
I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure. In what sense? The math can guide you. In this case, it means the functor laws.
That's not to say that coming up with other associations to help ease understanding is a problem - I have no problem with saying, "for now, think of Functor as 'mappable'". The equivalent for Monad would probably be "flatMappable", and Monoid would be "appendable".
Its 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.
> e.g. C++ also has functors, and they're completely unrelated to Haskell functors.
You can't blame that one on Haskell or the functional community - the term was already established before the C++ community decided to use it in spite of pre-existing definitions. They even ignored Prolog's pre-exising abuse of the term functor :-)
A few similar terminological accidents of history come to mind, where the original definition of some term is now obscure and a different definition popular:
- POSIX capabilities (as implemented in e.g. Linux), which are a security mechanism that has nothing to do with what security researchers have been calling capabilities since the 1970s
- Microsoft operating systems using the term "Format" for creating a file system, despite the fact that it is impossible to actually format hard disks at the hardware level since the 1990s
- imperative programming languages abusing the term "function" to mean procedures with side effects
- "thunk" meaning a stub that emulates/bridges different calling conventions, instead of a call-by-name (or lazy) closure
- "Tea Party" used to refer to a fine rock band from Canada
Functors and monads are somewhat not going to change their names, partly because Haskell derives from math and those are what they're called over there.
> 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.
you might like elm [http://elm-lang.org/]; it's inspired heavily by haskell, but the author thinks long and hard about finding the right names for things rather than just using the defaults from haskell or ml.
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 :)
I'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!
I 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).
I've actually found the exact opposite. The library ecosystem is rich and mature. Haskell is, by default, "concurrency safe" because of referential transparency. You can safely "async" and compose almost any library in the Haskell ecosystem without worrying about shared memory etc underneath.
Also, a lot of the really common libraries like text, attoparsec (parsers), aeson, networking, etc are highly tuned for low latency and performance. Many use compiler rewrite rules and techniques called stream-fusion to compact a lot of the machine code away. Also aggressive inlining etc can be done.
I'm sure there are some memory-heavy or poorly optimized libraries out there but that's certainly not the norm. I've had no problems with the libraries off-the-rack.
Haskell has a problem in that people think about the basic libraries as deprecated, but won't deprecate them due to backward compatibility. Thus, people starting on it will get plenty of slow and unsafe constructs, while people used to it only look at the fast and safe ones.
There should be warnings all over the Prelude and basic libraries documentation.
Nice 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...
We 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.
If 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.
This 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).
In 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.
Learning 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.
I 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?"
This is a standard that Haskell is held to a lot, but I'm not sure how robust a test it is. I never use programs written in Java, for example, and I use a program written in Scheme every week. That doesn't say much about their relative popularity, let alone their quality as programming languages.
Presumably I use server-side applications written in Java, but I've no way of telling. If server-side counts then most people with computers indirectly use Haskell via Facebook's Haxl project.
I've mentioned this before, but there's a lot of music stuff written in Haskell - tidal[0] (DSL for live-coding electronic music, not the 'save Jay Z from penury for $20/month' initiative that has just clobbered its google results) and Euterpea[1] spring to mind.
Whenever 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.
Haskell 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. :-)
You 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. :-)
Start 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.
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.
> 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.
I'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?
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).
Could 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?
Haskell is a bit weird in that there are no niches where its a total killer-app and has the best libraries for everything. What its really good at is that it has a very solid type system and the core language is very clean, which encourages the use of powerful abstractions (for example: coroutine libraries for async IO, parser combinators, etc).
Out of the things you mentioned, server-side programming is the one where Haskell fits best. Server-side programming is more amenable to unusual languages because you get to choose your own platform and there are plenty of mature web frameworks you can use (too many of them, I might say). It might be worth a try to experiment writing code in a more type-safe language. Even the simple things like algebraic-data-types are things I miss a lot when working on other languages.
> Could 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?
Yes, and yes.
> Also, can you recommend a good book or resource that uses real world examples to teach Haskell?
The obvious thing to recommend here is Real World Haskell [0], which directly addresses some of the areas you raise.
Also, Write Yourself a Scheme in 48 Hours [1] is more in-depth and real-world than most tutorials (writing a Scheme interpreter isn't exactly a common real-world application, but its more real-world scale than most tutorials address, and it uses a lot of things that are of concern in many real-world apps.)
Haskell is useful for just about everything that Python, Ruby, Java, C#, etc are useful for. For the last 5 years my day job has been writing Haskell. Most of that has been web apps, but there have been other things like machine learning applications, a nice command-line interface to Amazon Redshift, an automated ETL tool for a large production application, and most recently a complex interactive browser app (using GHCJS to compile Haskell to Javascript).
What 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.
> "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.
Nice article, i've been learning Haskell for about a month solving kata on http://www.codeswars.com/ using 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.
Haskell 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.
Kind 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.
I 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 ...
> 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
OP: 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.
QuantumRoar|11 years ago
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.
munro|11 years ago
When trying to build complex software in Haskell, I find myself spending a lot of time commenting/uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi. It sucks. What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle. This is definitely possible. Not compiling is great for production, but not while developing.
Software is built in pieces, if I'm working on one piece, another statically unrelated piece shouldn't prevent me from working. In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it's not intrinsic.
I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check. Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn't mean the code works. Automated testing is still more useful for writing software that works. Haskell isn't as safe as many people think [1].
[1] http://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude...kaeluka|11 years ago
hyperpallium|11 years ago
But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.
I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off.
Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.
ffn|11 years ago
And that's where Ruby, Python, Javascript, and to some extent Matlab come in. For whatever else people may say about them later (they don't scale, they're a roadblock, they're a mess, null is not a function, etc.), they were there for you when you were programmatically young and they introduced you gently into a world that's otherwise extremely complex.
After all, programming, like literally everything else, is 99% human and 1% logic, machines, data, "scaling", etc. Programs are written by people for people (incidentally they can also be read by a computer), so it's incredible important that the 99% of that equation (you the programmer) don't become discouraged at the onset by an extremely elegant, expressive, but rather rapey language before you're ready for it. In that sense, it's absolutely okay to be "seduced" by an easy scripting language in the beginning. Eventually, though, when you start lamenting about "undefined is not a function" and how that could be so easily avoided when proper type-checking, that's your body telling you that you're ready for Haskell now.
imakesnowflakes|11 years ago
Wouldn't Scripting languages allows one to gradually build that understanding. Suppose you end up with a lot of complex code? Ditch it and build it from scratch. Usually takes around 1/10th the time it took first time with much better results.
So I think by the time one can think up and build the perfect abstractions in Haskell, one can write 3 or 4 iterations of the program in a dynamic language. Each time with better abstractions and neater organization....
hyperpallium|11 years ago
[deleted]
1971genocide|11 years ago
I am sorry, haskell is just a huge roadblock to get things done in the real world.
In the real world proffesional need to juggle all sorts of models. Haskell just says "Fcuk you ! its my way or the gonadway !".
I need to juggle between json, matrix, html, etc. Each of them have hundreds of expections.
You can say my model is imperfect but guess what buddy, every model is. The only models that will work for all cases is prolly einstein's equations but even that has exceptions when dealing with blackholes !
I tried writing a music library in haskell and haskell makes it really hard to create rules that are expections to the model. Apparently the models developed by 1000s years of music theory is not good enough for haskell !
I cannot even image what it must to be code chemical rules using hakell that have hundreds of expections, or biologial models ! Oh My !
I am sorry haskell just gets makes computation much more difficult. Apparently mutation is a crime even though god himself thought it was okay as a rule for everything in the universe.
my anecdotal experience.
((
btw i really like the concepts in haskell. I read two of its famous books - LYAGH and RWH. And use all haskell concepts almost daily in production. However the implementation of haskell is not really ready for production or useful enough for the average developer. Its also not easy for the average developer to put food on the table using haskell
))
david-given|11 years ago
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...
dllthomas|11 years ago
I agree that a shared vocabulary is important, but standardizing in a way that makes the mathematical writings on the topic more accessible seems a big win. Moreover, "functor" is a bit more precise than "mappable" - a functor is a mapping that preserves structure. In what sense? The math can guide you. In this case, it means the functor laws.
That's not to say that coming up with other associations to help ease understanding is a problem - I have no problem with saying, "for now, think of Functor as 'mappable'". The equivalent for Monad would probably be "flatMappable", and Monoid would be "appendable".
1971genocide|11 years ago
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.
the_why_of_y|11 years ago
You can't blame that one on Haskell or the functional community - the term was already established before the C++ community decided to use it in spite of pre-existing definitions. They even ignored Prolog's pre-exising abuse of the term functor :-)
A few similar terminological accidents of history come to mind, where the original definition of some term is now obscure and a different definition popular:
- POSIX capabilities (as implemented in e.g. Linux), which are a security mechanism that has nothing to do with what security researchers have been calling capabilities since the 1970s
- Microsoft operating systems using the term "Format" for creating a file system, despite the fact that it is impossible to actually format hard disks at the hardware level since the 1990s
- imperative programming languages abusing the term "function" to mean procedures with side effects
- "thunk" meaning a stub that emulates/bridges different calling conventions, instead of a call-by-name (or lazy) closure
- "Tea Party" used to refer to a fine rock band from Canada
octatoan|11 years ago
But foldl' is horrible, I agree.
sordina|11 years ago
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.
unknown|11 years ago
[deleted]
zem|11 years ago
runT1ME|11 years ago
for expressions in scala are monadic comprehension and implicit parameters are analogous to typeclass constraints.
cies|11 years ago
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|11 years ago
LukeHoersten|11 years ago
windlep|11 years ago
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).
LukeHoersten|11 years ago
Also, a lot of the really common libraries like text, attoparsec (parsers), aeson, networking, etc are highly tuned for low latency and performance. Many use compiler rewrite rules and techniques called stream-fusion to compact a lot of the machine code away. Also aggressive inlining etc can be done.
I'm sure there are some memory-heavy or poorly optimized libraries out there but that's certainly not the norm. I've had no problems with the libraries off-the-rack.
marcosdumay|11 years ago
There should be warnings all over the Prelude and basic libraries documentation.
bsummer4|11 years ago
estefan|11 years ago
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|11 years ago
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#readm...
mightybyte|11 years ago
lmm|11 years 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.
DanWaterworth|11 years ago
wyager|11 years ago
tormeh|11 years ago
tormeh|11 years ago
peteretep|11 years ago
kwindla|11 years ago
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.
harry8|11 years ago
nathankleyn|11 years ago
Some notable ones include:
* Facebook Haxl, an abstraction around remote data access [1]
* Microsoft Bond, a cross-platform framework for working with schematized data [2]
* Google Ganeti, a cluster virtual server management tool [3]
* Intel Haskell research compiler, a custom Haskell compiler used internally at Intel Labs [4]
---
[0]: https://wiki.haskell.org/Haskell_in_industry
[1]: https://code.facebook.com/projects/854888367872565/haxl/
[2]: https://github.com/Microsoft/bond
[3]: https://code.google.com/p/ganeti/
[4]: http://www.leafpetersen.com/leaf/publications/hs2013/hrc-pap...
jeremyjh|11 years ago
icebraining|11 years ago
tome|11 years ago
Presumably I use server-side applications written in Java, but I've no way of telling. If server-side counts then most people with computers indirectly use Haskell via Facebook's Haxl project.
Codas|11 years ago
https://github.com/begriffs/postgrest
grp|11 years ago
lubomir|11 years ago
[0] http://www.shellcheck.net/
mintplant|11 years ago
tobias2014|11 years ago
wetmore|11 years ago
[1] http://en.wikipedia.org/wiki/Standard_Chartered [2] https://donsbot.wordpress.com/2014/08/17/haskell-development...
madez|11 years ago
As a practical note, the fact that educated people use it is an indicator that it is useful.
tragic|11 years ago
[0] http://yaxu.org/tidal/ [1] http://haskell.cs.yale.edu/euterpea/
ihm|11 years ago
unknown|11 years ago
[deleted]
akurilin|11 years ago
musername|11 years ago
pubby|11 years ago
agrafix|11 years ago
boothead|11 years ago
marcosdumay|11 years ago
TheSmoke|11 years ago
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-...
[1] https://github.com/bitemyapp/learnhaskell
kitd|11 years ago
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.
pjungwir|11 years ago
- 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|11 years ago
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
kyllo|11 years ago
Scotty and Spock are both Sinatra-like.
There's a lot of good info here: https://wiki.haskell.org/Web/Frameworks
akurilin|11 years ago
x0054|11 years ago
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?
ufo|11 years ago
Out of the things you mentioned, server-side programming is the one where Haskell fits best. Server-side programming is more amenable to unusual languages because you get to choose your own platform and there are plenty of mature web frameworks you can use (too many of them, I might say). It might be worth a try to experiment writing code in a more type-safe language. Even the simple things like algebraic-data-types are things I miss a lot when working on other languages.
dragonwriter|11 years ago
Yes, and yes.
> Also, can you recommend a good book or resource that uses real world examples to teach Haskell?
The obvious thing to recommend here is Real World Haskell [0], which directly addresses some of the areas you raise.
Also, Write Yourself a Scheme in 48 Hours [1] is more in-depth and real-world than most tutorials (writing a Scheme interpreter isn't exactly a common real-world application, but its more real-world scale than most tutorials address, and it uses a lot of things that are of concern in many real-world apps.)
[0] http://book.realworldhaskell.org/read/
[1] http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
mightybyte|11 years ago
arbsn|11 years ago
Haskell is a general purpose programming language.
outworlder|11 years ago
> "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.
julian_perrott|11 years ago
I'm missing Visual Studio, are there any realy good Haskell IDEs out there? for example ones which allow debugging.
grp|11 years ago
pjmlp|11 years ago
http://leksah.org/
http://eclipsefp.github.io/
mercurial|11 years ago
Vim + ghcmod + syntastic has a useful subset of the functionalities of an IDE.
agarden|11 years ago
__Joker|11 years ago
IanCal|11 years ago
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|11 years ago
cies|11 years ago
http://www.reddit.com/r/haskell/comments/33mnlc/becoming_pro...
musername|11 years ago
there are only two problems in CS, cache invalidation and naming things - phil karlton
prajjwal|11 years ago
An RSS feed would be great.
Also, does anyone know what colorscheme this is using for the code samples? Looks nice.
solaris999|11 years ago
michaelochurch|11 years ago