11 ms·

With respect my experience is the diameteric opposite. One of the most talented and brilliant programmers I know learned object-thinking first, starting at abou

With respect my experience is the diameteric opposite. One of the most talented and brilliant programmers I know learned object-thinking first, starting at about age 10 or 11. Spent the first several years doing stuff like window.open(); Line aLine = new Line(...); window.add( aLine ); I will never forget the day he came to me - after about 3 years programming in Java to ask, "Where are the methods for ints documented?" and I and we had to have a Birds and Bees conversation to the effect that not /everything/ was an object. He vanished for several days after that conversation to process this oddity. I began to wish we'd chosen Smalltalk rather than Java. (Actually I still wish that as a matter of general principle.) No. I believe that we simply approach the problem wrongly. I think that objects are (and were deliberately intended to be) closer to the way we naturally think about the world. It's the baroque mental twists and turns we have to learn to make on procedural programming that are the problem. If you don't learn that odd way of thinking first, you're just fine with learning OO first - streets ahead, in fact.

raverbashing 13y ago
" It's the baroque mental twists and turns we have to learn to make on procedural programming that are the problem." What? For me the "modern OO" is as baroque as it gets. First of all, and your example reminded me of that, because it hides what's happening. What's a window and a line? How am I supposed to know what's happening, if one has the .add method? Docs, sure, but it's non intuitive. Granted, today there's so much complexity you can't handle it all in your head. But especially because procedural is how the computer works. Assembly. A list of instructions that are read in sequence. That I can understand. Now, OO makes this flow very convoluted, and the more "OO" someone programs, the shorter the procedures are, rather relying on inheritance, types to make computations, which of course, are good in one sense, but break the train of thought.
- seanmcdirmid 13y ago
  Some people will always prefer assembly code because they eschew all abstraction, but most of us need abstraction to deal with complexity. Picky your poison: do you like your abstractions to be objects or functions? Once he FP programmer starts flinging around higher order functions, FP can just as convoluted as OOP.
  - userbinator 13y ago
    The article is arguing that abstractions like OOP are unnecessary for a beginner. It is only after you understand procedural code that OOP "makes sense".
  - yodsanklai 13y ago
    Actually, some authors define objects as functions with an internal state. In that sense, objects derive from functions. For instance, in OCaml, the function "counter" defined as: "let counter = let x = ref 0 in fun _ -> x := !x + 1; !x ;;" is an object with one method that increments and returns the value of a counter. In my opinion, OOP is intrinsically more complicated that FP because you can't really avoid complex patterns even to do simple things. An example that comes to mind is the "Visitor" pattern. To me, it requires more mental gymnastic than what is found in most functional programs. It amounts to mixing higher order and functions with state which is something you try to avoid in FP. But I admit that I'm not well-versed in OOP. I've always found it complicated. Not Objects per se, but design of big programs using classes with complex relations, UML, design patterns and so on...
    - seanmcdirmid 13y ago
      I haven't used the visitor pattern in OOP in over 10 years and I write lots of code. There are many other better solutions to the expression problem than visitors. I don't bother with design patterns much or UML at all. I do mix my style up with FP when appropriate, but OOP is my dominant organizing principle. OOP really is just about object thinking, just like FP really is about thinking in terms of functions. All the other baggage in either paradigm is quite optional.
ufo 13y ago
TBH, your example is not too different from openwindow(window); Line aLine = make_line(); addwindowtoline(aLine); A small pet peeve of mine is people insisting that encapsulation and abstraction are exclusive to object orientation even though abstract data types are also a core concept in prodecural or functional programming. To make your example "trully OO" you would need to be using dynamic dispatching and polymorphism in those method calls. But are we really going to need multiple Window and Line classes and even if we do, is this really going to be the best way to architecture our code?
- userbinator 13y ago
  To take that example even further down the "procedural with OO-ish conventions": Window_open(window); Line aLine; Line_make(aLine); Window_add(window, aLine);
- Goladus 13y ago
  open(window); add(window, make_line(...));
