Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Conversation About OOP vs. FP Turns Constructive

github.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: A Conversation About OOP vs. FP Turns Constructive

#61

Post by svanderbleek »

johncolanduoni wrote: post #50

I think the OOP vs FP debate misses the real asset that functional programming offers us, and it's not writing everything in [your favorite functional language]'s typical style. Look at a language like Idris; a formal definition of its unsugared semantics would fit on half a page easily. However it still manages to give us all kinds of goodies, like effect tracking, compile-time checking for virtually any condition y…

I like your points, but I'm not sure of the Idris on half a page. How much tacit knowledge does that rely on? We do need to focus on the fundamentals of education, the spectrum of logics with quantifiers, lambda calculus, and natural deduction style presentations of language semantics (not sure what to actually call this?).

Re: A Conversation About OOP vs. FP Turns Constructive

#62

Post by ebbv »

svanderbleek wrote: post #56
ebbv wrote: post #4

This conversation is awful. This seems like a bunch of armchair developers with really strong opinions and no real world experience. No experienced developer I want to work with has the kind of dogmatic views that most of the people in this chat log have. FP and OOP are both just tools, how you use them is way more important than which tool you choose.

I would love some constructive feedback on how to do better, thanks.

Off the top of my head:

Drop the dogma. Stuff like "OOP is terrible" or "FP is terrible" or "JavaScript is terrible", etc. are not only wrong but they are destructive only to you. Nobody else cares that you hold this view, it just keeps you ignorant about that thing and holds back your skill set and career. If you take the time to actually learn how to use the thing in question properly, what the good parts of it are and how good things not only can be made with it but are being made with it you will be better for it. Even if at the end of that you still decide you don't want to use it yourself (which is totally valid, we all have our preferences) you will be better off. You will be take the view not that "X is terrible" but that "X is not my preferred way of doing Y."

Second, don't waste your time bullshitting with a bunch of people who don't know anything about anything and just want to be "right" all the time. Where "right" here is actually "agree with the trendy position", which right now is "FP is good, OOP is bad." Talk to professional developers who actually do the work you want to do, and learn from them what it is they do and how they do it. To be sure, some people who hold those silly views do work as developers, but I would argue they're not professional. A professional sees tools as tools and not as a substitute for a personality.

Bullshitting is a great thing to do to blow off steam, we can't code 24x7, but there's constructive chat and then there's a useless echo chamber full of nonsense (which IRC is really good at forming.)

Anyway, hope that helps. I used to talk like the stuff I see in this chat when I was younger, then I realized what I just said about those opinions only being harmful to myself and now I try to be more open minded.

Re: A Conversation About OOP vs. FP Turns Constructive

#63

Post by [deleted] »

wangchow wrote: post #38
TheRealPomax wrote: post #27

Earlier quoted context omitted.

That has never been a problem in a large part of the programming job market. If your skill set fills the job opening a big coorporation or institution has, and that job sets you up for life (instead of the frantic contract based work for startups or small companies) then exploration is a luxury, but in no way a necessity. Note that logic applies here: I'm questioning the "you should know" claim, not claiming "you sho…

Well, this is true if all one is interested in is getting a job today . However, the best developers aren't primarily concerned about getting a job or not, they are genuinely interested in programming as both an art and a science. Money and jobs is secondary (and readily available because such individuals are more skilled than those that limit their pursuits).

[deleted]

Re: A Conversation About OOP vs. FP Turns Constructive

#64

Post by svanderbleek »

ebbv wrote: post #62
svanderbleek wrote: post #56

Earlier quoted context omitted.

I would love some constructive feedback on how to do better, thanks.

Off the top of my head: Drop the dogma. Stuff like "OOP is terrible" or "FP is terrible" or "JavaScript is terrible", etc. are not only wrong but they are destructive only to you. Nobody else cares that you hold this view, it just keeps you ignorant about that thing and holds back your skill set and career. If you take the time to actually learn how to use the thing in question properly, what the good parts of it are…

Thanks. I was trying to show it started off unproductive and went into a constructive chat about Haskell type and value level functions, but this was also a lazy test of if people are interested in the conversational format. I think the result is maybe? I want to make a socratic dialogue style presentation of some ideas in FP, I don't have much interest in saying OOP is terrible, because I don't have much interest in talking about OOP.

Re: A Conversation About OOP vs. FP Turns Constructive

#65

Post by runT1ME »

ryandvm wrote: post #52
runT1ME wrote: post #51

Earlier quoted context omitted.

Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?

Just my two cents, but regardless of whether it is a more pure representation, I'd say it is empirically more difficult for the average, object-oriented human to wrap their brain around. At least on that measure, the object oriented paradigm has demonstrated some success.

I don't see how. One gives you guarantees, one is a lie. I've done a lot of both, the OO model is strictly inferior in almost every way.

Re: A Conversation About OOP vs. FP Turns Constructive

#66

Post by runT1ME »

ryandvm wrote: post #52
runT1ME wrote: post #51

