Then take a look at computationally intensive applications. There you simply can't compete with the speeds that fortran provides. Neither with the simplicity to prototype programs as matlab or mathematica does.
Ocaml and SML (with MLton) are fast enough. Often faster than C++ (without crazy template expression optimizations), and approaching the speed of C. See here.
Of course they aren't as fast as Fortran for purely numeric code, but then they also are a lot easier to program in than Fortran, and if you really need speed you can use Foreign Function Interfaces and write your inner loops in some SIMD instruction set to make things really fly.
As a side note, hopefully Fortress (which I mentioned earlier) will provide something nice which approximates parts of ML, while providing very good facilities for replacing Fortran on the other side of things. It is, after all, supposedly a Fortran replacement. Hopefully Sun will get this one right
In hardware construction I can see the usefulness of fp when the constructors start to realize that the designs have to be correct in the first revision - small possibilities to patch an asic once it's produced. Then the property that you can prove correctness can be useful. But still I haven't seen that many (commercially useful) tools that can do this yet... Not any in fact, but I haven't looked very hard.
I've seen a lot of these, but I'm not very good at keeping tabs on this sort of thing since hardware isn't typically my primary interest. FP has been seeing increasing usage in hardware design and verification all over the map though. One interesting application that I do know of right off the top of my head (because I was looking at it a few days ago), is Lava. I've seen many similar projects to this.
As a final note, it's worth saying that whether or not something is popular is not an indication of quality, technical proficiency, performance, etc., etc. This should be a rather obvious point by now.
Well, the obvious answer to that is that whether something is popular or not is an indication if you can make money out of it.
Absolutely. But whether you can make money out of it or not is also not a good indication of worth. You can make boatloads of money selling snake-oil audiophile toys like $6000 power cables, for example
Also if it's popular it will be easier to draw on other people's work for your own. I mean, there are heaps of discussion groups etc where you can look for answers when you run into a problem in a popular language, and also lots of code already written which you in many cases are free to use in your own program.
Yes. And many people may suspect that this is not the case with a less popular language like Haskell or LISP or ML or even Erlang. But this isn't really the case. Usually there's a much smaller community, but arguably those communities are more knowledgeable, more enthusiastic, more willing to help, and generally have a higher signal to noise ratio than the same communities you'd see for very popular languages. You may be able to find more raw code examples in a popular language, but you will probably find fewer good code examples, and probably will have a harder time finding the same level of expert advice you'd get than if you went to say #haskell or something like that.
My own exposure to functional programming is not nearly as big as yours - only an introduction course and one or two after that - so there are many things about it which I don't know, but I will try to keep an open mind. And I think your posts here are quite insightful and interesting, so I don't mind if you try to convert me...
[{POST_SNAPBACK}][/a]
If there's one thing I've learned, it's that most undergrad courses in fp are an atrocious experience. I think this is partly because of preconceived notions of the student before taking the course, but also a big failure on the part of the education system for CS as a whole. And sometimes it's a fault of the professor for not realizing all of this and finding a better way to teach things.
My own experience with CS has been incredibly negative, in large part because I don't fit in at all with the curriculum (I should be taking grad courses, but can't even take certain undergrad courses I need yet, which is totally frustrating), but also because most professors don't give a shit, and most students don't give a shit.
I guess the bottom line is that your average CS course is probably not going to leave you with a great impression of fp unless you have an awesome professor or unless you are going to a school which is very heavy on theory and has a strong fp basis from which to draw. On the other hand, if you haven't programmed at all before, and are mathematically inclined, then maybe things don't have to be so perfect to have a good experience.
Haskell is a strange language, teaching wise. It can be very natural and simple, which you can see [a href="http://conal.net/fran/tutorial.htm]here[/url]. It can also be incredibly difficult and complicated, and nearly require an understanding of category theory, which you can see here. This variance is a testament to the flexibility of the language, that it can encompass such broad scope and still remain, at base, a relatively minimal language (no OO or things like that, few keywords, very compact and consistent library, etc.). So in the end, it requires a very carefully thought out course to get people on the right path early and to get them interested.
For what it's worth, I don't think that this would be as much of a problem if CS was the way it used to be -- more of an offshoot of discrete math and logic than an engineering enterprise. I still believe this is the way CS should be taught, but it's not usually the way things actually happen nowadays.
So anyway, I'm not too surprised if you aren't really enthusiastic about fp. Most people aren't. Most of them completely hate it by the time they finish their first CS course on it. I never took a CS course on fp (or any language for that matter -- even in my C related courses, I already knew C beforehand). I've learned fp along with the rest of programming through self-study, and as a result, I've probably not had some of the negative experiences many people might have, and usually what I know, I've learned because I was interested in learning it.
It is rather interesting though... to this day, I probably would not have learned much beyond C,C++,Java, and Python, if it weren't for one of my best friends trying to explain this strange Haskell thing to me one day and showing me the magical quicksort in 4 lines (which can actually be made into a 1 liner without too much ugliness):
qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
where elts_lt_x = [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]
When I first saw it, I just couldn't understand how it worked, after being used to this:
qsort( a, lo, hi ) int a[], hi, lo;
{
int h, l, p, t;
if (lo < hi) {
l = lo;
h = hi;
p = a[hi];
do {
while ((l < h) && (a[l] <= p))
l = l+1;
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
t = a[l];
a[l] = a[h];
a[h] = t;
}
} while (l < h);
t = a[l];
a[l] = a[hi];
a[hi] = t;
qsort( a, lo, l-1 );
qsort( a, l+1, hi );
}
}
I'm glad I took the time to figure it out