Don't Distract New Programmers with OOP

http://prog21.dadgum.com/93.html?HN2

by ColinWright • 13 years ago

192 218 13 years ago

prog21.dadgum.com

hazz• 13 years ago

In the same vein (linked at the bottom of the article): http://prog21.dadgum.com/156.html

yconst• 13 years ago

"The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture."

Interesting thinking, never thought of it this way.

userbinator6• 13 years ago

If you view OO as a set of organisational facilities above procedural code, then it makes a lot of sense.

pjmlp4• 13 years ago

Yes, that is the main point of OO. Basically it boils down to extensible modules.

I think the people that have problems to grasp OO, are the hacker type of guys that code away without much thinking about what they are trying to accomplish.

OOP requires putting the keyboard aside and think about the architecture of what you are trying to accomplish.

davedx2• 13 years ago

Well, no shit sherlock. You also don't start teaching people to drive a manual car by telling them to use all 5 gears and drive on the highway.

I would have thought this was self-evident.

Pitarou2• 13 years ago

Then I guess you haven't suffered through introductory programming texts like "Objects First With Java".

DSMan195276• 13 years ago

I would agree - I'm current in a college CS program (I have ~6 years of programming experience already, so the introductory stuff is a breeze). The very first programming class we took was "Intro to Object-Oriented programming in Java". The irony is that a good 3/4's of the final projects people turned in where just a big mess of procedural static methods and global variables all shoved into the single 'required' class to hold main(). There were some who after going through the class understood OOP a bit more then they used to, but those were really just people who already had some programming experience. Those who came into the program with no experience were still trying to figure out the basics of procedural stuff ('This is how a for loop works', 'this is an int, it's not an object', 'i = i + 1 is a valid statement', while() vs. do while(), etc...) (And are still trying to figure that stuff out even now, though now a bit more complex issues, a year later, since it was never really taught that well)

I think the biggest thing that stuck-out to me as being utterly wrong with teaching Java and OOP is that you're forced to talk about references/pointers extremely early on, when most of the students don't have enough grasp on the core language to understand them conceptually (And really, who understands a reference/pointer the first time they heard about it? let alone 2 months after starting programming).

I honestly think starting off with C would have been better, and I don't view C as a good beginners language. But C itself has a pretty simple core language, and writing small procedural programs in it isn't very hard to conceptualize, so it requires a minimal amount of hand-waving to get simple programs running. (Hello 'public static void main(String args[])') The biggest hurdle would probably be string handling, as it's an array of char's. If you're not concerned with buffer overflows though, simple stack-allocated arrays work fine for tons of simple introductory programs, and <string.h> provides enough to get by without messing with any pointers.

davedx2• 13 years ago

At my Uni, we learned C first, then OOP in C++, then Java.

Munksgaard• 13 years ago

Wait, what? I think I was driving on the highway the second or third time I was behind the wheel of a car (I didn't drive an automatic until well after I'd received my license).

Bad choice of analogues aside, I (somewhat) agree with you. Python is a very beginner-friendly language.

pjmlp4• 13 years ago

Really?! Then you are not an European I guess.

munchor• 13 years ago

Another reason I approve of Python has a first language is Turtle[1]. It allows new programmers to approach problems in a modular way, i. e., if they have to draw a pyramid, they'll easily learn why a draw_square() function is important. You can extend this way of thinking to many other exercises using Turtle.

Additionally, it makes students have fun programming, since it gives them some graphical power and making a computer draw things is much more exciting than making a computer print things on a terminal (especially for newcomers). Plus, even though it's very simple, you can write some very interesting stuff with Turtle[2].

[1] http://docs.python.org/3.0/library/turtle.html

[2] https://github.com/FranciscoMSM/IPRP/blob/master/4linha.py

analog313• 13 years ago

Thanks for those links! Regarding making programming fun, I've observed that certain kids (well OK, my kids) get a kick out of programming that interacts with the physical world.

Kids seem to prefer writing programs that "do" something, where their definition of "do" might be different than ours.

TazeTSchnitzel8• 13 years ago

I disagree. OOP is not a difficult concept and not hard to teach. For an example of what happens when "OOP must not be taught to beginners", see PHP.

Pitarou2• 13 years ago

Trying to scare us with the PHP bogeyman? Shame on you!

Joeri• 13 years ago

Ah, but what is php popular for other than "it's easy to get started in"? The focus on procedural programming is why people flock to it, because those objects really do make things more complicated.

TazeTSchnitzel8• 13 years ago

But they don't. In practice, the difference is between:

  $x = new Object;
  $x->bar($foo);

vs.

  $x = object_create();
  object_bar($x, $foo):

See, for example, the "procedural" version of MySQLi.

programminggeek• 13 years ago

PHP for the longest time wasn't OOP at all and most of it really isn't. An awful lot of what you do with PHP has nothing to do with OOP at all.

TazeTSchnitzel8• 13 years ago

I am aware. I use it as an example because plenty of good API designs for it that could've made it in did not because of "OOP shouldn't be used by beginners". The PHP community is unreasonably scared of OOP.

TillE• 13 years ago

OOP "for beginners" always seems to be taught as some godawful real world analogy.

It's probably easier to talk about it if you've done a little imperative programming and can grasp OOP as a solution to actual problems, rather than just some abstract nonsense.

purringmeow• 13 years ago

It isn't. I took a course in my last year at high school and real world analogies made OOP seem a breeze. Almost no one in the course had problems grasping OOP basics and applying them. Of course, the OOP lectures came after 3 months of intensive studying and basic algo tasks solving.

gavinpc• 13 years ago

some godawful real world analogy.

Yes, I think this is a real distraction. This Cat/Dog/Animal trope leads to the view that you should use classes to model your domain objects. In some cases, you should. But this can cause as many problems as it solves, and should not (IMO) be the default approach.

In getting away from this view, I've found it helpful to think of most programming as designing DSL's. To that end, you can use OO to build the infrastructure necessary to support this. But I worked in OO languages for many years before grokking that.

n1ghtmare_• 13 years ago

We'll php didn't start out as an OO language. Many of the OO "features" we're added later. Just saying (not really disagreeing).

Goladus16• 13 years ago

First, I disagree with your premise that PHP's flaws can be attributed primarily to lack of OO design. But regardless:

For all its (many) flaws, PHP was (and is) an extraordinarily successful project relative to the vast majority of programming projects attempted. This is in fact a confirmation of the original post's thesis. The theory is that teaching OOP to beginners bogs them down worrying about the architecture of their code before they've had any experience solving problems at the scale where the architecture matters. It's easy for a beginning programmer to waste hours on pointless refactoring that doesn't actually improve their program in any meaningful way, simply in order to appeal to some professor, teacher, or other religious figure's concept of "good code". PHP, on the other hand, said "screw you religous types, we're just going to design a product people will use."

The reason that OOP should not be taught to beginners is not because it's a difficult concept. The reason OOP should not be taught to beginners is that it is an advanced concept. There are many other important fundamentals that can come first.

TazeTSchnitzel8• 13 years ago

First, I disagree with your premise that PHP's flaws can be attributed primarily to lack of OO design.

That's not my premise. I just point to PHP (and its community) as it has some examples of it.

The reason OOP should not be taught to beginners is that it is an advanced concept.

I've never quite got this. Spend any time writing code that's not using classes and you end up reinventing OOP anyway.

bane2• 13 years ago

IMHO, the thing that new programmers really struggle with is learning how to break a problem down into the steps their language allows them to express. Lots of people have never had to logically think out and algorithm to do simple things and it takes them lots of practice to understand how to do that.

For example, suppose I'm a new programmer given the notional task of making a program to make me a sandwich, can I just:

  makeSandwich();

and be done with it?

Or do I need to break it down to the n-th degree?

  //make bread
  bread=harvestwheat();
  bread=millwheat();
  bread=bread+water;
  //and so on

is that the right way to even make bread? Or do I already have bread I can work with someplace?

Do I?

  Sandwich=bread+jam+butter+bread;

  Sandwich=Sandwich.add(bread).add(jam).add(butter).add(bread);

Or do I need to do something else? Maybe this particular programming environment doesn't need me to make bread, but I have to transform a milk object into butter for some reason that seems entirely random to the new programmer. Who knows? Lots of the things that we take for granted seem entirely arbitrary to the new programmer and learning to break a problem down in a way that maps to the environment is a very hard problem to learn to solve repeatedly.

edit in a way this is a common topic even on HN with the "do x in n number of line" posts that are common.

spion2• 13 years ago

Here is a methodology that I recently started using:

Describe, at high level, what needs to be done to make a sandwitch, in your head. Then write code that looks exactly like what you said in your head, as much as possible. Dont worry if it turns out to be impossible to implement that way - you can always tweak it later until it becomes possible. Just try to make sure it reads more or less clearly.

Repeat with each of the steps, checking whether there already is a library that does that for you.

  function makeSandwich() {
    var breadSlices = getBreadSlices(2);
    var ham = getHam();
    var butter = getButter();
    var butteredSlice = spread(breadSlices.first(), butter);
    return foodPile(butteredSlice, ham, 
                    cheese, breadSlices.last());
  }

Continue the same way with getBreadSlices, getHam, getButter, pile.

As you progress this way, you'll notice that you'll be able to implement some processes in terms of more generic functions (e.g. spread and foodPile).

You'll also notice that you need an environment (macro, such as kitchen, or micro, such as frying pan) to temporarily place stuff that you're working with, while you wait for some process to complete. Thats when you start creating classes and objects that represent this environment.

Real code example:

https://github.com/jlipps/async-showcase/tree/master/promise...

anuragramdasan• 13 years ago

Gerald Sussman had explained this in one of his SICP classes. He called it wishful thinking.

One of the best ways I ever came across to break down a problem.

tseabrooks2• 13 years ago

I know it's a bit silly but the thing that jumped out about your comment and the parent comment is the butter. You butter a hame and cheese sandwich? Is this a cultural thing I'm not familiar with? zooms off to google to check

kensan• 13 years ago

This approach makes sense for a procedure you know exactly how to do. In the case of a procedure I do not know, I break them down into simpler and simpler pieces. Until I get to one I can do, then come back up the graph. Maybe akin to a depth first graph

example story: as a user I would like a form page that take an address I enter and renders a google map of it

http://i.imgur.com/38pXuJT.png

twobits• 13 years ago

Totally agree. A simple example: print, princ, echo, cout, ... For god's shake =8-/

mikro2nd2• 13 years ago

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.

raverbashing2• 13 years 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.

seanmcdirmid2• 13 years 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.

ufo2• 13 years 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?

userbinator6• 13 years 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);

