10 ms·

Don't distract new programmers with OOP

• knowtheory 16y ago
  Or you could use a language that uses object orientation in a more natural way, such as Ruby and Scala, which both are fundamentally OO languages. You can do procedural-y things with both languages, much to their credit, but packaging up functionality is both natural and intuitive. Over building APIs is not a hallmark that Objects are bad. They're a hallmark of bad design. So, yeah, i agree, prototype a minimal solution and iterate, and teach others to do this. This is an issue that is orthogonal to object orientation. At least, it is in languages that don't make you jump through weird hoops (C++ & Java, i'm looking in your general direction).
  • Tekahera 16y ago
    I think the point is precisely to take design entirely out of the picture when you're teaching a new comer about programming. The fact that you have these problems and you can write executable recipes to solve them is already more than a mindful, everything else only confuses.
    • zaidf 16y ago
      Reminds me of my AP Computer Sci class in high school a decade ago. There were five people in the class, two of them being my brother and I. Two of the three left had zero prior programming experience. I could only sympathize with them as we rushed through the "syllabus" learning about everything from pointers to classes to inheritances. Suffice to say they were completely lost and dreaded the class as much as math. I wasn't particularly good at math and could not imagine seeing programming as "math" because of how much fun I was having with VB/ASP(yes, you can chuckle) at home. I don't even want to think what perception of programming the two people left with. I recently finished college with communications degree, make a decent wage doing programming and haven't needed to even think of the word "inheritance." Of course there are many great uses for it. But to assume everyone should learn about it is to assume that everyone wants to be a genius programmer at google. There is so much gray in between the curriculum just ignores.
      • bachatawat 16y ago
        you lost me at "I recently finished college with communications degree"
        • zaidf 16y ago
          I still get a chuckle out of it, too. Then again, how else do you end up in a debate class full of basketball players who are gonna win the NCAAA Championship later in the semester?
          • deleted 16y ago
            [deleted]
  • jerf 16y ago
    The delta between Python and Ruby is way, way smaller than the Ruby community seems to think it is. You are aware that everything is an object in Python, too, right? The idea that that isn't true still seems to be knocking around the Ruby community. Everything he said about Python applies precisely to Ruby (or fails to apply in exactly the same way if it is a bad argument), because there's hardly any difference that matters to a newbie. "But, but, len is a function! And you can't monkeypatch the base classes even though you can monkeypatch everything else!" Yes, please, by all means burden your neophyte with that tirade. They'll really appreciate it while they're trying to figure out what an "if" statement really does or why calling a function with the wrong capitalization doesn't work.
    • deleted 16y ago
      [deleted]
    • jonhohle 16y ago
      > You are aware that everything is an object in Python, too, right? Python is missing encapsulation and message passing. It's object model seems to be similar to something like PHP or JavaScript: objects are essentially hashes. In practice, that's not a huge deal, but they aren't quite the same. This is not important for beginning programmers, but for programmers thinking about their toolset more information can only help.
      • BobKabob 16y ago
        "Any traditional OOP programmer might tell you that essential elements of OOP are encapsulation and message passing. The Python equivalents are namespaces and methods. Python doesn't subscribe to protecting the code from the programmer, like some of the more BSD languages. Python does encapsulate objects as a single namespace but it's a transluscent encapsulation." From: http://www.voidspace.org.uk/python/articles/OOP.shtml http://www.voidspace.org.uk/python/articles/OOP.shtml
        • GeneralMaximus 16y ago
          TBH, private fields are a stupid idea. It's just a cutesy concept that gives the newbie a false illusion of being in control. I've never seen a program where a private field was actually important to the integrity of the program.
• scootklein 16y ago
  couldn't agree more. i started with java in high school and was too caught up in "public static void main" to realize that it was up to me to define methods that made sense and that things generally ran top to bottom. switching to php for a while made everything "click" before heading back to java getting rid of CS terms and data types allows you to learn how to think in program flow and "what am i actually doing here". failing to capture the attention in this first step is lethal to most people that otherwise would be good at programming if they hadn't run quickly at their first try
  • Groxx 16y ago
    That's precisely why I think Java is a horrible language to start people out in. Well, not language. Library. It's abstracted to the extreme, and confusing as heck to anyone just starting to learn how to think about how to program. Start people out in something simple. Ruby can teach bad habits, so don't tell them about monkey patching, but it's so simple it's a great way to hook people, and has simple console / file IO that'll let newbies actually do something with their skills, instead of being glad their project doesn't overflow its array bounds or get stuck in hideous C input handling deathtraps (which flags do you have to reset in the input stream if they start inputting Japanese? I forget...) Best of all, despite being OO, you don't need a class to start doing things. Something Java gets wrong for beginners. #!/usr/bin/env ruby puts "hello world" Classes can wait, they're a whole can of worms that should come after people learn to think clearly enough for a computer to understand them.
    • phillco 16y ago
      If you're burnt out on using Java for introductory courses, consider using Groovy. (http://groovy.codehaus.org/ http://groovy.codehaus.org/). It takes a lot of the pain and boilerplate code out of java, making it easier for students to focus on what they're actually doing and not writing "public static void main String args" all of the time. Similar to your example, this is a valid groovy program: println "Hello!" But, unlike Python or Ruby, you're still in the Java world so migrating back to to pure Java is a lot easier. Though, the shrieks of pain you'll endure when you explain why they now have to write constructors or getters and setters might hurt. :-)
