Hacker News new | past | comments | ask | show | jobs | submit login
Hello Haskell, Goodbye Scala (joshbassett.info)
100 points by nullobject on Jan 22, 2013 | hide | past | web | favorite | 116 comments



For personal projects or for learning the principles of FP, there is nothing wrong with using Haskell.

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.


When did you use Haskell?

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.


>When did you use Haskell?

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.


Two years ago the situation was far worse, dependency-hell-wise.

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...


It's still bad and cabal is still bad. 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.

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.


I am not saying cabal is perfect, but the situation has dramatically improved since the prevention of spurious reinstalls. It also seems that hackage uploaders are playing nicer these days, and I just generally get far less breakage.

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.


It's rarely painful these days because you've spent 5 years learning it.


Experience comes into it too, but as I mentioned earlier, they mostly fixed the "butteryfly problem" by avoiding spurious reinstalls. The butterfly problem was the source of at least 90% of the pain relating to cabal installations.

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?


>It's still bad and cabal is still bad.

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.


>You have the exact same problems with CPAN

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.


Nobody's pretending that everything is "hunky-dory" with Cabal--there are concerted efforts at fixing the problems, and discussions on it come up often both on the mailing list and on /r/haskell. However, some people are pretending that it's worse than it really is. It's not perfect, but it's certainly not bad enough to not use Haskell!

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.


>It's sbt on Scala and ghc-pkg/cabal on Haskell that have been a pain in the ass.

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!


Could you elaborate what 'real-world' means to you in this context? Millions of users, hundreds of servers, a personal blog? 'Real-world' is often a very broad term with a huge likelihood of misunderstandings.


Serving my real needs both for a professional job:

* 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.


Thanks.


Interestingly, despite their respective reputations Haskell is by far more popular than Scala:

http://www.langpop.com/


There's lots of measures: Indeed job listings, google searches, mailing list volume; tiobe tries to incorporate a few.

http://www.drewconway.com/zia/?p=2892

http://www.wired.com/wiredenterprise/2012/06/berkeley-progra...


I think "respective reputations" can be quite subjective. In my circles Haskell is definitely more talked about/used.


Sure: In the "hacker" world it seems that people prefer Haskell (Purely functional, native code) to Scala (OO Hybrid, JVM).

However I'd say that Scala is far more popular for building bussiness/real software than Haskell is (Twitter for example).


What is a war file?


It's short for (Web Application ARchive), it's a jar file used for deploying web applications written to work on the JVM.


It's a zip file following Java convention that can be dropped in any Java web application server (like Apache Tomcat).

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]).


Are you suggesting that SO - StackOverflow.com - runs on Java?


Having no idea what the software stack is, and only basing a guess on having read plenty of Joel's musings, I'm guessing a Microsoft technology. I'm sure someone has the goods, or Google could probably answer.


It's an ASP.net MVC app, if I recall correctly. The .NET world has a parallel mechanism to .war deployment, though.


I think he is suggesting that the number of java related questions on those sites indicates the language is widely used. Neither SO or quora run on java.


I had the exact opposite experience. We switched from scala to haskell and it has been a huge relief. I spend no more time dealing with dependencies in haskell than I did in scala, and our team contains precisely zero people with any post-secondary education (I didn't even finish high school in fact). The myth that you need "a team of PhDs" is so bizarre and so far from reality that I don't understand how anyone who has taken any time to actually try haskell could repeat it.


I've invested a lot of time in trying to learn Haskell properly.

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.)


One of the things I like about Haskell is that there's never scarcity of new concepts to learn: Functors, Applicatives, Monoids, Monads, Monad transformers, Comonads, Arrows, Lenses, Foldables, Iteratees... And every one of these has a world in itself!


On the other hand, that one time you just need a simple library for something, you get to use some guy's pet experiment for learning one of these concepts (Monoids, Monads, Monad transformers, Comonads, Arrows, Lenses, Foldables, Iteratees, Functional-Reactive Programming) you haven't learned yet just to parse some XML.

Yeah, a real productivity booster. It's like batteries included but with C4 attached to every battery.

Sometimes, people have work to do.


Yeah, those tricky monoids. So hard to learn, and even harder to use a library based on them. You have a whole whopping one function to learn, that does some incredibly convoluted and arcane nonsense called "appending"? What a horrible language. You should definitely devote more time to complaining about ridiculous strawmen like this, it seems like a very good use of time.


Here is some of my code to parse html:

    tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
    (path, score) <- css "td[class~=score-time] a" >>>
        (this ! "href") &&& (getAllText >>> arr parseScore) -< el
