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

OOP Isn't a Fundamental Particle of Computing

prog21.dadgum.com

Post reply on HN
Print view View original

81–90 of 163 posts

Re: OOP Isn't a Fundamental Particle of Computing

#81

Post by eternalban »

michaelochurch wrote: post #80
eternalban wrote: post #79

Earlier quoted context omitted.

> ... functional programming has two design patterns: Noun and Verb... You have a fundamental misunderstanding about pattern languages. It would be correct to say "functional programming is a pattern (language)" and this pattern (language) has the "elements Noun and Verb". p.s.: http://patternsinfp.wordpress.com/

Pattern languages are new to me but I'd guess that I know more about programming languages in practice than 97% of programmers, and 100.0% of the people (by definition) who think VisitorSingletonFactory classes are a good idea. So if I'm getting fundamentals wrong in that part of the discussion, and I could well be, then I think there are precious few people getting this stuff right.

Your competence as a programmer was not questioned, Michael, and was not even remotely a consideration. Have a beautiful day!

Re: OOP Isn't a Fundamental Particle of Computing

#82

Post by michaelochurch »

eternalban wrote: post #81
michaelochurch wrote: post #80

Earlier quoted context omitted.

Pattern languages are new to me but I'd guess that I know more about programming languages in practice than 97% of programmers, and 100.0% of the people (by definition) who think VisitorSingletonFactory classes are a good idea. So if I'm getting fundamentals wrong in that part of the discussion, and I could well be, then I think there are precious few people getting this stuff right.

Your competence as a programmer was not questioned, Michael, and was not even remotely a consideration. Have a beautiful day!

Sorry if I seemed aggressive and snarky. OOP gets my blood boiling. The disgraceful state of most software architecture is a hot topic for me, having seen a couple of companies fail on account of code quality issues.

Re: OOP Isn't a Fundamental Particle of Computing

#83

Post by Jare »

mercurial wrote: post #75

Given the amount of comments on this article, I feel like I'm the only one who missed the point the author is trying to make. TFA goes from praising the existence and ease of use of data types, particularly collections, in high-level languages such as Python (an object-oriented language) and constrasts it to C and Pascal (neither of which are object-oriented) and then seems to extoll the virtues of relying on basic d…

OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical way to architect every piece of your solution. That's all.

The underlying reason is that data types must address (in some way) a number of requirements: copyability, management of owned resources, conversions, limits, etc. You need to take care of all that for every single custom data type you create, or your code will be a minefield of half-baked data types. This large base cost for data types in turn makes the classic 'divide and conquer' strategy for software development more costly, which triggers further practical problems with overgrown and over-engineered types.

Re: OOP Isn't a Fundamental Particle of Computing

#84

Post by fholm »

waxjar wrote: post #77
fholm wrote: post #55

Earlier quoted context omitted.

You mean like this? :) type Color = RGB of int * int * int | HSV of int * int * int | CMYK of int * int * int * int let toHsv = function | HSV(h, s, v) -> HSV(h, s, v) | RGB(r, g, b) -> ... | CMYK(c, m, y, k) -> ...

That's very elegant. I don't recognise the language from the syntax. From what I understand it makes a new type called Color and defines a function that can do something with that type. Is that much different from making a class called Color and defining some methods for that class? I don't see how one is better than the other. An OO example would perhaps be slightly more verbose, but accomplishes the same result.

The language is F#, basically the code does this:

1) Creates a type which is a discriminated union called Color, that can have three different values (RGB, HSV or CMYK).

2) Defines a function which converts a color of any value (RGB, HSV or CMYK) to HSV.

The argument, although implicit, from me was that even though this can be easily represented using OO, this approach is far cleaner and easier to read (once you know the syntax and concepts obviously - but that can be said for any language), and that the poster above me saying that the benefits of a "good abstraction" becomes apparent implying that this good abstraction can only be supplied by OO, which is not true.

The OO representation would either be one class called Color which always stores it values in one format (say RGB), and then have get/set:ers for manipulating it as CMYK, RGB or HSV. The other way would be an abstract base class called Color which subclasses ColorRGB, ColorHSV, ColorCMYK, etc.

Re: OOP Isn't a Fundamental Particle of Computing

#85

Post by stonemetal »

michaelochurch wrote: post #74

One of the reasons discussions of OOP leave me feeling dissatisfied is that OOP has a "blind men and the elephant" problem. One feels the tail and says, "this Creature implements Rope". Another feels a leg and says, "this Creature implements Tree". A third feels the side and says, "this Creature implements Wall". We end up discussing dramatically different things. My big issue with OOP is that it injects unnecessary…