• raganwald 16y ago
  Provocative. The suggestion is that thinking in OO terms makes you think about architectures instead of programs, and the result is to move you away from thinking about the problem and the solution and towards thinking about the program's organization. This is always assumed to be a good thing, especially when accompanied by the usual examples of writing programs for teams of programmers with varying levels of skill. But if we grant that non-OO is better for someone learning to program, why wouldn't it be better for someone reading a program for the first time? EDIT: Thinking further about this, I am not against the idea of design considerations that should be kept from the beginning programmer. But OO isn't really a design consideration, it's a metaphor. If it really "worked," then new programmers would be looking all confused trying to write a Towers of Hanoi program, and you would explain, "Think of each tower as its own thing. What can it do? What does it have?" And slowly you could tease out a program by designing objects from the ground up. But if it actually doesn't work to teach programming using objects, if you teach programming without objects and introduce them as an 'advanced' subject, then at some level you have to wonder if the metaphor is fundamentally broken. If the purpose of OO is design and organization rather than a fundamental way to think about programs, then really we shouldn't say things like "Everything's an object." We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements rather than thinking that there is this obvious "metaphor" that naturally leads to well-organized programs.
  • deleted 16y ago
    [deleted]
  • deleted 16y ago
    [deleted]
  • knieveltech 16y ago
    "We should ask what we need to do to design well-factored programs that are cohesive without being coupled and then design language features that directly address those organization requirements" Language designers have been chasing that chimera for decades now. An unfortunate (in my mind at least) side effect has been legions of new programmers that are ready to fight to the death over concepts (separation of presentation and logic being an example) that are implied to be the One True Right Way when in my experience most programming rules should not only be broken on occasion but frequently ignored wholesale. "rather than thinking that there is this obvious 'metaphor' that naturally leads to well-organized programs." Herein lies my greatest criticism of OO and it's proponents. There is nothing inherently "obvious" about the metaphor in general and in my opinion adding a layer metaphor on top of an already complex process simply adds further complexity without bringing anything to the table.
• trustfundbaby 16y ago
  Exactly. Its like trying to teach someone basketball for the first time and at the same time trying to explain a pick and roll, a full court press, Triangle offence etc. You'll just confuse them. Teach the basics and slowly ease into the big picture/strategy stuff when they have a handle on the fundamentals.
• sunsu 16y ago
  I couldnt agree more. The first "programs" I ever wrote were BASH scripts. Definitely no OOP distractions there.
  • Groxx 16y ago
    That's hugely debatable, actually. If you ever called a command-line application in one of those scripts, you called what's essentially an object - it encapsulates its own behavior, hides how it does it, you can create multiple ones (instances) without them competing or sharing information, the command line arguments are arguments to the constructor, etc. They're nearly identical.
    • pdenya 16y ago
      Seems like this logic would apply to any procedural program.
      • deleted 16y ago
        [deleted]
    • freedrull 16y ago
      Several posts have mentioned that objects are merely metaphors, and isn't that exactly what you are doing here?
      • Groxx 16y ago
        Pretty much. But I see "BASH isn't OO" fairly often, and really? Every process you spawn has its own memory. That's pretty definitively OO.
        • jonhohle 16y ago
          You're missing message passing (though you can have that with a separate process as well). Something isn't OO just because it has its own memory.
        • 16y ago
