I think people generally prefer not to have answers to questions of this sort.
OOP Isn't a Fundamental Particle of Computing
21–30 of 163 posts
Re: OOP Isn't a Fundamental Particle of Computing
#22Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…
> OOP is not that useful for anything other than namespacing
Namespacing, and modularization in general, are cornerstones of well structured code. OOP gives you nice tools to help with this.
Re: OOP Isn't a Fundamental Particle of Computing
#23Well, most OOP isn't object oriented at all, it's class oriented or maybe another way to look at it is that most of the time OOP is used as containers for data and function, not for things. For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash? Is that object oriented? If you add a couple helper methods to said object is it more…
>For example, say you have an object that holds some strings and numbers and it has getters and setters on it. How is that different than a Hash?
Of course this is the most degenerate case of an object, so pointing to this as an counter-argument to OOP seems rather specious. The typical case is that the data being encapsulated is related to each other in some way, and thus having a restricted set of operations on the object can ensure certain invariants are maintained. You cannot duplicate this with just a standard hash.
>and inheritance lets humans do what they love to do - name and categorize things.
You say that like its a bad thing. If humans like to categorize, why shouldn't our programming languages be designed around this tendency?
Re: OOP Isn't a Fundamental Particle of Computing
#24> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing a…
You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this?
You sound like someone who doesn't really understand performance very well. Lists and strings and arrays as implemented in any scripting language can implement virtually any algorithm with only a constant factor performance and memory penalty. (Try to come up with a counter-example to that statement, I dare you.) Switching from language to language comes with similar factors. If you discover that you've got a problem that requires you to worry about data structures at that level, worry about it then. Possibly you should use a more efficient language.
But for most apps and websites, those constant factors are really not a big deal. Basic algorithm mistakes are a different story.
For the exceptional cases, you should build working code first, then use a profiler to figure out where your problems are. You should only worry about performance after identifying actual bottlenecks.
If I interview with a company that uses a scripting language and does not understand all of that, that's a pretty good sign that I don't want to work there. Because their opinions on performance are clearly misguided, and I don't want to have to work with what they thought would be "optimized code".
Re: OOP Isn't a Fundamental Particle of Computing
#25OOP have strong stuff behind, strong enough to say it a fundamental practice of computing, specifically of the software engineering (And someone can have opinions on what computing is and if software eng. is part of it, but lets say it could be)
After reading all way down it seems that you see OOP as a simplifier tool that make code easier to understand as you say in the very bottom paragraph:
"That's too bad, because it makes it harder to identify the cases where an object-oriented style truly results in an overall simplicity and ease of understanding. "
And also your argument of seeing OOP as just making abstractions for standard types. And yeah objects represents information relaying on the standard types the underlaying language provide but the fundamental stuff is not there, actually the standard types relay on the underlying machine, SLA, etc... So they all are just "repurposing of what's already there".
So my point here is that the same arguments can be applied to any upper abstraction we made to "make stuff simpler". But as far as I can see what is behind any of this abstractions or frameworks are the fundamental concepts of reuse, coupling and cohesion. And here is really my point with this replica, the discussion about something being fundamental or not on the computing field, besides than it appears to be a subjective matter, should be in terms of this 3 core concepts and the way the "tool" under discussion makes easier to achieve each one as needed.
Of course there is a different tool for different works and OOP could be a lot of overhead to solve some kind of problems (Technically talking because OOP is more than just defining bunch of data and functions together). But if the discussion is about computing and specifically to software engineering where reuse is critical, let me say that the way OOP faces the 3 core concepts of software engineering works very well if your problem space can handle the overhead and most of our "Engineering problems" and restrictions can handle that for sure IMO.
More code is not necessarily a bad signal, not if you are getting real benefits from it, and again its not just simplicity to go and read the code its simplicity modeling your problem so you can reuse your low coupled and high cohesive abstract datatypes.
I have posted this replica using the cool replica.la service ;) http://www.replica.la/discussions/37
Re: OOP Isn't a Fundamental Particle of Computing
#26> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing a…
From other reading on this blog, he has a past doing assembly based game programming. It's clear from those other posts that he could care if he wanted to.
But having done his own analysis of the tradeoffs, he doesn't find if valuable to worry about performance overly for the kinds of problems he now works on.
Re: OOP Isn't a Fundamental Particle of Computing
#27> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing a…
[deleted]
Re: OOP Isn't a Fundamental Particle of Computing
#28OOP has never been just about computing. It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written. When both parts of this process are performed by the same person it loses much of it's value (until the problem gets larger and you need more than one person). As we have better computing tools in modern languages it is more often the same person. It has never be…
> It's strength is that it allows the business rules to be most directly mapped to the code that needs to be written.
Absolutely this. Discussions around OOP vs functional always seem to ignore this massive boon to productivity that OOP brings. Being able to create something of a DSL and map your business rules onto basic operations on this DSL is a huge win. The trick is to design your objects and operations such that the salient rules "rise to the top" of the stack, and thus can be easily programmed and verified at the highest level of abstraction.
Of course a DSL comes with its own drawbacks. Having to learn a new "language", with operations that are sometimes just renaming more basic operations has an extra cognitive load that can't be ignored. This is why there is a threshold of complexity below which you're better off just writing it straight imperative/functional style.
Re: OOP Isn't a Fundamental Particle of Computing
#29I happened to read this interview (http://www.codequarterly.com/2011/rich-hickey) with Rich Hickey today which I'm sure has been posted here before. I mention this because of this statement:
> When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications. Clojure eschews this and instead advocates a simple associative model for information. With it, one can write algorithms that can be reused across information types.
Re: OOP Isn't a Fundamental Particle of Computing
#30> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing a…
You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? You sound like someone who doesn't really understand performance very well. Lists and strings and arrays as implemented in any scripting language can implement virtually any algorithm with only a constant factor performance and…
Cache coherency matters, and making sure a large data structure fits in memory is important too. If you can't fit it, at least make it nicely match up to page boundaries. If you don't understandt he implementation of your choice array / set / map / tuple data structure that you are throwing around all over the place, you could be missing plenty of performance just from TLB misses or some other hardware voodoo.