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

71–80 of 81 posts

Re: A Conversation About OOP vs. FP Turns Constructive

#71

Post by dllthomas »

knucklesandwich wrote: post #43
jblow wrote: post #3

Earlier quoted context omitted.

Haskell has been around for over 20 years. If it hasn't set the programming world on fire yet, there are probably reasons.

Haskell definitely has problems. I'm a huge fan of the language, but I think its disingenuous to pretend like its flawless. To name a few: 1. Poor debugging tools. Unfortunately this is sort of intrinsically tied with non-strict evaluation. Typical evaluation stepping debuggers would be sort of unpredictable in haskell. Along these lines, haskell doesn't have stack traces enabled by default, and reading them is sort…

The bits about exceptions and IO isn't quite right.

So far as I'm aware, there is no technical difference between exceptions thrown in IO versus exceptions thrown in pure code. There are two contextual differences.

First, exceptions can only be caught in IO, but everything running has IO above it somewhere, or it wouldn't be running in the first place.

Regarding exceptions thrown in IO versus elsewhere, it's worth noting that exceptions thrown anywhere are only actually thrown if the thunk representing them is forced. IO values tend to be used quite close to where they are created, whereas an exception in lazy, pure code might hide in the creation of the leaf of a tree or at the end of a list.

Re: A Conversation About OOP vs. FP Turns Constructive

#72

Post by dllthomas »

cm3 wrote: post #13
NegativeK wrote: post #8

Earlier quoted context omitted.

Haskell might be bad, but its unofficial slogan is "Avoid success at all costs" -- so I don't think lack of fire necessary implies it's shitty (which is I think what you were implying.)

Actually, Simon PJ clarified that it's "avoid success-at-all-costs" and not "avoid success at-all-costs".

I've always interpreted it (and I'm not sure Simon would disagree) as a serious "avoid success-at-all-costs" and a tongue-in-cheek "avoid success at-all-costs".

Re: A Conversation About OOP vs. FP Turns Constructive

#73

Post by svanderbleek »

delish wrote: post #68
svanderbleek wrote: post #61

Earlier quoted context omitted.

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 sam…

I was just trying to tease out what you need to know so that Idris fits in half a page. I'd actually like to know those things!

Re: A Conversation About OOP vs. FP Turns Constructive

#74

Post by wangchow »

sbov wrote: post #67
wangchow wrote: post #38

Earlier quoted context omitted.

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 th…

Not stereotyping the best developers but saying that one who keeps an open mind to new ideas will be a better at what they do. Now, obviously there are limits to what people can do but more exposure is generally better.

C is all well and good (anything can be implemented in C) but one must recognize that higher level languages serve one purpose: to help express certain ideas in a more concise and easier-to-understand way than a lower-level language. It can be very helpful to look at why a particular functional language (just for example) achieves a result, and then implement the same concept in C or even assembly if necessary. But by abstracting the problem into a more simpler one, more complex ideas can be express.

Just look at integrals and derivatives in Math. One could compute derivatives using the difference-quotient but that would make more complex ideas almost impossible to understand. We create rules to help us derive common patterns, then use those to build more powerful ideas in a simpler way.

Re: A Conversation About OOP vs. FP Turns Constructive

#75

Post by johncolanduoni »

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