• Rhapso 16y ago
  A reminder, The the objects are only in your mind not in the computer. They exist only as a metaphor to allow you to wrap your mind around programming easier, Rarely does the easier path yield any benefits except shorter travel time.
• jarrett 16y ago
  I don't think objects unavoidable lead beginning programmers to get lost in "architecture." My go-to language for teaching new programmers is Ruby--in part because it's my strongest language, but also because it's capable of expressing most programming problems intuitively. Is Ruby object-oriented? Yes and no. Certainly, objects are core to its design. But it's also a scripting language that can be used purely imperatively. Or you can use it like a functional language. What makes it so good for beginners, in my opinion, is that in Ruby, things are objects that naturally seem like objects. For example, it's very natural to think of a string as an object that can be passed around and manipulated, and Ruby makes this totally intuitive. Writing "Hello world".downcase.sub('hello', 'goodbye') doesn't tempt beginning programmers to create bizarre class structures or reams of boilerplate code. But it does make you feel empowered, and because it's so darn logical, it makes programming seem way less scary to a beginner.
  • jablan 16y ago
    Agreed. It's the hogs like Java, C# and C++ that gave OO a bad name. Moreover, in dynamic OO languages like Ruby, even scary things like design patterns usually take lot less time and lines of code to implement and, later, understand.
• siglesias 16y ago
  Speaking from personal experience, when I transitioned from C (first language that I was three months into) to Objective-C, I couldn't STAND the number of cutesy metaphors used to describe what objects were and how they functioned: "Like, you can send the duck a message to swim, or to fly." "Ducks inherit from birds." Coming from a highly plausible programming world of data and operations on data, this came off as nonsense. I wanted to tear my hair out finding a sober explanation of what an object actually WAS, practically, in practice instead of hearing them referred to as things that could be told to do stuff. Apple's Object-Oriented Programming was by far the most enlightening document in my early days: http://developer.apple.com/library/mac/documentation/cocoa/conceptual/OOP_ObjC/OOP_ObjC.pdf http://developer.apple.com/library/mac/documentation/cocoa/c... (chapter 2)
  • kragen 16y ago
    > Coming from a highly plausible programming world of data and operations on data, this came off as nonsense. It is nonsense. On IRC the other day, I said this: 19:19 < xentrac> I propose a new rule for discussions of object-oriented programming 19:20 < xentrac> which is that anyone who brings up examples of Dog, Bike, Car, Person, or other real-world objects, unless they are talking about writing a clone of The Sims or something, 19:20 < xentrac> is immediately shot.
    • phillco 16y ago
      Person is shot.
      • deleted 16y ago
        [deleted]
      • possibilistic 16y ago
        Person has a GunShotWound, which is a subclass of Wound. (cf. AbrasionWound, LacerationWound, etc.) Also note the new properties such as bulletType, entryPoint, and fragmentationPattern.
• freedrull 16y ago
  I think that a language for beginners should be as paradigm agnostic as possible. Lua does not force OO or functional programming upon the user. And unlike Ruby, there aren't a bunch of list-like datatypes like lists, arrays, and hash tables to keep track of. There is just the table datatype which takes care of all of those.
  • cageface 16y ago
    Lately I lament that Python, Perl, Ruby and PHP are the dominant scripting languages instead of Lua. None of the former really justify their extra complexity, IMO.
• onan_barbarian 16y ago
  Interesting, but one could go further with this: there still seems to be the assumption that learning OOP concepts is indispensable and necessary in the long run. This may or may not be true depending on the application area, language and intent of the programmer. Some languages and frameworks make it impossible to get anything done unless you know how to subclass things; at the other extreme you've got Stephanov-inflected C++. Arguably you would have people learn at least a little more about algorithms and data structures of greater complexity before dropping the OO-hammer. I still have moments where mid-way into astronauting up a class hierarchy I realize that all of this could be done more clearly in 10 lines of STL/Boost (and yes, I'm aware of the problems of that style of coding, too).
  • nickik 16y ago
    I agree but STL/Boost hard tiny bit to hard. Teach that stuff with Scheme, python or something that isn't <insert what you hate about C++>
    • onan_barbarian 16y ago
      You misunderstand. I'm merely using STL/Boost as one example of advanced non-OO programming. Many other such paths to sophisticated programming exist that don't go through OO, including the ones you name. I use STL/Boost in this case not because I think they're wonderful but because they're realistically what I'd have to use, as our codebase is mostly C/C++.