Goladus16• 13 years ago

    open(window);
    add(window, make_line(...));

mikro2nd2• 13 years 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.

Goladus16• 13 years 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.

ghostdiver• 13 years ago

OOP is fun, it makes some sense for beginners, doing something "The OOP Way" always felt like an achievement for me, when I was a child. It motivated me to learn more.

popee• 13 years ago

Python is good for a wide range of simple and interesting problems that would be too much effort in C. (Seriously, a basic spellchecker can be implemented in a few lines of Python.)

But, but, someone somewhere in galaxy far away already made lib so you can use it in C with only few lines of code.

VLM• 13 years ago

In a world of circular time, not linear time, all syntactic sugar, or all fads in general, naturally rotate endlessly thru:

"You'd be crazy to use that"

"Um, OK"

"Often, I use it"

"Everyone must be forced to exclusively use it"

"Sometimes its sucks, but its the only sane thing to do"

And then right back to start. Endlessly. Forever.

So in 2014 OO is rapidly nearing the "you're nuts" and I see functional is rapidly nearing the "I use it" with, inevitably, "Everyone must be forced to exclusively use it" coming up soon. The relevant point is, have we started preparing for functional fundamentalism or whatever you want to call it? Also have we started scrubbing our resumes and githubs to remove the stain of OO programming?

