Why Why Functional Programming Matters Matters

http://weblog.raganwald.com/2007/03/why-why-functional-programming-matters.html#

by shawndumas • 15 years ago

99 25 15 years ago

weblog.raganwald.com

It's nice to see this surface again. Personally I think it's interesting, and useful. If you want to read previous discussions about it from here on HN, here are some references:

http://news.ycombinator.com/item?id=1048304 <- 9 comments

http://news.ycombinator.com/item?id=3934 <- 4 comments

The original "Why Function Programming Matters" has, of course, also been submitted:

http://news.ycombinator.com/item?id=50193

http://news.ycombinator.com/item?id=983401

http://news.ycombinator.com/item?id=1482797

There was less commentary on that.

shawndumas• 15 years ago

You know... I often do not give encouragement and/or express gratitude because I am afraid of being corny.

But I am beginning to see that even if you already know the value you bring to HN, or even if it seems sycophantic to say I appreciate you, it never matters so much that it should suppress a sincere, neighborly, human, "thank you, keep it up"!

So even if this is the wrong place (or even the wrong way) to do this -- an upvote seems insufficient -- I want to say thank you, RiderOfGiraffes, for all that you bring to the experience that is HN; may your tribe increase.

RiderOfGiraffes2• 15 years ago

Thank you - appreciated.

kenjackson4• 15 years ago

I disagree with a lot of the points in the article, but I think its well-written, thought out, and worth reading.

raganwald3• 15 years ago

I'm interested! Can you elaborate a little on which points clashed with your experience?

kenjackson4• 15 years ago

Sure. Here's one example, "It looks at first like there’s a clear factoring 'Baltic Avenue has a method called isUpgradableToHotel,' but when you look more closely you realize that every object representing a property is burdened with knowing almost all of the rules of the game.

The concerns are not clearly separated: there’s no one place to look and understand the behaviour of the game."

The concerns are clearly separated, but they're separated along a different axis than what you're looking for. I'll argue that for any partitioning of concerns there will be a concern that is not adequately separated.

With that said, I must admit I'm unclear why each property object has to know all of the rules of the game. They don't have to know most of the rules AFAICT. This may seem like a small point, but I do think its important. I think the only thing they have to know if their cost to buy, upgrade, and rental price (I'm not a monopoly expert, so its possible I've missed something).

To buy there's a fixed price associated with the property-- you just need to not be owned by someone else. To upgrade I assume its a fixed price. I think the only requirement is you own all the colors. In which case you defer their ability to buy to another class -- the property group class. Baltic Ave doesn't need to know what the actual rule is -- it just asks "Light Blue Property Group Object -> Can I be upgraded?"

But the property object has no idea about passing Go, what Jail is, how many dice are used, what Chance cards are, who their neighbors are, how many other like-colored properties there are, what special powers railroads have, if there's a community pot, or how many players are even playing the game. The partition of concern has been made along some axis that this programmer thought useful.

Another is the telephone test and entangling what and how. I think what and how are the same thing. The for-loop example though is solving a different problem than the select example. It's solving a more constrained problem that you can't generally solve with the select syntax. It turns out though that what you are looking for happens to be provided by both solutions. As you move up the stack your problem requirement may be less constrained, in which case you don't need the rigor, but we should note that the rigor isn't simply the how, but just a degree of rigor (unfortunately standard languages with for-loops have to solve more constrained versions of the problem). What the telephone test is really about is that for anything you actually care to discuss on the phone will not be extremely rigorous.

But I feel like those are nits which I probably uniquely have, which is why I didn't actually mention them. But I wanted to point out that I disagreed, because I think it strengthens how much I enjoyed it. And while I disagree today, the fact that I read it and thought about it may mean that I disagree less tomorrow.

JulianMorrison2• 15 years ago

"It is a logical impossibility to make a language more powerful by omitting features" - false. Different designs have different limitations. C can't have precise garbage collection. Shared-memory threads can't be isolated and so can't be automatically migrated. Pure functional code can be rewritten by the compiler in a way that imperative code can not. A language that omitted any global construct would be intrinsically sandboxed against use of any functionality not injected. And so forth.

raganwald3• 15 years ago

I think we're in violent agreement. Removing a feature only makes things better when it permits the addition of another feature. This is the point I trying to make about pure functional programming. Removing the ability to arbitrarily entangle state in time does not make a functional language more powerful, but adding lazy evaluation does make it more powerful.

Am I correct that we are seeing things the same way, even if my ability to explain it is poor?

joe_the_user• 15 years ago

Ah,

You are looking at the situation from a pure semantic point of view and from there, you are correct.

I think the parent is looking thing from the point of view of effective computing and they are correct from their point of view.

The viewpoint are perhaps incompatible.

One thing to consider is that I would say that I "can't" implement a recursive descent parser in Ruby because Ruby is too slow. Thus from the point of view of effective computing, adding features that make Ruby slow also removes some power.

I wouldn't say either position is "correct" but I think you have to take both into account.

eru2• 15 years ago

You can argue that removing features can make a language more powerful, even if you don't add another feature.

Basically, if removing your feature, like side-effcts, allows you to give more guarantees about sub-program, you can do more with your sub-programs. Like use equational reasoning.

MichaelGG• 15 years ago

Not really. Take the pure functional example - you've got power because the compiler can transform certain parts of code. Now, throw in all sorts of unsafe mutable operations to the language. The language can still transform the pure parts, so you've lost no power. But you've gained the power to write other types of code as well. It's not as if you have to use every language feature all the time and suffer the downsides everywhere.

JulianMorrison2• 15 years ago

This still depends on the design of the language, though. Consider Java. There is definitely a pure functional subset of the language. However, any time you call across an object boundary the compiler has no way to know that the call can be treated as functional - because the language has late binding, and the actual implementation is swappable. In practise the JIT learns stuff like this and transforms it at runtime. That extra effort is needed because the language can't guarantee functional purity.

The point here being that some design decisions that add functionality remove the ability to rely upon design assumptions.

goodtobe• 15 years ago

The link to the original paper seems to be broken.

I found this one on Kent's website: http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...

wladimir• 15 years ago

An argument for functional programming languages that I've heard many times is that they can be optimized very well for (automatic) multi-core parallelism and even GPUs.

But I've never found any actual examples, evidence or benchmarks showing this in practice.

Anyone have any pointers on this?

eru2• 15 years ago

You should listen to Guy Steele's talk he gave on 2009's ICFP: "Organizing Functional Code for Parallel Execution: or, foldl and foldr Considered Slightly Harmful" (http://www.vimeo.com/6624203).

He drives the point home, and adds that you also need appropriate data structures.

dsc• 15 years ago

What about the stack? With all these function calls, it's nightmarish to optimize.

merijnv• 15 years ago

(I think) you're starting with the flawed assumption of what "the" stack is, while functional languages like Haskell have a stack, it is very different from the stack as you may now it in C, so the optimization issues are different too. The assembly of functional calls in functional languages can be a lot more lightweight then in for example C.

jarin• 15 years ago

"And one reason many people consider Java “better than Ruby” is because you cannot open base classes like String in Java?"

Do people really say this? The ability to monkeypatch classes is one of Ruby's many strengths. It would only add unnecessary complexity if there were any "special case" classes. I guess it's somewhat helped by the fact that people generally modify base classes responsibly.

Rspec is one example of how this is used to great effect:

  my_object_of_any_kind.should == "pretty awesome"

  MyModel.should_receive(:find).with(id).and_return(@mock_model_instance)

regularfry• 15 years ago

People do argue that by allowing monkey-patching, you guarantee that groups of developers will step on each others' toes. Refinements in 2.0 (http://ruby.about.com/od/advancedruby/a/Refinements-The-End-...) are an answer to that.

Why Why Functional Programming Matters Matters

Related Stories