So yes, you do have to learn about arrow syntax in order to use HXT efficiently. For most newbies it is not an easy concept to grasp, not helped by the fact that HXT isn't a very well documented library.


    tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
This, on the other hand, is one of the thing I don't like about Haskell: there are 4 operators on this line, and no easy way to see, at a glance, their precedence. Also, some operators are "mentally interpreted" as flowing data left to right or right to left; changing the direction mid-statement, I find confusing. I have the same problem when unix shell commands are expressed like this:

    program < input > output


"Use >>> like a pipe in unix" is not an easy concept to grasp?


I shouldn't have to learn what parser combinators are to just rip a few things out of a tree of XML.


Good, good. Now take it to the next level. Rather than just using a scary word that means something very ordinary and mundane, try making up totally nonsense combinations. Like "I shouldn't have to learn co-recursive monomorphic functoid transformers just to open a file!".


I personally find the "universe of knowledge" to attain an attraction, not a repellent.


I guess it depends in what context you're looking at it. What makes Java so successful is its simplicity. You can get fairly quickly up to speed on it, and you can have junior coders on it producing code quickly without shooting themselves in the foot too much or spending a couple of hours trying to find out how to update a tree efficiently.

On the other hand, as a hobbyist, it's absolutely fantastic.


In the case of Java, the simplicity of language leads to complexity of programs.

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.


But many dev shops just want a pool of cheap labour and care little about robustness. And the abundance of cheap labor is a function of both learning curve and critical mass.

I gather this is not a design goal of a language with "avoid success at all costs" as an unofficial motto


I learned F# as this guy learned Scala. I too dived into Haskell after a while and learnt a lot of new things.

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?


Comparing a statically typed language to a dynamically typed language is silly when talking about type signatures. Of course you don't have type annotations in Ruby, it's a dynamic language. But it also means you don't get compile-time guarantees.

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>
And SomeFormResultWithWidget would have to be defined elsewhere. I'm not convinced it's clearer than the Haskell version. And you could easily remove the verbosity of the Haskell version with a type alias.


Why not define a type alias?

  type AppForm a = Html -> MForm Blog Blog (FormResult a, Widget)
And then you get:

  newPostForm :: AppForm (Text, Text, Text)


The real fun with type aliases is that GHC rarely uses them in error messages. So you get about 20 lines of type vomit whenever something refuses to compile and then you get to try to piece it back together into a level of abstraction that humans can handle.


Well, it isn't the case here, is it?


>LINQ ... However, monads, monoids, functors still don't matter when you switch over.

Funny that you say that; LINQ is actually implemented using monads.


>I've used Yesod to write a small app

Well, hopefully now you know better.


I can respect and applaud the man for wanting to learn, When I picked up scala I had the same experience he did. When I went to solve a problem I immediately fell back to the imperative style of programming since that's how my brain has worked for a decade. It has taken real time and effort to _try_ and solve problems in a functional manner. Turns out that's a really good and elegant solution for some problems and a skill that's worth developing. If another language makes that training easier then by all means use it. One of the real benefits of scala is you can be useful in it ( just solving the problem ) while you have all the tooling necessary to make those elegant solutions when you have the requisite skill set to implement them. It would be handy if scalac has a setting like -Werror in C land where non-functional constructs would be flagged in the codebase.


If anyone wants an introduction to functional programming using Scala, I really recommend Martin Odersky's coursera course (https://class.coursera.org/progfun-2012-001/class). He restricts you to functional Scala; there isn't a mutated variable in the whole course. It isn't officially a course right now. You won't get a certificate for taking it, and I don't think the grader is turned on, but the other materials are still there.

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. 
I recently had this same a-ha moment listening to Gary Bernhardt (destroyallsoftware.com) talk about the functional core with an imperative shell.

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.


Does the course cover Functors, Applicatives, Monoids, and Monads? What about other higher-level functional constructs (Arrows, Zippers...)?

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...


>Does the course cover Functors, Applicatives, Monoids, and Monads? What about other higher-level functional constructs (Arrows, Zippers...)?

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.


If anyone wants an introduction to functional programming using Scala, I really recommend Martin Odersky's coursera course (https://class.coursera.org/progfun-2012-001/class). He restricts you to functional Scala; there isn't a mutated variable in the whole course. It isn't officially a course right now. You won't get a certificate for taking it, and I don't think the grader is turned on, but the other materials are still there.

That course does not allow registration right now.


Really? Normally you can enroll for old courses that have completed and view the old material. I've done it before, but you do need a coursera account. Is that not working in this case?


Exactly:

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


"Enrollment is Closed We are sorry"

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.


You can't compare time-based courses to general information provider like wikipedia. Providing content of previously offered courses is controlled by colleges/instructors [1]