I'm referring to the operational semantics[1]. This doesn't require any tacit knowledge to fix the language past what the horizontal line and definitional equality symbols mean (it's entirely in the form of purely syntactic "given this, you can write this"), but it won't be remotely helpful to teach you what the syntax reductions mean or how to use them. If you're never heard of lambdas, you could technically still "use" them in the sense a computer can, but good luck figuring out that they represent functions. It wouldn't fit any sensible definition of "understanding".

My point isn't that these things are easy to learn because their presentations are so brief; personally, dependent typing took me a long time for me to wrap my head around. What I think the briefness of the operational semantics in combination with the examples of things people have built within them suggest is that they're very versatile. Even if only people working on language level features bother to learn them, the utility of their creations (all without needing to move to another language or introduce possibly incompatible extensions) is a huge asset.

[1]: https://en.wikipedia.org/wiki/Operational_semantics

Re: A Conversation About OOP vs. FP Turns Constructive

#76

Post by ArkyBeagle »

wangchow wrote: post #7

At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. This is why you see languages like C++, Java, and C# adding support for them all. It is useful to express a particular problem domain in a way that is efficient and makes sense. I would be more interested in a discussion about concurrency because it becomes more relevant acros…

The path to concurrency is paved with a mix of finite state machines and event-driven programs. IMO, neither FP nor OO have all that much to say about that.

FSM/event driven is pretty easy even in rickety old languages like 'C'. C++ is a bit nicer because there is dispatch demuxing built in. I suppose the same is true of Java.

I guess webby stuff doesn't lead to the appeal of FSM but for everything else, it's generally a better path. FPGA guys use a lot of FSM and they simply don't have the same defect rates as software guys.

I've used toolsets like ObjecTime/Rose where "everything is a state machine" and It Just Works. I'm not sure why this approach is still obscure - the various works in Verification ( with a capital V ) seem to point to FSM as a means of reducing complexity.

Re: A Conversation About OOP vs. FP Turns Constructive

#77

Post by ArkyBeagle »

wangchow wrote: post #74
sbov wrote: post #67

Earlier quoted context omitted.

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 th…

Not stereotyping the best developers but saying that one who keeps an open mind to new ideas will be a better at what they do. Now, obviously there are limits to what people can do but more exposure is generally better. C is all well and good (anything can be implemented in C) but one must recognize that higher level languages serve one purpose: to help express certain ideas in a more concise and easier-to-understand…

You don't (usually) solve a problem directly in 'C' - you build furniture in 'C' that you arrange to then solve the problem.

Using a "higher level" toolset just means (possibly) buying rather than building. Which is "better" is an economic decision, until people's self-identity starts to get in the way.

I just remember a J2EE class, where every day we'd spend thirty minutes updating all the bizarre tools, which would frequently break things. I'm insufficiently venal to put up with that.

Re: A Conversation About OOP vs. FP Turns Constructive

#78

Post by knucklesandwich »

dllthomas wrote: post #71
knucklesandwich wrote: post #43

Earlier quoted context omitted.

Haskell definitely has problems. I'm a huge fan of the language, but I think its disingenuous to pretend like its flawless. To name a few: 1. Poor debugging tools. Unfortunately this is sort of intrinsically tied with non-strict evaluation. Typical evaluation stepping debuggers would be sort of unpredictable in haskell. Along these lines, haskell doesn't have stack traces enabled by default, and reading them is sort…

The bits about exceptions and IO isn't quite right. So far as I'm aware, there is no technical difference between exceptions thrown in IO versus exceptions thrown in pure code. There are two contextual differences. First, exceptions can only be caught in IO, but everything running has IO above it somewhere, or it wouldn't be running in the first place. Regarding exceptions thrown in IO versus elsewhere, it's worth no…

Yeah, just reread how I worded this and it's not quite correct. Your points here about how all synchronous exceptions are handled the same is correct. I think what I was trying to get at was that exceptions in pure code are usually treated like fatal errors.

The biggest challenge is definitely how easily exceptions can slip by handling code unless you make strict use of throwIO with synchronous exceptions (or something equivalent like throwM from exceptions). My favorite example is the following:

let foo = try . return $ error "foo".

Which evaluates to "Right * Exception: foo".

Re: A Conversation About OOP vs. FP Turns Constructive

#79

Post by runT1ME »

jblow wrote: post #3
nitrix wrote: post #2

A few incorrect points during the discussion as well as poorly approached. The only thing beneficial that I see from it is people trying to better their skills and Haskell gaining traction. I personally would recommend #haskell-beginners on freenode IRC as well as http://haskellbook.com for the ones interested. For everybody else, well I'm not a sale person and my job isn't to convince you. If it takes you 30 years t…

Haskell has been around for over 20 years. If it hasn't set the programming world on fire yet, there are probably reasons.

How long has ML been around and how long did it take for it to become 'mainstream' enough to be used by big teams at Facebook and Jane Street?

Re: A Conversation About OOP vs. FP Turns Constructive

#80

Post by edem »

rjbwork wrote: post #46

Most statically typed programs/systems these days (Java, C#, even C++ if you wish) these days, use DI via IoC containers as the mechanism for constructing objects and choosing which code to run. You can even do it with dynamic languages like JS/Python if you wish, though many argue it being dynamic means you don't need to use a container - which is pretty true. This approach is equivalent to a family of functions (wi…

This is how I also work. You can use rudimentary languages like java to do FP if you have the proper mindset.
Post reply on HN