- mikro2nd 13y ago
  You're right - I didn't attend to developing a really good example. But then I wasn't developing material for a programming course. ;) It was pretty off the cuff.
Goladus 13y ago
There's a difference between learning to use object-oriented systems and learning to design and implement them. This code snippet posted does not implement a new class. In a language like Python, you can code for years relying on objects without ever implementing a single class of your own. As a programmer, deciding when to switch from writing procedures and functions to writing classes and methods can be a tricky design call. The OP's argument is focused on this issue, not the simple matter of using OO APIs or frameworks.

raverbashing 13y ago

" It's the baroque mental twists and turns we have to learn to make on procedural programming that are the problem." What? For me the "modern OO" is as baroque as it gets. First of all, and your example reminded me of that, because it hides what's happening. What's a window and a line? How am I supposed to know what's happening, if one has the .add method? Docs, sure, but it's non intuitive. Granted, today there's so much complexity you can't handle it all in your head. But especially because procedural is how the computer works. Assembly. A list of instructions that are read in sequence. That I can understand. Now, OO makes this flow very convoluted, and the more "OO" someone programs, the shorter the procedures are, rather relying on inheritance, types to make computations, which of course, are good in one sense, but break the train of thought.

seanmcdirmid 13y ago
Some people will always prefer assembly code because they eschew all abstraction, but most of us need abstraction to deal with complexity. Picky your poison: do you like your abstractions to be objects or functions? Once he FP programmer starts flinging around higher order functions, FP can just as convoluted as OOP.
- userbinator 13y ago
  The article is arguing that abstractions like OOP are unnecessary for a beginner. It is only after you understand procedural code that OOP "makes sense".
- yodsanklai 13y ago
  Actually, some authors define objects as functions with an internal state. In that sense, objects derive from functions. For instance, in OCaml, the function "counter" defined as: "let counter = let x = ref 0 in fun _ -> x := !x + 1; !x ;;" is an object with one method that increments and returns the value of a counter. In my opinion, OOP is intrinsically more complicated that FP because you can't really avoid complex patterns even to do simple things. An example that comes to mind is the "Visitor" pattern. To me, it requires more mental gymnastic than what is found in most functional programs. It amounts to mixing higher order and functions with state which is something you try to avoid in FP. But I admit that I'm not well-versed in OOP. I've always found it complicated. Not Objects per se, but design of big programs using classes with complex relations, UML, design patterns and so on...
  - seanmcdirmid 13y ago
    I haven't used the visitor pattern in OOP in over 10 years and I write lots of code. There are many other better solutions to the expression problem than visitors. I don't bother with design patterns much or UML at all. I do mix my style up with FP when appropriate, but OOP is my dominant organizing principle. OOP really is just about object thinking, just like FP really is about thinking in terms of functions. All the other baggage in either paradigm is quite optional.

ufo 13y ago

TBH, your example is not too different from openwindow(window); Line aLine = make_line(); addwindowtoline(aLine); A small pet peeve of mine is people insisting that encapsulation and abstraction are exclusive to object orientation even though abstract data types are also a core concept in prodecural or functional programming. To make your example "trully OO" you would need to be using dynamic dispatching and polymorphism in those method calls. But are we really going to need multiple Window and Line classes and even if we do, is this really going to be the best way to architecture our code?

userbinator 13y ago
To take that example even further down the "procedural with OO-ish conventions": Window_open(window); Line aLine; Line_make(aLine); Window_add(window, aLine);
Goladus 13y ago
open(window); add(window, make_line(...));
mikro2nd 13y ago
You're right - I didn't attend to developing a really good example. But then I wasn't developing material for a programming course. ;) It was pretty off the cuff.

Goladus 13y ago

There's a difference between learning to use object-oriented systems and learning to design and implement them. This code snippet posted does not implement a new class. In a language like Python, you can code for years relying on objects without ever implementing a single class of your own. As a programmer, deciding when to switch from writing procedures and functions to writing classes and methods can be a tricky design call. The OP's argument is focused on this issue, not the simple matter of using OO APIs or frameworks.