ovis• 13 years ago

Although that may be true, I didn't really read the article as saying that OOP is bad, just that it brings a lot of extra baggage that newcomers to programming needn't worry about. Certainly as they begin to write more advanced programs, more advanced paradigms become relevant.

bad_user5• 13 years ago

Personally I like OOP and I think a lot of its criticism is flawed, since the OOP flavor that most people are exposed to nowadays is Java's OOP. And personally, whenever I see class names suffixed with "Executor", "Manager", or anything really that ends with "er" and "or", I feel like puking.

Besides, the state in which we are in is rather healthy. Back in the late nineties, early 2000, everybody was into class-based designs described with UML.

And I do wish people were forced to use functional programming, because that's the only way many people end up learning something new. OOP is not the best choice for every problem. Sometimes a function is better than an ExecutorManager. Sometimes a Map or a type-class are better than an inheritance chain. Sometimes a monad is better for manipulating data streams instead of iterators. And so on and so forth.

Also, the Gang of Four is seriously outdated.

pjmlp4• 13 years ago

Besides, the state in which we are in is rather healthy. Back in the late nineties, early 2000, everybody was into class-based designs described with UML.

UML is great as collaboration mechanism at the enterprise level across sites.

Also, the Gang of Four is seriously outdated.

Still largely unknown on the enterprise, sadly.

microtonal• 13 years ago

But the term 'functional programming' is perhaps even less clear than 'object-oriented programming'. Is a language that can pass a function 'as data' a functional language? Does it need to support tail recursion elimination? Does it need to be pure? Does it need to support algebraic datatypes? Should everything be an expression?

I am also not sure if programming trends follow circular time. I haven't seen logic programming making a big return and OO and FP are still in its first cycle. It just took FP ages to go from stage 1 to 3 (outside niches).

MichaelGG2• 13 years ago

HoF is functional nature. The rest just help things along that path. I'm not sure why people get so hyper about classifying things. The map is not the territory. Where you draw lines has no bearing on how easy it is to attain functional style in a language.

FP is far more clear a concept than OOP. OOP has no real fundamentals apart from encapsulation, which really isn't specific to OOP. OOP is whatever haphazard setup a language designer feels like using. FP concepts (like the ones you mentioned) are pretty clear across languages.

FP is certainly in its first cycle; ML just keeps going on. Industry is only now catching on.

Tycho• 13 years ago

OOP is a bundle of concepts and I find it hard to reconcile them all and explain them to people. Individual principles like information hiding, classes, those are good to teach but the monolithic 'OOP' is tough going for beginners. And non-beginners.

thomasz4• 13 years ago

I think beginners should be confronted with OOP very early, but not in the typical way:

- DO teach encapsulation of state.

- DO NEVER ever try to teach about objects as representations of real-world things. And for the love of god, do not give out modelling assignments where "Human inherits mammal" is an answer.

- DO start with collections: Vector, List, Stack etc. are easy to implement and showcase the virtues of encapsulating.

- DO teach polymorphism, but only in terms of interface inheritance. The collections you have taught before are a good starting point: ICollection, IRandomAccessable etc.

- DO NEVER EVER talk about class inheritance. Do not even use the word inheritance. Call it "is a relation" or something like that.

- When the time comes to teach inheritance, emphasize the Liskov substitution principle.

cliffbean• 13 years ago

I think I get why some people rage against inheritance, but I don't understand one of your remarks here.

