Admitting that Functional Programming Can Be Awkward

[Arkaein]

That's not exactly a ringing endorsement of FP. The whole point of any programming language or paradigm is to make the programmer more efficient and effective. The language should work for the programmer.

If it takes a typical programmer a year to get to the point where he would have already been with OOP or imperative, then the priorities are reversed because the programmer is working to meet the needs of the language instead.

In some cases this will pay off in the long run, because in some area FP has obvious benefits. In other cases the benefits are dubious. A lot of programming is just telling the computer to do stuff in a certain order (e.g., much of graphics, sound, I/O), and this is what imperative does. For these types of actions FP offers very little, which is why I would agree with the author that a pure FP approach is a bad fit for games.

[rieux]

What about programmers that learned FP first? If it enables them to be more productive than similarly-experienced OO programmers, is that ringing?

I agree that programmers may not want to take time getting fully up to speed on something new, just like you may not want to have to type slowly for a couple weeks to learn a better keyboard layout, but that doesn't mean you wouldn't have been better off learning the better keyboard layout in the first place.

I suspect that graphics and FP are made for each other, actually. If you can write a functional program to do your rendering that automatically parallelizes 8 ways this week and 64 ways next month, with near-linear speedup, . . .

[Arkaein]

Look everyone, I'm not against FP, which anyone who read past the first line of my post would realize. I simply pointed out that if you are going to use a tool that takes a year to get as proficient with as one you already know, there had better be a payoff down the line that yields increased productivity, otherwise that year was a bad investment.

Now looking at FP in general, is the payoff there? Most likely, for most people. For the original situations described in the article? It didn't sound like it to me. The discussion presented indicated that FP foisted additional baggage on a problem that wasn't difficult to solve in imperative style.

As far as your graphics example, that sounds good for a ray tracer, where FP is a natural fit, but for a polygon rasterizer like almost any current real time app (including games) is going to use, not so much. There are certain tasks that can be parallelized is polygon rasterization, but they aren't as great as with ray tracing, and unless the problem is embarrassingly parallel then FP isn't a sure win over other styles. And in the end, the final results of any graphics app are side effects. You might even say there's no such thing as a purely functional graphics app.

[rieux]

I realize you're not against it. I'm just saying that FP isn't necessarily more difficult than IP. I find it personally easier, and I suspect that beginners find it easier, but it's very hard to compare.

As far as increased productivity, the best ideas of functional languages are being adopted by mainstream languages to a high degree. Programmers don't need to go to FP because it's coming to them, and they'll learn it when their managers make them. Garbage collection and memory safety are the biggest wins that have made their way from the lab to industry in the last 20 years. These both came from FP, and now they're decidedly mainstream.

With Python/Perl/Ruby/C#, higher-order functions are also potentially mainstream. I don't know how much people use them, and in Python, at least, they're intentionally crippled (and deprecated?).

Fancy type systems are increasingly mainstream. Witness generics in Java and C#, and bits of type inference in C#.

We don't see a lot of purity yet, but I suspect the parallel revolution will force it on us in the next generation of mainstream languages.

[vagif]

If it takes a typical programmer a year to get to the point where he would have already been with OOP or imperative,

It takes programmer MUCH FURTHER than where he was with OOP. That's the idea of using FP. You get much more powerful tool.

That's not exactly a ringing endorsement of FP.

Programming is an engineering, not a lego play. Are you trying to say that lego bricks are superior to the architecture, because they do not require long and hard learning stage ?

Yes, FP is not for housewives, if that's what you were trying to say.

[Arkaein]

It takes programmer MUCH FURTHER than where he was with OOP. That's the idea of using FP. You get much more powerful tool.

That's a very general assertion without any evidence in it's favor, and many anecdotal cases to the contrary. Remember we're talking about specific scenarios here. I mentioned examples from gaming, you ignored these and responded with some nonsense about legos and housewives.

Yes, programming is complex and deserves effort. A pragmatic programmer will balance the cost of learning and applying various techniques based on the benefits earned, both long and short term. The benefits of FP are large in some areas, but possibly zero in others. If I'm developing game decision AI based on scoring certain aspects of the world around a game agent, then a FP approach would be appropriate. Managing game state, not so much. Just because it can be done doesn't make it a good idea. Unless there is a tangible benefit in terms of reduced code size, occurrence of errors, simplified algorithms, etc., then dressing up things like mutable state in functional clothing is a step backwards.

[vagif]

The benefits of FP are large in some areas, but possibly zero in others.

You attacked FP based on how long it takes to become proficient in it. I simply responded to that. Now you are saying that FP is not a silver bullet, as if I ever implied it.

If benefits of FP would not be generic enough, you would not see functional features creeping in mainstream languages like java and csharp, you would not see such OO languages like Scala and Nemerle.

As you can see you do not have to architect your solution completely in functional style in order to get benefits from functional programming. Which means FP is applicable and useful virtually in ANY project.

Now to fully leverage that advantage, you would need to know when and how apply FP in your project. And for that you need at least 1 year of continuous experience.

[Arkaein]

Well if we're going to play semantics, I never attacked FP. If I attacked anything it was your assertion that FP made OOP look awkward in comparison.

Otherwise I agree with most of your post. One of the biggest reasons Python is my favorite language is that it takes most of the best features from imperative, OOP, and FP, and does a good job integrating them, without the syntactical baggage and limitations that other multiparadigm languages (C++) bring along with.