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

Programming without objects

falkoriemenschneider.de

Post reply on HN
Print view View original

91–100 of 133 posts

Re: Programming without objects

#91

Post by chton »

arethuza wrote: post #58
chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

"The big advantage of OO is that it acts as a distillation of how humans think." I first encountered functional programming in the 1980s on my Computer Science degree course a few years before I encountered OOP (CLOS and then C++) and I'm not convinced that OOP is fundamentally closer to "how humans think" than FP. Most programmers these days were taught an OOP language first so think that is most natural - but I don…

You should try explaining some business logic to a non-technical person some time. If you are able to properly model the problem domain, non-technical people have a much easier time understanding the flow of the code and how it works if it's written in an OO way. This is precisely because they recognize the concepts and ideas they are familiar with and can already reason about. They know that 'a Person pays their Bills by asking a Bank to deposit Money'. This means they can make sense of code that is structured in the same way. FP, for all its advantages and elegance, doesn't offer that same correspondence.

Re: Programming without objects

#92

Post by chton »

rockshassa wrote: post #30
dragonwriter wrote: post #13

Earlier quoted context omitted.

> The big advantage of OO is that it acts as a distillation of how humans think. Honestly, while I think OO programming in the broadest sense does that, I think class-oriented OOP (what the article mostly focusses on) languages, particularly statically-typed class-oriented languages in the C++/Java lineage--don't do a great job of either supporting that intuition or facilitating applying it intuition to the construct…

>don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs My first thought is that this is dependent on implementation. It is possible to write classes in a way that aligns with intuition, but it is sometimes hard to do that, and even if you're great at OOP it is hard to do consistently. I think the Smalltalk message-…

I'm exactly in your camp. I would love to see more functional influence in OO, and more careful thought about what to use at what time.

Re: Programming without objects

#93

Post by chton »

thunderbong wrote: post #55
chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

'skeumorphic' - did you mean 'anthropomorphic'?

I didn't. I meant 'skeuomorphic' as in 'designed with cues that correspond to reality, to indicate corresponding functions and behaviour'. It's a bit more nebulous when applied to real code, since we're thinking in terms of concept and behaviour, but the same thought applies.

Re: Programming without objects

#94

Post by tome »

mpweiher wrote: post #89
denibertovic wrote: post #82

Earlier quoted context omitted.

I've learned Haskell at university too. That doesn't prove anything though does it? At the time I've found it useless and plain wrong ... it is much later that I learned to appreciate it and value what it brings to the table...much much later.

We didn't have Haskell in 1989. As I wrote, there are things I value in FP languages in general, and more specifically Backus's FP calculus inspired me to come up with Higher Order Messaging[1]. It's nice to have language support for functional style (let, for example) where that is appropriate for the problem at hand, but you can write in that style without the language support easily enough. On the other hand, when…

> Many if not most problems ... don't really fit the functional style, and have to be made to fit

Some examples would be helpful here.

Re: Programming without objects

#95

Post by chriswarbo »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think.

Citation needed.

Browsing around Google Scholar for variations of "object oriented empirical comparison" shows a huge body of research comparing various OO approaches to each other, but very few comparing OO approaches to anything else. Those which I have been able to find compare OO to procedural code, and find either no significant difference in comprehension levels, or that procedural code is easier to understand (ie. closer to "how humans think") than OO:

An empirical study of novice program comprehension in the imperative and object-oriented styles

http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-...

Assessing the cognitive consequences of the object-oriented approach: A survey of empirical research on object-oriented design by individuals and teams

http://arxiv.org/pdf/cs.HC/0611154

An exploratory study of program comprehension strategies of procedural and object-oriented programmers

http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%2...

I've only been able to find one source comparing OO with functional programming, which didn't measure comprehension. Instead, it compared code quality metrics between C++ and Standard ML. Most showed no significant difference, except for SML taking longer to run its tests (it also had more tests), having higher code and library re-use and having a larger number of errors per 1000 lines (although the same number of known errors overall):

Comparing programming paradigms: an evaluation of functional and object-oriented programs

http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf

Re: Programming without objects

#96

Post by chriswarbo »

mpweiher wrote: post #54
nbevans wrote: post #27

Every OOP developer is on a journey, they just don't know it. Some of them will never make it. But some will reach a point of realisation where writing well-designed software comes naturally to them because they've inadvertently stumbled upon the core concepts of functional programming. It then requires them to realise that what they've found is just FP and then requires a further minor step to actually learn a more…