Human isa mammal (let's say). Human is a Liskov substitute in any context requiring a mammal. What's the problem here? Is it just the fact that Mammal brings to mind a classification system which happens to be hierarchical, and you're afraid people will become too accustomed to hierarchies?

Mikera• 13 years ago

The problem is the design paradigm where you enforce an arbitrary fixed hierarchy on real-world data.

This doesn't work for several reasons:

* In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

* Your hierarchy will almost certainly have to change (you'll be wrong, or new requirements will come along). Frequent major code breakage / refactoring is the likely result. If you also need to persist data across versions, you're in big trouble.

Property / prototype based methods are in general much more flexible for real world data.

thomasz4• 13 years ago

Exactly. It fucks everything up: As soon as you teach OO with real world stuff as examples, all they see are inheritance relationships. It is really hard to make 'em stop creating extremely complicated hierarchies in order to solve simple problems.

dhimes8• 13 years ago

- DO NEVER ever try to teach about objects as representations of real-world things. And for the love of god, do not give out modelling assignments where "Human inherits mammal" is an answer

I have to disagree with this. I think this is exactly how to think about this.

I once explained the shift to OO to an older gent who was familiar, not just with ancient scientific programming, but also with building a house. I told him that the idea was that code was so large and complicated that it was divided up among teams with each team getting specific parameters that their code had to fit. He said, well of course.

Then I said it was much like constructing a house. You had to put the frame up, and know where the windows and doors would be, but the details of the windows and doors could be decided later. Every door had to be able to respond to an "open" command and a "close" command, some may have a "lock" command, and so on, but the builder of the door worried about getting that stuff right. All you had to specify were the dimensions and the direction of the door.

Now this was a pretty technical person- and perhaps doesn't qualify as a beginner, but I find, in general, real world metaphors to be powerful for teaching.

oneeyedpigeon4• 13 years ago

"I told him that the idea was that code was so large and complicated that it was divided up among teams with each team getting specific parameters that their code had to fit."

IMO, this is the first mistake. Code should not be large and complicated; when it is, few things can save you, whether it be the language or paradigm you're programming in, or the structure of the team doing the programming. OOP is a solution to the wrong problem.

thomasz4• 13 years ago

That's using a metaphor to explain OOP, not teaching OOP modeling with examples from the physical world.

kazagistar5• 13 years ago

Right. And monads are burritos. (http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...)

The heart of the matter is that people begin with the concrete, and move to the abstract. Humans are very good at pattern recognition, so this is a natural progression. By examining concrete objects in detail, one begins to notice similarities and patterns, until one comes to understand on a more abstract, intuitive level. This is why it’s such good pedagogical practice to demonstrate examples of concepts you are trying to teach. It’s particularly important to note that this process doesn’t change even when one is presented with the abstraction up front! For example, when presented with a mathematical definition for the first time, most people (me included) don’t “get it” immediately: it is only after examining some specific instances of the definition, and working through the implications of the definition in detail, that one begins to appreciate the definition and gain an understanding of what it “really says.”

Inheritance is not taxonomy. If you want to teach inheritance, show a couple of realistic examples of code which, when you add inheritance, becomes clearly better. We can see the pattern; we can make our own intuitive, abstractive jumps.

js74• 13 years ago

Why should you never try to teach objects as representations of real world things? Just curious.

betterunix10• 13 years ago

Let's put it this way: you are asked to write a program that simulates the behavior of an LCR circuit. Do you create objects to represent the components of the circuit?

repsilat2• 13 years ago

Not the grandparent, but in my view it distracts from what the code actually needs to do. OOP is a tool to structure code and data. It gives us some useful ways to deal with responsibilities, namespaces, some kinds of polymorphism, etc. We should use it in a pragmatic way, and making a class hierarchy reflect the real world often puts aesthetics above practical considerations.

Goladus16• 13 years ago

DO teach encapsulation of state.

I agree, with the caveat that there should be good discussion about when it's important to encapsulate state, rather than a rather blanket "always encapsulate data and methods" which is how it's often presented.

gruseom2• 13 years ago

"Never ever try to teach about objects as representations of real-world things"

I hear this from time to time—it seems bizarre. Representing real-world things as objects is a fine design approach for many problems and is well worth teaching. Where on earth did the idea that it isn't get started?

SICP, a classic of programming pedagogy if ever there was one, has this to say:

One powerful design strategy, which is particularly appropriate to the construction of programs for modeling physical systems, is to base the structure of our programs on the structure of the system being modeled. For each object in the system, we construct a corresponding computational object. For each system action, we define a symbolic operation in our computational model. (p. 217, 2nd ed.)

It's true that by "object" they mean something more general than OO. But that doesn't change the basic design approach.

It's also true that they are careful to teach more primitive concepts first, so what they do is compatible with the OP's point. But there's a reason why the above passage on real-world representations appears immediately after they mention modularity.

thomasz4• 13 years ago

The key here is p. 217. Examples and Exercises that come before p. 217 are:

- Square Roots by Newton's Method - Testing for Primality - Arithmetic Operations for Rational Numbers - Extended Excercise: Interval Arithmetic - A Picture Language - Symbolic Differentiation - Representing Sets - Huffman Encoding Trees - Symbolic Algebra

SICP teaches algorithms and data structures before that quote. And goes on to teach more about data structures without doing any of that awful OO modeling exercises you typically do in a typical Java Programming 101.

But there's a reason why the above passage on real-world representations appears immediately after they mention modularity.

After that quote, you return to data structures. Okay, after lists, queues and tables, there is a chapter about simulating digital circuits, which is both a fairly abstract and a well defined thing. Well, we can disagree on how abstract a digital circuit is, but at least we can agree that its no fucking dog that is_a animal and has_a head and has_a leg array and methods like

    bark(int howManyTimes) {
        for (int i = 0; i < howManyTimes; i++) 
            println("woof"); 
    }

Using OOP to model real world stuff wouldn't be so bad if it would happen in the context of real problems, like simulations where you can show how to use the state pattern to model behavior. What I want to see gone is that stuff like inheritance and composition is explained with examples taken from the physical world, completely detached from the programming practice. If you use File, Directory and FileSystemEntry as examples for a hierarchy, you can demonstrate it's usefulness with concrete examples. With Dog, Frog and Animal, not so much.

fiatjaf• 13 years ago

Writing complex classes which require inheritance is never a necessity of a begginer. He can only know that objects encapsulate values and methods and that's all.

When he needs inheritance he will know about it.

danso• 13 years ago

After my brief time in Java, I instinctively agree with the OP...but I wonder if there's a happy middle ground here, such as just using the out-of-the-box parts of OOP?

The easiest example I can think of is: using Ruby without getting into how to define/redefine classes or methods. Just stick to instantiating simple data types and invoking their methods:

     my_string = "Hello world"
     puts my_string.upcase
     # => "HELLO WORLD"
     puts my_string
     # => "Hello world"

Among the first roadblocks beginners seem to have is grokking that `my_string` isn't modified...but isn't that an early point of confusion for functional programming too, to some degree?

analog313• 13 years ago

I keep my eye on which programming languages and techniques are recommended for kids (plus kids-of-all-ages such as hobbyists, scientists, etc.).

Then I use those languages myself. ;-)

hyp0• 13 years ago

tangent: isn't the tricky part of a spellchecker the edit/Levenshtein distance? i.e. to still recognize a word even when misspelled - else you can only look up words that are already spelled correctly.

(I checked the comments on the last three times sunmissions of his spellchecker article, but no one seemed to raise this point...)

userbinator6• 13 years ago

Python advocacy aside, I agree that OOP is best taught when it "comes naturally" and NOT the first thing programmers should be learning. That is, the ideal sequence of concepts I think would be (along with a possibly contrived but relevant example):

1. Very basic, sequential computation. Add two numbers. 2. Conditional computation. Find the absolute value of two numbers. 3. Computations over homogenous data: Arrays and loops. Find the average of the absolute value of a set of numbers. 4. Computations over inhomogenous data: Structures. Find the area of a set of rectangles. 5. Computations over "even more inhomogenous" data: Objects. Find the area of a set of shapes of different types, and find the centroid of them.

That's where you ask "how would you do this with what you've learned so far", and the learners should start to build different structures with a lot of similar aspects and duplication of code (I realize I didn't explicitly talk about the value of functions/procedures above, I guess it'd go somewhere after 3), and then you show them how much more straightforward it is to do with OOP. Now they know the value of OOP and what "doing it without" would entail, and you end up with a bunch of more knowledgeable programmers who won't needlessly create baroque class hierarchies and write more code than they need to, but will use those abstractions when they have value. There is a huge difference IMHO between e.g. being taught dogmatically "you MUST use functions because abstraction is good" like it is something you should take at face value, and being taught by being given a problem in which you do not know about functions at this point and thus write lots of duplicated code and then being shown the value of eliminating that duplication via functions.

I've seen way too many learners create half a dozen classes with a ton of methods in them when given a problem that could be solved in a single function of a few lines, then have trouble figuring out what to put in the method bodies... it's completely backwards! No matter how much "architecture" you manage to create with deeply nested objects, in the end all the functionality of your code is essentially based on a series of statements executed in sequence, much like they would be in a purely procedural language. The fact that many otherwise highly-regarded educational institutions are churning out programmers who can create dozens of classes with dozens of methods in them, and then not know what goes in those methods, i.e. the actual "meat" of the computation, is something I find highly disturbing.

betterunix10• 13 years ago

Why start with computation as a sequence of operations? It might be equally useful (maybe even more useful for some students) to start with computation as a series of reductions e.g. with combinator logic.

userbinator6• 13 years ago

Because that's how a computer actually works, and the sequential execution concept is something that is intuitive to anyone who has followed a schedule, a recipe, been taught how to tie their shoelaces, ... , in essence, done any sort of living.

marcosdumay3• 13 years ago

maybe even more useful for some students

Maybe. But I've never met those students at real life (ok, I have a very small sampling set). The imperative paradigm is easier to learn.

macspoofing• 13 years ago

Programming is hard. There's no magic bullet. OOP is fine. Functional is fine. Procedural is fine. Every generation of programmers started with something different than the previous and turns out fine.

At the end of the day, every abstraction leaks so the student has to have a good working mental model of computing. And your first programming langauge does not dictate your career. You're expected to keep yourself up to date and have continue honing your craft.

pgbovine• 13 years ago

yep there was an epic debate about "objects-first" vs. "objects-late" CS1 curricula last decade. the objects-first folks seemed to have lost, though. here's a paper:

http://homes.cs.washington.edu/~reges/sigcse/basics.pdf

pixelmonkey• 13 years ago

In Python, OOP boils down to a style choice, which is exactly as it should be, IMO, and is very helpful to beginners.

In Java, you're forced to use OOP for every problem. No beginner understands why to define "hello, world", you also need a class, and a 'static' method on that class, and to invoke a weird-looking special class called "System".

It isn't obvious why there are "String[]" types and "ArrayList" types, and why I should care about the difference. Why does "main()" take "String[]" yet I am encouraged to use "ArrayList" in my code? This is just a sampling of difficult-to-answer questions that a beginner encounters in using Java that don't have a grounding in computer science, but just in Java.

It just so happens that among design choices, the choice to implement your Python code using OOP is a trade-off. It always is, but Python makes the trade-off clear as day. The win is increased ability to implement interfaces, language protocols, inheritance, polymorphism, the ability to bundle state and behavior, and the ability to bundle related behavior together. The loss is reduced readability and reduced beauty. Since these latter things are counter to The Zen of Python (PEP 20), idiomatic Python programmers will tend to torture themselves over OOP usage, to the point where only data structures that truly demand OOP's features come into existence.

This means that beginners will more often see a useful_function than a UsefulClass in Python's stdlib and associated ecosystem, and this is A Good Thing, since functions are much more composable than classes are (not to mention simpler).

I think Python will therefore also teach beginners vigilance in the use of classes, which the entire software community could use a little more of!

bad_user5• 13 years ago

You're saying that in Java you're forced to use OOP for every problem and then you exemplify with "hello world". Well ...

1. function definitions being constrained to classes has nothing to do with OOP

2. static functions or members have absolutely nothing to do with OOP

I see a lot of criticism of OOP, but when I get to reading the details, it's all about Java's flavor of OOP.

possibilistic3• 13 years ago

I think you missed OP's point. Beginner programmers introduced to Java are forced to grapple with OO from the outset.

What is a class or static method? These are OO constructs and require additional mental overhead when learning.

Goladus16• 13 years ago

function definitions being constrained to classes has nothing to do with OOP

It doesn't?

justinpombrio• 13 years ago

I suspect your parent would agree with (1) and (2). Those criticisms were aimed at Java, not at OOP.

nilkn• 13 years ago

I see a lot of criticism of OOP, but when I get to reading the details, it's all about Java's flavor of OOP.

The OP actually did a very clear job of distinguishing between Python- and Java-style OOP. I think you're the one cherry-picking his Java example and then extrapolating that to refer to all of OOP.

jafaku7• 13 years ago

In python you don't even have abstract classes, and instead you have to use horrible hacks.

RodericDay• 13 years ago

http://docs.python.org/2/library/abc.html

Even if that had flaws, PyQt carries over all the Qt abstract classes just fine.

possibilistic3• 13 years ago

If you're tying to develop interfaces in Python, I would argue you're using the language from the wrong standpoint.

Every language has a design goal. Python doesn't care about interface contracts. The "one correct way" is the contract.

raverbashing2• 13 years ago

Maybe because you don't need abstract classes

I'd say even that Abstract Classes are a horrible hack to the braindead inflexibility of languages like Java

And 99% of the time you're doing them in Python, you're doing it wrong

skrebbel• 13 years ago

Unlike many HN'ers, I'm a big fan of OOP (yes, even in the Java sense). Still, I think the author is absolutely right.

OOP is useful because it helps tackling some common non-functional concerns, mostly modularity and as a result extensibility, reusability and, to some extent, maintainability. These are architecture concerns. They're vital to take into account when you're writing any piece of non-trivially large software (and OOP is one, though not the only one, good approach to deal with them). They're entirely unimportant in small little programs, which includes nearly anything a beginning programmer makes when learning.

This also means that languages that religiously enforce OOP, like Java and C#, might not be the best starting points indeed.

marcosdumay3• 13 years ago

This may be the wrong timming, but I'll dare say it anyway: OOP (and OOP-like namespaces) is the best known approach for creating modularity. Other approaches are so far behind that they are not even in the same game.

Yet, there is an entire generation of programmers that learned OOP at school, and are hitting that hammer on everything, hoping for it to be a nail. That's all that's wrong with OOP: it does not solve all the problems in the world.

weavejester2• 13 years ago

I definitely agree that namespaces are a good idea, but if by modularity you mean isolating pieces of functionality, I'd suggest OOP is one of the worst approaches to take, because it results in a lot of implicit connections. Only global state is worse.

dnkrtz• 13 years ago

I don't think Python is a good first language. It's far too abstracted. I've always felt that learning lower level languages first then moving up the ladder is the better approach.

LyndsySimon• 13 years ago

I agree, and I love Python. Python is better suited to be the language you learn the architecture parts with. Basics should probably be in C.

betterunix10• 13 years ago

I disagree; abstractions are good, and it is more important for students to learn to think abstractly than to learn how a computer works "under the hood." The vast majority of computing tasks involve abstract problems with abstract solutions -- computing account balances, querying databases, cryptography, UIs, networking, etc. Even basic things in a CS curriculum like data structures and algorithms require abstract approaches and gain very little from knowing low-level details.

There is a place for the low-level details: computer architecture, compilers, and operating systems. Students should take these courses to be well-rounded and to see how theory is translated into practice, but elsewhere things should be done at a high level.

Goladus16• 13 years ago

Even basic things in a CS curriculum like data structures and algorithms require abstract approaches and gain very little from knowing low-level details.

I'd disagree somewhat. Data structures, from a CS perspective, often involve learning about low-level implementation details (why is accessing a hash O(1)? Why do array elements have to be the same size? What's the difference between representing a graph as a linked list versus a 2-dimensional matrix?). It's similar with algorithms.

