4 ms·

Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's

Even then you can go wrong. I've learned that first hand while trying to write some lower level networking stuff in Go. Also OOP in Go is perfectly fine.. it's just by composition only and without inheritance.

lloeki 9y ago
Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.
- fileeditview 9y ago
  Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point. Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :) TLDR: While I learned about composition at university, they failed to really show how it is used and what it is good for..
  - barrkel 9y ago
    JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future. IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.
    - clover-lab 9y ago
      Which bring us to old school has-a relationship. Nothing wrong with that.
- exikyut 9y ago
  What would you consider solid references to learn sane OOP? I have a vague working model of object orientation but a lot of the finer details go straight over my head.
  - deleted 9y ago
    [deleted]
  - CamTin 9y ago
    While Lisp is usually associated with FP practices, the CLOS (Common Lisp Object System) really helped me with getting OOP to click as a concept. Part of it is that, CLOS is just Lisp, so all of the concepts of OO programming are there with none of the syntax generally added in other OO languages. Also, the method/function names clearly name all the concepts instead of using opaque notation: SLOT-VALUE instead of dot, arrow, or double-colon notation, DEFCLASS does what it says on the tin instead of the vaguer "class ClassName { }" of C++/Java/etc. I feel like this makes it clearer what is happening. A good overview of CLOS is chapters 16 and 17 of /Practical Common Lisp/ (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) I've heard other people speak similarly of learning Perl's MOOSE after already being familiar with non-OO Perl. This probably is no coincidence since MOOSE is heavily inspired by CLOS.
  - jerf 9y ago
    I'm being very serious here, with no sarcasm: Using a language that has an alternate model of OO that either simply doesn't have inheritance, or makes it relatively hard. IMHO it doesn't matter much how much you read about the differences, until you get in there it won't do much good. This is a good place to have a throwaway project on hand, because your first try is likely to be a very big mess. If you know an inheritance model and a non-inheritance model, you'll be well on your way to understanding the nuances because you'll have the experience in the field. (For reference, my personal definition of OO is pretty much any language where you can write object.method(arguments), some kind of polymorphism is made available on that, and that is either the primary or a very important element of design in the language. It's a very expansive definition because I find that having massive definition debates about what OO is to be nothing more than useless flamewars.)
  - 9y ago

lloeki 9y ago

Many people were taught OOP the UML and Java way†, to which the concept of prototype-based inheritance is completely alien, while composition is not even on their radar. † Although they have their fair share of issues, this is not a jab at UML nor Java themselves, but the way things have been taught, terribly, for so many.

fileeditview 9y ago
Yes that's true. When I was at university we learned about the concept of composition but the reference language for this 'software engineering' course was C++. The whole composition idea felt contrived at that point. Some time later I learned Lua for fun and almost instantly understood what this whole prototype based programming / composition was about :) TLDR: While I learned about composition at university, they failed to really show how it is used and what it is good for..
- barrkel 9y ago
  JS mixin / Ruby module / C++ mixin style composition are less than excellent, mind - throwing all the methods from multiple locations into a single scope is a recipe for implicit dependencies. There's an assumption that you won't define any methods that the mixins also define, not only today, but in the future; and even more, you assume that a same-named method won't be defined in multiple mixins, not only today, but in the future. IMO it's much better to explicitly reference all mixins, and compose by reference rather than by direct inclusion, unless the composition has strong reliance on the identity of 'this' / 'self' in its implementation.
  - clover-lab 9y ago
    Which bring us to old school has-a relationship. Nothing wrong with that.
exikyut 9y ago
What would you consider solid references to learn sane OOP? I have a vague working model of object orientation but a lot of the finer details go straight over my head.
- deleted 9y ago
  [deleted]
- CamTin 9y ago
  While Lisp is usually associated with FP practices, the CLOS (Common Lisp Object System) really helped me with getting OOP to click as a concept. Part of it is that, CLOS is just Lisp, so all of the concepts of OO programming are there with none of the syntax generally added in other OO languages. Also, the method/function names clearly name all the concepts instead of using opaque notation: SLOT-VALUE instead of dot, arrow, or double-colon notation, DEFCLASS does what it says on the tin instead of the vaguer "class ClassName { }" of C++/Java/etc. I feel like this makes it clearer what is happening. A good overview of CLOS is chapters 16 and 17 of /Practical Common Lisp/ (http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/) I've heard other people speak similarly of learning Perl's MOOSE after already being familiar with non-OO Perl. This probably is no coincidence since MOOSE is heavily inspired by CLOS.
- jerf 9y ago
  I'm being very serious here, with no sarcasm: Using a language that has an alternate model of OO that either simply doesn't have inheritance, or makes it relatively hard. IMHO it doesn't matter much how much you read about the differences, until you get in there it won't do much good. This is a good place to have a throwaway project on hand, because your first try is likely to be a very big mess. If you know an inheritance model and a non-inheritance model, you'll be well on your way to understanding the nuances because you'll have the experience in the field. (For reference, my personal definition of OO is pretty much any language where you can write object.method(arguments), some kind of polymorphism is made available on that, and that is either the primary or a very important element of design in the language. It's a very expansive definition because I find that having massive definition debates about what OO is to be nothing more than useless flamewars.)
- 9y ago