4 ms·

IMHO this is a pretty poor rant. Let me argue each point: * Data structure and functions should not be bound together In some cases encapsulation works really

• jwilliams 18y ago
  He probably has a point in some ways, but some of the points seem so bad they are almost impossible to rebuff - e.g. functions are functions, data is data, therefore they must be separate? Additionally, he's run up against the pitfall with OO - it actually lacks a definition. It's got lots of dimensions and facets, and each implementation interprets these in it's own way... e.g You could argue that SmallTalk's message passing metaphor was the precursor to Erlang's model.
  • visitor4rmindia 18y ago
    Actually the first line sums up the problem with this article: >When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". It's more a personal rant than a well thought-out article.
    • access_denied 18y ago
      What is wrong with a personal rant? Does every writing needs to be a well thought-out article? Discussions. Essay. Opinions. Why not?
      • silentbicycle 18y ago
        The problem is when people mix them up, I think. Rants are usually written to appeal to the emotions (whether intentionally, e.g. to rally support, or just venting), and sometimes people get so caught up in them that they miss major gaps in the author's argument...and people busy cheering aren't usually in the mood to coolly debate.
  • cabalamat 18y ago
    > Additionally, he's run up against the pitfall with OO - it actually lacks a definition I think OO is well-defined. I would define it thus: an object is something with state and behaviour. An OOPL is a PL with facilities for handling objects. These facilities must include (i) specialisation -- either through subclasses or prototypes -- and (ii) method invocation determined at run time, so that for example: someShape.drawOn(aCanvas); their are several drawOn() methods and the one that is executed is determined at run time by the class (or equivalent) of someShape and possibly also by the class of aCanvas.
    • bad_user 18y ago
      The second property you mention has a good name: polymorphism
      • silentbicycle 18y ago
        Or "late binding".
    • jwilliams 18y ago
      Someone else posted here a good reference: http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html The OO paradigm is a parcel of a lot of different things. When it was released, Java hit a nice sweet spot of these with the developer community.
• ntoshev 18y ago
  He is actually correct that in an OOPL data type definitions are spread out all over the place In a typical OO language all the code belongs in classes, and there is no way of telling which classes define the essential data types and which are mostly placeholders for code. There is no way to tell at a glance what are the important data structures. Just look at any open source Java project. I use python and I find myself using more functions and fewer and thinner classes recently. In particular, if some state is transient, I find it is much better to keep it in local variables of the more abstract functions than obscure it as object state.
  • visitor4rmindia 18y ago
    Couldn't you just put the ubiquitous data structures in a "com.proj.basic" package? EDIT: I'm using the word "ubiquitous" because that's what was used in the article.
    • ntoshev 18y ago
      Most people treat packages just like bigger-than-classes chunks of related functionality and state. Typically there is a 'common' package for supporting stuff that is used all over the place, but these are not the data types most important for the project, these are just that project's particular incarnation of datetime utilities. The 'basic' package is certainly not common practice.
    • silentbicycle 18y ago
      Yes, but if you're subclassing them at all, then any extensions on the core data structures are very likely to get fragmented and scattered around.
  • jwilliams 18y ago
    For a clearly delineated API/Module, often the essential data types are the public classes - the code is whatever is behind interfaces.
    • ntoshev 18y ago
• jamongkad 18y ago
  This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters. Yikes guilty as charge here as I currently have a unhealthy fascination for the use of instance variables if not all in most of my objects. Thanks for the heads up.
• yters 18y ago
  Uh, you only really make 2 counter arguments out of these 5 points.
  • omouse 18y ago
    he ran out of steam/coffee :p