Even though you CAN use completely abstract computational models to learn algorithms, many of the most important algorithms are designed around tradeoffs between real-world resources and being able to map abstract algorithms to a low-level language like C is a very useful skill to those who have it.

walshemj• 13 years ago

You right we dont teach mathematics by starting with advanced concepts we start with addition and subtraction.

Back in high school in the 70's our first language was a variant machine language CECIL - which we had to do by sending of coding sheets to a bureau.

Goladus16• 13 years ago

I agree in principle but still think Python is best to start with, for two reasons.

First, many people need a simple introduction to the entire concept of programming-- codifying precise instructions to a computer to get specific results.

Second, python is a great tool for exploration of other low-level systems, eg the socket library, the posix library, the os library.

collyw• 13 years ago

I have seen some truly awful code that has been written in Python. It wouldn't have been possible in Java due to the nature of the language.

pointernil2• 13 years ago

I believe, if you want to teach programming as a commercial (9-5) profession it is easier get the ideas of imperative programming (OOP or not) across and it will bring more benefits to the "pupil" ;)

... and teach declarative programming (Functional or not) to the pupils interested in the background of computer science and targeting some innovation/invention trajectory in their "career".

In other words (and very exaggerating):

imperative programming : translating more easily "real world" into code

declarative programming : translating more easily "platonic world" into code