[1] http://help.coursera.org/customer/portal/articles/572218-can...


When did they take that down? Thankfully I got the material for the course I was working through downloaded. Why would they do that?


If you were enrolled before just go to your courses page, find fp course and go to archive of your class (with all the content, problem sets, forums, etc).


Would it be okay/possible to post the materials online? I'd be interested in going through the course.


The course material is still available, although you'll need to sign up for a Coursera account. It also looks like they're running another course in March 2013.

https://class.coursera.org/progfun-2012-001/class/index


Weird, when I click that link I'm asked to login. When I login it says to check out other courses.


Not to mention, functional programming forces you to grok recursion and higher-order functions. Huge side benefit of learning FP that you can also implement in your OOP to write more elegant methods. Never write "for int i..." again.


And hope that your imperative language supports tail call optimization? ;)


Ah. Well, yes, you wouldn't want a call stack overflow.

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.


My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello ML", "Hello Clojure", "Hello Rust",...

I don't know why you say goodbye, I say hello.


That's where you went wrong. You're supposed to start by writing factorials & quicksort.


Maybe you should actually learn something about FP rather than trying to learn a bunch of languages?


I think you'll discover that languages are actually much smaller than they appear in your mirror.


That's my point. You're talking about jumping around from language to language, but Functional Programming techniques tend to be applicable across all of them. My personal angle is that Haskell puts up less bullshit in your path while you're learning stuff about type based reasoning at the cost of being much less like things you may have seen before.

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.


I wouldn't call opening myself to multiple languages "jumping", and it seems a bit of a leap that you assume so. (Note that I said nothing of the proportions invested in each.) The only point of my post was that one does not need to wall oneself off from one language in order to open oneself to another.

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.


Learning any one of these, if they have a strong type system and an emphasis on immutable data are going to prepare you for the literature.

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.


You're a strange chap. If you agree that languages are small – so much that you insist it was your point when, in fact, it was mine – then why do you think there's such a large cost to picking up another one?

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?


You said, 'My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello ML", "Hello Clojure", "Hello Rust",...' and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies". You really have to use a language for a while to understand how to make a good software design inside of it. It's not the cost of learning the language, it's the cost of not spending enough time working with the language.

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.


...and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies"

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.


Pro tip: Don't make glib comments and be surprised when people respond brusquely.

Also, Pro Tip: Assumptions are necessary in order to have reasonable conversations. People aren't inference engines.


That word doesn't mean what you think it means. My initial post is sincere wisdom.

And your initial brusqueness didn't bother me, FWIW. The determined obstinance does a bit, but no worries.



That which does not conform to your world view must be disparaged, because you'd feel embarrassed to be caught red handed in the process of learning. I get it.


Yeah, well, y'know... that's just, like uhh... your opinion man.


I enjoyed the read, but I borked at your suggestion that not being purely functional, and the language barking at you if you break that convention stops you learning functional programming.

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.


I haven't seen much functional code in elisp, which is the Lisp I most commonly read.

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.


Common Lisp is a multi-paradigm language. The standard supports imperative, functional and object-oriented programming styles. It even tries to mix them. The Common Lisp Object System for example uses Generic Functions, and not the more usual message passing mechanism. The language is also traditionally extended by other paradigms: rule-based, logical, actors, agents, concurrent, ...

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.


Lexical binding, higher-order functions, etc are very common in Python, for example. Except for TCO which is not widely supported in Python, and problematic if support is not guaranteed, Python seems to be just as functional as CL. Nobody cites Python as a functional language, yet people mostly cite CL as a functional language.


Functional Programming is discouraged in Python. See the various statements by its Benevolent Dictator starting here:

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

then here:

http://python-history.blogspot.de/2009/04/origins-of-pythons...


So more a matter of the atmosphere around the language than the language itself.

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).


Sometimes you need side-effects. The world is far from pure. I think Common Lisp gives you exactly the tools you need and gets out of your way. Dynamic variables (a very specific term in CL) are simply awesome. You need side-effects when you're dealing with I/O -- sockets, files, shells, etc. I prefer languages that make it as painless as possible when I need it.

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.


> Dynamic variables (a very specific term in CL) are simply awesome.

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...


Sorry, didn't mean to imply it was a feature unique to CL.


Type-inference doesn't provide anything related to parallel maps, though Haskell's type system can verify that they're safe. Switching an arbitrary loop to a parallel one in C#, Scala, Java, whatever, is certainly a crapshoot.

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...


All kinds of large Lisp codebases are written in an imperative style. There's no reason it's any more difficult to write that kind of code in Lisp than it is in any imperative language.