• pelotom 16y ago
  Better yet, teach them a language which doesn't even have the "extra layer of [OO] nonsense". Teach them something simple, clean, and logical. Teach them Haskell.
  • warrenwilkinson 16y ago
    You need monads to do any IO, that's not an easy first lesson. And you are a great distance from hardware.
    • anghyflawn 16y ago
      The first point is not too much of a downer, actually: it's not much harder to learn the IO monad as pure syntactic sugar than to learn printf and its ilk.
    • brehaut 16y ago
      main = print "Hello, World!" Not a monad in sight. Yes, print is an IO Action, but you don't have to use monads to do IO. Add in 'interact' and a you can be writing trivial stdin / stdout programs very quickly.
  • pnathan 16y ago
    Yick, then you've got an extra layer of type nonsense.
    • dons 16y ago
      Without types, how do you know you're not writing nonsense?
      • IvarTJ 16y ago
        As someone who gave Haskell a shot, I was very quickly put off by having to learn functions to convert from integers to floats, while such things were automatically taken care of by more low-level programming languages such as C. Also, I was confused by the package management with Cabal, and now I appear to have broken it with an error message whenever I start ghci. When choosing a first language for students, you have to think of idiots such as me.
• kragen 16y ago
  I wonder if part of the problem is that objects and classes are additional concepts to understand, on top of statements, variables, functions, modules, data types, if, while, for, and so on. In a language like the ς-calculus, you wouldn't have to introduce objects and classes separately from those other things.
• 6ren 16y ago
  It's a question of scale. Modules become increasingly important for larger projects. It's a form of infrastructure, ridiculous for a birdhouse, essential for a city.
• yason 16y ago
  This is very true. I write most of my Python code using only procedural/functional constructs and limit the OO parts to a minimum and that's the way I want to do it. Now, I haven't known exactly why I want to do this, except maybe that OO constructs soon turn my code ugly but that's a gut-feeling argument which I've kept to myself. Maybe I've thought that I've unconsciously absorbed from the athmosphere enough of that Java-hating mentality to let it show up in the way I write Python, too. But maybe I've been on to something as well. I'm glad to read about someone else thinking in the same way.
• pnathan 16y ago
  As a former TA, I agree. Objects are not ways of solving problems. They are a metaphor, which gives you a handle into the problem space. OO design is building a metaphorical data storage mechanism for your system, and then you need to cross the data into the metaphor and back again. I wasted countless hours when learning programming trying to wrap my head around coding in an OO fashion. Eventually I integrated enough OO to make my programs better. But I never really got 'into' OO, although I tried real hard! I don't have good words yet to explain the problem in detail, but fundamentally, a metaphor is not the solution. Most discussions of object orientation badly confuse themselves with that. As an example - an interface (ala Java/C#) is not an interface as a hardware engineer would speak of it: an interface from the OO perspective is some sort of promised type or 'protocol'. Are you building a model of your problem? Or are you solving your problem. I'm willing make a small wager that building models of your problem doesn't pay off until you really start scaling your system in some direction. If we use the Pareto idea, only 20% of your systems actually need the heavyweight approach - the other 80% can be put together without the heavy object-oriented machinery. Anyway, I'd rather be given the opportunity to teach in Scheme or other functional untyped language, instead of Java or C++. :-)
  • btilly 16y ago
    I don't have good words yet to explain the problem in detail, but fundamentally, a metaphor is not the solution. A number of years ago I wrote http://www.perlmonks.org/index.pl?node_id=318257 http://www.perlmonks.org/index.pl?node_id=318257. You may find that it solves the problem in a reasonable mount of detail.
• jpr 16y ago
  If only someone told me what on earth they mean by OOP...
• mtraven 16y ago
  Hm, nobody seems to have yet mentioned that OOP was practically invented as a teaching tool for novice programmers: http://samizdat.cc/shelf/documents/2004/08.02-historyOfSmalltalk/historyOfSmalltalk.pdf http://samizdat.cc/shelf/documents/2004/08.02-historyOfSmall...
  • nickik 16y ago
    Atomic Power was invented to build bombs do you really thing that we should use everything for what it was invented for?
