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

Goodbye, Object Oriented Programming

medium.com

Post reply on HN
Print view View original

231–240 of 355 posts

Re: Goodbye, Object Oriented Programming

#231

Post by eru »

lispm wrote: post #117
eutectic wrote: post #108

Earlier quoted context omitted.

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…

The majority of software written ever has been written in the world's most popular functional programming language: Excel.

Re: Goodbye, Object Oriented Programming

#232

Post by EugeneOZ »

ebbv wrote: post #26
millstone wrote: post #21

Let me try to list the objections: 1. Inheritance creates dependencies on their parent class 2. Multiple inheritance is hard 3. Inheritance makes you vulnerable to changes in self-use 4. Hierarchies are awkward for expressing certain relationships All true. But likewise, functions introduce dependencies on their arguments, and data structures introduces dependencies on their fields. You must consider your dependencie…

That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right way and you don't like the right way?" His entire problem seems to be he thought OO was a magic bullet he could do whatever he wanted with and then he learned there was more to using OO than the three concepts he cites at the beginning. And this guy has suppo…

Actually "right way" is described in article, so don't worry about his knowledge.

I think point of this article is OOP have so many limitations for safe usage, that makes usage of FP more comfortable.

Re: Goodbye, Object Oriented Programming

#233

Post by eru »

pdimitar wrote: post #146
lispm wrote: post #117

Earlier quoted context omitted.

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…

I would argue this is inertia and a hype train that never slowed down -- up until the last 2 or so years that is. I do agree with you that thinking in FP takes a bit more experience however.

Actually, from what I've seen, pure FP forces people with less experience into design and structures of their code that they'd only do in imperative settings with considerably more experience.

Eg when I asks students to do some simple exercise like "write a function that finds the shortest path through a given graph", in impure languages their solutions tend to return a path if they find one, but just give up with eg a message printed to screen when there's no path.

In pure and types languages, I see more people reaching for a Maybe or Either return type to express that the function as asked for might not succeed.

Re: Goodbye, Object Oriented Programming

#234

Post by eru »

jonnybgood wrote: post #224
iainmerrick wrote: post #222

Earlier quoted context omitted.

No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.

How is that related to easily proving theorems about the code?

It's easier to prove stuff about simpler code.

Re: Goodbye, Object Oriented Programming

#235

Post by eru »

seanmcdirmid wrote: post #155
eutectic wrote: post #108

Earlier quoted context omitted.

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is…

As a weaker form of going around and proving stuff: people do care a lot about properties. We just check them via QuickCheck, instead of formally proving them.

And we organize our programs such as to get nice properties.

Re: Goodbye, Object Oriented Programming

#236

Post by eru »

tmptmp wrote: post #210
eutectic wrote: post #108

Earlier quoted context omitted.

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…

>>Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. How much of the Haskell (a pure FP language) library code is formally proved? Just curious. Also I wonder, if code like xmonad can be proved at all.

XMonad comes with quite a few QuickCheck properties. See https://donsbot.wordpress.com/2007/05/17/roll-your-own-windo... and https://donsbot.wordpress.com/2007/05/01/roll-your-own-windo... for some readable introduction.

One might consider proving the properties instead of just checking them with a few thousand random examples.

Re: Goodbye, Object Oriented Programming

#237

Post by iainmerrick »

seanmcdirmid wrote: post #229
iainmerrick wrote: post #225

Earlier quoted context omitted.

The "proving theorems" stuff is definitely overstated. People always toss that term around, and it's true in principle, but in practice hardly anyone ever uses correctness proofs in real world code. But to flip it around and make a less grandiose version of the same point: the majority of bugs are to do with state. (I don't actually know if that has been "proved" but it's definitely what I find in practice!) Pure FP…

I agree with this mostly. You can get rid of state in OO programs, and that often involves a bit of functional programming. Struct/values in C# help a lot in keeping the performance up (well, if GC is a problem, you can also inline your closures to prevent boxing...lots of crazy things like that). Essential (rather than accidental) state is impossible to eliminate in any case.

Yes, I think just trying to use an FP style where possible is a great approach.

Re: Goodbye, Object Oriented Programming

#238

Post by eru »

Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

It took people quite a while to figure out how to compile functional code (especially lazy functional code) to commodity hardware. The research only caught up in the 80s.

Re: Goodbye, Object Oriented Programming

#240

Post by eru »

MarkMc wrote: post #187

I love using object oriented design and find it quite odd when I meet seasoned programmers who still don't 'get it'. It feels a bit like meeting someone who says Obama was born in Kenya. Here's a concrete example of object oriented design: To understand the problem domain, go to https://whiteboardfox.com and click Start Drawing > Create Whiteboard, then draw something. Play around with different colours, erase some l…

> I honestly don't see how you could implement it without object oriented design. Surely it makes sense to have a Diagram class that encapsulates a list of strokes and pictures? Isn't it easier if the Diagram class exposes addStroke() and removeStroke() but does not reveal how it's implemented? And shouldn't I have a separate view class which encapsulates how much zoom and pan the user has applied to the diagram?

Data structures and operations on them are indeed a useful concept. Not limited to oop, though.

> Could you implement Undo and Redo actions so neatly without a command pattern?

Persistent data structures make it even easier. You just keep a list of references to the old states around.

> I actually get a little thrill when I think about how cleanly this design addresses the requirements. Could I get that feeling if this were implemented in a functional programming style?

I can't predict your feelings, but what you described could very well be done in eg Haskell. (You just wouldn't use oop classes, but you can abstract over similar concepts.)

Have a look at http://shaffner.us/cs/papers/tarpit.pdf for some thoughts on software design. (The paper advocates using relations. I have seen them work very, very well in functional settings. Just the opposite of ORMs.)

Post reply on HN