Four months with Haskell(lexi-lambda.github.io) |
Four months with Haskell(lexi-lambda.github.io) |
There were quite a few things about Haskell that I truly love and miss, such as the type system, but the tradeoffs just weren't worth it to me and I honestly don't think it's mature enough to be considered "enterprise ready". Aside from the learning curve, there were several bugs in one of the Haskell libraries that caused frequent outages (until we were able to pinpoint what was wrong), lazy evaluation caused excessive memory bloat when used incorrectly, and my all-time favorite: needing to switch on profiling in order to get stack traces (this is suppose to change in future GHC versions) which defeated the whole purpose of "haskell is fast". I don't know, perhaps we were using Haskell wrong. From a business perspective, it just wasn't making that much sense given how difficult it was to hire, getting engineers excited to learn it, and having the features needed to monitor a production system.
Advantages of Haskell: unit tests were 100% reliable. Performance was amazing compared to PHP. The number of accidental regressions was very low compared to PHP. Yesod's typed HTTP router was super awesome. The ability to easily parallelize IO was a big deal for reducing latency.
Disadvantages: there was a great deal of internal resistance to learning Haskell. I never managed to separate the resistance to the language itself vs. resistance to a parallel stack, but PHP was really not pulling its weight, so I'm not sure if, say, Go or Java would have had the same level of internal drama or not. Haskell Strings are stupid. We had to write our own high-performance JSON encoder to achieve <50ms service response times ( https://chadaustin.me/2015/02/buffer-builder/ ) on large JSON responses, like news feeds.
So, I love Haskell, and were I writing a new backend for a new company with people that I know would be productive in it, I'd definitely choose it again. But it's not something to be taken on lightly. Even though I was not the original Haskell advocate at IMVU, I did end up supporting it and did what I could to teach it to others.
It was surprisingly easy to teach to people. I remember showing a new engineer who'd never seen any Haskell before monads on a whiteboard and he after I explained monoids and functors and then monads, he just nodded and said "oh, okay, makes sense". He wasn't bluffing - he actually internalized the concept that quickly. The trick with teaching Haskell is to start with specifics and THEN generalize the ideas. "So, you know how you can concatenate lists? And if you concatenate a list with an empty list it stays the same? Well, those properties are true for lots of things, and those things are called monoids."
Sorry, I rambled a bit, but tl;dr: Haskell was a mixed success, brought along some drama, but overall enabled us to reduce the latency of some critical services by about 10x. At least while I was at IMVU, teaching people Haskell was actually not hard. Getting them to care about Haskell or even want to try it was sometimes VERY hard, depending on the person.
Oh yeah, and I 100% agree with slezakattack that Haskell programmers are not necessarily magical systems designers or system programmers. They're just like you and me. Some are better at some things than others. Many of my favorite Haskell libraries were written by people who came from high-performance programming in imperative languages but fell in love with Haskell's safety. Their libraries tend to have nice, safe APIs while not sacrificing performance. :)
I agree that any new technology introduced into an enterprise requires significant investment in training, which can be hard to justify for a startup chasing product market fit.
What was the bug and what was the library?
You could say that Haskell itself is only good at the first of these.
And: that it's common for a Haskell dev to not be good at the first, leads to deeper questions about Haskell's reason for existence at all in industry.
Because of this, the only kinds of FP shops that would hire me want to hire me at a junior or low-paying level, but my market value in lots of other skill areas (machine learning, Python, database stuff, etc.) is much higher, so I'm not willing to take a salary anywhere close to what they think fits the position.
As a result, even though I would love to get industry experience with functional programming, there is a market wage energy barrier preventing me from considering it. I was burned once early in my career with malarkey about how you should accept a lower salary for some alleged other benefit (like cool functional programming, or working with a team of awesome people, or getting in on the ground floor on something, etc.) -- I won't make that mistake again.
So I basically had to learn to divorce myself from real world Haskell practically just as soon as I learned how much I really love it.
Plus, and this should not be discounted, the professional tooling with Haskell is still extremely immature with lots of esoteric corners duct taped together in unsatisfying ways. It's getting better, but if you work with Haskell for real there are likely to be as many, if not many more, extremely frustrating painpoints of the language tooling as with any other language, enough to amortize away all the warm fuzzy happiness you'd get from the status effects of being able to say you do pure functional programming for a job.
The part on errors is mostly "some guys use error but don't mention it". Partial functions are not nice, that's true. In some cases tools like hlint may help. Actually I'm wondering there's no tool / hackage functionality around, that flags modules / (pure) functions that are partial.
For documentation: Starting with Haskell I felt the same, some more examples and more documentation would be nice. But in the meantime I've come to like the concise documentation most often used. When searching for a certain function I don't want to read screenpages of text, but find that function fast. If, however, I need more detail or want to be really sure what the function does I need to read the source anyway.
However, true is that some libraries lack _any_ documentation and it seems you should be grateful to have the typesignatures.
Also, I think more libraries should have examples/ directories so one can get at quick glance how the library is designed to be used. Perhaps even have hackage emphasize the existence of these examples more.
Off the top of my head I've got:
pandoc - translates from one document format to another
ion - a window manager
git-annex - store stuff in git without it being in git.
If we can get to 50 useful "apt-get install"-able programs Haskell will be worth looking closely at again.
This is not trolling, this is useful data. We know FP is fun, cool, funky and all that. It's a different discussion as to what problems remain (if any) and how to solve them (if needed). I just want to see where we're up to in mid 2016.
Thank goodness everything else is library/ecosystem, rather than language, problems. I think those are easier to fix :).
Most of the time I'm too lazy (or consider it too much boilerplate) to wrap strings in classes. But on more than one occasion I've spent too much time tracking down a bug because I passed the wrong string to the wrong argument in a method.
[1] Implementation - https://github.com/louthy/language-ext/blob/master/LanguageE...
[2] Unit tests / examples - https://github.com/louthy/language-ext/blob/master/LanguageE...
[3] The request that led to the feature - https://github.com/louthy/language-ext/issues/95
About half of companies using Scala are only doing so because it is a trendy way to trick people into continuing to maintain god-awful legacy Java (basically same for Clojure too) -- and in these places they code Scala like it is Java, e.g. use mutability everywhere, poor code style, no emphasis on functional patterns.
The other half seem like legit and interesting jobs, but they tend not to believe that self-taught Haskell experience, or on-the-job machine learning experience with say Python (even with pyspark) is translatable to Scala, and they heavily emphasize seeking people who are specifically experienced in exactly their tech stack already and immersed in the culture of it.
Either way it creates barriers that make it seem like my quality of life wouldn't be very good switching to Scala. But if I found a company that valued what I already can do with Python and my statistics experience, and was happy partially training me / helping me while I teach myself idiomatic Scala, that would be great. It just seems impossible to find that, even though some companies pay lip service to that idea.
1. People who learn Haskell put in a lot of effort for their own learning benefit - they're not usually learning Haskell to get a job.
2. Once you learn Haskell you really kind of want a Haskell job to put all this nice stuff into practice.
3. There aren't many Haskell jobs about (in part due to a perception that it's hard to hire Haskell developers).
As a company in the lucky position of hiring for a Haskell role you have a pool of people who have self selected to be above average in determination and smarts, but limited options in employment in their new tech of choice.
source Built a Haskell team at a startup, now work on a Haskell team in finance. Hiring has NEVER been a problem.
Personally, not really.
I enjoy dabbling with Haskell on my open source projects but doing so has made it abundantly clear why I would never want to use it on a production system, especially one I'm responsible for. Laziness making performance intractable, bad tooling (see the stack trace observation above), difficulties hiring Haskell programmers and the fact that while they can be good coders, they are usually very weak on the engineering side, etc...
Both Haskell and Scala are on my list of languages that I love to experiment with on my free time but that I think are not ready for mission critical stuff.
> you have a pool of people who have self selected to be above average in determination and smarts
I hear this claim a lot from Haskell programmers but this has zero evidence.
It's just a human thing to believe that your choices of technology make you better than people who made different choices.
[citation needed]
There's really no evidence that people choosing Haskell are any smarter or more determined than anybody else.
I'm mainly pointing this out because the Haskell community's "We're smarter than everybody" attitude is a big pet peeve of mine.
Mind sharing names?
With Haskell, well, that's probably a lot less of a problem, for now.
If you are able to pay people what they are worth, I can't imagine how easy you'd have it.
Maybe you hire a "developer with experience in functional languages such as Haskell" if you are in a rush. But if you find yourself in a place where you need to hire very specific skills with no time to train, then you have already lost.
Knowing a less-commonly-used language like Haskell could be a fairly good indicator for this quality.
For a "Hello World", maybe. Developing a non-trivial Haskell app or library will require the equivalent amount of knowledge (if not more) as developing a Java app or library.
Claiming that Java is complicated because it has all those "different design patterns and classes and other contraptions" and _then_ saying that Haskell is simple is simply dishonest.
try{
Well, obviously, you're making them write Java.
}catch(CheekyJokeException e){
// todo
}
Sub WriteGoodJava
On Error Resume Next
While True
'todo: write something
End While
End SubYes, after looking at code that reads
int i = (STDIN);
For all C's faults, I still miss the simplicity of "FILE (star)", created by either "fopen()" or "popen()"
Not that I would have wrote that... :-)
$i = <STDIN>;
For what it's worth, this bug was an outlier. The pitfalls of unsafePerformIO are relatively well-known.
For contrast, there a bug in PHP's opcode cache that causes memory corruption in our setup. The best we've managed to do to deal with that by patching PHP to bump the refcount of some object to a billion. The failure condition is sufficiently obscure that it took us multiple man-months to figure that much out.
And this seems like a non-sequitur. A technology can be new to a company without being new in itself.
The latest core language spec is 2010, and GHC (the de-facto standard compiler) adds several new language extensions annually.
I'd go as far as to say it's not a skill you pick with any programming language, paradigm or technology. It's an important skill which happens to be orthogonal to the technology you're using.
I find this curious, since both languages have been successfully used for mission critical stuff, and in particular Scala is deployed for mission-critical enterprise applications. At my day job, for example, but this is starting to look even more common, judging by the recruitment emails I get.
https://twitter.com/donsbot -- author of Real World Haskell
See https://wiki.haskell.org/Haskell_in_industry for more.
Several other financial names including Bank of America Merril Lynch, Barclays Capital, Capital IQ, Credit Suisse, Tsuru Capital are listed.
I am honestly curious whether you think PG's opinions on Python 12 years ago also "make no sense whatsoever" and are "Purely subjective speculation at best". Speculation about my professional growth is irrelevant.
The total market cap of companies coming out of YCombinator is a pretty staggering number.
I don't say that as proof Paul Graham's writings are all true and should be accepted as gospel without question. But it's not credible to suggest Paul Graham doesn't understand "the real world" of software business.
I remember showing a new engineer who'd never seen
any Haskell before monads on a whiteboard and he
after I explained monoids and functors and then monads,
he just nodded and said "oh, okay, makes sense".
He wasn't bluffing - he actually internalized the concept
that quickly.
The trick with teaching Haskell is to start with specifics
and THEN generalize the ideas.
Sorry, I rambled a bit, but tl;dr: Haskell was a mixed
success, brought along some drama, but overall enabled
us to reduce the latency of some critical services by
about 10x. At least while I was at IMVU, teaching people
Haskell was actually not hard. Getting them to care
about Haskell or even want to try it was sometimes VERY
hard, depending on the person.
Oh yeah, and I 100% agree with slezakattack that Haskell
programmers are not necessarily magical systems designers
or system programmers. They're just like you and me.
Could you share your monad teaching technique?
https://code.facebook.com/posts/745068642270222/fighting-spa...
I'm sure there are others too.
Their anti-spam group definitely uses it
First, your response is a straw man; there is an enormous amount of effort put into systems that are more complex than needs to be be. Mostly this is for historical and compatibility reasons (including social inertia). In case of Java, it succeeded because it was based on C++.
Also, simpler programming doesn't always translate to more runtime efficiency. Haskell programs on their own are not very efficient; potentially, yes, but IMHO at this moment efficiency shouldn't be a reason why to choose Haskell over C++ or Java.
Paradoxically, to understand how to do things in a simple way requires a lot of effort, and history seems to progress from more complicated to simpler (although there is also increase in abstraction, because that's what improves productivity).
I work in mainframes, and it's a sort of archeology that gives you a good perspective on that. A good canonical example is datasets; on z/OS, datasets have different organization (different record sizes and whatnot), unlike in Unix, where file is simply a sequence of bytes. There are many other examples from mainframes (like CKD DASD). Some of them were given by historical limitations of hardware (or also done for efficiency reasons), but mostly they are evolutionary dead ends of too much complexity.
So I really think Haskell has simpler building blocks. More abstract, more orthogonal, and so on, than Java (or most imperative languages). The point is, it's not simpler to build something with more complicated building blocks, on the contrary. There are intrinsic complications of the problem (which other reply to me alludes to), but there are also unnecessary complications arising from complicated building blocks (such as, having to deal with different ways to access files on z/OS, compared to Unix).
To conclude, I feel that the concept of Java-like "class" is a too complicated building block that tries to do too many things in one abstraction. And I see design patterns as a sort of evidence, because most of these explain how to build things from classes that are perfectly obvious when you have data types and functions.
What in the world about js8's post, which said (https://news.ycombinator.com/item?id=11895156):
> I actually prefer Haskell, because it is pretty simple, you have datatypes and functions and that's it.. In Java, things are more complicated, with all the different design patterns and classes and other contraptions. I think you have to be smarter to program in Java than to program in Haskell.
did you take to be a claim that Haskell offers equivalents of the vast Java ecosystem, or even any claim about the relative merits of the products of the languages (rather than the ease of using them to program)?
I like Haskell, and I consider Haskell far superior (and more complicated) than Java. I also know Java pretty well. Java is far from being "more complicated" than Haskell. There is a reason why there are way more Java developers than Haskell developers. In my experience Haskell is powerful and elegant but not very practical. Practical are other languages (Rust, C++, Java, Nim, OCaml, ...). That' why Eclipse, Open Office, MS Office, operating systems, mars land projects and other big software is written in everything but Haskell.
https://www.quora.com/Functional-Programming-Which-of-Haskel...
Yi is nice. There is also Leksah which looks even more appealing.
http://leksah.org/images/Bildschirmfoto-leksah-13-linux.png
I just wonder why are there are so few practical applications if Haskell is so practical and "simple".
Turing machines can do all computable things. They are the most simple computers yet they are not practical at all.
> You can have a more complicated thing being more practical simply because there is a better tooling or ecosystem
The point I am making is that after 25 years of age "simple" Haskell should have be a better ecosystem than Java.
I cannot speak for js8, but I think you took his or her statement of personal preferences as a statement of value. (That is, I think that the statement that he or she preferred a simple language was not the statement that it was 'worth' more in any abstract sense.) I imagine that everyone in this discussion would agree that 'simple' and 'practical' are different. I personally think that the lambda calculus is even simpler than the theory of Turing machines, and yet probably still less practical. I enjoy the theoretical beauty and austerity, and I imagine that js8 is in somewhat the same boat.
(For an extreme example of going the other direction, consider Perl, which is an eminently, even sometimes excessively, practical language, but which none among even its most ardent fans—and I am one!—would call simple.)
Haskell is pure functional programming, and it's structure actively discourages a lot of the more common practices in iterative languages. I watched my friend struggle with a very simple web project for weeks while he was learning the language. At the end of it all though, when it finally came together and worked for the first time, he was confident about its behavior in a way I'm not sure I ever could be with the code I write regularly. (I'm a game programmer, so I write a lot of C++ and dabble in Python and Lua.)
I think there's something to be said for the journey that Haskell necessarily takes you on. I don't think the upper skill ceiling for good Haskell developers is any higher than other languages, but the barrier for entry certainly seems to be.
Please link to concrete examples of this. I'm genuinely interested in calling people out on such rudeness. The Haskell community has traditionally been modest and very welcoming and I'd like to keep it that way.
More generally, it makes sense for the sort of people who make non-mainstream choices to be qualitatively different from many who do go with the mainstream.
Plus, someone who's studying Haskell probably is smarter on average than the average developer (and no, I'm not a Haskell developer although it interests me)
People who are just looking to get into software engineering for the money are unlikely to learn Haskell.
They will almost certainly learn Java, PHP, Ruby, Node or maybe even Go, but not Haskell. And looking around SV these days, there is a huge number of people around that are only in it for the money.
Not that that is a panacea... my instinct is you might end up with a very strong technical team, but one that might be more likely to miss the forest for the trees when it comes to building a successful business.
AFAIK there is _nothing_ comparable in the Haskell world!
I know things like Leksah and FP-Complete's online editor but these things are far from being comparable to power IDEs like Eclipse. Haskell, as it is today, is a nice language for study purposes and academic use but it is barely used in the industry. Haskell is by far not so practical as the Haskell community wants it to be.
People have no right to complain without suggesting solutions. So do I. My suggestion: The Haskell community should develop languages based on Haskell which are much more practical, and which use all the nice power features of Haskell - the purity of functional programming for instance. Haskell is too cool to be wasted for academic use. It could be a very nice backend for really practical languages. The first promising attempts are there - IDRIS for instance.
I think you're confusing orthogonal issues. Only writing code because it pays the bills really says nothing about how smart or motivated a person is. Is there a rule somewhere that dumb people can't enjoy programming and learn Haskell? On the other hand I know a few very smart people who only write code because it pays their bills.
It's not about smart vs dumb, it's about intrinsic versus extrinsic motivation. Being smart is an advantage, but it is meaningless without a massive amount of practice. There's nothing about programming that a 100 IQ person can't become competent at it.
Programming is first and foremost, an exercise in frustration. It is exacting and unforgiving in a way that few human activities are. It's somewhat unnatural. In order to excel at it I believe you need to feel an intrinsic thrill when solving a problem that surpasses all the frustration leading up that point, and you need to seek this out over and over and over.
Note that this says nothing about whether you only work for money, or even what brought you to the field. However, if you do not feel this thrill, then you will naturally gravitate towards a job where you can execute rote incantations again and again without having to face new problems. I'm sure there are people who love programming and persist in it despite being terrible at it, but I guarantee you they are far outnumbered by the hordes of wannabe tech millionaires flooding into the Bay Area as we speak, completely oblivious to how much they will actually hate and subsequently suck at programming—and those people ain't learning Haskell.
No, but actually bothering to learn something that isn't what is being shoveled through most major outlets is at least somewhat correlated with motivation.
No, there's no such rule. Can you possibly imagine that there might be any factors at play that affect the observed intelligence of Haskell programmers besides "a rule"?
Please link to concrete examples of this. I'm genuinely interested in calling people out on such rudeness. The Haskell community has traditionally been modest and very welcoming and I'd like to keep it that way.
As a simple example, even dropouts probably know Java.
This is more than two tweets long. How is it supposed to become the viral quote it deserves to be?
jlarocco said two things: "There's really no evidence that people choosing Haskell are any smarter or more determined than anybody else" and "I'm mainly pointing this out because the Haskell community's "We're smarter than everybody" attitude is a big pet peeve of mine."
Note the phrases "smarter than everybody" and "not smarter than anybody else". Those are not nuanced statements, but I don't think they're intended to be absolutely exclusive statements.
Or to put it another way, if you interpret "smarter than everybody" as the claim that Haskell programmers are actually the smartest programmers, then grammatically, you also have to read "not smarter than anybody else" as the claim that Haskell programmers are as dumb as the dumbest programmers in existence - which I'm pretty sure was not jlarocco's actual claim.
