Sorry, but I have to take you up on this. In the last six months I've been using C# extensively and I have to say it is quite a good language for rapid application development. I can understand grievances about cross platform issues to do with .NET (although there is Mono), but what exactly is wrong the C# language itself. As for VB.NET, it is a large step away from traditional VB (now it's object orientated), but it actually is a far better language for it. Again, there are cross platform issues, but if you use enough features of almost any implementation of a language you're going to run into cross platform issues. I can't run Objective-C+Cocoa on Windows either. So again, what are the specific failures of the C# language?

I've seen this obsession with functional languages take over some persons around me, and they sometimes go on and create fantastic things. But all this stays in the academic world - I've never seen any practical applications built on Haskell for example. I think it's simply because they are not well suited for that. The Haskell / Lisp / ML fanatics though think otherwise. Time will tell who was right...

I'd actually love to discuss this, but it'd be a long post, and it would be even more off topic than my previous post on this issue.

I'll only say that, in the context of modern language development and cutting edge research (which was the topic at hand by my reference to MS language researchers and their work on other languages), C# is quite lacking. This is in regards to design mostly but also to features. C# appears to make a better alternative to some common industry choices, such as Java (at least in some regards that is), but that in itself doesn't make it a good language -- it just makes it a better one than some other popular choices.

I'd suggest that if you really want to know what's "wrong" with it, that you spend some time looking into some of the other languages I mentioned and some of the research done by the people I mentioned, among others who have done related work. If you still are surprised at why I don't think C# is a very good language after that fact, I'd be quite surprised myself

If you really must have something more from me, I would probably say that some, but not all of the criticisms that I made of PHP also hold true for C#.

Indeed, I shouldn't have furthed the debate. Another day perhaps.

Edit: Just realised where I'd seen that logo in your avatar before.

But, don't you both have moderator status at least? Then couldn't you just move some posts to the Off topic forum? I'd love to hear more opinions about this...

I wasn't really planning on debating this in such a thread, but oh well

No practical applications from Haskell?

I guess Darcs (the best RCS I have probably ever seen) and Pugs (*the* Perl6 implementation) don't count. These being only 2 pretty recent examples. There are many more.

But seriously, people who say that functional languages and that Haskell / Lisp / ML are only used in the academic community need to take a closer look at things. There are often great industrial grade applications written in these languages, and often times they are used in mission critical places, such as telecom, wall-street and the banking industry, energy companies, etc.