Earlier quoted context omitted.

Explain why FP doesn't do 'create a new type and overload operators to make it feel like the abstract mathematical idea it represents' better with say, parametric polymorphism?

Just my two cents, but regardless of whether it is a more pure representation, I'd say it is empirically more difficult for the average, object-oriented human to wrap their brain around. At least on that measure, the object oriented paradigm has demonstrated some success.

I don't see how. One gives you guarantees, one is a lie. I've done a lot of both, the OO model is strictly inferior in almost every way.

Re: A Conversation About OOP vs. FP Turns Constructive

#67

Post by sbov »

wangchow wrote: post #38
TheRealPomax wrote: post #27

Earlier quoted context omitted.

That has never been a problem in a large part of the programming job market. If your skill set fills the job opening a big coorporation or institution has, and that job sets you up for life (instead of the frantic contract based work for startups or small companies) then exploration is a luxury, but in no way a necessity. Note that logic applies here: I'm questioning the "you should know" claim, not claiming "you sho…

Well, this is true if all one is interested in is getting a job today . However, the best developers aren't primarily concerned about getting a job or not, they are genuinely interested in programming as both an art and a science. Money and jobs is secondary (and readily available because such individuals are more skilled than those that limit their pursuits).

Anyone who stereotypes the practices of the best developers is kidding themselves. Some of the best developers I know only know C.

In reality there are roughly two types of tech: staples and new ones. Staples are around for a long time, but HN tends to focus on new ones. The thing is, even our modern staples came from a much larger set of new pieces of tech.

What this means is, that if you're using a piece of tech that has been popular for at least 20 years, you're probably good for at least the next 20. If you keep switching to the new hotness, you will have to keep doing that because you are most likely learning stuff that won't stay around.

Re: A Conversation About OOP vs. FP Turns Constructive

#68

Post by delish »

svanderbleek wrote: post #61
johncolanduoni wrote: post #50

I think the OOP vs FP debate misses the real asset that functional programming offers us, and it's not writing everything in [your favorite functional language]'s typical style. Look at a language like Idris; a formal definition of its unsugared semantics would fit on half a page easily. However it still manages to give us all kinds of goodies, like effect tracking, compile-time checking for virtually any condition y…

I like your points, but I'm not sure of the Idris on half a page. How much tacit knowledge does that rely on? We do need to focus on the fundamentals of education, the spectrum of logics with quantifiers, lambda calculus, and natural deduction style presentations of language semantics (not sure what to actually call this?).

> How much tacit knowledge does that rely on?

It looks like you're criticizing the GP's praise of Idris' concise formal definition of its unsugared semantics. I wouldn't use such a formal definition for educating novices (like I think you're implying in your next sentence); I'd use it professionally to show that many desirable things--effect tracking, compile-time checking, and design-by-contract--derive from the same thing. Ken Iverson in his notes on mathematical notation says that one criterion for a good notation is "suggestibility"--the notation should suggest that other problems similar to those you found just now could be solved as well.

Whether formality is useful for novices, it is certainly useful for experts.

Re: A Conversation About OOP vs. FP Turns Constructive

#69

Post by bad_user »

mcphage wrote: post #44
fowlerpower wrote: post #6

I really believe the future is a mixed OOP and FP world. I think we will see industry use languages like Scala and F# more and more. In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. I also believe the crazy complexity of OO languages like Java is slowly being reigned in. With other languages like Go explicitly maki…

> I also believe the crazy complexity of OO languages like Java is slowly being reigned in. Java itself is a pretty simple language, and the complexity of programs written in Java is partially due to the spareness of the language.

Java didn't have generics either, until Java 5, when they've added an implementation with use-site variance with wilcards, for backwards compatibility reasons probably, but which is very user unfriendly. The irony is people complain about type erasure as being Java's problem, when in fact that has been one of its greatest features.

But anyway, the creators of Go where right to fear generics, b/c generics are hard. However the more time passes, the harder it is going to be to add. And truth is it's inevitable for generics to happen in Go and when they'll do they'll be half baked.

And remember that Java has striking similarities. Java is also a very opinionated and anti-intellectual language.

Re: A Conversation About OOP vs. FP Turns Constructive

#70

Post by seagreen »

frozenport wrote: post #53
seagreen wrote: post #36

Earlier quoted context omitted.

Come on frozenport, do you really think that applies to Standard Chartered, Jane Street, or FB?

While the motivation for their models might be complex or esoteric, calculating out the parameters might as well be done in Excel. Typically, the data flow is linear, and well suited for FP. But it ain't hard either. The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner, along with the user interaction that is found in desktop applications - or in my…

  the so-called "reliability" offered by FP is can be attributed
  to comparable simple tasks these developers work on

  The kind of complexity I'm referring to is the need to synchronize
  and coordinate concurrency in a time efficient manner[..]
There's more than one kind of complexity. Keeping 1.3 million SLOC of trading code relatively error free while allowing non-full-time programmers to contribute to it is also complex.
Post reply on HN