• edw519 18y ago
  Because it makes it easier and safer to get programmers working together as a group. Making OO the ultimate dogfood. Whenever I encounter any kind of new "thinking", the first question I ask is, "Who is it good for?" Ultimately, OO was made for us, not our customers. True, anything that helps us helps our customers, but I'd prefer to ask a more basic question... If we have so many programmers that we need new technologies to work better together, are we doing something fundamentally too complex to begin with? Most of us aren't working on the space shuttle. We're doing relatively simple bread and butter apps moving data through logic. Before we surrender to OO, maybe we should take a closer look at why we need "easier and safer" ways to work together. For most of us, a simpler approach than OO often makes more sense. I suspect that's OP's biggest point.
  • DannoHung 18y ago
    I think it's more that OO was created because lots of programmers couldn't be bothered to exert discipline in observing APIs, so discipline was forced upon them.
    • jmtulloss 18y ago
      I'm not sure what you mean here. How does OO force APIs on a user more than any other programming style? If you don't follow an API, your code won't work whether it's OO or not.
  • miked 18y ago
    Back in the '80s I was the first person in my CS dept to champion the idea of OOP. It wasn't some conspiracy to make money (not a bad thing) selling a fresh set of buzzwords (that would be a bad thing). My views were strongly influenced by the views of writer Michael Jackson, who pointed out that every program contains a model -- at varying levels of explicitness -- of its domain. OOP just seemed to make the model clearer by creating a more explicit mapping between the objects in the world and those in the program. Grady Booch and Bertrand Meyer later made similar arguments specifically about OOP. What happened next was that an idea that worked well in a few contexts (discrete simulation and graphics/GUIs) was expanded to almost all kinds of programming where it didn't work as well. That's because a lot of the world-to-be-modeled is more verb than noun. That in turn means that functions will make better models than objects. I now think that Lisp-class functional languages (using, say, Clojure) are better for most programs. The reason, as pg has pointed out, is succinctness. The problem with OOP is that it's hard for it to be succinct because new data types are constantly being created and new methods added to them, all of which requires extra code. All programs are programs about a particular domain. Programs become succinct when the language being used can be sculpted to the domain at hand. That's best done in languages with macros and a simple (e.g., s-expression) syntax. One last point. I've looked for many years for the One True Programming Paradigm. I no longer believe that any such thing exists. Different classes of problems simply require different approaches. What I've come home to is using a language that allows easy creation of DSLs and controls side-effects, while still allowing them. A wet clay language that allows experimentation and sculpting to the domain at hand. Lisp-class languages do this best, with Clojure at the top of the heap in my opinion. I still think that OOP is best for GUIs, where state is inherent in the domain and inheritance can pay off big.
• cabalamat 18y ago
  > Everything has to be an object There are plenty of OOPLs where this is not the case. For example C++ or Python. > Why is OOPS popular? Because it makes it easier and safer to get programmers working together as a group. That's true. But the main reason why OOPL is popular is because it makes programming more productive, whether there's one programmer writing the code or lots of them.
  • russell 18y ago
    Python is a pure OO language; everything is an object. Java is impure; primitives are not objects. Python is not an everything-must-be-in-a-class language, like Java. Python allows you to create a variable or function without having to put in a class. Much better, I think;
    • cabalamat 18y ago
      > Python is a pure OO language; everything is an object. It is now, but it wasn't always. For example, you didn't used to be able to create a subclass of dict or int. And you can certainly code in Python just using built in data types and functions, not making use of any OO features.
      • visitor4rmindia 18y ago
        Which is pretty much my point. Python has morphed into "everything is an object". To see how C++ has moved towards objects-for-everything, I have just one word - boost! RE your second point - I don't know of any studies that show OOPS makes programmers more productive. As a matter of fact, some anecdotal evidence (cough pg cough), points to the opposite!
• joe_the_user 18y ago
  I actually wanted to like this post but visitor4rmindia is right, it is, sadly, a fairly ill-thought-out rant. For example: 'Consider "time". In an OO language "time" has to be an object. But in a non OO language a "time" is a instance of a data type'. In an OO language like Ruby, A time value is an instance of a class "Time", in a non-OO language, a time, variable may be an instance of a built-in type "time" if you are really lucky (PL/SQL) but it is more likely to be an integer or a string or a structure or all of these at different times.