Haskell vs. procedural programming in the real world [closed]

Answer 1

I learned Haskell because it was by far the best functional language that I tried out of Scala, Clojure, OCaml and Scheme but I didn't seriously expect to use it for work.

As it turns out, it is perfect for those sorts of odd jobs that are too small for a team and would be just too time consuming in Java. So far, I've used it for ad-hoc data migrations i.e. mangling CSV exports into another format, batch conversions of XML (HXT is more concise and more powerful than XSLT), screen-scraping off the internet and software project estimating including modelling risk using the probability monad and producing optimum gantt charts using backtracking. This is all real work that needed doing, that I wouldn't have even bothered to try and do in Java as it would be a multi-day undertaking.

I now use it instead of Excel for anything vaguely mathematical as it is little more effort to create a list of values in haskell source in a text editor than it is to type them into Excel. Once in haskell, I can then do all sorts of magic like backtracking, probability distributions etc. that Excel can't do. If I need a graph then I spit the values out as CSV (2 lines of code) and load them into Excel.

The only downside is that it does take several months to get proficient, but worth the effort IMHO.

Answer 2

The functional concept is coming on strong. Note the flurry of activity and interest around Ruby. I've also noticed a bit more interest in JavaScript beyond a mere browser scripting language lately. You can get ahead of the game by diving in now, though the time invested might not pay off this year or next.

It depends on your general game plan. Are you into programming as an end in itself or as a means to an end? If it's the former, go nuts with Haskell. If the latter, stick with mainstream, "employable" languages. Wait for Haskell to take off and then pounce.

Answer 3

I can see that functional programming can be a plus in a production environment if it's very easy to use by non functional code. MS could see that too when they came up with F# I guess.

Since they both compile to IL, you can handle problems that ask for a functional approach functional and use those solutions very easily in your procedural code.

In that way functional code can easily find its way in a production environment a bit at a time

Therefore, and since the userbase of MS is that big, my guess is that if F# will not catch on in the very near future, that Haskell won't either.

Answer 4

Why procedural and not Object Oriented, not seen procedural being used for many years apart from C.

Commercially speaking. I would go with Java or C#. Doesn't really matter which they both pay well and the skills are interchangeable with other like minded languages such as python, Ruby and JavaScript.

Haskell is worth the time and effort, although it is very academic, some banks use it, although many in Europe and the UK are moving the code base over to F#.

I don't think FOP will be moving at great speeds commercially speaking. But the techniques are definitely making an appearance in the main stay languages. Especially with Multi-Core chip designs and making code run parallel on them.

Answer 5

As opposed to procedural languages, will it be valuable for me to study Haskell and functional programming paradigms?

Not unless you want to be miserable. Luke Plant says, in Why learning Haskell/Python makes you a worse programmer:

So, learning Python and Haskell has demoralised me and encouraged me to write code that is bizarre and difficult to understand...

(This is not entirely a joke.)

Answer 6

I think it's worth the struggle. It will help you to understand how problems are solved and not only how a computer works.

Maybe one particular problem is Haskell itself - As a purely functional language, it's kinda "hardcore" which may on the other hand even complicate things.

Functional programming instead may be extremely useful in a very pragmatic manner - Many OO/imperative languages have now included functional elements for this reason (Linq, anonymous functions, readonly values, function pointers/delegates, type-inference): You can concentrate on what should be done which allows you to express more in less code (that is even less error-prone).

Non-purely functional languages (standard functional languages) like Scala or F# can be integrated easily into existing Java or .NET-projects, so you can combine the benefits of both paradigms where they are needed. For typical advantages of functional languages, see this thread. Just think of extremely powerful parsing (Monadic parser combinators / Parsec) or concurrent programming that is possible with functional languages and you'll see how useful they are.