Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Haskell vs. procedural programming in the real world
Few times I heard people saying things like "Every programmer should know Haskell", "You aren't a programmer if you don't know haskell" and so on.
However, I'm not exactly sure if I should bother trying to get a brief understanding of that language or not. Playing around with interpreter (to get intuitive understanding of basics) will take at least few days (if not weeks), and I"m not exactly sure if the result will be worth it.
A bit of background (to get idea of my knowledge)
I've started programming as a kid (somewhere between 10 or 13 years ago) with programmable calculator, moved to basic, then onto non-x86 assembly (reimlementing multiplication and division, and writing self-modifying mouse driver was fun), pascal, delphi, now I'm using C++ almost exclusively. Know my way around unix shell, can write software in python and probably in anything (if I have a reference book nearby) that remotely resembles C++ or Pascal (i.e. blocks, similar flow control, etc). Specialization is 3D programming and shaders. "Fish in the water" with low-level operations (C-style memory allocation, pointers), less comfortable with extremely OOP approach (i.e. when classes are made for the sake of having classes). Almost completely self-taught. I.e. definitely not a newbie, but there are areas where I could improve.
So... what could I possibly gain from studying Haskell at this point? As far as I know, this language is not really widely used, as a result there probably is less libraries it can interface with (as it was with Delphi programming - you can do DirectX programming in delphi, if you really want, but you can't write 3dsmax/maya plugin with it (well, it is probably theoretically possible, but it certainly won't be easy)). I also don't think that I'll be easily able to plug a piece of Haskell code into game engine.
So, what kind of useful knowledge I can get from it?
P.S. I won't buy "if you learn another language, you'll probably learn something that will be probably useful" argument.
(Surely this is a duplicate question, but I can't find one now.)
You learn it in order to learn pure functional programming, which forces you to do many things in a completely different way. You get a new way of thinking. Programming without state? Programming without effects? Everything is lazy? Crazy type system with type inference? What the hell are monads? Your mind will be repeatedly blown, but in the end you come out with new perspectives/techniques from functional programming that are hard to otherwise pick up without going full-blown Haskell.
The problem with trying to be specific, is that trying to tell a non-Haskeller what they'll learn from Haskell is like trying to explain the color "green" to a blind guy.
A few years ago, many people were surprised to discover one of the introductory courses was being taught using Haskell as a/the programming language! Although I didn't have experience with Haskell, I had some background in Lisp and other Functional Programming languages.
I think the anecdote shows how knowledge can be useful when you least expect it.
In more practical terms: You may have noticed that CPU speeds hit a wall some years ago, and now the most practical way to pull more performance from computers is by installing multiple CPUs. Now it so happens that most if not all of the programming languages you know are essentially single tasking, and subject to the Von Neumann bottleneck. An obvious solution is parallel programming, but that can be very painful if the parallel parts of your program end up sharing state, i.e. memory - and this is most often the case.
It turns out that Functional Programming is a style that allows you to mostly circumvent the problems of parallel programming with shared state. Stated differently, it's fairly easy to write programs in the FP style that are "naturally" thread safe and suitable for parallel processing. Depending on the language, compiler and hardware you may even find (as I recently did) parts of your program running in parallel without ever having done any explicit coding for parallelism.
I'm frequently wrong, but my guess is that Functional Programming will turn out to be one of the hot programming paradigms of the future as parallel programming becomes more important and more difficult. Haskell may not turn out to be the language of choice - my personal favorite is currently Clojure - but it may well be worthwhile to take a look at one or more FP languages.
I also don't think that I'll be easily able to plug a piece of Haskell code into game engine.
If you only want to write 3D game engines then maybe there's not much point in learning Haskell.
If you want to be a well-rounded programmer capable of programming in multiple paradigms and you currently only know C-like languages then it is worth a look.
Every time you learn a new very different language it makes learning the next language easier because you're not just memorizing new syntax, you're also learning different ways of thinking about programming. If you try out a new language and you see some new feature you will more quickly understand it if you can relate it to another feature in a language you already know. The more languages you know the more likely it is that this new feature is similar to something you've seen before.
It's also handy to have many tools available in your toolbox. Some problems are better solved in one language than another. If you have 5 very different types of languages then you can select the best one for each problem. If you know only 2 or 3 very similar languages then some problems will be easy to solve, but others might be more difficult than if you used a language which is better at that specific task.
If 3D programming is your thing, you might be interested in some slides from a talk entitled The Next Mainstream Programming Languages: A Game Developer's Perspective by Tim Sweeney, the founder of Epic and technical director for the Unreal engine. He's spoken on the subject multiple times, and he clearly thinks very highly of Haskell.
There are several things you can get, mainly in the way you think about things. For example, it is interesting to notice what a minimal language is. If you go through SICP (and the same concepts apply to Haskell too), you will notice how you don't need loop syntax at all. You don't need any predefined functions that work on larger structures. You can define pretty much everything you need if you are given a cons constructor/deconstructor, or a way of defining one, and ability to recurse functions. You can define everything else yourself - and it is an interesting exercise to do so. And this is only the tip of the iceberg.
On a more practical level, for example, a couple of weeks ago I was doing OCaml homework and moaning "why doesn't this $%$%# language have call/cc!?!" My mind was blown when I noticed what I was thinking - I would never have missed it if I didn't know what it was, and I wouldn't known what it was if I didn't take a look at Scheme, Haskell, Ruby.
You can find many nice examples at ICFP contest; the one that really wowed me was this entry at this contest. They created a new language inside Haskell to solve their problem.
Learning a functional language will be quite a change from what you are used to.
So yes, you'll probably going to learn something useful ;)
I would say, if it's a chore don't do it. Otherwise start to read this and you should see after 10 mn if you are bored or if you are gripped and can't stop reading it.
Functional languages like Haskell are a different way of thinking about a problem. They are useful for learning and teaching data structures and algorithms, as they simplify those kinds of problem.
If you use the STL from C++, that has functional concepts that are similar to Haskell and other languages, so having a grounding in Haskell will help understand how the STL works.
If you use XSL:T to transform XML, that is very functional in its design.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There is a lot of hype around Haskell, however, it is hard to get information on how it is used in the real world applications. What are the most popular projects / usages of Haskell and why it excels at solving these problems?
What are some common uses for this
language?
Rapid application development.
If you want to know "why Haskell?", then you need to consider advantages of functional programming languages (taken from https://c2.com/cgi/wiki?AdvantagesOfFunctionalProgramming):
Functional programs tend to be much more terse than their ImperativeLanguage counterparts. Often this leads to enhanced
programmer productivity
FP encourages quick prototyping. As such, I think it is the best software design paradigm for ExtremeProgrammers... but what do I know?
FP is modular in the dimension of functionality, where ObjectOrientedProgramming is modular in the dimension of different
components.
The ability to have your cake and eat it. Imagine you have a complex OO system processing messages - every component might make state
changes depending on the message and then forward the message to some
objects it has links to. Wouldn't it be just too cool to be able to
easily roll back every change if some object deep in the call
hierarchy decided the message is flawed? How about having a history of
different states?
Many housekeeping tasks made for you: deconstructing data structures (PatternMatching), storing variable bindings (LexicalScope with
closures), strong typing (TypeInference), GarbageCollection, storage
allocation, whether to use boxed (pointer-to-value) or unboxed (value
directly) representation...
Safe multithreading! Immutable data structures are not subject to data race conditions, and consequently don't have to be protected by
locks. If you are always allocating new objects, rather than
destructively manipulating existing ones, the locking can be hidden in
the allocation and GarbageCollection system.
Apart from this Haskell has its own advantages such as:
Clear, intuitive syntax inspired by mathematical notation.
List comprehensions to create a list based on existing lists.
Lambda expressions: create functions without giving them explicit names. So it's easier to handle big formulas.
Haskell is completely referentially transparent. Any code that uses I/O must be marked as such. This way, it encourages you to separate code with side effects (e.g. putting text on the screen) from code without (calculations).
Lazy evaluation is a really nice feature:
Even if something would usually cause an error, it will still work as long as you don't use the result. For example, you could put 1 / 0 as the first item of a list and it will still work if you only used the second item.
It is easier to write search programs such as this sudoku solver because it doesn't load every combination at once—it just generates them as it goes along. You can do this in other languages, but only Haskell does this by default.
You can check out following links:
https://c2.com/cgi/wiki?AdvantagesOfFunctionalProgramming
https://learn.microsoft.com/archive/blogs/wesdyer/why-functional-programming-is-important-in-a-mixed-environment
https://web.archive.org/web/20160626145828/http://blog.kickino.org/archives/2007/05/22/T22_34_16/
https://useless-factor.blogspot.com/2007/05/advantage-of-functional-programming.html
I think people in this post are missing the most important point for anyone who has never used a functional programming language: expanding your mind. If you are new to functional programming then Haskell will make you think in ways you've never thought before. As a result your programming in other areas and other languages will improve. How much? Hard to quantify.
There is one good answer for what a general purpose language like Haskell is good for: writing programs in general.
For what it is used for in practice, I've three approaches to establishing that:
A tag cloud of Haskell library and app areas, weighted by frequency on Hackage.
Indicates that it is good for graphics, networking, systems programming, data structures, databases, development, text processing ...
Areas it is used in industry - a lot of DSLs, web apps, compiler design, networking, analysis, systems programming , ...
And finally, my opinion on what it is really strong at:
Problems where correctness matters, domain specific languages, and parallel and concurrent programming
I hope that gives you a sense on how broad your question is, if it is to be answered with any specificity.
One example of Haskell in action is xmonad, a "featureful window manager in less than 1200 lines of code".
From the Haskell Wiki:
Haskell has a diverse range of use
commercially, from aerospace and
defense, to finance, to web startups,
hardware design firms and lawnmower
manufacturers. This page collects
resources on the industrial use of
Haskell.
According to Wikipedia, the Haskell language was created out of the need to consolidate existing functional languages into a common one which could be used for future research in functional-language design.
It is apparent based on the information available that it has outgrown it's original purpose and is used for much more than research. It is now considered a general purpose functional programming language.
If you're still asking yourself, "Why should I use it?", then read the Why use it? section of the Haskell Wiki Introduction.
Haskell is a general purpose programming language. It can be used for anything you use any other language to do. You aren't limited by anything but your own imagination. As for what it's suited for? Well, pretty much everything. There are few tasks in which a functional language does not excel.
And yes, I'm the Rayne from Dreamincode. :)
I would also like to mention that, in case you haven't read the Wikipedia page, functional programming is a paradigm like Object Oriented programming is a paradigm. Just in case you didn't know. Haskell is also functional in the sense that it works; it works quite well at that.
Just because a language isn't an Object Oriented language doesn't mean the language is limited by anything. Haskell is a general-purpose programming language, and is just as general purpose as Java.
I have a cool one, facebook created a automated tool for rewriting PHP code. They parse the source into an abstract syntax tree, do some transformations:
if ($f == false) -> if (false == $f)
I don't know why, but that seems to be their particular style and then they pretty print it.
https://github.com/facebook/lex-pass
We use haskell for making small domain specific languages. Huge amounts of data processing. Web development. Web spiders. Testing applications. Writing system administration scripts. Backend scripts, which communicate with other parties. Monitoring scripts (we have a DSL which works nicely together with munin, makes it much easier to write correct monitor code for your applications.)
All kind of stuff actually. It is just a everyday general purpose language with some very powerful and useful features, if you are somewhat mathematically inclined.
From Haskell:
Haskell is a standardized, general-purpose purely functional
programming language, with
non-strict semantics and strong static
typing. It is named after logician
Haskell Curry.
Basically Haskell can be used to create pretty much anything you would normally create using other general-purpose languages (e.g. C#, Java, C, C++, etc.).
For example, for developing interactive, realtime HTML5 web applications. See Elm, the compiler of which is implemented in Haskell and the syntax of which borrows a lot from Haskell's.
This is a pretty good source for info about Haskell and its uses:
Open Source Haskell Releases and Growth
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is the real benefit of creating a new programming language? It is highly unlikely that you are going to actually use it.
In short, how will the process of creating a new language make you a better programmer?
You will understand the decisions behind language design and garner a better overall understanding of the compromises made between readability, performance, and reliability.
Your familiarity with concepts such as recursion, closures, garbage collection, reference management, typing, data structures and how these things actually work will increase. Most programmers will utilize resources and language features better.
Similar to the way we learn new ways to code solutions when we use other languages, when we write our own languages, we explore new ways to create solutions. See Metaprogramming. Contrary to the what the question suggests, Domain Specific Languages are used in many environments.
If you're writing a compiler, you'll learn more about how computers work than you ever did before. (Depending on your goal, perhaps more than you intended to learn)
When I wrote my own sort routines in school, even re-implementations of good ones, it really drove home some of the weaknesses of some of the algorithms.
In short, there's an order of magnitude of difference in a programmer who knows how to use tools, and a programmer who knows how to make tools.
I can speak from experience here ...
Fun, Domain specific problem solving, Complexity in context
I love creating new languages for fun, and for tackling domain specific problems. A very simple example might be Wikipedia markup or something as complex as Erlang which specializes in concurrent processing.
Many general purpose languages are similar, because they are general purpose. Sometimes you need a more accurate abstraction of the mechanics of the problem you are solving. Another example would be the M4 macro language.
Remember a language is not magic, it is just a collection of defined grammatical structures with implied semantics. SQL is a good example of a language for a purpose, with that purpose defined in it's syntax and semantics.
Learning how languages work, what makes a language parsable, what makes semantics sensible and the implementation of this, I think can make you a better programmer.
compilers embody alot of theory that underpins computer science:
Translation, abstraction, interpretation, data structures, state .... the list goes on. Learning these things will make you understand the implications of your program and what goes on under the hood. You can of course learn things independently but compilers are a great context to learn complex topics such as DFA/NDFA automata, stack-based parsers, abstract syntax trees ....
compilers are beautiful machines I think :)
Multiple reasons:
bragging rights
economic incentives
extreme boredom
dissatisfaction with the hundreds of existing languages
untreated insanity
desire to implement language that facilitates new design concepts (like languages that make design patterns more straightforward to incorporate)
other reasons, perhaps
I think Jeff Attwood answers this well in this Coding Horror post -- though he's talking about a more general issue (why create any new library, framework, etc, when other artifacts in the same design space already exist), I suspect that exactly said broader viewpoint gives him a different and interesting perspective.
I will add that if you write a semantics, so that your language is an actual language and not merely what happens to be accepted by some particular implementation, you will learn an enormous amount about how to describe computational behaviors precisely:
You will learn what kinds of behaviors are and are not easy to describe—and prove correct.
You will learn how to trade off different kinds of formalisms for describing different kinds of features.
You will ultimately be a better programmer because the formalism and proof techniques you will learn will apply to all kinds of problems: locking techniques, safety properties in kernels, lock-free data structures, network protocols, and information security, to name just a few. All these areas are amenable to the same kind of formal treatment that is given to a programming language.
To pick just one example, if you give your language a static type system and you then prove that a well-type program is guaranteed to be memory-safe, you will learn just as much (on a different dimension) as you will by writing an interpreter or compiler.
EDIT: If you want to learn this stuff I think the easiest starting point is Benjamin Pierce's series of two books on Types and Programming Languages. There is also a graduate textbook by Glynn Winskel which is a little harder but more oriented toward semantics and proof techniques.
Creating Domain Specific Languages is very valuable. Instead of thinking only about general purpose languages, consider creating so-called "little languages" that clearly express abstractions in your project.
For example, in a recent project I decided to use a Command Pattern to drive a Service Layer. I found some repetition in my command code, so I wrote a little compiler that accepts a simple language that expresses commands and emits command implementations in the "underlying" language.
For the same reason that taking a Compiler Construction course at university will benefit you even if you never write a single compiler in your whole life. It's a look under the hood, if you may.
In addition to what altCognito said, which is a theoretical/academic perspective, some highly specialized languages are created to solve specific problems efficiently when existing "general-purpose" languages are either extremely inefficient for your task or there just isn't an easy-to-use existing alternative.
Granted, that such cases tend to be rare and if your first instinct on encountering a problem is "I need a new language for this.", then it is most likely you're missing something. There needs to be a fairly substantial gap in "available" tech and and your needs to warrant such an undertaking.
I think there are really two conceptually different answers to this. First, you gain an understanding of how compilers transform your code into executable code. This can help you make better decisions about how to structure your code to optimize (or allow it to be optimized) better. If, for instance, you knew that a certain construct would prohibit the compiler from inlining a code block or unrolling a loop, then you could avoid that if performance became a real concern.
Second, all current languages were invented (or derived) at some point in history. For each one of these, the likelihood that it would actually be used was potentially small, yet here they are. They all found their reason for being in the fact that someone wanted to do something that wasn't possible or easy to do in an existing language and decided to do something about it. Laziness (or the desire to let the computer do the work for you) is the mother of invention.
Just for fun... and then you'll realize that you cannot make anything better than all the languages that you thought they sucked xD (so you stop complaining about them).
how will the process of creating a new language make you a better programmer?
You're right, you may or may not use the language, but at the least the experience you will gain from doing it will benefit you to understand the implementation of programming languages and of certain things that you will be able to apply to future computation problems that you run into.
Writing a compiler or interpreter requires a very firm understanding in computer science theory. And if you're compiling to machine code instead of to another language, it requires a firm understanding in hardware design as well.
In addition to that, knowing how to design a compiler means you will have a better understanding of languages in general, and the languages you work with specifically. You will have a better appreciation for syntax and trade-offs the language designers took when they wrote their specification.
It's not that writing compilers makes you a better programmer. It's the deep understanding of language theory and compiler design that makes you better.
Mostly you do this for fun or to broaden your comprehension of a subject.
I disagree that creating new language influences performance - performance of what? IMHO execution speed should not depend on the language constructs but what the language is translated to - which is something different: like creating a syntax for a language and writting a compiler/virtual machine for it.
Because a talking frog is pretty neat.
I want a managed language that permits tinkering with its internals as standard practice. Kind of like Ruby's duck punching on a wider scale.
I should, as the client of a library, be able to swap out library functions that don't do what I want.
That's what drives me crazy with .NET. There are bugs in the framework Microsoft will not fix and thanks to GAC signing I cannot. And even if it were not for GAC signing, hotpatching a global library is a bad idea (might break some other application).
I for one don't care about how compilers work, don't care about learning new languages, and don't care about using scripting languages like perl and javascript. I'm much more interested in the ways big programs are constructed (or should be constructed). There are still no good solutions for making LARGE software as easy to use as prototyped code. Programming languages are not helping with that. They solve trivial problems like sorting and memory deallocation, and leave you struggling alone with problems that really matter (that keep you or your firm from losing money).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I am wondering if I should continue to learn OCaml or switch to F# or Haskell.
Here are the criteria I am most interested in:
Longevity
Which language will last longer? I don't want to learn something that might be abandoned in a couple years by users and developers.
Will Inria, Microsoft, University of Glasgow continue to support their respective compilers for the long run?
Practicality
Articles like this make me afraid to use Haskell. A hash table is the best structure for fast retrieval. Haskell proponents in there suggest using Data.Map which is a binary tree.
I don't like being tied to a bulky .NET framework unless the benefits are large.
I want to be able to develop more than just parsers and math programs.
Well Designed
I like my languages to be consistent.
Please support your opinion with logical arguments and citations from articles. Thank you.
Longevity
Haskell is de facto the dominant language of functional-programming research. Haskell 98 will last for many more years in stable form, and something called Haskell may last 10 to 30 years---although the language will continue to evolve. The community has a major investment in Haskell and even if the main GHC developers are hit by a bus tomorrow (the famous "bus error in Cambridge" problem), there are plenty of others who can step up to the plate. There are also other, less elaborate compilers.
Caml is controlled by a small group at INRIA, the French national laboratory. They also have a significant investment, Others are also invested in Caml, and the code is open source, and the compiler is not too complicated, so that too will be maintained for a long time. I predict Caml will be much more stable than Haskell, as the INRIA folks appear no longer to be using it as a vehicle for exploring new language ideas (or at least they are doing so at a smaller rate than in the past).
Who knows what a company will do? If F# is successful, Microsoft could support it for 20 years. If it is not successful, they could pull the plug in 2012. I can't guess and won't try.
Practicality
A hash table is the best structure for fast retrieval. Haskell proponents in there suggest using Data.Map which is a binary tree.
It depends on what you are searching. When your keys are strings, ternary search trees are often faster than hash tables. When your keys are integers, Okasaki and Gill's binary Patricia trees are competitive with hashing. If you really want to, you can build a hash table in Haskell using the IO monad, but it's rare to need to.
I think there will always be a performance penalty for lazy evaluation. But "practical" is not the same as "as fast as possible". The following are true about performance:
It is easiest to predict the time and space behavior of a Caml program.
F# is in the middle (who really knows what .NET and the JIT will do?).
It is hardest to predict the time and space behavior of Haskell programs.
Haskell has the best profiling tools, and in the long run, this is what yields the best performance.
I want to be able to develop more than just parsers and math programs.
For an idea of the range of what's possible in Haskell, check out the xmonad window manager and the vast array ofpackages at hackage.haskell.org.
I don't like being tied to a bulky .NET framework unless the benefits are large.
I can't comment:
Well Designed
I like my languages to be consistent.
Some points on which to evaluate consistency:
Haskell's concrete syntax is extremely well designed; I'm continually impressed at the good job done by the Haskell committee. OCaml syntax is OK but suffers by comparison. F# started from Caml core syntax and has many similarities.
Haskell and OCaml both have very consistent stories about operator overloading. Haskell has a consistent and powerful mechanism you can extend yourself. OCaml has no overloading of any kind.
OCaml has the simplest type system, especially if you don't write objects and functors (which many Caml programmers don't, although it seems crazy to me not to write functors if you're writing ML). Haskell's type system is ambitious and powerful, but it is continually being improved, which means there is some inconsistency as a result of history. F# essentially uses the .NET type system, plus ML-like Hindley-Milner polymorphism (See question "What is Hindley-Milner".)
OCaml is not quite consistent on whether it thinks variants should be statically typed or dynamically typed, so it provides both ("algebraic data types" and "polymorphic variants"). The resulting language has a lot of expressive power, which is great for experts, but which construct to use is not always obvious to the amateur.
OCaml's order of evaluation is officially undefined, which is a poor design choice in a language with side effects. Worse, the implementations are inconsistent: the bytecoded virtual machine uses one order and the native-code compiler uses the other.
Should you learn F# or Haskell if you know OCaml?
I believe the answer is certainly yes, ideally you should learn all three languages because each one has something to offer but F# is the only one with a significant future so, if you can only feasibly learn one language, learn F# by reading my Visual F# 2010 for Technical Computing book or subscribing to our The F#.NET Journal.
Longevity
Microsoft committed to supporting F# when they released it as part of Visual Studio 2010 in April. So F# is guaranteed a rosy future for at least a few years. With a powerful combination of practically-important features like a high performance native-code REPL, high-level constructs for parallelism built-in to .NET 4 and a production-quality IDE mode, F# is a long way ahead of any other functional programming language in terms of real world applicability now. Frankly, nobody is even working on anything that might be able to compete with F# in the near future. My own open source HLVM project is an attempt to do so but it is far from ready.
In contrast, both OCaml and Haskell are being developed in extremely unproductive directions. This has been killing OCaml for several years now and I expect Haskell to follow suit over the next few years. Most former professional OCaml and Haskell programmers already moved on to F# (e.g. Credit Suisse, Flying Frog Consultancy) and most of the rest will doubtless migrate to more practical alternatives such as Clojure and Scala in the near future.
Specifically, OCaml's QPL license prevents anyone else from fixing its growing number of fundamental design flaws (16Mb string and array limits on 32-bit machines, no shared-memory parallelism, no value types, parametric polymorphism via type erasure, interpreted REPL, cumbersome FFI etc.) because they must distribute derivative works only in the form of patches to the original and the Debian package maintainers refuse to acknowledge an alternative upstream. The new features being added to the language, such as first-class modules in OCaml 3.12, are nowhere near as valuable as multicore capability would have been.
Some projects were started in an attempt to save OCaml but they proved to be too little too late. The parallel GC is practically useless and David Teller quit the batteries included project (although it has been picked up and released in a cut-down form). Consequently, OCaml has gone from being the most popular functional language in 2007 to severe decline today, with caml-list traffic down over 50% since 2007.
Haskell has fewer industrial users than OCaml and, although it does have multicore support, it is still being developed in a very unproductive direction. Haskell is developed almost entirely by two people at Microsoft Research in Cambridge (UK). Despite the fact that purely functional programming is bad for performance by design, they are continuing to try to develop solutions for parallel Haskell aimed at multicores when the massive amounts of unnecessary copying it incurs hits the memory wall and destroys any hope of scalable parallelism on a multicore.
The only major user of Haskell in industry is Galois with around 30 full-time Haskell programmers. I doubt they will let Haskell die completely but that does not mean they will develop it into a more generally-useful language.
Practicality
I wrote the article you cited about hash tables. They are a good data structure. Other people have referred to purely functional alternatives like ternary trees and Patricia trees but these are usually ~10× slower than hash tables in practice. The reason is simply that cache misses dominate performance concerns today and trees incur an extra O(log n) pointer indirections.
My personal preference is for optional laziness and optional purity because both are generally counter productive in the real world (e.g. laziness makes performance and memory consumption wildly unpredictable and purity severely degrades average-case performance and makes interoperability a nightmare). I am one of the only people earning a living entirely from functional programming through my own company. Suffice to say, if I thought Haskell were viable I would have diversified into it years ago but I keep choosing not to because I do not believe it is commercially viable.
You said "I don't like being tied to a bulky .NET framework unless the benefits are large". The benefits are huge. You get a production-quality IDE, a production-quality JIT compiler that performs hugely-effective optimizations like type-specializing generics, production-quality libraries for everything from GUI programming (see Game of Life in 32 lines of F#) to number crunching. But the real benefit of .NET, at least for me, is that you can sell the libraries that you write in F# and earn lots of money. Nobody has ever succeeded selling libraries to OCaml and Haskell programmers (and I am one of the few people to have tried) but F# libraries already sell in significant quantities. So the bulky .NET framework is well worth it if you want to earn a living by writing software.
Well designed
These languages are all well designed but for different purposes. OCaml is specifically designed for writing theorem provers and Haskell is specifically designed for researching Haskell. F# was designed to address all of the most serious practical problems with OCaml and Haskell such as poor interoperability, lack of concurrent garbage collection and lack of mature modern libraries like WPF in order to bring a productive modern language to a large audience.
This wasn't one of your criteria but have you considered job availability? Haskell currently list 144 jobs on indeed, Ocaml list 12 and C# list 26,000. These numbers are not perfect but I bet you that once F# ships it won't be long before it blows past Haskell and Ocaml in the number of job listings.
So far every programming language included in Visual Studios has thousands of job listings for it. Seems to me that if you want the best chance to use a functional programming language as your day job then F# will soon be it.
Longevity
No one can predict the future, but
OCaml and Haskell have been surving well for a number of years, which bodes well for their future
when F# ships with VS2010, MS will have legal obligations to support it for at least 5 years
Practicality
Perf: I don't have enough first-hand experience with Haskell, but based on second-hand and third-hand info, I think OCaml or F# are more pragmatic, in the sense that I think it is unlikely you'll be able to get the same run-time perf in Haskell that you do in OCaml of F#.
Libraries: Easy access to the .Net Framework is a huge benefit of F#. You can view it as being "tied to this bulky thing" if you like, but don't forget that "you have access to a huge bulky library of often incredibly useful stuff". The 'connectivity' to .Net is one of the big selling points for F#. F# is younger and so has fewer third-party libraries, but there is already e.g. FsCheck, FParsec, Fake, and a bunch of others, in addition to the libraries "in the box" on .Net.
Tooling: I don't have enough personal experience to compare, but I think the VS integration with F# is superior to anything you'll find for OCaml/Haskell today (and F# will continue to improve a bit here over the next year).
Change:
F# is still changing as it approaches its first supported release in VS2010, so there are some breaking changes to language/library you may have to endure in the near future.
Well Designed
Haskell is definitely beautiful and consistent. I don't know enough OCaml but my hunch is it is similarly attractive. I think that F# is 'bigger' than either of those, which means more dusty corners and inconsistencies (largely as a result of mediating the impedence mismatch between FP and .Net), but overall F# still feels 'clean' to me, and the inconsistencies that do exist are at least well-reasoned/intentioned.
Overall
In my opinion you will be in 'good shape' knowing any of these three languages well. If you know a big long-term project you want to use it for, one may stand out, but I think many of the skills will be transferable (more easily between F# and OCaml than to/from Haskell, but also more easily among any of these three than with, say, Java).
There's no simple answer to that question, but here are some things to consider:
Haskell and OCaml are both mature languages with strong implementations. Actually, there are multiple good implementations of Haskell, but I don't think that's a major point in its favor for your purpose.
F# is much younger, and who can predict where Microsoft will decide to take it? How you feel about that depends more on how you feel about Microsoft than anything anyone can tell you about programming languages.
OCaml (or ML in general), is a good practical language choice that supports doing cool functional stuff without forcing you to work in a way that might be uncomfortable. You get the full benefit of things like algebraic data types, pattern matching, type inference, and everybody else's favorite stuff. Oh, and objects.
Haskell gives you all that (except objects, pretty much), but also more or less forces you to rethink everything you think you know about programming. This might be a very good thing, if you're looking to learn something new, but it might be more than you want to bite off. I say this as someone who is only maybe halfway along the path to being a productive, happy Haskell programmer.
Both OCaml and Haskell are being used to write lots of different kinds of programs, not just compilers and AI or whatever. Google is your friend.
One last note: OCaml gives you hashtable, but it's hardly sensible to use it in code if you really want to embrace functional programming. Persistent trees (like Data.Map) are really the right solution for Haskell, and have lots of nice properties, which is one of the cool things to learn about when you pick up Haskell.
F# and OCaml are very similar in syntax, though, obviously, F# is better with .NET.
Which one you learn or use should be dependent on which platform you are aiming for.
In VS2010 F# is going to be included, and since it compiles to .NET bytecode, it can be used on a windows OS that supports the .NET version you used for it. This will give you a large area, but there are limits, currently with F# that OCaml don't have, in that F# appears not to take advantage of all the processors on a machine, but, that is probably due to F# still being developed, and this may be a feature that isn't as important yet.
There are other functional languages, such as Erlang that you could look at, but, basically, if you are strong in one FP language then you should be able to pick up another fairly quickly, so, just pick one that you like and try to develop interesting and challenging applications in it.
Eventually language writers will find a way to get OO languages to work well with multi-cores and FP may fall to the wayside again, but, that doesn't appear to be happening anytime soon.
This is not directly related to the OP's question as to whether or not to learn F#, but rather, an example of real world OCaml usage in the financial sector:
http://ocaml.janestreet.com/?q=node/61
Very interesting talk.
In terms of longevity, it's very difficult to judge popularity of languages, but just doing a quick check on here, these are the numbers of questions tagged with the appropriate (functional) language :-
2672 Scala,
1936 Haskell,
1674 F#,
1126 Clojure,
709 Scheme,
332 OCaml
I'd say this was a good indication of which languages people are actively learning at the moment and therefore might be a good indication of which ones might be popular in the next few years.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
These days I'm getting seriously into functional programming.
While I'm really excited about Haskell and the possibilities it seems to offer, I can also see now that it is going to take me a while to learn. In an SO question on How to learn Haskell an answer states that it'll take months if not years to actually "master" it.
Now, I know C, PHP, some object oriented stuff, etc. And having been told that Haskell isn't much used out there in "the real world", will I be better off improving my skills in the regular languages I know? Is Haskell worth the struggle?
In this question on Why people think functional programming will catch on the conclusion seems to be that functional programming will "catch on". But surely procedural programming will stay on top, right?
EDIT: keparo nicely clarifies my question to: As opposed to procedural languages, will it be valuable for me to study Haskell and functional programming paradigms?
Haskell isn't as hard as people like to make out to learn. Haskell opens up a new world that you never knew existed for you. It's as valuable to learn as any other language. You might not find a job requiring you to do Haskell programming, but does that really mean a language isn't valuable?
Haskell will teach you a lot of new stuff, and it will show you how to program even better in the languages you /do/ work with. You can do your own personal projects in your spare time with it.
Haskell isn't really used much in the "real world" if you define "real world" as "cash generator". So if that is your objective, then you might have to rethink objectives :p
Also, I don't really like that part of chosen "how to learn haskell" answer. It takes months to years to master any language, not just Haskell. Depending on how you define "master". I can use Haskell to a pretty good degree of efficiency and I've only been learning it for a month, and I've been taking it slow even.
If nothing else, the change in mindset that learning Haskell provides will help you when you have to go back to using those procedural languages that still are used in the workplace.
The functional paradigm is beginning to make it's way into various mainstream applications and languages - Even C++ is going to be adding a (crippled) lambda in C++0x.
You may also want to look at some of the hybrid languages like Scala or OCaml. Scala is being used at Twitter, and OCaml is being used at Jane's Street in a financial trading platform.
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.
You probably shouldn't expect to use Haskell anywhere nearly as often as a C family language in professional settings. If the question is whether it will be valuable for you to study Haskell and functional programming paradigms, the answer is yes. You can apply your enriched understanding of programming to all of your work.
As opposed to procedural languages, will it be valuable for me to study Haskell and functional programming paradigms?
If having an expanded skill set is valuable, then: yes.
One advantage you might pick up: parallel and concurrent programming. Procedural languages of the past tend to have no clear notion of side effects, as a result writing parallel programs in them is difficult to do correctly. Functional languages (in particular, ones that limit side effects like Haskell) have a lot more to say about productive parallel programming.
Having that skill up your sleeve can't hurt.
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.)
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.
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.
Broadening your horizons helps you be a better programmer no matter what language you happen to be using at the moment. You'll never look at programming the same way after you've written Lisp macros, for instance. After you begin to think in Haskell terms, you'll find yourself composing functions and wishing for closures in less advanced languages.
Judging from goodies in C# such as lambdas, type inference, closures, and so on, learning Haskell will give you a leg up on tomorrow's cutting edge in mainstream languages.
Some people enjoy programming in Haskell. If you can choose your environment, and enjoyment is a consideration, then maybe you should hop in.
Many programmers are not in position to choose their tools and enjoyment is not a factor for their choices. Many of them get to use C/Java/etc at their workplace for the "core project source", but then also choose or need to use Python for "scripts" such as build-scripts with SCons, other scripts that generate Java/etc code, testing systems, proofs-of-concepts, etc.. And in other places Python is also used in the "core project".
In 8 years, it will be Haskell, not Python, which will be "coming to you". But you can come to it sooner.
You can combine the use of functional programming and be pragmatic about the language.
All modern scripting languages s.a. JavaScript or Lua allow use of the functional paradigm.
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.
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.