Anybody here has developed and deployed a Scala-based or/and Haskell-based project for production? I mean systems for business purpose where rubber meets the road with timeline to hit and budget to meet. Far too often the stories are shared by people who learned a new language for 3 months and implemented a pet system where only a few real users. Definitely I respect their zeal and curiosity, but I am more interested to know what the veterans are thinking


At my company we started a Scala project a little over a year ago. Two of us had a Java background the other two had a C++ background. We targeted Scala 2.9, Akka 1.3, and ran it on JVM 1.6. For us the stack proved to be very easy to work with. The project spent about 5 months in development and has been in production for another 9 months with weekly updates.

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.


Our company uses both Scala and Haskell for revenue-producing projects. There's a lot that goes into choosing a language for such projects. I think it's fair to say that Scala is not really a beginner friendly language, nor do I think it is meant to be. Odersky's Coursera course is pretty heavily inspired by SICP (see 'Scala by Example' for an earlier manifestation of this material). And SICP was definitely designed to be used as an intro to programming. But as anyone who has gone through SICP can attest, it's probably not the best choice for a lot of people. But the Coursera Scala course is good in much the same way that SICP is. It is deep and well designed. Just not for everyone.

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.


I know of a few strong mostly Haskell places in NYC alone. Likewise I'm actually bootstrapping a biz where I've spent most of the past year building the tech where some of the things I'm doing are only tractable to build by using Haskell.


> I know of a few strong mostly Haskell places in NYC alone.

Hedge funds? Or something else?


Both! more precisely, at least one large quant shop, at least one normal hedge fund (apparently theres a difference!). Probably others in the finance space.

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've recently finished an internal web app in Scala. It uses Play 2.x web framework, Squeryl for database access. The main pain point was that there was no way of reverse engineering an existing database schema into classes for use with Squeryl, but I was able to write my own. Overall I've been very happy with the combination, and I plan to use it on my next project.


Fairly certain that twitter used scala at some point for message passing (back-end); At one point Foursquare was using scala/lift for their web platform.

I'm not certain if this is still accurate; my information is pretty out of date.


Yes. We wrote a webapp in PHP. It has actual paying customers, and handles billing and invoices for real money. As is so common with PHP projects, as we needed to keep adding features, changing functionality, etc it got difficult to maintain, and hard to make changes without adding bugs.

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.


Thanks for sharing. Could you elaborate why you were not pleased with the previous experience with Scala? The project was hard to maintain? Or it couldn't take heavy hitting of requests? Or it has limitation for multi-programmers kind of work?


Scala wasn't really the problem, lift and play were. Scala is fine, although it did feel like using an ugly crippled haskell at times. Lift and play both presented us with a bad combination of being both immature (which means lots of missing functionality) and opinionated (which means forcing you to do things their half-finished, not really working way). We ended up using snap in haskell which is just as immature, but because it isn't opinionated, it is easy to fill in the missing bits however you please,


Yeah I've tried learning Scala for a year.

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...


While i liked his gumption, I personally thought god i don't want to do that.. I have been playing around haskell on and off, in my free time, and have come to a conclusion that while it's a fun and cool language to play around, it may not be useful(as in career) hobby. It might be categorized as pure fun language learning.


Haskel/Scala has Learn You a Haskell/Scala for Great Good! and Lisp has The Land of Lisp.

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.


I find it unconvincing. That Haskell deemed is better for learning functional programming for the sake of learning functional programming does not really say much about general usefulness.


And the OP is talking only about learning FP, not about general usefulness.

Not sure what you are unconvinced about.


The title and the first few paragraphs gave the impression that this was an article about the general utility of the two languages. Only half-way down did the truth out.


Maybe one shouldn't make general comments about a piece one hasn't read in its entirety.

Especially for an 11 small paragraphs piece.


I did read it fully. Then I commented that I found it unconvincing, which in my book is one step below misleading.


I then find unconvincing your usage of the word unconvincing.


Yeah, you are likely to find it unconvincing if you are hoping to be convinced about something the author isn't talking about. Perhaps the issue is your expectations, and your unwillingness to take the writing for what it says rather than what you want it to say.


Nice choice! Learn You a Haskell for great good is an excellent book, I learned a lot reading it.


>For christmas I bought myself a copy of Learn You A Haskell For Great Good by Miran Lipovača. Apart from being a great Haskell learning resource, it’s one of the best programming books I have ever read.

I second that. Miran is a superb technical writer. He also annotates the book with little excerpts from all my favorite movies.


Perhaps Scala was built for introducing functional programming gently to Java programmers, with the intention to make them switch to Haskell.


Obsessive, compulsive, pure functional disorder. Now drop it all and go and build something.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: