Hacker News Reader

Comment by lightblade | Hacker News Reader

I think OO and FP can coexist peacefully. You just need to pick out their good parts and discard the rest, and use a programming language that allows this.

Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist.

Separate behaviors out into its own module. I'd avoid calling them classes here because there will be confusion. Interactions between objects can be implemented in FP style. This is where you get to use map and reduce.

I've been learning about DCI (data context interaction) recently. I can't say I've fully grasped it yet, but it did opened my mind on how to do design differently.

View on HN

So just use objects for type-checking? Isn't that just FP with types?

OO itself is just syntactical sugar for standard C structs with functions taking them as args. Substitute in "self" for an additional first argument and you've got FP with types and structs.

The definition of OOP rather depends on who you ask, but I suspect Alan Kay would disagree with you there :)

Take a look at some OOP C code sometime. Oh, C doesn't have objects? Sorry, I meant a my_struct{} and a bunch of my_struct_op(struct, otherargs) functions.

You seem to be pretty emotionally invested in FP vs any other programming paradigm. I'm more of a "lots of tools in the box" kind of guy.

Bundling a set of methods to a struct in C is not full OO. It lacks inheritance/delegation, encapsulation, polymorphism, and message passing, and I don't know of any definition of OO that doesn't insist on at least one of those.

Alan Kay's summary is interesting: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

I just meant that people have very different ideas about what OOP means. You seem to have an unusually broad definition, but others, particularly the guy who coined the phrase in the first place, have more specific definitions. In general, most people agree that OOP involves some form of information hiding, which you seem to disagree on.

I also wouldn't say I'm particularly emotionally invested in FP, just that I'm very skeptical of OOP as a paradigm. OOP languages tend to promote hidden, mutable state, but visible, immutable values are far more useful.

Fair enough.. if you're talking about a giant class hierarchy with lots of mutable state, then I tend to agree that it doesn't usually lead to good software (although things like java's collections library and the outputstream hierarchy are good exceptions).

Do put your object in classes, but don't put behaviors there. Use classes to allow static type checking so that functions taking them can guarantee certain field exist.

Why not just use algebraic data types and modules? Classes are such a verbose, jumbled, complected mess compared to those simpler tools.

> ...algebraic data types and modules

Sorry, I not familiar with that term. Can you explain that more?

I would, but I'm afraid my explanation would pale in comparison to the one on Wikipedia. Why not check it out?:

http://en.wikipedia.org/wiki/Algebraic_data_type

OO and FP coexist peacefully. FP is all about passing functions as parameters into other functions.

Its exists on decent languages. Which in case allow OO also.

ie. perl, allows all that, and has Moose which allows Class and Roles and Types. So you can build classes like lego, literally.

> FP is all about passing functions as parameters into other functions.

That's a common misconception. First-class functions and higher-order functions are definitely commonly used in functional programming, but they are not what makes it functional programming. As with any paradigm, there is no universally agreed-upon definition, but most functional programmers will likely agree that lack of mutable state and lack of side effects are much more central to functional programming than first-class and higher-order functions. The latter are really just useful and elegant tools to help accomplish the former.

Without side effects you couldn't do anything. Pure functional languages make side effects explicit, but it isn't about them being missing.

> Without side effects you couldn't do anything.

Not true.

> Pure functional languages make side effects explicit, but it isn't about them being missing.

True. I should have been more clear about that.

Not a downvoter, but I believe "Without side effects you couldn't do anything" means that any interesting program ultimately has a side effect. The rocket is launched, the form is printed, pi is displayed on the monitor, etc.

Isn't that an effect, not neccesarily a side effect?

"Function with side effect" is a term of art in functional programming. It's a function which (like all other functions) takes in arguments and puts out arguments (that's the "effect", if you like). But also, with a "side effect" -- the simplest example being, display something on the monitor.

I.e.,

  (display "hello world")

returns whatever it returns (we throw it away), but also puts that string on the monitor. The latter action is not just computing a function (in the sense of FP) of the inputs.

For more, see http://www.eecs.berkeley.edu/~bh/ssch20/io.html (search for "side effect").

Yes true. Running a program with no side effects is a no-op. All side effect free programs are identical, and do nothing. This is one of the most common misconceptions people afraid to learn haskell bring up, because people keep saying "functional programming is having no side effects".

It's funny: "not having side effects" was the main reason for me to start learning Haskell just because that idea didn't make much sense hah

So you're saying that a library that has no side effects but performs a complicated data transformation "doesn't do anything"?

A library is not a program.

Your claim was "Without side effects you couldn't do anything." I was rebutting that claim. Again, unless you want to claim that libraries "don't do anything."

The more specific claim that you need side effects for a program to do anything is also false. You can prove mathematical theorems with programs that have no side effects. Of course now you'll say that that only works because of the compiler, which does have side effects, but that's really just moving the target so you can be "right" (as you did with this post).

Even if theorem proving isn't good enough, since the entire purpose for having the term "side effects" is to be able to usefully discuss referential transparency, the other poster who noted that IO can be an effect and not necessarily a side effect was correct. If IO is isolated, it is not a side effect, it is just an effect. A good example of this is the execution of the main action in a Haskell program.

You are not rebutting that claim, you are being obtuse.

>You can prove mathematical theorems with programs that have no side effects

No, of course you can not. How do you see the result? That requires a side effect of some kind.

>A good example of this is the execution of the main action in a Haskell program.

That is a terrible example, as executing main precisely is a side effect.

> No, of course you can not. How do you see the result? That requires a side effect of some kind.

The result is whether or not the program type-checks.

Your original claim was, again, that "without side effects you can't do anything". So, again, unless you are claiming that functions and libraries "don't do anything", your original claim was incorrect. Your new claim, that programs must have side effects to do anything, is still wrong but more debatable.

You can call me obtuse if you want to, or you can learn how to communicate clearly and say what you actually mean. Doesn't much matter to me either way.

>The result is whether or not the program type-checks.

Ok, you are very confused. Type checking has nothing to do with program execution. Type checking is done at compile time. Any program with no side effects, the compile can safely optimize into nothing, since it does nothing. The compiler does the type checking, not the program.

>Your new claim, that programs must have side effects to do anything, is still wrong but more debatable.

It is the claim I made and you replied to. If you want to be pedantic and obtuse you can't expect people to not call you out on it.

Seriously? I'm directly quoting you in a post that is still visible, and you're denying it? Again, the quote that I originally replied to: "Without side effects you couldn't do anything."

> Ok, you are very confused.

You are both very arrogant and wrong. Not a pretty combination. Thank you oh so much for telling me that type checking is done at compile time, as though there were the slightest possibility I didn't know that given what I've been saying.

If you took some time to learn how to have a conversation on the internet without being an asshole, you might actually learn something. Until then, I'll stop wasting my time trying to have a discussion with you. Cheers.

I would argue that FP is also about avoiding mutable state.

Reply on news.ycombinator.com