What arrogant hogwash. I was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust. That doesn't mean certain aspects can't be nice to h…

> was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust.

In other words, when you first tried a functional programming language you tried to write imperative code in it, and the result ended up bloated and fragile? I'm not surprised.

Guess what, trying to write pure FP in Java by chaining together static methods and "Function" objects would end up with bloated and fragile code too; but that's not a valid criticism of OO.

Re: Programming without objects

#97

Post by mpweiher »

chriswarbo wrote: post #96
mpweiher wrote: post #54

Earlier quoted context omitted.

What arrogant hogwash. I was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust. That doesn't mean certain aspects can't be nice to h…

> was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust. In other words, when you first tried a functional programming language you…

> when you first tried a functional programming language you tried to write imperative code in it,

Guess again. Did I mention the arrogance and the unwarranted assumptions?

Re: Programming without objects

#98

Post by pdkl95 »

colanderman wrote: post #18
millstone wrote: post #12

This article, like many that cheer functional programming, falls into a certain cognitive bias, that prevents it from seeing what OO is good at. Alan Kay wrote "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be." To start to see what this means, consider the annoying String / Data.Text split in Haskell. St…

I think you and the author have posed a false dichotomy. I avoid "traditional" OO in my own work for the some of the same reasons the author points out; not least of which that traditional classes are a kitchen sink. But many of the ideas of OO; notably extensionality (what the author incorrectly calls intensionality), I could never do without. I agree with you, that exposing the innards of my data structures is a cr…

I suspect some of the problems that many people have with OO tend originate from the C++ and relate languages such as Java. These languages aren't really OO in the Alan Kay sense of the term[1]. They are languages with classes, polymorphic inheritance, and object style binding of methods to structures, but they do not feature "everything is an object with message passing".

By comparison, you really see a lot more of the utility of OO in languages smalltalk or possibly ruby[2] where you can extend everything. I know tend to write my ruby (despite it being a multi-paradigm language) in a manner that you describe: FP style with objects hiding the details.

Of course, all of these languages have their strengths and weaknesses and OO isn't useful for everything. I just think OO has gotten a bit of a bad reputation from some of the languages that chose to label themselves OO even when their implementation was only superficial. This bad reputation may lead to dismissal of the whole idea, producing the false dichotomy you mention.

Incidentally, the lack of strict OO (or any language style) in ruby is what I really like about the language. You can be strict OO if you want, but you can also use classic (C-style) imperative programing when it makes more sense (or FP, or whatever).

[1] http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

[2] Regrettably, OCaml is one of those languages that is still in my "looks interesting, I should learn that" queue, so I cannot speak to how it implements OO.

Re: Programming without objects

#99

Post by pdkl95 »

chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

Steve Yegge's "Execution in the Kingdom of Nouns" has some interesting commentary on the idea of OO being in any way how humans think. The allegory has some harsh things to say about Java, which are not my intention in suggesting this link. The observations that objects tend to be nouns while functions tend to be verbs is very interesting.

/* footnote 3 is hilarious */

Re: Programming without objects

#100

Post by chton »

chriswarbo wrote: post #95
chton wrote: post #10

What this article seems to miss is part of the raison d'être of Object Oriented Programming. It's not just about how you encapsulate state and how you act on that state. Forget the exact way the type system works, or what extension methods are, or even what polymorphism is. The big advantage of OO is that it acts as a distillation of how humans think. We're accustomed to thinking in terms of 'things that do stuff'. W…

> The big advantage of OO is that it acts as a distillation of how humans think. Citation needed. Browsing around Google Scholar for variations of "object oriented empirical comparison" shows a huge body of research comparing various OO approaches to each other, but very few comparing OO approaches to anything else. Those which I have been able to find compare OO to procedural code, and find either no significant dif…

The most commonly cited proponents of this viewpoint are Rosson and Alpert (http://dl.acm.org/citation.cfm?id=1455754, behind a paywall). The first study you linked refers to them and a few other explicitly, and uses their research as a basis. It's difficult to find much more than those, because this kind of 'programming philosophy' is rarely under this level of academic scrutiny.

Aside from official sources, it's a statement that I didn't think needed much citation. It's absolutely fair to criticize it, but it's a widely-held belief that seems to hold true (at least anecdotally)

Post reply on HN