And as for these languages not being practical for personal programming, well you could have fooled me. Just to give an example of some of the stuff I've created quite recently: I created a CPU emulator complete with an assembler, for a homebrew CPU I designed in about a day of work, just a few weeks ago (yes, in Haskell, yes, without assignments or side effects, and no it wasn't hard). I also created a Scheme implementation in Haskell, with a REPL, file interpreter, etc., in about 2 days -- this from having never implemented a programming language before. Some months back I won a programming contest at school here using Ocaml with OpenGL to render pretty fractal designs (I actually used lindenmayer systems). Not only did it run faster than the competition (who programmed in C and C# mostly), but it also produced the prettiest output. I've written dozens of other things in these languages (usually Haskell), from distributed concurrent cellular automata simulators, to genetic algorithms, to physics simulations, linguistic analysis, etc. Currently I'm working on turning the Scheme interpreter into a full fledged optimizing compiler with an LLVM backend, and am also working on implementing a subset of Fortress. Just about all of these projects I've worked on or that I am working on are non-trivial for the most part, and would not be possible in languages that were incapable of producing anything non-academic. And furthermore, most of these projects would be significantly more difficult in your typical run of the mill industry favorite language.

Really, I would like to see some one come up with an example of something that couldn't be done in one of these well established functional (or symbolic, in the case of LISP) languages that doesn't deal with direct memory management (something that most modern procedural languages aside from C/C++ also don't have control over). The truth is that they probably won't or can't. They've just heard that functional languages are no good, or maybe they tried one once but were too set in their ways to figure out how to do something the non-C or non-Java way. This isn't to say by the way that some of these languages are the best tools for the job at all times -- of course this isn't true. You wouldn't use Haskell for example if you needed to do realtime DSP, but you might use OCaml. Even if you used C or even C++ (gaining Fortran like performance with expression templates), that would be fine. All would probably make a better choice than Java or C#. You probably wouldn't use a purely functional language as a first choice for your average run of the mill GUI desktop application either, but this is mostly because of API issues and the host language for these. That's not to say you can't though, Haskell has bindings for Cocoa, GTK, wx, etc., and most other notable similar languages have something in that vein also.

But anyway, it's not just about functional languages. They tend to be my favorite, and they tend to offer massive benefits for certain areas of programming such as reasoning about program correctness and preventing a huge portion of the most common programming errors, but aside from this I also happen to like procedural languages, symbolic languages (like LISP, which in truth isn't really functional through and through -- it can be used functionally, but Common LISP is usually not used in this sense the same way ML or Scheme is), declarative languages, etc.

I program in C, Objective-C, C++ (w/ advanced template and macro metaprogramming, functional style, a la Boost), Python, Ruby, Scheme, SML, OCaml, Alice ML, Oz, Haskell, and APL, just to name the ones I'm mostly active with. I don't consider myself obsessed with functional languages, but I do consider myself to be able to know a good language when I see one. And I also consider it to be the case that the majority of languages in popular use are most of the time either simply not very good, or not the right tool for the job.

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. Most languages that are currently popular are not so because they are the best, but because they have had the most exposure. They are usually the ones that are taught, because they are the ones previous generations know well. Also, because the less technically proficient segments of industry tend to be conservative in their choices (tending to make certain languages outlive their usefulness), and because most "software engineers" could give a shit about programming for the love of it rather than just "as a job", you tend to see little variation in what is popular, and little adoption of radically new paradigms. This is rather unfortunate, and many people see this and seem to mistakenly assume that these other approaches must be no good. Of course, they could "see for themselves," in much the same way HA encourages people to perform their own listening tests, but it appears that for the most part, this is too much too ask...

Thank you for your very extensive answer. I'll answer some parts of it below...


Oh, they most certainly count. Only it seems they are a bit obscure programs that not many seem to use. Perhaps I'm wrong, but I thought Perl5 was the version people actually use, and likewise I thought CVS and SVN were the programs mainly used in the open source world (Rational Rose, Starteam etc in the commercial world).


I only know of the local company Ericsson which uses a homebrewn functional language in their telecom switches. And from what I've heard, new engineers who are introduced to that system are not too happy when they have to make changes in the existing code.. Not to say that functional programming must lead to messy code (quite the opposite), but in this case I guess it has.

Do you have better examples where they use functional programming in commercial applications?


Impressive list! And they all seem to be typical academic projects


I didn't say functional programming is useless. But it's less useful for some things than it is for others.

The areas where it is really useful is where the problems are of a recursive nature. Compilers, lexigraphical analysis etc is very much so as far as I have understood it. Also the mathematical part of the fractal thing you mentioned is easily described with recursion.

Also when you need to prove correctness of your program I think it's better to use functional languages.

But this is a very small and fairly uninteresting area if you want to make money on programs. Yes, for research it's very interesting, and if you happen to be a company which makes compilers then it is also, but otherwise not so much.

Look at the very successful office suite from microsoft. Do you think a functional language would have been useful in the development there?

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.

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.



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.

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.



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

Well I've got nothing against functional languages. They do have advantages and are great for the problems you describe. Any problem that uses heavy mathematical functions and relies heavily on recursion is natively suited to a functional programming language. And you're correct when saying that any problem that can be solved by an object-orientated language can be solved by a functional language, and vice-versa. However that doesn't always mean it will be easy.

The advantage of an object-orientated language is obviously the ability to break any problem down to the smallest of components that each work individually to perform a specific task. In functional programming, you have functions that depend on other functions that depend on other functions. Change one and you could break ten others. It is possible to build programs in a functional language with OOP principles in mind, but is it more difficult to do this in a functional language... that's debatable.

I looked at your criticisms of PHP. Now PHP is not a language I have a strong background in. In fact, I've only ever used it on one project and only in a very small way, so I do not really have a good understanding of the language. However, you said most of these criticisms apply to C#, so I will try to address them.


I do not believe this holds true for C#. Now admittedly, C# is only in its second iteration so it's difficult to see how the language will evolve over time. However, I find the language to be consistent. I'm not sure what you specifically meant in regards to PHP as again, I have a poor understanding of that language.


Well I'll agree that C++ is ugly is this situation. C was definitely not designed for the types of things C++ does. As such I see C# as what C++ should have been, an object-orientated language syntactically similar to C.


Again, I don't believe C# suffers from this problem. In fact, many things that were changed in C# were designed to reduce the amount of superfluous syntax.


The lack of functional programming features is true for C# as well, but this is not its purpose. If you want functional programming, use a functional language.


Clearly not applicable to C# as it's an OOP language with strong typing.


C# 2.0 has generics that are similar to C++ Templates, but support a few additional features.


Again not applicable as C# is not designed as a web language.


After you get used to the visual complexity Visual Studio, you realise it is a very powerful IDE offering a number of very useful features. Furthermore, the express editions of VS.2005 are now free if you get them within the next year (by which time the next version of VS will be in full development). The license is not restricted to that year period either, so you can use them as long as you want.


I point you to this (rather limited) perfomance comparison. Now again, I'll admit this test was fairly limited (ok very), but I think it accurately depicts C#'s average performance. There is another (limited) performance comparison here. The consensus seems to be that C# is slower than C++, but faster than Java. So it's relatively quick compared to it's main competition (Java).

OK, it seems ErikS got in before me. Anyway, like Erik I'm relatively new to functional languages, so don't destroy my credibility too badly .

As a final note, C# and Haskell are to completely different languages. They target different markets with different problem solving needs. One is designed around the rapid and easy building of applications. The other is designed around the speedy evaluation of functions and recursion. There are problems best solved by OOP languages, and problems best solved by functional languages, but in terms of OOP languages, I think C# has to be one of the better ones.

It is true that they are somewhat obscure. Darcs is a newcomer to RCS and has not been around as most of the other well established systems. Perl6 isn't even finished yet -- the specifications are still being worked on. But both programs are surely shining examples of Real World applications whether people actually use them much or not, I think. I also happen to think that both of these programs have the potential to become heavily used in non fp circles. They are certainly useful enough to do so, but it depends on a variety of issues. For one thing, I certainly hope Perl6 replaces Perl5, because Perl5 is quite ugly



That's interesting, but what I have heard about Erlang (the language of which you speak) is quite the opposite. From what I'd heard, Ericsson claimed programming efficiency improvements after switching to fp through Erlang versus other alternatives, and that engineers found themselves more comfortable with the latter approach. Some of this is discussed here, and at some papers linked too off of that page. I suspect information to that regard is also available on the Erlang page itself, although I'm too busy to dig around for it right now.

Erlang is regarded as one of the greatest success stories for "recent" implementation of modern functional programming as far as I'm aware though.

As for applications, aside from what is discussed on the page I just linked to, there is also stuff here and here. There's a lot more that's available without too much digging. Most of that list is Haskell / ML centric, but if you include LISP, Erlang, and others, it should grow quite considerably.



Well, I think maybe we have a different definition of "academic"

To me, something purely academic is something that is implemented purely for the sake of research with regards to the implementation itself. If something is task centric (which most of my examples were), meaning if it was designed to perform some task beyond the sake of research alone, then it is a Real World application.

It so happens then that a lot of Real World applications can be academic in a certain sense, yes. But I think this makes sense -- Real World shouldn't be limited to office suites or media players or video games, or simply some typical desktop application. If we only allowed that definition, huge chunks of Unix userland (or the OS itself -- any OS that is), for example, would not be considered Real World.



Sure. This is definitely true. I just think I disagree with you on where exactly it might be useful.



This is true. But it's also useful in other areas, provided the language is powerful enough. For example, my CPU emulator is not a problem that is naturally specified recursively. It's naturally specified as a state machine, which is practically by definition full of side effects. Yet, even in this case, a language like Haskell was perfect (for rapid development that is -- it would not be perfect for speed). Admittedly this is because I used Monads, which are a clever way to handle things like side effects in a purely functional way but while still allowing an imperative facade over the top. In my case, I threaded the CPU state through a series of monadic combinators, but for someone who does not understand the theory behind it and does not know the inner workings of the language, they would have assumed it was all imperative simply by looking at the code.



I disagree. Whether you choose a recursive or imperative style is really not important most of the time. What is important is which language can most closely match the problem domain, and which language offers the best tools to do this, and which language is the most flexible in this way, etc.

I believe there is a large category of commercial programs which could be made more quickly, more efficiently, more error-free, and more flexibly by using a better approach at the language level, which may include fp or not, but which would probably include expanding the possibility of implementation beyond the couple of choices usually considered.

In Haskell, when I need to solve a problem, I usually implement a domain specific language that suits the problem best, and then use that. It sounds like a strange approach, but it usually results in 1/4th the code it would have taken in a typical language, and it often simply works the first time around. Usually, it's incredibly modular too, and in a way much less restrictive than relying on the OO approach.



Actually, yes.

There are many areas where an fp language could have been good for an office suite. For one, there's a lot of parsing type stuff going on, which as you just mentioned is an area fp is good at. There's a lot of stream processing type stuff going on as well, which is another area they are good at. Processing of large documents can be done pretty efficiently and naturally with a lazy language too, which is something not possible with conventional approaches.

For XML processing, which is increasingly important in recent office suite implementations, Haskell can be incredibly powerful. You might want to take a look at this as an incredible example of the power available. That particular example shows something which I have seen very few other languages able to accomplish -- perhaps LISP can somewhat approach that power, but often at the sake of dynamic typing, which I see as a disadvantage for that type of problem.

For spreadsheet applications like Excel, fp should be a no brainer. Being able to embed small snippets of fp code into cells would be a natural usage, and is completely practical in the case of a concise expressive language like Haskell or ML. Look here to see a great example of these possibilities. This type of thing would not be practical with most procedural languages.

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



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.



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



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.



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



When I first saw it, I just couldn't understand how it worked, after being used to this:



I'm glad I took the time to figure it out

I can't blame bad professors in our courses, in fact I think we had an extraordinary good teacher (John Hughes) in our first computer science class which introduced fp right away before any imperative language. And most faculty members here are very partial towards Haskell. At that time I was also completely convinced that fp was the way to go, but that has changed over time.

Maybe you should come over here and do your master You can choose courses freely then...

http://www.cs.chalmers.se/Cs/Education/Courses/index-en.html

Hrmm. Maybe. I suggest that any problem easily solved with OO can just as easily be solved with a sufficiently powerful fp language. If you can come up with a good example where this is not true, I would like to know about it, because I suspect I could provide you with an easy counterexample.



You are thinking of procedural languages, not functional languages.

Functional languages likewise have you break the problem down to the smallest components, except usually the smallest components are even more abstract and general than what you see in OO. You do not run into the dependency problem because you use abstract data types, parametric polymorphism (which in fp you essentially get for free because of the ease of functional abstraction and automatic type inference -- the same isn't usually true of OO and you need to design the polymorphism in with a lot more effort), and higher order functions (the latter of which you don't even have in procedural languages). If you need sufficient flexibility, you use higher order polymorphism, type classes, and quantified types. Through type classes you get something quite analogous to overloaded functions and groups of types (something like class interfaces, but with a functional flavor), which you can compose through (multiple) inheritance in a way very similar to OO. Unlike OO, you are not forced into the data encapsulation, message passing paradigm. You can be more general, which is quite a good thing. But if data encapsulation and message passing is your game, you have closures and records, and because you have first class functions in an fp language, you can perfectly emulate OO if you need it. Taking it further, with the ability to arbitrarily define operators (infix functions of symbolic characters like +, ->, =, etc.) and through the use of type classes and monads, you can define a domain specific language that looks practically *exactly* the same syntax wise as your favorite OO language.

FP is a lot more sophisticated than you give credit for, especially if you are considering a modern language. If you are talking about a procedural language like C, without OO, and without any of the mechanisms which allow you to easily achieve the same ends as OO, then I agree with you that there is a problem. But the way you just said it is a misunderstanding I believe.



I don't think I'd say most, but I'd say many. Obviously there are many that do not apply



I will agree that C# is much, MUCH, better designed than PHP. There's no comparison. But I don't agree with many of the design decisions.



C# isn't significantly less ugly than C++. It is in certain ways, but it makes up for it, like Java, in other ways by being more verbose. OO doesn't have to be so cluttered and verbose. Smalltalk or even LISP proved that a long time ago.



It's better, but it's still too much IMO. I suppose it's very hard to understand my complaint here though unless you have programmed in ultra concise languages. Using something like Haskell, ML, or APL, and then going to something like C# or Java, is a HUGE difference. The former show that a language can be extremely compact and more expressive at the same time, than what you see in recent popular languages.

My beef with this goes beyond aesthetic concerns too though. In my opinion, there's so much syntactical cruft in the latter languages that it becomes more difficult to reason about program operation simply because you can't absorb as much of the code at once -- you have to consciously filter out a lot of stuff that doesn't need to be there, in terms of brackets (FWIW, I hate this about LISP and Scheme too, and this is why I don't program much in these languages even though I recognize it's power aside from its verbosity -- I often have long arguments about language terseness and expressivity with my LISP weeny friends ), keywords, etc.



Sure. But why not have some of both? Most OO languages use iterators these days (something like the STL for C++), which to anyone having used fp, is obviously trying to emulate higher order functions. Why not do something like Python and actually provide lambda and list comprehension and some of the rest of it? Why not do something like OCaml and provide a thoroughly functional ML dialect with powerful native OO at the very same time?

Languages which can offer both styles are better than languages which can only offer one style. Oz, even more than the previous two, is an excellent example of this. If you'd like to explore this idea more, I suggest reading this book.

IMO it's stupid to constrain a language solely to one style if that style cannot at least emulate the others necessary with sufficient transparency. Most of these OO languages, when trying to do fp type stuff with iterators, are not sufficiently transparent.

And FWIW, some of the features I mentioned (pattern matching, list comprehension laziness, constraints, continuations, etc.) do not even necessarily need to be constrained to fp languages. Often times, things like this really have nothing to do with fp per se at all. It's just the case that fp type languages that follow in the footsteps of ML often provide them. There is absolutely no good reason to leave them out of other languages like C#.

C# 2.0 has generics, but those generics are not capable of metaprogramming like C++ templates are. Java's similar solution is likewise not capable of it.

C++ are quite a strange exception in this regard, because they were not designed with metaprogramming in mind, and in fact it's more of a side effect that you can actually use them as such. Some may be surprised to learn that most of this power is due to C++'s template implementation being Turing complete. Indeed, when it was first discovered that one can use C++ templates for metaprogramming, someone implemented LISP inside the C++ template system. No, not as a C++ program using templates, but as a template program running inside of the C++ compiler.

It may be unclear what exactly this means if you are unfamiliar with the powerful macros of other languages like those of LISP, Scheme, and Haskell, but trust me, C#'s generics are not even in the same class. They will provide a nice solution to some problems, but not this one.



I've no argument with regards to C# development tools. I know there are good ones.



Yes, this is the impression I've had before too. I actually like C# a lot better than Java from what I have seen of it.



Hrmm, I don't really agree with such a simple depiction of the situation.

Both C# and Haskell are full fledged, general purpose programming languages. It is true that as far as marketing is concerned, they target different markets. But as far as capability to solve problems is concerned, this isn't all that important of an issue.

C# may be designed with RAD in mind, but I think you would find that a seasoned Haskell programmer (or even possibly a moderately successful one) could prototype a solution to a problem in a fraction of the time it would take you in C#. Likewise, the codebase would only be a fraction of that of C#. I would argue, that if it were the seasoned Haskell programmer, it would also be a more general solution, and probably more modular too (despite being functional).

As some evidence to substantiate this claim, you might want to take a look at this. The ICFP contest is called a "functional" contest, but you can really use any language you want. People use C fairly often, and I believe people have probably used Java and C#. The problems for the contest are not at all what you expect for a "functional" contest. The last one, I believe, was a contest to design an ant simulation where people designed ant models that competed against eachother (in other words, IIRC, the idea was to design the best ant model and behavior for competing against opponents). Not surprisingly, in my opinion, Haskell and OCaml usually dominate this. I believe this is because they are better at fundamental problem solving. Given time constraints, the "RAD" aspect of C# shows itself in these situations to be somewhat of a facade, unless you are dealing with very specific types of problems.

(Edit: Actually, this one from 2004 is the ant one)

This is, of course, assuming that you are working on a problem for which there is a similar level of library support. I think there is a reasonable correspondence for most situations.

Perhaps the one exception where this may not hold true is with GUI programming. A lot of this is going to depend upon your tool usage outside of the language. Haskell can make use of Glade through Gtk2hs, but I have a feeling that C# via Visual Studio will be a better solution there. It may be the case though that in the end, the ease of implementing the rest of the solution to the problem in Haskell may make up for inferior GUI construction tools however.



Strictly speaking, there is some truth to this. However, a powerful enough functional language can emulate all of what an OO language can, especially once you recognize that closures are equivalent to objects. With algebraic data structures, as I described above, you have everything OO has. But this is not true with OO -- you can't nearly as easily emulate the same stuff the other way around. And also strictly speaking, the cases where OO is *clearly* a good choice (stuff like network transparency, agent based simulations, etc.) is not the domain that most people recognize OO to be superior in -- instead they usually think it is best for "almost everything." This simply isn't true.

Oh, wow. I am jealous of you now I would have loved to have taken a class from someone actually interested in fp to the degree Hughes is. I've been reading some of his work lately (about Arrows specifically), and it is very, very interesting to me.



Yeah, I've heard that there's a bit of support for Haskell there

I in fact may try to go to school in Europe somewhere once I am finished with the first part of my education here. Right now, I do not know for sure what I will do, but I am thinking quite a bit about language research as a serious possibility. Part of why I am so partial to Haskell is that it has sort of served as a launching pad for me to begin to learn some very difficult aspects of theoretical computer science and in some cases math (stuff like category theory, theory of types, denotational semantics, etc.) that I would not have otherwise had exposure to. To find out that I like this stuff as much as I do, and to have it all fit together so nicely, is part of my enthusiasm over fp and related concepts (though I find the idea of multi-paradigm kernel languages like Oz to be quite fascinating as well).

Indeed, I just spent some time looking into metaprogramming, and it's a much more powerful tool then C#/Java generics. There not even the same type of tool really.

However, C#2.0 does provide a number of other FP style programming paradigms. For example, C# has anonymous delegates (closures, but not closures). This allows for curring, and a whole lot of other nice FP style things. See here. C#3.0 will also add Lanbda expressions like:


I did 1.5 years of Java programming before learning C#, and let me tell you C# is a much nicer language. It's not just the language though, but the whole system. The libraries, core language features, the IDE's, the documentation... C# and .NET have seemingly one-upped everything from Sun. This is however typical Microsoft style, take the core ideas of someone else's product and re-invision them into a wholey better product (or they at least try to).


Perhaps, but the beginner programmer certainly couldn't. You can't just pick up a functional langauge and start using it unless you have a solid understanding of functional languages in general and mathematics. The concept of objects is much easier to grasp and learning most object orientated languages is a relatively easy affair. Does it pay to learn a functional language through-and-through... certainly, but it takes more time and effort to learn a functional language then a OOP language. That being said, my University starts with LISP (although I started with Java at univeristy, and VB6 in high school).


I think ugly is the wrong word. I think C# is more consistant then C++. Being more verbose isn't neccessarily a bad thing either. The whole point of high-level languages is to:
a. make it easier to program, and
b. make it easier to read.
Verbose languages are certainly easier to read and understand than something like LISP, particularly for someone who is new to the language. Of course verbose languages mean more typing, and that means more time, but IDE's do half the typing for you now anyway. BTW, LISP's brackets annoy me to .


Fair enough. I know plenty of people who don't agree with the design decisions in C#. There are things that annoy me to.


C# certainly does significantly improve on C++ in terms of controlling object behaviour. That said, I'm looking forward to the next version of VS. They'll provide full integrated support for WinFX with WPF for graphics, and XAML code to build forms. I've watched a few channel9 videos of late and XAML is certainly going to make form design and connecting program logic to the GUI significantly easier than in C++. But like you say, this is down to tools.


Is that like building the car/house/insert-your-favourite-inanimate-object-here that has everything. The whole strength of .NET is that one minute you can be writing in C#, and the next in Perl, then in J#, then in C++. When you can so readily switch between languages, why build a language that can do absolutely everything? Why not more closely target your languages to specific problems.


That's like saying I could drive faster than any other car if I had a powerful enough motor-cycle. Of course you can. That doesn't mean FP/OOP languages are good/bad, it just means they're different. I will however look for an example where FP languages are not richly suited to the task. And I am sure you could provide an easy counter example, there are many situations not suited to OOP languages.

Hrmm, I don't think that's what it is like. Oz, for example, is a much less complex language than C#, yet it is significantly more general. You should look at that book I posted a link to if you ever get a chance.

Designing a language general enough to encompass a wide variety of computational styles doesn't necessarily imply you have to go the kitchen sink route -- it just means you need a very clever design is all.

As for why you'd want all of that in a single language, well it comes in incredibly handy when you want to keep things clean, concise, and maintainable. You can break things into very small components, yet use different styles -- sometimes these programmatic units are too small to be worthy of using an entirely different language for, and often language interfaces are not as nice as you'd want and add too much of an overhead to make this approach viable otherwise.

If you ever use a language which is suited to domain specific language implementation, you'll see why having this sort of flexibility is so incredibly useful. Sure, you can get some of that with .NET, but it comes at a high price, both conceptually, and tool-wise.

Bookmarked. That's now two books I have to read over my end-of-year break from university. The other one is that C book you recommended a while ago.

Nice. Both are good, but this one should probably prove more worthwhile if you don't plan on doing much plain C programming.

In fact, the authors were giving away pdf revisions of the book while it was being written some time back. There is probably a late-but-not-final revision floating around somewhere still if you look.

Another good book in the same spirit as Concepts... is the SICP (although Scheme based rather than Oz based), which is available for free online. Some view Concepts... as being a sort of modern SICP.

At any rate, regarding C#, I should clarify that I don't think it's crap -- that was just strong language in the context of a general frustration I was expressing. I think that for what it is, it's a probably a pretty good iteration. If I ever have to use that type of language, I'd much rather use it than Java.

Aaah, another bookmark, oh well.



Well I can settle for that.

Seeing as where talking about programming languages, what have you been building your new music player in. Is it all Objective-C+Cocoa, or is their some FP in their two (or can you fake FP with Obj-C)?.

About functional vs. OO languages:

Maybe the question is stupid - why is it actually neccessary to choose between the two? Take ruby for example: technically, it has no functions.... but methods are very similiar to functions. So, ruby only has methods and objects, but the trick now is that you can use ruby as a functional language as well and ignore the OO-part if you wanted to..... why? well, because you start out with a "root-object"... the root-object basically is the environment in which your code is executed...... this means that you can add methods seemingly without attaching them to an object..... so, use them just like functions.... behind your back, these "unasigned" methods are just bound to the root-object.

I do find this approach very interesting, because you can code however you want.... you dont need to care about OOP vs. functional programming..... if you want to programm with functions only, then you can do that.... if you want to code with objects and classes, you can do that...... and you can also do both at once, as well as start with the functional approach, and later add OO-aspects to your code, without having to rewrite much.

I definatelly dont consider ruby to be a pretty and good language...... but the above aspect of it i like very much... you can just code your style, without being forced to decide on paradigms beforehand.

I was very taken with the whole idea of functional languages for many years but I've gradually grown more suspicious of them. Advocates of functional languages make all kinds of claims for their superiority but offer very little proof. There's this unstated assumption that academic programmers are inherently more intelligent and sophisticated than their industrial counterparts and the only thing holding back the success of functional languages is the poor taste of the working programmer.

It seems more likely to me that people working in academia enjoy a life free of the constraints imposed on the working programmer and that many of the claimed advantages of those languages don't translate to typical software development projects. Take Haskell, for instance. A very elegant language, but lazy evaluation as the *default*? What a nightmare to debug memory problems. All the real Haskell code I've seen is littered with strictness annotations. OCaml seems more practical at first but the type system can make C++ templates seem straightforward. Lisp is much more pragmatic and, IMO, the most genuinely useful of the whole family but it scares off too many people to form the kind of community a language needs to thrive without the backing of a Sun or a Microsoft.

These days I'm much more taken with the "scripting" languages, particularly Ruby. Very practical, cleanly organized, none of the complexity of static typing etc. I've learned a lot from studying functional languages and I think it's made me a better programmer but I also have to confess I'm glad I don't have to work in one. I turned down an Erlang job a few years ago and with hindsight I think it was the right move.

@Lyx:

What you describe isn't quite functional programming.

Ruby is capable of emulating some important bits from fp with its block/closure thing, but that alone doesn't give you fp. And fp itself isn't just about programming with functions.

Probably the two most defining features of fp are higher order functions (with Ruby can kinda sorta do), and referential transparency (which Ruby doesn't have).

There are definitely some trade offs by going lazy by default. Simon Peyton Jones had some interesting observations on this here. Sure, basically, it's not all roses. But it has many pluses. I personally tend to like something like the approach in Alice ML, where you can get laziness quite easily if you need it, but everything is strict by default. However, Alice ML is not as flexible as Haskell in many regards, unless you are doing constraint based programming or doing something with distribution and concurrency.



I really have to disagree completely here. Have you seen advanced C++ template programming? Take a look at Boost. Then come back and tell me OCaml's rather simple type system is less straightforward. Strong, static typing via some derivative of Hindley-Milner with the type of annotations that OCaml uses is, in my opinion, not much more difficult to understand than the type system in much less advanced languages -- that is, unless you're not used to thinking about static typing. Most of the LISP users I know find ML very difficult because of this.







For reference, are you talking about Scheme or Common LISP? Sure, both are good languages. I'd argue as to whether they're more genuinely useful than ML though, but that's a debate that probably won't see any resolution.



Ruby is nice. But as strong static typing leaves, and with it algebraic data structures, you lose a lot of flexibility overall. It might make the rest of the language seem easier to use for some things though.

I don't think I'd call OCaml's type system "simple". Have you actually used it much? When people start nesting functors and using polymorphic variants the type inferencer can start spitting out some really scary stuff. Then it becomes a game of finding all the right type declarations to keep it happy. A bunch of the real-world OCaml code I've seen is littered with type prefixes like string_ on fields etc to help keep this stuff straight. The objects system exists as almost an alternate type system alongside the underlying ML core, and things can get really weird when you start mixing them.



CL by far. Scheme is a pretty research and teaching language but it's *far* less useful than CL for real work. I can think of quite a few extremely complex and large CL apps out in the world now but pretty much nothing for Scheme. It's not obvious at first, but CL is an extremely practical language. Much of what's in there is there because it makes writing real code easier, unlike Scheme which always chooses the elegant over the practical. People point to the conciseness of the Scheme spec but it's not hard to define a language that simple when you leave so much out.



People always say this but I'm not sure I believe it. Surely in an absolute sense duck typing is far more *flexible* than any static typing system could be.

I think in all language debates it's important to keep in mind that no language is the "best" in any absolute sense. OCaml and Haskell are very nice for writing compilers but I don't think it's an accident that nobody's written a web browser or photoshop or itunes or a vorbis encoder in them. The research languages are valuable in that they provide a testing ground for new ideas and the best ideas tend to percolate down to the mainstream eventually but I think there are good reasons why they tend to stay in the laboratory.

Yes, I've used it quite extensively. You are right, there are parts of it's type system that are non-trivial. But polymorphic variants, functors, and similar features (which I have used) do not need to be used for most typical programs either. I'd expect an advanced programmer in a functional language to be likewise advanced in dealing with the type system. For many tasks, however, you rarely have to deal directly with the type system and can rely mostly on type inference. As the complexity of your task grows, the complexity of the tools (type system) grows along with it to some extent -- no real surprise there.

And at the end of the day, I still find OCaml's type system to be significantly less difficult than Haskell when you really push them to the edge of their capabilities. This also should be no surprise, because Haskell's type system is simply more advanced through and through (rank-n polymorphism, fundeps, GADTs, existential types, type classes, etc.). Again, though, most of these features won't need to be used for simple programming tasks.



That's pretty much what I expected. Yes, Scheme is less practical than CL, if only for the library support. I admit I tend to like the design of Scheme a hell of a lot better than CL on a number of points though. I don't anticipate using either for large projects though -- they remain a little more like a novelty to me, or something to experiment in, than anything else. For me, giving up strong static typing and most of the other features I've grown used to in ML family languages is too much, unless I'm going to program in a wholly difficult language paradigm to begin with.

But it is interesting that you consider CL functional -- most of my LISP using friends tell me(and from what I infer from many other places) CL is rarely used functionally. Although you can do it, most people don't. Scheme is often used more functionally (obviously), but on the whole its usage is still less pure than ML, and the same for ML vs. Haskell or other purely functional languages.



It's flexible in the sense that "anything goes", sure. But in the sense of doing something complex in a safe way that's easy to reason about (usually important for complex things!) and easy to maintain, it's not.



I never said that they were the best languages. I never even said functional programming was best. I explicitly stated many times that I tend to use many non-functional languages -- but for some reason, people latched on to the functional parts of my comments more than others, and the discussion has slowly gone off in that direction.

Someone has written a web browser in Haskell FWIW, and probably OCaml. The latter you are probably correct about. But this I believe is not so much due to the languages as it is due to API issues. The applications you list are quite typically heavily dependent upon OS specific API's for network code, image code, audio code, and GUI toolkit. Most functional languages have bindings for large parts (or even all) of those, but they do not match what is often provided as the "native" implementation language for the OS, and this is the reason I believe you don't see those types of programs in fp often. Again, this isn't really a mark against fp though, because aside from Java, most of the world is still stuck in C or C++ mode on that regard. The situation is pretty similar for most of the "scripting" languages as well, although not quite as bad since there is a little more interest in supporting them (I believe this is due to the fact that they are on the whole quite similar to languages most people are already familiar with).

While i as well am mostly interested in this kind of languages, i disagree that ruby is cleanly organized - sure, it has achieved alot without a single revamp, but even matt now agrees that it is suffering from growing pains, that some of its behaviour (like local vars) is weird and that some of its syntax for advanced features like hashes, keyword-arguments, etc. are plainly unnecessary complicated. I'm very interested in how RITE/ruby2 will turn out - but then again, currently they seem to lack the necessary manpower to do it.... and i fear ruby2 may become something like duke nukem forever ;)

What, however, i'm more afraid of, is that in all those plans for ruby2 and its syntax-redesign, no single word was mentioned on the topic nested namespaces... i consider the :: notation the most ugly piece of ruby's syntax. And dont get me started about the limitations and unnecessary complicated creation and handling of nested namespaces.

So, i do like ruby alot - coding with it overally is just "fun"... it feels intuitive. I completely agree with the intro of the pragmatic programmers guide to ruby - it brings back the fun into coding. Unfortunatelly however, i don't consider ruby to be ready yet.... the overall concept and philosophy behind it are great, but it needs a revamp and polishing to be ready. Take the roadmap-features of ruby2, RITE, and namespace/module-handling as it is done in python, and it would be my dream-language.

Scheme certainly has fewer warts, but Lisp was pretty simple in the beginning too. Languages tend to become less elegant as they evolve.



CL's syntactic flexibility makes it a truly multi-paradigm language. You can write oo, functional, imperative or logic code with CL. I think it's probably true that most CL code isn't particularly functional, but I'd argue that it's because the functional paradigm isn't really all that practical for a lot of things. Mutable state is just usually more straightforward for than a more elegant but less tractable functional implementation. Have you read Okasaki's "Furely Functional Data Structures"? Some very clever stuff in there but I found myself shaking my head halfway through it at the convolutions he has to go through to do relatively simple things. I like the functional, expression-oriented style in the small but I think it breaks down when you start trying to treat big complex aggregates in a functional way.



It seems that this point always gets argued in a vacuum. Large and complex programs have been written in statically and dynamically typed languages, so I think it's not really clear which one has the advantage. Perhaps other factors are more important?



People have writen toy browsers in OCaml, Haskell, and even emacs lisp, but I'm talking about something to compete with Firefox. Your point about the C bias of the underlying OS is valid, but I don't think it's the biggest issue. Honestly, I think people put too much emphasis on programming languages. I think the biggest predictor of a project's success is the skill and the motivation of the programmers. I think the biggest problem for the ML/Haskell/Lisp is that they're too weird and counter-intuitive to attract the kind of grassroots support that a language needs to survive without the backing of a big company. Somebody's got to write all the essential but unglamorous libraries and documentation and I think it's instructive that Ruby's made more progress in two years than OCaml or Haskell has in toto.

I wrote my first "program" in RPG II in 1974. In college (TAMU '80), all of my assignments were in Fortran, except process control stuff in some obscure assembler. Since then, I've programmed professionally in several assembly languages, Basic variants, scripting variants, lisp, C, Objective C, C++ (starting before they had templates), C (starting with original K&R pre ANSI), Java... Blah blah blah blah.

I've read a couple of books on C# and like it, but haven't actually tried to use it. I've done a couple of things (not professionally) in Smalltalk and think it would be the Only Language in a Just World.

(Oh, I can't believe none of you mentioned Just About Every Function in emacs as a use of lisp. sortof. 'Not to start a vi vs emacs war. )

After all of that blah blah blah, the bottom line is this: you are going to write your best, most creative *and* most reliable code in the language you know best. You're communicating instructions to a dumb machine, for heaven's sake. Yes, new languages are Good (Java and C# make some aspects of reliability *easier* than, say, assembly language). But it's what you know. Yes, some problem spaces just should not be attempted in certain languages and sometimes it's time to learn a new language.

A semi parallel: I know folks who are fluent (really!) in multiple spoken languages. They don't just "get around", they know the grammars. But they're an aberration. The Rest Of Us are wise to stick with our first language when possible. We make mistakes when we try to communicate in any other language.

Why it's not a good parallel: programming languages are vastly simpler than spoken ones. Sometimes, it's worth learning a new one when the new one makes it easier to express your desires to the computer.

Here's another rub: if you're going to argue about which language is better, you need some criteria. Ease of expression is a Big One. You may think your language is The Best. But I'm here to tell you that the only way to measure that is to do some random sampling and see how easy folks pick it up. If 100 random people all have a harder time picking it up than, say, C#, you may be tempted to conclude you found 100 idiots but the truth really will be that your new language sucks. If you don't have the tests to prove your language is easier and more expressive, well, see Ye Olde Rule 8.

And, after all of that, I'll admit that just about every language I program in (I currently stick to C++, Java, and Javascript) sucks.

Second, wide acceptance IS a fair criterion. Why don't I waste my time learning Latin when it's Such A Beautiful Language ™? Because nobody speaks it (unless, of course, you have alternative motivations). For most folks and for this reason, Latin sucks and so does your New Obscure Programming Language. And no, I don't have one in mind. And yes, I know that the ease of expression issue (which, again, can only be addressed by testing with large numbers of people) can turn today's obscure language into in the Lingua Franca of tomorrow.

Oh, FLAC R0X0RZ!

Mark

You should check out "Io" in that case - you'd probably like it. Personally, while i've been fascinated about the smalltalk-approach, i always found myself doing too much micromanagement and loosing track of the big-picture when using smalltalk-alike languages.

I don't think I'd call a hash an advanced feature. Ruby's hash syntax is essentially the same as Perl's or Python's so I'm not sure I understand what you object to about it. The keyword syntax for functions is a hack, and I do hope they do something about it for Ruby 2.

I think Ruby gets the important things right though:

1. deep and pervasive object orientation
2. consistent method naming
3. simple but flexible object system
4. dead simple C api
5. consistently expression, not statement, oriented
6. abundant syntactic sugar without perl's excesses
7. good documentation and third-party library support

It's not perfect but I very strongly prefer it to the alternatives. Matz set out to make a language that was elegant and enjoyable to use and I think he succeeded.

That's the plan.
http://www.rubyist.net/~matz/slides/rc2003/

I agree that LISP is quite multiparadigm. I feel that Haskell is as well, although it all boils down to a functional base. With monadic combinators, and many of its other more advanced features, you can emulate basically any style of computation you want. This is meant as a joke, and it's a bit twisted, but it's actually also quite illustrative. And many of those examples only touch the surface of Haskell, not really using many of the recent extensions to the language. Oz, I think, is another great example of a truly awesome multiparadigm language. Sadly, it will probably remain rather obscure.

As for Okasaki's book, I actually own that one You're right about some of the convolutions. But you have to remember that he took a rather extreme approach with that book -- going purely functional with a fairly minimal set of fea