ps: no, i don't believe this to be absolute truth, yes it is quite a hyperbole ;)

marcosdumay3• 13 years ago

and teach declarative programming (Functional or not) to the pupils interested in the background of computer science and targeting some innovation/invention trajectory in their "career".

Ok, but only after you teach them imperative programming. That's because it's also easier for them to learn the imperative paradigm, and you want to minimize the amount of "pollution" they have to learn alongside with "what is a computer and what it does".

That's also why avoiding OOP at this stage is a great advice. Architecture is "pollution" too.

pointernil2• 13 years ago

Yup, I too believe that agent-based imperative thinking is very deeply anchored in us and for sure helps a lot to explain a computer at conceptual level

agent: computer

imperative commands: instructions you give it

... but later on once the understanding of the machine/tool is established i see how much more powerful the declarative resp. transformational "paradigm" gets for "computers" applied to the "platonic world"

I believe that the transition towards the declarative paradigm and understanding of it is essential to grasp the idea of how "computers" and computation differs from other physical machines mankind invented.

Bahamut2• 13 years ago

This is a good article I think. I've helped mentor a couple of people learning programming and helped get them to understand the web development environment.

One person we started out with some Java since he was taking a Java class, and then I quickly found that he was very confused with Java. I shifted gears and had him start Python from scratch. His understanding skyrocketed, since he was getting to understand how control structures worked, defining functions, and using them.