• robee 16y ago
  Object Oriented programming exists because it is how humans conceptualize the world around them. Humans think in objects and actions on, in and between objects. OOP is a translation of natural thinking into systems and behaviors. Why is this a bad thing, especially for learning? I guess my question is, why does OOP and an natural translation between the real world and the code world lead to this discussion and a certain level of condescension around utilizing the concepts of OOP?
  • zvrba 16y ago
    The way humans conceptualize the world is miles away from how computers work. We (or at least I) conceptualize the world in terms of relationships between things we encounter, but the focus of OOP is designing individual classes and their hierarchies. But note that, in everyday life, relationships exist mostly between objects that would have been instances of unrelated classes in OOP. For example, my SCREEN IS ON TOP of the TABLE; I (a human being) AM SITTING on a CHAIR; a CAR IS ON the ROAD; I am TYPING on THE KEYBOARD; the COFFEE MACHINE BOILS WATER. We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. Contrast that with OOP where you first have to find one object and tell it to perform some action on another object. The way of thinking is shifted from actions/verbs operating on nouns to nouns operating on nouns, which is highly unnatural for me. It is as if everything is being said in passive voice, e.g., "the keyboard is being typed on by me".
  • nickik 16y ago
    Why don't you use Erlang? Its much closer to you definition of OOP.
    • Ingaz 16y ago
      Exactly. And I think that Erlang is most closest to Kay's definition of OOP. (If we can drop "Everything is object") Erlang processes are objects.
  • weavejester 16y ago
    I'm not sure that's true. In OOP, a methods belong to objects. In a natural language, a verbs don't really belong to nouns. To me, the structure of OOP is very different to how people typically think.
• suyash 16y ago
  I agree with you, I began with functional/event-driven programming at first and that help me ramp up pretty quick, OO principles need lot of time and initial curve is steep!
• InclinedPlane 16y ago
  I think this is a bit silly. The problem isn't OOP, it's how OOP is taught, and how OOP is abused. To be honest most programming education is so terrible that it will still come down to who has the talent and passion to figure things out on their own, that's been true completely orthogonal to the presence or absence of OOP education.
  • nickik 16y ago
    And thats we people write blogpost about it.
• vrode 16y ago
  As a new programmer I felt blessed when I learned OOP. I could actually write long and clean pieces of code, without spending double time on restructuring them. Clean and coherent structure is important for understanding, while understanding your own code, and remembering what it does, creates a more fruitful development. Since new programmers often work iteratively by adding new features to their code, this is rather positive, than negative and that extra learning effort is always rewarded. By knowing OOP you can access other's libraries in the language you recommend. By using other's libraries and by altering them, you can create more cool stuff faster.
• jarin 16y ago
  I didn't even know this was a big, controversial issue still. Coming from a PHP, Ruby, and Obj-C background (and having taken C and Java classes in college), I always saw it as "use objects when you want things to be easy, use C when you want things to be fast". Of course, being primarily a web developer and not having implemented a linked list or a bubble sort since college, the anti-OO people probably wouldn't consider me a "real" programmer anyway.
  • bigfudge 16y ago
    This is a serious question: is there ever an occasions when someone working on a real-world project should be implementing linked lists? I've no experience with C, but surely this stuff comes from libraries now?
    • JoachimSchipper 16y ago
      The C world has various reusable linked lists, but yes, there is occasionally a reason to implement one yourself: a {data, next} tuple usually fits in a single cache line, whereas some libraries only offer {data pointer, next} tuples, which requires loading in the memory that <data pointer> points to. The performance difference can matter. That said, some more agreement on reusable code may be useful, especially for things that aren't as easy to implement as linked lists.
• extension 16y ago
  Modularity is a fundamental design principle that pre-dates computer science: complex systems should be broken down into independent components that interact through formal abstractions. It's very simple and obvious. Everyone understands it on some level. OOP is really just taking the principle of modularity and making it a first class language feature. There's no reason not to teach it to a beginner. They are going to be using the concepts right away anyway. Also, OOP is ubiquitous in the real world and rookie coders need to get involved with the real world as early as possible.
  • nickik 16y ago
    If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do. The Objects loss this proberty because they have inheritance. The other problem is that every in OO the data is mixed with the functions. Rich Hicky on how it can be done right: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
    • trezor 16y ago
      If you build a house you dont need worry about the inside of bricks. Objects dont have that property, Pure Functions do. I see this exactly the other way around. Objects makes sure you don't have to worry about what's on the inside, but if you use pure functions you need to know how the function is implemented, how it processes data, how it expects input to be and how the output will be. Using pure functions requires you to seek out lots of information and verify implementation. Not that you shouldn't investigate this when using OOP, but in OOP a lot more of this is formalized in class-definitions IMO making the interaction easier to understand. The way I see your analogy, is that if you use pure functions, the electricity in your house needs to know what material the bricks are made of so that current doesn't accidentally leak and cause a fire. With OOP this is a detail you don't have to worry about as long as the pieces fit. If that sounds somewhat flawed or too simplistic, I will take the liberty of blaming the poor metaphor. I'm just pointing out that I see the exact same metaphor in the exact polar opposite way ;)