I usually put it like this. Instead of having 23 poorly-understood and often badly implemented design patterns, functional programming has two design patterns: Noun and Verb. Nouns are immutable data: from integers to record types to OCaml's unions to Scala's tree-based Map and Set. (Occasionally Nouns have to be mutable, which means they have attached Verbs. I'm glossing over that for now.)

Then I would have to ask how is that different than OO other than the straw man at the beginning. It has Nouns and Verbs, sure data is default mutable instead of immutable but immutable is certainly an option. OO typically calls their verbs methods instead of functions but referential transparency is a good thing on the OO side of the fence too. We tend to call map for_each, etc.

Frankly I am beginning to realize that FP vs OO is the biggest bike shed I have ever seen in the real world.

Re: OOP Isn't a Fundamental Particle of Computing

#86

Post by pjmlp »

klibertp wrote: post #67
pjmlp wrote: post #62

Earlier quoted context omitted.

Because the people that rant against OO make the faux pas of using OO languages as argument.

Python: "Paradigm(s): multi-paradigm: object-oriented, imperative, functional, procedural, reflective" JavaScript: "Paradigm(s): Multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional" Ruby: "Paradigm(s): multi-paradigm: object-oriented, imperative, reflective, functional" From Wikipedia. So, where the faux pas is?

All data types in those languages are objects.

Re: OOP Isn't a Fundamental Particle of Computing

#87

Post by delinka »

Well, if you want "fundamental particles of computing," have some machine code. Assembly is a bit more tolerable, but directly correlates to machine code, so sure, use that. The thing is, the CPU is "imperative" - it's a machine whose state changes according to instructions provided to it. Everything else is abstraction. Abstraction attempts to reduce the amount of stuff the programmer needs to think about all at once (i.e. 'complexity.') A nice procedural language lets you more easily reuse code by referring to procedures which, in turn, are executed sequentially. OOP lets you group functionality with conceptual objects. Every bit of code you write is executed sequentially by a CPU core. So what abstraction works best for you?

In some cases, it's not about what works well for the programmer. I'm currently an OS X and iOS developer and I see problems in the Cocoa APIs with an overabundance of OOP. The simplest of iOS apps gets a view, a view controller, an app delegate (which often gets used as an app controller), etc ad nauseum. Now, I come along and look at the code and just want to know how the thing does what it does, but the functionality is spread across dozens of classes and to follow along I actually have to run the app to see that the entry point to the functionality is really -touchesBegan on some deep class... it's obnoxious. What's worse is the design of Cocoa and CoreFoundation lead to many app designs that have magical entry points unless you have more deep knowledge than you ever thought you might. I get that this is an attempt by Apple at keeping the developer more productive by writing less code, but I don't think that idea is being implemented as well as it could be.

Re: OOP Isn't a Fundamental Particle of Computing

#88

Post by colanderman »

I thought he was going to talk about how OOP can be broken down into several simpler orthogonal concepts, namely:

1) Code reuse (e.g. inheritance)

2) Implementation hiding (e.g. methods)

3) Subtyping (e.g. interfaces)

4) Code composition / programming in the large (e.g. classes)

5) Run-time dynamic dispatch (e.g. instances)

Functional languages such as Haskell, Mercury, OCaml, and Scheme do a good job of teasing these apart:

1) Code reuse doesn't need anything fancy. You can do this with function calls even in C.

2) You can hide implementations using opaque types + accessor functions. OCaml has some pretty neat typing constructs that allow partial type hiding as well. You can even do this in C with incomplete types.

3) Subtyping is provided at the module level by OCaml's module interfaces, at the opaque type level by Haskell and Mercury's type classes, and at the transparent type level by OCaml's polymorphic variants and functional objects.

4) Code composition / programming in the large is provided by OCaml's module functor system or Scheme's unit system. You can even do this in C at the linker level.

5) Run-time dynamic dispatch is a feature that's rarely actually needed in practice. (Compile-time dynamic dispatch is usually sufficient; that's provided by Haskell's type classes or OCaml's module functors.) Nonetheless OCaml provides RTTD -- with multiple dispatch -- through functional objects, Mercury provides the same through a combination of type classes + existential types. (I think you can even use existential module types in the latest OCaml.)

Re: OOP Isn't a Fundamental Particle of Computing

#89

Post by mercurial »

Jare wrote: post #83
mercurial wrote: post #75

Given the amount of comments on this article, I feel like I'm the only one who missed the point the author is trying to make. TFA goes from praising the existence and ease of use of data types, particularly collections, in high-level languages such as Python (an object-oriented language) and constrasts it to C and Pascal (neither of which are object-oriented) and then seems to extoll the virtues of relying on basic d…

OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical way to architect every piece of your solution. That's all. The underlying reason is that data types must address (in some way) a number of requirements: copyability, management of owned resources, conversions, limits, etc. You need to take care of all that for…

> OOP philosophy is to turn concepts from your problem space into custom data types.

I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their own. In languages supporting even basic pattern matching, I use tuples whenever I need to return more than one value for a function, and I'm not interested in reusing together elsewhere.

But this does not scale to complex program and complex data types. And your custom data structures will need to support a number of operations (eg, comparison, etc...). I don't really see what this has to do with OOP per se.

Re: OOP Isn't a Fundamental Particle of Computing

#90

Post by Robin_Message »

stonemetal wrote: post #85
michaelochurch wrote: post #74

One of the reasons discussions of OOP leave me feeling dissatisfied is that OOP has a "blind men and the elephant" problem. One feels the tail and says, "this Creature implements Rope". Another feels a leg and says, "this Creature implements Tree". A third feels the side and says, "this Creature implements Wall". We end up discussing dramatically different things. My big issue with OOP is that it injects unnecessary…

I usually put it like this. Instead of having 23 poorly-understood and often badly implemented design patterns, functional programming has two design patterns: Noun and Verb. Nouns are immutable data: from integers to record types to OCaml's unions to Scala's tree-based Map and Set. (Occasionally Nouns have to be mutable, which means they have attached Verbs. I'm glossing over that for now.) Then I would have to ask…

http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

The real differences are in solving the expression problem (verbs are easy to add in FP, nouns are easy to add in OO), and as you say, OO's default of mutability vs FP's aim at referential transparency.

Post reply on HN