There is something to be said about the importance of understanding a compiled language though. While it depends on the individual, I think most people would benefit from learning with a language like Python first since some of the most basic concepts of programming become more accessible.

dschiptsov• 13 years ago

It is good to learn that OO capabilities are almost entirely a set of conventions and how these could be implemented as a DSL, like it have been done many times with Common Lisps and Schemes. CLOS is just a DSL.

Another case study is Scala language, which is functional in the first place, and uses OO as a convenient way to structure the code, which, together with message passing were Alan Kay's original concepts.

OO should be a nice optional add on, not a forsed the only way to do it all as it is in case of Java or Ruby.

lettergram2• 13 years ago

I agree with the author for the most part, however here is my experience:

I have taught three people how to program (not a large sample size I know...) each one I have chosen a different approach. It honestly depends more on the individual than the language.

Individual 1: They were interested in history, video games, politics and desired to learn programming. For him, he seemed more interested in the history of programming, so I chose to help him learn BASIC as his first language simply because of the history associated with it (I could have chose FORTRAN or COBOL). He enjoyed it more because he could connect, he thrived off imagining the other early programmers writing in BASIC. Further, he felt as if he was building and learning in a similar fashion to most programmers and that made him want to learn more languages advancing in a similar fashion.

Individual 2: For her, NetLogo was the simple choice. She understood nothing of programming and honestly did not want to at the time, but knew she needed programming knowledge to help her obtain a job in biology in the future. NetLogo offered a way to both teach her the basics of programming (objects, loops, etc.) while being pretty fun, we made an eco-system. This actually excited her about programming to the extent that she is now learning python and joined ACM.

Individual 3: For him Ruby was probably the best introduction to programming, he was interested in learning how to develop website applications. Due to the fact he had no programming experience and was interested in web applications it seemed clear (to me) that Ruby was going to be the easiest way for him to learn to program. He loved it, and has since moved on to learning C, since it turns out he loved the control programming offers him.

The point, is that each programming language has a community/documentation and specific uses, it depends on personality and what ones goals are when determining what language to learn first. Since I have always been interested in both improving myself and others I have read a few books on the subject, my favorite is The Talent Code [1]. The book explains that each person has a different personality/experiences and in turn "learn best" in different ways, which is essentially what I employed here (without explicitly meaning to).

I agree with the author that Python (in many cases) is the best language to have a want-to-be programmer learn. It offers simplicity, logic, standard libraries, community, and tutorials in abundance, however it may not excite a person or have applications in what a persons interests are (which can reduce enthusiasm and in turn learning).

[1] http://thetalentcode.com/

andyidsinga2• 13 years ago

re: "early programmers writing in BASIC"

thanks. I feel oooold :)

lettergram2• 13 years ago

Hahaha I started with BASIC myself and I'm only 22, so...

blueatlas• 13 years ago

Would understanding structures be useful before trying to learn classes in any OOP language? If you understand how structures are stored in memory, would that provide the foundation for understanding class instantiation? I feel the answer is yes, and the optimal language before OOP is C. Other aspects of C that help prepare for OOP - pointers: how they are stored and referenced, pointers to functions (so you will understand object references), native data types and the memory that they consume. A foundation in these aspects prepare one for any OO language.

userbinator6• 13 years ago

Definitely. Structures are data grouped together, classes are that plus you can define functions to implicitly operate on their contents (also known as methods), extend them, etc. Then it becomes even easier to move onto C++.

brudgers• 13 years ago

Python might be the best programming language for an introductory pedagogy. But it is hard for me to take seriously assertions of that which are not backed with a comparison to the languages created by the PLT group and their research.

To put this in perspective, the PLT group of languages starts off eschewing not only OOP but mutation as well. Even more relevant, these are not options in the introductory languages.

This means the practice of not using OOP (or mutation) does not rely on the beginner practicing a type of discipline that even seasoned professionals might struggle for, i.e. a large class of kludgey habits cannot be developed when the PLT languages are used. A side effect of the PLT sequence is that it suggests the idea that switching languages isn't a big deal - rather useful since different languages are suited to different problems.

shittyanalogy• 13 years ago

There is no right or wrong way to teach programming. You should just do whatever you can to keep whoever you're teaching motivated.

When you teach it's not about you or what you think would have been best for you, it's about understanding other people's needs.

If you think bring up OOP should wait for some time in the future then wait to bring up OOP. If you think that OOP should be the basis from which programming is taught, then start with OOP. Just be a good teacher and keep them motivated. The whole goal is to get them past it all anyway.

Also, programming IS messy. Extremely messy, and teaching people as though it's gonna be all greased tracks the whole way isn't doing them any service.

lispm• 13 years ago

Don't start with learning how to use a bicycle. Start with Rocket Science.

The Anti-OOP propaganda gets stronger.

Didn't Alan Kay of Smalltalk fame work with and for children?

vinceguidry• 13 years ago

I don't understand why inheritance is always taught before composition. I almost never reach for inheritance these days, composition winds up more accurately modeling the domain. I'll define a bunch of classes modeling the actual behavior of domain objects, then get some code working using those classes. Then I'll start cleaning up, figuring out what goes together and creating composed classes out of the individual pieces of behavior. As I'm doing this, a lot of times I'll pull out functionality in one class and put it where it seems to belong.

analog313• 13 years ago