• nwjlyons 16y ago
  I completely agree. I wish I was taught Python or Ruby at University instead of Java.
• agentultra 16y ago
  I'd actually skip on Python and give them Scheme with a copy of "The Little Schemer." However, I agree with the OO sentiment. It brings a lot of vernacular and concepts that are not important to the building of a program; at least not at first. Classes, objects, meta-classes, inheritance, multiple inheritance, method resolution order, operator over-loading, class methods, static methods... it's all baggage for a new programmer. It's an interesting way of organizing code and encapsulating the responsibilities of different parts of a larger program... but it's a purely architectural tool. For a beginning programmer they aren't worried about such design concepts. They just need to understand inputs, outputs, and control flow. A single function is a program for them. Once they have a grasp of the fundamentals then you can think about introducing them to OO programming. Beginner's mind. It's hard for an experienced programmer to grasp.
• edw519 16y ago
  People often ask what's the single biggest difference between a good programmer and a great programmer. I've heard a lot of good answers dealing with talent, hard work, experience, imagination, communication, cleverness, simplicity, vision, and even laziness. The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. This makes me think about my answer: You first enable yourself to become a great programmer the moment you stop worrying about your own problems and focus primarily on your customer's.
  • randallsquared 16y ago
    I'd say many of the best programmers never had a customer, and therefore only had their own problems to worry about in the first place. The person you're describing is a great businessperson, but that's neither necessary nor sufficient for being a great programmer.
  • swannodette 16y ago
    This definition is far too narrow. Some of the greatest programmers are researchers and teachers.
  • CrLf 16y ago
    When you focus primarily on you customer's problems and forget your own problems, you tend to give your customers something that's not what they really want. You have to think about your own problems in the context of your customer's needs. You are you, your customer is your customer. Each to its own.
  • dwc 16y ago
    Despite the other comments, I think you make a very valuable point. Take out the "customer" angle and I think they'd also agree. It's really thinking about the problem, working the problem and solving the problem. Thinking about and working on your toolset is not solving the problem. Whether the problem is yours or your customer's makes little difference.
• iandanforth 16y ago
  As someone who is just making the transition to OOP in Python I totally agree with this post. I started with PHP: Learning programming syntax was really annoying then learning loop and nested loop structures was hard then learning a set of useful built in methods was hard then learning how to interact with other systems was really hard All the time I was learning this basic stuff I was writing code primarily for myself. I was the only one who maintained it and had to use it. Now that I've moved over to python and I'm working on a code base that I expect to last, and will get to work with others on, OOP makes a huge amount of sense. OO code may have more overhead to write (it does) but I find it much easier to read good OO code now that I understand the model, than I ever found procedural code even as I grew comfortable with writing it. As a number of others have mentioned, OO code is about architecture and that seems to be what matters when you're trying to grok other peoples code. The specifics of how they did it only matter when you start debugging or optimizing. (In my limited experience to date) I look forward to really getting OO, writing lots of code, and then starting to climb the functional programming mountain. But the poster is right, start bare bones, start simple, and build from there!
• Tycho 16y ago
  I just think of it in terms of OO is important for the design patterns. That's when I'd 'use it.' I wouldn't bother trying to explain the theoretical underpinnings to a beginner - the definitions passed around in these types of debate are hilariously confusing.
• r00fus 16y ago
  This OO complexity becomes more pronounced once you start talking about serious persistence, which today, likely means SQL. Has the object/relational problem been solved? Last I checked, it's still a confusing and complicated inelegant hack-job to reconcile inheritance/polymorphism vs. relational storage schemes.
• erehweb 16y ago
  I'd start with BASIC. For real beginners and kids, GOTO is their friend. http://erehweb.wordpress.com/2010/06/24/goto-considered-helpful/ http://erehweb.wordpress.com/2010/06/24/goto-considered-help...
• Apocryphon 16y ago
  My obligatory link to Joel Spolsky's lament on JavaSchools and championing of C: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...