Hello Haskell, Goodbye Scala
joshbassett.info
joshbassett.info
From personal experience however, I will not be using Haskell again for a larger professional project, because our team ran into too many time consuming issues and problems that have been solved successfully in other languages/environments (especially the JVM) like dependency management or reasoning over runtime characteristics before deploying the application on production systems. Especially memory consumption is very hard to predict.
Of course, the language also has its benefits and even after some years it tickles your brain just the right way.
I like programming in Haskell very much, but in real world projects (you know - when you work in a team not only consisting of PhDs) I prefer Scala or Java, because getting a war file deployed or profiling an application is just so much easier.
YMMV, of course.
The dependency hell situation has vastly improved (and there are plans to make it much better still).
I agree that a downside of Haskell's very high level nature is difficulty to predict some runtime characteristics. This is just an instance of the general trade-off between low-level and high-level languages. Everyone is already comfortable with the loss of easily predictable performance incurred by GC, but people are still not comfortable with the same w.r.t laziness.
I use Haskell for real world projects, and I find it more practical and more suitable than any other language I've ever used. Laziness rarely bites me, and has incredible real-world benefits such as easy refactoring and simpler code.
I think the silliness about PhD's is very very silly. Of the Haskell programmers I know, the majority don't have a first degree...
About profiling -- I have never profiled a Scala/Java application, but how much easier is it compared with: "cabal configure --enable-executable-profiling", and then running the program with "+RTS -p"? It may not be point-and-click, but it really is not hard at all.
Roughly two years ago.
>I think the silliness about PhD's is very very silly.
Of course it is. I just wanted to make a point that the "average programmer" has probably never seen a single line of ML-syntax before.
>About profiling -- I have never profiled a Scala/Java application, but how much easier is it compared with: "cabal configure --enable executable-profiling", and then running the program with "+RTS -p"? It may not be point-and-click, but it really is not hard at all.
I don't remember exactly what we tried, what worked and what didn't; we had no experts on the team, and just came to the conclusion that hooking up jconsole/yourkit/<insert jvm profiler here> to a running jvm process and see what's happening in real time on an app server was so much more comfortable.
About hooking up the process for some profiling information, take a look at:
http://ocharles.org.uk/blog/posts/2012-12-11-24-day-of-hacka...
Your propagandizing is either based on very insulated anecdote or you're being disingenuous for the sake of promoting your favorite language.
The salesmanship does not help Haskell and sets expectations poorly. Fix ghc-pkg and cabal!
Clojure and Go make this look ridiculous and unnecessary.
N.B. Been using Haskell off and on for 3 years. Never once has it not been a pain.
Lots of work is being done on Haskell's package system to make it better.
I've been using Haskell for 5 years. It used to be very painful. It is only rarely painful these days.
They are also going to allow multiple installations of the same package version with differing dependencies very soon, which will help alleviate some of the final problems still there with cabal.
I do think that it is not my relatively smooth experience that is the anomaly, but your unsmooth recent experience. Perhaps your installation was somehow borked? Perhaps you were trying to install new packages using a very old "cabal-install" that still had long-fixed issues?
If you just install the newest Haskell Platform and run "cabal install cabal-install" that does work on Linux. For Windows, IIRC, you also need to install cygwin/mingw (well-documented) and then it is a smooth install as well. I don't know about OS X but it is generally smoother than Windows.
Can you describe in more detail the actual problem you encountered?
No, it isn't. You have the exact same problems with CPAN and everyone and even the most devoted perl-haters will admit "perl is a terrible language, but CPAN is amazing". You run into the exact same problems with every other language, the only difference being dynamic languages tend to be lazy about correctly managing version numbers, so you get "installs properly but completely breaks my app" instead of "tells you it can't install because of a version conflict".
>I was in #haskell on IRC not too long ago and they couldn't even figure out why a haskell-platform install couldn't upgrade its own cabal with no other packages installed.
Well obviously, since it does in fact work just fine, it is quite difficult to figure out what weirdness that individual did to create his problem.
I don't use Perl and that's a crock anyway. I've used Leiningen on Clojure, easy_install/pip on Python and the Golang stack happily with no trouble. I don't like XML or Java, but you'd have a hard time arguing Maven "doesn't work". It's what Leiningen is built upon anyway. Rubygems, rbenv, and bundler aren't perfect but they do largely work for everybody in the Ruby community. Quicklisp has done a lot to improve the state of affairs in Common Lisp and made it pretty easy to use arbitrary libraries.
It's ghc-pkg/cabal on Haskell that have been a pain in the ass. Even sbt on Scala is better and that sucks too.
Cut the tu quoque bullshit, not everybody has a crappy ecosystem. Those that don't, don't because they didn't project a reality distortion field so they could pretend everything was hunky-dory.
Python used to have serious packaging problems. It got over them and eventually became a smooth experience because people recognized the problem and worked on it.
Clojure without Leiningen was horrific. Hagelberg's work there was amazing.
The Golang team has taken things like this seriously all along and since 1.0 a lot of things have been standardized.
Stop denying there's a problem. I'm far from the first person to mention the Haskell ecosystem need works.
The REAL irritation isn't with just ghc-pkg and cabal, but rather that I keep running into crazed partisans like you that won't admit there's a problem. You're the problem.
I remember having annoying problems with Python--both easy_install and pip--just a year ago. Perhaps it's better now, but that just means packaging issues can be fixed. And, for Haskell, people are fixing them.
And yet scala people will tell you sbt is totally fine and has no problems. Just as you pretend pip has no problems, and go has no problems, despite it being trivial to get package conflict errors in both of those.
>Cut the tu quoque bullshit, not everybody has a crappy ecosystem
No, not everybody does. You just pretend a couple do because you have an irrational dislike for those particular cases, while ignoring the fact that they are actually equally good to the languages you do like.
>Stop denying there isn't a problem. I'm far from the first person to mention the Haskell ecosystem need works.
True. And because the haskell community is tolerant to a fault, they humour trolls like you, and try to find ways to make a perfect packaging system. But the reality of course is that all the packaging systems are 95% identical, and the 5% isn't making a difference.
>My REAL isn't ghc-pkg and cabal, but rather that I keep running into crazed partisans like you that won't admit there's a problem. You're the problem.
Yes, obviously I broke your packages and made you troll haskell articles like a petulant child. I had nearly forgotten about doing that, I am quite sorry. To make it up to you, I'll let you give an actual, real example of a problem cabal presents that doesn't happen with python. Ready? Go!
* Debug information processing and analysis
* Concurrent execution of tests
* Build systems
* Various automation/scripting needs and other auxiliary projects
Also, in a different context, a structural editor for programming based on our own GUI framework (~10KLOC so far). This project is still preliminary but advancing at a (mostly) steady pace.
http://www.drewconway.com/zia/?p=2892
http://www.wired.com/wiredenterprise/2012/06/berkeley-progra...
However I'd say that Scala is far more popular for building bussiness/real software than Haskell is (Twitter for example).
Basically a lot of sites you go to have been deployed by dropping a .war file in a Java web application server. That technologically powers a gigantic part of the Internet (just look at SO or Quora or expert exchange or any TIOOBE index or any Java job offer: Java webapps are pretty much powering the Real-World [TM]).
On one hand, it's incredibly rewarding when a completely new and strange concept finally 'clicks', then you write a few lines to test your understanding and it just works.
On the other hand, it's frustrating to realize that there are still a lot of concepts you don't fully grasp, several libs that are still out of your reach, yet another completely new way of structuring your code that you are yet to unravel. Essentially, that you are (I am) still a newbie.
All in all, I find Scala better suited to learning FP and applying your newly-acquired knowledge to develop mildly useful apps, as quick results usually lead to more motivation. Just IMHO.
(Not to mention there are many libs that aren't yet up to par with their JVM counterparts, but that's another can of worms.)
Yeah, a real productivity booster. It's like batteries included but with C4 attached to every battery.
Sometimes, people have work to do.
tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
(path, score) <- css "td[class~=score-time] a" >>>
(this ! "href") &&& (getAllText >>> arr parseScore) -< el
tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
program < input > outputOn the other hand, as a hobbyist, it's absolutely fantastic.
The extra difficult-to-learn parts of Haskell makes for programs that are more practical, shorter and easier to work with.
There's a trade-off between simplicity and power - and we don't really want to maximize simplicity only. And if we did, Java would not be a good candidate either.
I gather this is not a design goal of a language with "avoid success at all costs" as an unofficial motto
Having learned some great functional tips, I came back to my regular C#/Ruby and applying LINQ and Ruby's blocks seemed more natural to me. However, monads, monoids, functors still don't matter when you switch over.
I've used Yesod to write a small app. A typical form in Yesod (for model binding) has this signature:
newPostForm :: Html -> MForm Blog Blog (FormResult (Text,Text,Text), Widget)
Even after learning Yesod for a while, I wasn't able to completely reason with that signature. Why bother with all the name of the application, sub site, formresult, widget when all you want is just three simple form fields? Rails gives it to you in params[:form]. It's just too easy in Rails with a lot of gems lying around for every task you decide to do. And when you're stuck, you're just a google away from getting your answer.
So my question is: after learning Haskell, do you intend to stick to it? Did I make a wise decision in ditching Haskell?
Ask yourself what would be the type signature of a similar function in another statically typed language. You have a parametrized type with three parameters, which would give you something like:
MForm<Blog, Blog, SomeFormResultWithWidget>
type AppForm a = Html -> MForm Blog Blog (FormResult a, Widget)
newPostForm :: AppForm (Text, Text, Text)Funny that you say that; LINQ is actually implemented using monads.
Well, hopefully now you know better.
In my mind, the really mind altering thing was seeing not just that Object Oriented and Functional programming styles could be compatible, but that they were in many ways complementary. Good OO design, particularly the idea of small single responsibility classes, is kind of enforced by functional style. If you need to pass around fifty variables just to increment a counter, you'd go crazy. So writing functionally forces you to figure out ways to split things up. Similarly, its easy to convert well small, single responsibility OO objects into functional ones, and just a nightmare otherwise.
I was just blown away at how much a course on functional programming helped me to understand OO design.
> In my mind, the really mind altering thing was seeing
> not just that Object Oriented and Functional
> programming styles could be compatible, but that they
> were in many ways complementary.
In screencast #81 (Nov '12), he starts with code that looks like what most people would write if we wanted to write a script that compiles every .markdown file in the current directory to .html. It's an imperative loop that File.reads each path, compiles the file, determines the new filename, and File.writes the result.
Then he refactors away everything except the file I/O into a Page class with immutable methods. In other words, the only mutation that goes on in the end is in that loop (where it can't be avoided). And the result is a Page class that is effortless to test.
Something immediately snapped when I saw that even though it seems so obvious in retrospect. The boundaries of responsibilities in a system became incredibly apparent.
I don't know quite where it happened, but between Martin Odersky's course and idly watching Bernhardt's screencasts, I gained like 10 levels.
From what I've seen, I think Scala is a nice language. One thing I don't like is particularly that it's a bit kitchen-sink-ish: there's a whole lot of syntax and semantics to learn, seemingly due to the OO side of the language. By comparison Haskell is quite simple. All the higher-level constructs are implemented in plain Haskell, so you can easily understand them but thanks to a flexible, uniform syntax, using them doesn't feel clunky.
To me the main reason for not learning FP through Scala, however, is that the community isn't organized around teaching FP in the same way that Haskell is. It sounds like this course is an exception. But otherwise, I found that trying to learn about Monads from the scalaz documentation was not satisfying, and we all know that "A Monad is a Sheep with Curly Hair" blog posts are a dime a dozen (in Haskell and Scala). Learn You a Haskell made the concepts, and also their benefits, clear to me for the first time. Now I'm working through Real World Haskell to build my chops and reinforce my understanding.
While trying out both languages and picking which one to learn, I came across an interesting post on Gilad Bracha's blog which had a lively discussion including a comment by the [claimed] original author of Scalaz [1], which made it clear to me that it would be easier to start in Haskell and move to Scala than vice versa. I think I (and the OP) are both seeking to gain a strong foundation in FP concepts. To summarize, in my experience most Scala resources on the internet (blog posts that come up, etc.) aren't quite as good in this regard; at this point a lot of the Scala programmers using these techniques are probably Haskell programmers anyway.
That being said, the internet is a huge place. If there's a Scala equivalent of this post [2] please do share it! I agree with other posters here that Scala has quickly gained a significant amount of industrial acceptance. I'd imagine that I'm more likely to write Scala professionally in my lifetime than Haskell. But I also believe I'll be better off approaching it having learned the FP concepts in Haskell first.
[1] http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-m...
[2] http://stackoverflow.com/questions/1012573/getting-started-w...
Nope. It's very intro level, though the students basically begged Odersky for a part II, and he seemed very open to it.
And I totally didn't mean to imply that I thought people should learn Scala instead of Haskell. I was just sharing a FP resource I found helpful.
Not actually having mastered the higher level functional constructs yet myself, I really don't have a firm opinion about which is the "better" approach. Personally, I've looked at both languages and I know that each helped me understand the other. So if I have any opinion, it's that if you get stuck, it's probably a good idea to approach it from another angle, like the author is doing.
That course does not allow registration right now.
Enrollment is Closed
We are sorry, but the enrollment for Functional Programming Principles in Scala is currently closed. We will inform you via email when new Coursera classes are launched, so stay tuned for more.
Meanwhile, check out some of our other classes here!
The Coursera Team
Yeah me too. Coursera = MCOC = Massively Closed Offline Course.
Imagine wikipedia only allowing people to view the "Scala" page between the hours of 7:30 and 8:30 on alternate tuesdays, otherwise you're outta luck, for completely arbitrary reason.
Very unimpressed with the MOOC trend. Bring back MIT OCW where I can download and watch video lectures whenever I want, forever.
[1] http://help.coursera.org/customer/portal/articles/572218-can...
I am starting to realize why people who know functional languages despise Java. I first started programming in Java, but now the more FP I learn, the uglier Java gets.
I don't know why you say goodbye, I say hello.
Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper understanding of techniques. At most you'll understand how some very basic concepts work in different languages.
Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper understanding of techniques.
I suppose that's a fair view if one starts from the assumption that techniques are all that is worthy of pursuit.
But there is also comparison of priorities implicit in different design choices. There is also an appreciation of history (ML is a good example of that) and an appreciation for industrial frontiers (Rust is a great example there: if you're not following Graydon Hoare you're missing out). Each language also has its own unique traits that don't readily map to others. Haskell's lazy evaluation and monadic IO are a great example there. Want to wield the sword of homoiconicity? Better learn a LISP.
Moreover, learning Haskell prepares you to read a lot of literature. ML prepares one to read Chris Okasaki's book on purely functional data structures. (Yes, there is a Haskell appendix in the back of the book, but knowing both means you can compare them!). Scala is worth study as a case study in the tradeoffs of making on object/functional hybrid.
The human brain is an associative machine, you know. Sometimes the act of broadening has the consequence of strengthening (or even deepening), because you're giving your melon more things to interrelate.
Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
Now on the other hand, if you just like looking at a lot of languages and seeing the design tradeoffs, you can spend a lot less time using each one to get that perception.
But you only mentioned learning FP in the first place. I didn't divine that comparing the language design was your reason for not picking one and sticking with it.
That's where you went wrong, then, because it doesn't in any way rule out the possibility of learning it either.
In your initial response, you said "Maybe you should actually learn something about FP...". Let's make this clear: you don't know me.
Pro tip: if you have to make assumptions about other people, then it's possible to make a wrong assumption. In these cases, it's often better to ask a question than to launch into criticism based on assumptions.
Also, Pro Tip: Assumptions are necessary in order to have reasonable conversations. People aren't inference engines.
And your initial brusqueness didn't bother me, FWIW. The determined obstinance does a bit, but no worries.
Nah, fits what I meant.
Take most Lisps (I'll assume scheme, because it's what I'm most familiar with), which give you more than enough side-effecty rope to hang yourself with should you so desire- but you won't get far unless you're coding functionally.
Some Common Lisp code I saw was also very imperative.
Scheme seems to be a more functional language, but I don't really see why people consider other Lisps any more functional than say, Python.
Still Common Lisp uses mechanisms of functional programming widely. It supports lexical binding, many library functions are higher-order functions, etc. There are also some programs which are written in a very functional style and most implementations support tail call optimizations to further make a functional style useful.
Common Lisp does not enforce a particular programming paradigm. As a start all three supported would be used by a programmer. He or she might even add some more, if necessary.
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
then here:
http://python-history.blogspot.de/2009/04/origins-of-pythons...
Intrinsically, Python and CL seem just as fit for functional programming (with semi-legitimate reliance on TCO being a slight benefit for CL's side).
Purity, IMO, is over-rated. You can write pure FP code in C++, Java, or CL if you wanted to. It doesn't matter whether you can write imperative code with side-effects and doesn't make those languages any less useful. This purity thing that the Haskell-zealots are on about just stinks of bullish*t and it's not good for you.
That being said, Haskell does do some neat things and there is a lot to learn from it. It's type-inference lets it do some neat things like parallel maps and so forth. It also shows us that laziness is not always a good default. I'm not hating on Haskell but anyone who drools over its, "purity," is not saying much at all. Purity is not an attribute that wins you any battles.
I may be wrong but I think the name is rather common outside CL too (assuming you refer to "variables with dynamic scope rather than lexical"). E.g. as we are talking of scala
http://www.scala-lang.org/api/current/scala/util/DynamicVari...
The real benefit to purity and laziness (imo) is the STM. The type system (and pure functions) allow rerunning transactions arbitrarily without worry about side effects, and laziness by default minimizes lock contention by deferring most code execution outside of the transaction block. Joe Duffy has a pretty good writeup a few years ago outlining the difficulty of writing an STM for languages without such guarantees, it's definitely worth a read: http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetros...
What the author calls old habits, I call productivity. A lot of us started off coding imperatively and slowly started adapting functional along the way. It allowed us to get the best of both worlds. Over the past year we've definitely stumbled a few times (mutable objects for akka messages are really really bad), but overall we've been very happy with the stack.
One of the only real ongoing problems we are continuing to struggle with is limiting the impact of big GCs in production. Scala tends to generate more garbage then pure Java, so the GC has to work harder. Most of these objects are in the eden space, but we can run into memory fragmentation issues, which leads to eventual long compaction cycles.
Haskell has relatively simple syntax and coherent semantics (being unencumbered by a 'foreign' VM eco-system, such as the JVM). As such, it is somewhat easier to get into. But to quote Gerry Sussman (co-author of SICP and Scheme), 'Haskell is the most advanced of the obsolete languages'. It gets deep pretty fast. You don't learn Haskell, so much as get initiated into it. It's an ongoing process. This can be said of Scala as well. Neither are particularly small languages when you consider their entire respective eco-systems.
In general, if you are already competent in a mainstream, dynamic language, and want to get your feet wet in functional language concepts, diving into Haskell is not a bad idea; but you are not likely to stick with it. I would recommend Clojure for such people. However, if you are already a Java programmer (and don't completely hate it), then the transition to Scala will be tough, but somewhat gradual. It is designed to be. But I would also say that the Scala world (not so much the language itself) is easier to grok if you know Haskell to at least an intermediate level. I think it is worth the time to learn Haskell and build something useful with it. It does not need to precede learning Scala, however.
Hedge funds? Or something else?
Theres at least 2 not finance enterprise focused haskell shops in NYC that are currently profitable and growing, theres at least 1-2 other places that have a smidge of haskell here and there.
Oh, and theres my place, Wellposed, which is pre launch but for the first product, only Haskell is used, and if it works out, the # of (partially) haskell shops will increase quite nicely :)
I'm not certain if this is still accurate; my information is pretty out of date.
So, we re-wrote it in scala using lift. We were not pleased with the results. So we re-wrote it in scala using play. We were even less pleased. So we re-wrote it in haskell using snap. We were finally happy. That version is now in production, and the type safety of haskell makes doing changes far safer. The maintenance burden is much smaller now.
It was painful, real painful and I felt like I didn't learn much from it.
Now I'm learning Erlang and I'm applying what I've learned from Scala to Erlang and wow. I'm glad I took at stab at Scala. Erlang is wonderful btw, it's so simple there are some minor drawback like no string primitive... I also love the fact that there is no loop, it forces me to think recursively. I guess because it's so simple I can just focus on learning the functional part instead of other stuff such as new objects paradigm (traits, etc..), design pattern ("pimp my whatever"), and type. I'm guess once I'm done with this I'll focus on type, thinking Haskell...
Are there any _why-esque guides to Clojure and FP in general like these other languages have? I'm unaware of any and consider it surprising given the Clojure communities passion.
Not sure what you are unconvinced about.
Especially for an 11 small paragraphs piece.
I second that. Miran is a superb technical writer. He also annotates the book with little excerpts from all my favorite movies.