How about a more provocative idea (yes, a straw man, but I'm just thinking aloud):

Don't distract new programmers with computer science. ;-)

venomsnake• 13 years ago

That is not so bad idea. There is one essential skill - being able to get around and make any technology do your bidding.

People learn stuff well when it is rooted in reality. Make them make few simple programs that could be done with excel.

And right now with these insanely rich libraries that are on the market you could spend half your career without knowing what O notation is and have no problems.

jrmenon• 13 years ago

From the article:

"The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture"

Couldn't agree more... I have been doing OOP for a while in various prog. languages, and I had come to similar conclusions...It doesn't really help you focus on core ways to solve problems: focusing on algorithms.

Another read I would recommend is from the author of C++/STL:

http://www.stlport.org/resources/StepanovUSA.html

See the answer to the question:

"I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree? "

Note: not trying to endorse C++ templates here either...have my own gripes here but it did bring the attention back on algorithms and data structures.

andyidsinga2• 13 years ago

re: --- When you're trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked by faux-engineering busywork. ---

I like this for new programmers as they are often trying to solve a problem or make a game. My step son made a nice chunk of change by building a website for someone -- the last thing I would have tried to teach him was oop!

OTOH - there is a point where learning OOP and forms of modularization are a good idea to expand one's knowledge of the art - just like everyone should read tcp/ip illustrated and hackers and painters (#pandering on the later)

PhineasRex• 13 years ago

My main problem with OOP is that objects don't bound complexity.

If I call a function with some arguments, that function is composed of smaller functions which can only ever operate on the arguments I passed the parent function. As I follow the function down to primitives, each piece of code is operating on less data.

If I call a method, that method can operate on its arguments, properties of the object, and properties of the superclass. I often find myself ping-ponging around the code base as a class' method relies on a method of an abstract superclass which itself relies on methods of the original class, each step introducing more properties into the calculation, many of which are objects themselves!

_sh• 13 years ago

Python, seriously? How do you explain to 5-year-olds what the following line does?

  if __name__ == "__main__":

Python is there for when you move beyond beginner and you start to need libraries.

For everyone else, there's javascript: open up your browser console and you have a full IDE with breakpoints and inspection, and an interactive REPL. Object orientation is there if you want it, but what 5-year-old does? Functional paradigms are there when you're ready for them (map and foreach on arrays, for example). A smooth learning curve that gives you power when you reach for it, and a fast, flexible GUI environment. Free source code to study comes with every web site.

Best of all, its flexibility fosters many differing programming styles: consider jQuery and Angular. Very few programming ecosystems could give rise to such unique styles. I wish my first programming language was javascript, instead of C64 BASIC, with its 38911 basic bytes free.

pessimizer• 13 years ago

Javascript is absurdly complex, awkward, dishonest (in trying to appear to be OOP), and often a completely unintelligible mass of callbacks. I not only don't want beginner programmers to learn in javascript, I don't even want them to see js until they have experience in another functional language (although that ship has sailed.)

If you honestly think

  if __name__ == "__main__":

is more complicated than js variable scoping rules and closures, I'm intrigued by your mind.

Bahamut2• 13 years ago

JS, as with all languages, has its flaws, but I found JS the most accessible language for me. It solved the problems I was interested in, and so putting up with its issues was fine for me.

teach• 13 years ago

When teaching Python to a 5-year-old, you wouldn't use that line.

You'd just have statements in global scope and no main() function.

lhgaghl• 13 years ago

Can't tell if you're trolling. Ignoring the fact that you don't actually need the if __name__ == "__main__" thing in Python...

    <script type="text/javascript">
        $(document).ready();
    </script>

    int main() {
        return 0; // may or may not be needed depending on version of C/C++
    }

    class Main {
        public static void main(String args) {
        }
    }

Perhaps you should try Haskell, since you seem to care so much about how to write main...

    main = print "blah"

laureny• 13 years ago

These days, I think Javascript is a superior beginner language:

- Nothing to install, you most likely already have a full blown development environment installed (e.g. Chrome or Firefox).

- The language is straightforward, functions everywhere, easy control structures, very little to be distracted by.

- The reward loop is very high for beginners: load a page, tell them to write a Javascript one-liner and see their face light up when the HTML page gets instantly modified

MichaelGG2• 13 years ago

Odd scoping, equality, type coercion - those seem rather significant distractions. Having to explain that == doesn't really work and === is probably what they want seems beyond bizarre. And "function" as a way to introduce an anonymous function is just verbosity for verbosity's sake.

Unfortunately, the two other points you mention probably outweigh the actual language design.

dnm• 13 years ago

I agree with the article and think Python is great for a first language.

I asked my daughter's AP comp sci teacher: Why Java? A: because that's what the test uses.

ajanuary• 13 years ago

As a contrast, Steven Ragnarok has a interesting talk about teaching ruby with objects [1].

Whether it's appropriate to start with an OO language I guess is another question, but I think done the right way, starting with OO isn't as hard as people think.

[1] http://www.youtube.com/watch?v=SNbBC2pSiVw

Choronzon• 13 years ago

Im not a computer science major and got functional programming naturally but when I first encountered OOP i found it immensely confusing.I couldn't understand WHY you would want to do any of this, thinking about manipulating data was natural to me,but mapping classes onto so called 'real world ' ideas seemed like an immensely leaky abstraction. I eventually got a mental map that while functional programming resembled maths OOP resembled biology,considering an object as cell which can be a compartmentalised abstraction which could could change state and provide an interface.Probably not the most useful mental model for everybody but it helped me.

What i learnt was: Forget about all this dog inherits from Mammal bullshit(it doesn't work that way,its just wrong!). OOP is good for a few things. 1. Sharing state between a collection of functions(call them methods if you want to use two names for the same thing). 2. Code reuse (inheritance)

Im rather amused that test driven development forces you to simplify OOP as much as is humanly possible,thereby going against the advantages of a shared state,which is one of the reasons you would use an object in the first place.

Don't Distract New Programmers with OOP

Related Stories