Rob Pike on Object Oriented programming

https://plus.google.com/101960720994009339267/posts/hoJdanihKwb

by crawshaw • 14 years ago

243 168 14 years ago

plus.google.com

xakshay• 14 years ago

This is just flame war. Obviously using the right job for the right problem makes sense. There is no silver bullet.

This was not so obvious a few years ago. A lot of people believed that OOP always made programming better, and was a requirement to creating maintainable programs. Some still do.

oinksoft• 14 years ago

FP had its little Joe-programmer renaissance ca. 2007 slowing in 2009. It's been a while since anything approaching a majority thought OO-or-bust for all purposes, perhaps 2004-ish.

lusr• 14 years ago

Actually the author clearly states as much:

"Object-oriented programming [...] is a powerful idea. It truly is. But it's not always the best idea."

The problem is the opionated flamebait title submitted to Hacker News, the text of which is nowhere to be seen in the Google+ post itself.

pjscott• 14 years ago

Roughly half of the characters in your comment are part of platitude-phrases. By my count, exactly zero characters are about how to tell what the right tools are, which would at least have been making a concrete claim. This is unsatisfying.

Peaker3• 14 years ago

I don't really understand the justification for "There is no silver bullet". How do we know? There may very well be a silver bullet, after all, we've already had some!

Programming now using modern tools is at least an order of magnitude more productive than programming using punch cards or other methods used back in the day.

Why are we so sure that all the silver bullets are behind us?

dman• 14 years ago

Can someone paste his comment inline here - google+ blocked here.

k3n3• 14 years ago

Rob Pike 10:31 AM - Public

A few years ago I saw this page: http://www.csis.pace.edu/~bergin/patterns/ppoop.html

Local discussion focused on figuring out whether this was a joke or not. For a while, we felt it had to be even though we knew it wasn't. Today I'm willing to admit the authors believe what is written there. They are sincere.

But... I'd call myself a hacker, at least in their terminology, yet my solution isn't there. Just search a small table! No objects required. Trivial design, easy to extend, and cleaner than anything they present. Their "hacker solution" is clumsy and verbose. Everything else on this page seems either crazy or willfully obtuse. The lesson drawn at the end feels like misguided epistemology, not technological insight.

It has become clear that OO zealots are afraid of data. They prefer statements or constructors to initialized tables. They won't write table-driven tests. Why is this? What mindset makes a multilevel type hierarchy with layered abstractions better than searching a three-line table? I once heard someone say he felt his job was to remove all while loops from everyone's code, replacing them with object stuff. Wat?

But there's good news. The era of hierarchy-driven, keyword-heavy, colored-ribbons-in-your-textook orthodoxy seems past its peak. More people are talking about composition being a better design principle than inheritance. And there are even some willing to point at the naked emperor; see http://prog21.dadgum.com/156.html for example. There are others. Or perhaps it's just that the old guard is reasserting itself.

Object-oriented programming, whose essence is nothing more than programming using data with associated behaviors, is a powerful idea. It truly is. But it's not always the best idea. And it is not well served by the epistemology heaped upon it.

Sometimes data is just data and functions are just functions.

Pwntastic• 14 years ago

how about pastebin? http://pastebin.com/N3FXdisP

edit: ah, beaten to it. oh well

k3n3• 14 years ago

> But there's good news. The era of hierarchy-driven, keyword-heavy, colored-ribbons-in-your-textook orthodoxy seems past its peak. More people are talking about composition being a better design principle than inheritance.

Huh? Is he trying to say that composition is _not_ OOP, whereas inheritance is?

I hate to break it to him, but composition is just an expression of the composite design pattern, of which OO is part-and-parcel. You can't do either inheritance or composition without using OO principles.

edit: Ok, I concede that I'm an idiot, but at least it resulted in a lot of genuine discussion.

sp332• 14 years ago

You can do composition in functional style, which is not OOP. So OOP is not necessary for composition.

jbooth• 14 years ago

In the linked blurb it's mentioned as an alternative to inheritance, so clearly he means it in the OOP context.

(and yes, one should usually favor composition over implementation inheritance)

codewright• 14 years ago

Given that Rob Pike embraces neither OOP nor functional programming, one has to wonder what he really means by composition.

The closest thing to composition or reuse in Go are the typeclasses and it's pretty weak. I hope he enjoys specializing his maps and reduces for every type instance.

Rob Pike has in the last few years spent a lot of time complaining about the younguns and the slightly less young younguns, but I've not seen him talk in concrete terms about what he thinks the solution is.

Other than, "use Go", which doesn't actually answer the questions that are raised by his complaints. Like how Go somehow supports composition in a superior way. I've spent some time with Go, built a few projects and services. I wasn't impressed.

I'll just keep using Clojure and Python until Pike starts talking about what he actually means to do to solve these problems.

Hickey is an iconoclast too, but he's sensible enough to stay focused on what can move the profession forward as opposed to complaining profusely on Google+ every other week.

If you really want to learn something interesting, you'd be better off learning about the fundamental relationships between code, data, state, and objects such as Hickey has covered in his past talks.

They're enlightening even if you don't care about Lisp and the talks themselves aren't really in terms of Clojure except to explain how it does things differently.

btilly6• 14 years ago

Consider carefully that Rob Pike is co-author of a well-known programming language which doesn't really have inheritance, but in which composition is trivially easy.

I think that he may know more about this particular topic than you do.

seanmcdirmid4• 14 years ago

Not only that. Rob Pike is one the original Unix guys, he is also the principal of Plan9/Inferno, and its own language Alef/Limbo.

But appeals to authority are very shallow arguments. He should still be able to out debate someone who doesn't know who he is.

pfortuny• 14 years ago

What you think about someone and who Pike is I am sorry to say are irrelevant to any argument, as you probably know.

Sorry could not help saying it.

comex• 14 years ago

To be fair, anonymous fields in Go are essentially inheritance in disguise.

chubot3• 14 years ago

It's a semantic argument, but composition was how people structured programs in C for 20 years before popular "OO" languages like C++ and Java appeared.

Inheritance was the thing that was new in C++ and Java over existing practice. So therefore people associate OO with inheritance, which seems reasonable to me. (Academic languages have a different history, that's a different argument).

To put it somewhat more bluntly: there were naive C programmers who were writing procedural spaghetti code. And then there were real C programmers who actually knew how to use composition to structure large programs.

And then OO languages appeared. This caused the naive programmers to write spaghetti with inheritance. And the real C programmers were shaking their head because people already had the tools to write maintainable programs (composition), but they ignored them in favor of buzzwords and the "everything should be OO" mentality.

k3n3• 14 years ago

Thanks for the thoughtful reply, I actually learned something here. Much better than the "you're not qualified to argue Rob Pike" approach.

eridius• 14 years ago

I don't think I've ever seen a language that claimed to be OOP but used composition instead of inheritance. Can you point at any examples?

sea6ear• 14 years ago

Not a language but a library: see SNIT (Snit's Not Incr Tcl) at http://www.wjduquette.com/snit/ is a fairly complete object system for Tcl that eschews inheritance in favor of composition.

mixedbit• 14 years ago

This is also an example of composition:

cat /etc/passwd | cut -d':' -f1 | sort | grep -v root | tee /tmp/users

It was invented long before OOP and until today this is probably the most successful approach to code reuse.

sukuriant• 14 years ago

Unix arrived in 1969 according to Wiki

Smalltalk arrived in 1972.

That's only 3 years; and that's implementation not idea creation

acqq2• 14 years ago

Re:

http://www.csis.pace.edu/~bergin/patterns/ppoop.html

I can only read it as a joke -- the title is almost 'poop' and it's insane to write all the classes instead of the initial few lines. But I really see that one of the authors has more 'OOP forewa' articles where he's fully serious:

http://csis.pace.edu/~bergin/

chimeracoder• 14 years ago

> I can only read it as a joke -- the title is almost 'poop'

Don't be so sure!

POOP is the accepted term for Perl Object-Oriented Persistence - without any trace of irony, as far as I have ever been able to tell.

acqq2• 14 years ago

Actually, I have an impression that I relate very good to most of things Perl, I use it very often for small programs. I believe that most serious Perl people have a sense of humor, if you know what I mean. And exactly because of that bias, I've first believed that the article absolutely must be a very successful joke, and didn't understand why Rob isn't sure. Only after seeing the rest of the material, I wasn't sure myself. Maybe somebody should actually ask the authors.

Do read the paper! Note that I would consider an elegant solution this (string literals replaced with the names of them):

    static void judge()
    {
        String s = System.getProperty( p );
        if ( s.equals( t11 ) || s.equals( t12 ) ) {
            return m1;
        } else if ( s.equals( t21 ) || s.equals( t22 ) ) {
            return m2;
        }
        return m3;
    }

    public static void pjudge()
        { System.out.println( judge() ); }

Then read what they produced instead.

dschiptsov• 14 years ago

This is not a new realization. Some enlightened people never allow themselves to be deluded.) Brian Harvey is one of them.

OOP is just a set of conventions which could be implemented efficiently even in Scheme. CLOS is another canonical example which people prefer not to notice to maintain their comfortable reality distortion.

Everything was solved long ago by much brighter minds that now populating Java/Javascript world. Just imagine (but almost no one could) how much more clean, efficient and natural it will be to implement something like Hadoop in Common Lisp or Erlang - passing data and functions as first-class S-Expressions or even packed Erlang binaries. Instead they re-implemented a few concepts form FP in Java way.

Here is a heretic video about what OOP really is: http://www.youtube.com/watch?v=qbUJXsKAtU0&feature=edu&#... ;)

jamii• 14 years ago

> Just imagine (but almost no one could) how much more clean, efficient and natural it will be to implement something like Hadoop in Common Lisp or Erlang

Hell, let's go one step further and implement it in datalog:

http://boom.cs.berkeley.edu/ (scroll down to Boom Analytics)

jlgreco2• 14 years ago

I think you are on to something, but I don't think the root of the issue is OOP but rather a "C-like" syntax and all the baggage that seems to come along with that.

C is great (I absolutely adore it) but despite the numerous reasons that C++ did it I think we would be in a better position today if the fad of making new languages "C-like", even if just superficially, never took off. At each step, it is hard to point the finger at any one person (even in retrospect, it is hard to really fault Stroustrup), but I feel nevertheless too many prior advances were ignored along the way to modern Java for far too long.

A terribly superficial but I think potent example of how "C-like" has done harm is that languages have keep using it's abusive declaration syntax for so long. It is so clearly absurd and unnecessary that it is a wonder that people haven't started dropping it sooner. Instead, such as in the case of Java, it seems they have just redefined what is idiomatic in order to avoid the harsher cases seen in idiomatic C. At least Go strays from the example set by C, though it still falls a bit short I think.

Basically I see the primary driving force of many trends in programming, including to some limited degree OOP, to be pain inherited from C.

mamcx• 14 years ago

Agree. That is something I dislike about go. A lot of rigth things, ugly as hell c syntax. For people that love C-like is hard to understand how taste that bad for people that love something else. Is like OO vs FUNC, C-like VS anything else.

bad_user9• 14 years ago

Funny how I end-up arguing for or against OOP in the same thread.

Guy Steele, one of the big proponents of OOP and one of the creators of Scheme, does not agree that tacked-on OOP is practical: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

eternalban2• 14 years ago

Actually, he says quite a bit more than that. That article is a very effective rebuttable of OP's position.

btilly6• 14 years ago

I still believe that the book which taught me the most useful lessons about object oriented programming was Code Complete (first edition).

It was written before OO programming was popular. The concept is not described there. But if you've read and understood its description of things like abstract data types, it is obvious where and when OO is going to be an extremely good hammer to use. And - just as important - you're not going to wind up endlessly searching for nails for your OO hammer.

When I see things like http://www.csis.pace.edu/~bergin/patterns/ppoop.html it is clear to me that someone does not understand the value of simplicity. I don't care what complicated theories you have about what kinds of code are easier to refactor. Less code is generally going to be easier to change later. If need be you just rewrite it.

bad_user9• 14 years ago

> Less code is generally going to be easier to change later. If need be you just rewrite it.

That's in general an unhealthy attitude, because later might be too late to rewrite it, as complexity has a way of creeping in, as simplicity requires eternal vigilance and leadership with an iron fist, something which most teams lack.

You should watch the Hammock Driven Development presentation, by Rich Hickey, in which he makes a case for the value of thinking about the problem before acting. This man is in fact brilliant in how he delivers presentations, so while you're at it, watch Simple Made Easy, in which he argues that simplicity ain't easy.

TL;DR - easy to write code is not necessarily simple. But simple is objective, so you know you have it when you achieve it.

coliveira3• 14 years ago

Another reason why simple code is not always better is that in a typical project there are LOTS of simple decisions that need to be made. If you let them for later, they will become: hard to find, hard to integrate with other "simple" decisions you made, etc.

trhtrsh• 14 years ago

Hammock Driven Development is a create way to reinvent things from scratch every few users, building elegant systems that don't ever grow to solve large problems.

btilly6• 14 years ago

If you want to assume incompetent programmers, then I agree. If you assume competent, experienced programmers, there is constant willingness to say, "This worked here for a bit but it is time to sit down and do it right."

I've had the pleasure of working with the latter. If you have that pleasure, then a willingness to find a simple solution where it makes sense pays off in spades. And it it not unhealthy.

But there is a definite element of, "If you don't know what you're doing, this is a principle that can let you make horrible decisions without realizing it."

cpeterso• 14 years ago

Code Complete was a huge influence for me, but the book (understandably) focused on procedural modules and abstract data types. I still refer to some of the book's cartoons about information hiding when I think about code. :)

The book that brought me OO enlightenment was Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software. The book is quite dry and, in the small, it seems to describe nothing new, but by the end it was quite deep.

For impatient readers, I recommend Abel Avram and Floyd Marinescu's Domain-Driven Design Quickly, available as a free PDF: http://www.infoq.com/minibooks/domain-driven-design-quickly

swanson• 14 years ago

Matt Wynne raised a good point in a recent talk about hexagonal (Ports & Adapters) architecture that I agree with.

People are exploring new ideas for building software. Why is that so wrong? Instead of attacking people for adding unnecessary complexity or doing it "wrong", why aren't we praising them for thinking about new solutions and approaches to problems in software?

mathgladiator• 14 years ago

Basically, we learn from the people before us. I've noticed this, and you learn through code-review that "that's a bad thing to do"; if you are lucky, then you learn interesting edge cases.

I think people learn what is "right" by a combination of cleaning up peoples crap and by dealing with their own crap, and the difficult thing is to purposely try "wrong" things and push boundaries.

Stephenson, G. R. (1967). Cultural acquisition of a specific learned response among rhesus monkeys. In: Starek, D., Schneider, R., and Kuhn, H. J. (eds.), Progress in Primatology, Stuttgart: Fischer, pp. 279-288.

teeja• 14 years ago

Javascript's best feature is that almost any routine can be written without objects. And those that have to be there are hidden from sight like objects should be.

gizmo6862• 14 years ago

You do know that Javascript considers almost everything (including functions) to be objects?

seanmcdirmid4• 14 years ago

I once had a heated argument with Rob Pike over lunch about Java when I was a naive grad student; suffice it to say that I thoroughly got my butt whooped on inheritance. My argument was, I think, that inheritance basically is composition, just with some self recursion thrown in. Keep in mind that programming is always about composition, and we are just arguing about different styles of such.

OOP has recently been thrashed in the mud in the academic community, where it was never completely accepted. Now, industry always loved OOP, not because it was new, but it provided some stronger guidance on what they were already doing (composing software out of stateful parts), and was much more pragmatic than its older more aloof sibling (FP). People were already thinking in terms of objects probably even without using Simula, Beta, Smalltalk, C++, etc...vtables were even already being crafted like crazy in C.

I agree that object thinking is just another tool in your bag, sometimes you really need lambdas and should use those. Sometimes you want raw tables. Any program worth its salt is going to incorporate many different styles, and avoiding one style on ideological grounds is ridiculous.

TimGebhardt• 14 years ago

I think OOP really took off in industry because it was easy to sell third-party modules. You could "plug in" this module that you purchased and it was easy to hook up. Markets have a way of doing that: the solution that wins isn't necessarily the "best" solution but the one that's easiest to sell.

seanmcdirmid4• 14 years ago

I don't think the component revolution has happened. We got frameworks to be sure, we even got...gasp...libraries with our languages. Maybe for that reason, OO languages (Java/Python/Smalltalk) were more likely to come without their batteries included. I'm guessing inheritance helped out a bit with that.

But I don't think objects are really especially about third-party reuse or even any reuse at all, but they are more about enabling easy problem decomposition (i.e. break up your problem into a bunch of interacting objects).

gwillen• 14 years ago

I think inheritance basically _is_ composition plus self-recursion.

You get into trouble because of the self-recursion. Any time a base class method calls another base class method, that call is part of the class's interface, because when you extend the class, the call will be redirected to the subclass' method.

But how many base classes have documentation for every self-call that can be redirected in such a manner?

See e.g. the "hashtable with plurals" example:

http://norvig.com/java-iaq.html#super

georgeorwell• 14 years ago

My understanding is that composition can be changed dynamically whereas inheritance cannot. It has always seemed to me like composition is more flexible.

To give concrete examples: using composition, if instance A has a B, then at runtime you can replace the pointer to the B with a pointer to a C such that now A has a C. You basically change the type of A by changing where messages get sent / delegated.

With inheritance, you'd have B is an A and C is an A, and the relationships here are static unless you start messing around with reflection and dynamic class loading and stuff.

The tradeoff for the flexibility of composition is more verbose code, I think.

bunderbunder• 14 years ago

> You get into trouble because of the self-recursion.

Which is why (savvy) object-oriented programmers have largely moved on to interface polymorphism. Inheritance polymorphism has its uses, which is why there hasn't been a whole lot of effort to rally behind languages that lack it, but the general consensus is that you should really only use inheritance when inheritance is what you really want to use.

Unfortunately it's true that there's a whole lot of OO code out there that was written before people learned this lesson. And OO's popularity with pragmatists combined with its relative lack of popularity with academics means that a lot of code doesn't reflect lessons related to the pitfalls of inheritance polymorphism that academics figured out a very long time ago, such as the Liskov Substitution Principle.

ww5203• 14 years ago

I don't get this hate toward OOP. OOP is just a tool to organize your code. Like function is a way to organize your code. When the whole program is 5 lines long, putting them in functions would be unnecessary complicate. Does one seeing that would conclude that function is unnecessary complicate in general?

gizmo6862• 14 years ago

My dislike of OOP is its emphasis on state. If you do foo.bar(), then you have changed the state of foo, even for other references to it. If you do foo=bar(foo), then the state of the original data is unchanged, while code below behaves the same way. In most cases, I find minimizing state minimizes bugs.

I do however like objects, and think that they can have a very good role in code.

ww5203• 14 years ago

There's nothing wrong with state. State is a fact of life in programming. Even pure functional program has states, which are the parameters passed among functions.

I guess you meant mutable state. You don't have to use mutable state with OOP - just create a class that allows state initialization in the constructors but nothing else, with none of the methods changing the states.

hcarvalhoalves• 14 years ago

The given example is pretty damn stupid though. I can't believe anyone is taking a factory to return a string seriously. The procedural example isn't a solution either (maybe if you're stuck in the 80's).

Any "given X return Y" is a mapping problem, thus all you need is a hashtable and associated map function. It can be implemented equally well in ANY paradigm.

stevoski• 14 years ago

I agree, especially as the example problem is "given String x return String y".

ianstallings• 14 years ago

Can I ask a serious question? Why is there an argument about this every other day on this forum? Do you guys honestly think that the language or paradigm you choose is the most important decision you can make? I'm of the belief that programmers are programmers. Procedural, OOP, or functional, doesn't matter. What matters is the ability of your team to understand and build solid software from it. Can the tool accomplish this? Good, then appreciate the fact that other tools can also do this. Is your hammer the best? Yes or No is an opinion. There can be other hammers. And people using them aren't idiots. A bad worker will screw up even with the best tools. And a good worker will create the best software with even the worst tools.

I just feel like this entire industry gets caught up in trivial matters. What language, what paradigm, what editor. Not that these aren't valid decisions that need to be made but these are problems I can solve in a few minutes or a few hours of thinking about it. The big problems I face are people problems. Miscommunication. Lack of accountability. Developers going rogue. Management not understanding. Users not being trained properly. I could go on and on and I may sound like a grumpy old man. But I just do not get it. Choose your platform and be okay with it. Understand there are others. We don't need one platform or paradigm to produce great things.

bad_user9• 14 years ago

This industry has a tendency to make a religion out certain tools and techniques ... IDE people don't ever think about the possibility of working with a simple, yet effective text editor. People that have been doing OOP for the last 10 years won't even look at functional programming techniques that have been know for decades, with firm theoretical underpinnings and still continue to produce hundreds of PeopleDaoFactoryFactoryImpl every day.

The biggest problem is that, as a developer, you simply cannot pick the right tool for the job, because you're not doing your own thing as a solo developer. You're always part of a team. Even when starting a business, you probably need a good cofounder or first employee - finding a smart and dedicated individual is hard enough, while also having preferences about the right tools and techniques is a bitch.

So naturally there is a backlash ... some of us hate IDEs, some of us hate the noun-centric and problematic designs that we see in large Java applications, some of us are aware that there's a multi-processing revolution coming and that mutable state does not scale, etc. And if you work in a team that gets things done, you're really lucky and blessed.

But how can we avoid getting stuck in the status quo, other than expressing our educated opinions on it?

And btw, I actually love OOP, but as a tool, not as a way of thinking about the problems I have.

ditonal• 14 years ago

I find it amazing you talk about mindsets that keep us in the status quo, and then you disparage IDE users and write a post full of hacker news groupthink regurgitation. I've noticed the type of person who hate IDEs tend to fall much more into the religious and close-minded crowd than those who don't. Most people I know who use IDEs are perfectly competent at an editor like emacs/vim and simply prefer different tools, but that doesn't stop many people who prefer text editors from trying to feel superior by stereotyping IDE users as paint-by-number morons incapable of embracing the beauty of the command line. It's a traditionalist and condescending attitude that I think is holding us in the status quo more than something like OO's popularity, because there are all sorts of cool programming language ideas you can come up with if you're willing to sacrifice the source code being easily edited by a text editor. Yet we see far less experimentation there then we do with functional programming languages, and I think that's because functional languages are perceived as cool and smart but IDEs are associated with the philistine class of programmers.

Uhhrrr• 14 years ago

To be sure, it is all bits and most languages are capable of rearranging them as needed. But paradigm is important. If you start every solution by asking 'What classes am I going to write?', your ratio of typing to functionality is not going to be very good.

DigitalJack• 14 years ago

Having to do things you find abrasive becomes extremely painful when you must do them day in and day out for your living.

Try running a marathon with sandpaper in your socks. These things matter.

ww5203• 14 years ago

Then don't do it. Pick the tools you like and proficient in and go wild with them. But please don't preach it day in day out on how horrible it is to the rest of us. This is what is happening here. We actually found OOP very useful.

pfraze• 14 years ago

I think it's because the different platforms are incompatible, and a large compatible community of software is a value multiplier (both in terms of the longevity and the usability of your code). You want people on your platform. Similarly, it takes time and energy to master a new methodology, and that's time/energy not spent if other people work the way you do.

That, and ego.

jimbokun• 14 years ago

For developers, tool problems are people problems.

Can I get quick answers to questions about this language? Are there plugins for this IDE for the kinds of programs we write? Are there mature, well documented libraries for our problem domain?

For languages, especially, the culture around the language is probably more important than the language itself.

So arguments about tool sets are indirectly judgments on entire programming cultures, and humans are pretty passionate and defensive when they feel like their cultural values are under attack.

rizzom5000• 14 years ago

I completely agree with everything said, but I also think that conversations about languages and paradigms are worth having.

Yes, it's true that you can solve the decision on what language or paradigm to use in a few minutes or hours, but your options are not only limited to those that you understand, but are limited by the depth of your understanding.

A lot of the time the decision is likely nothing more than personal preference, but if there is a chance that one paradigm will work better for solving some problem or class of problems; I'm interested in hearing about it

pcote• 14 years ago

Arguing (or watching people argue) trivial matters gives my brain a break from the serious things I would otherwise be working on. That's probably what drives most people into these discussions and onto their soap boxes too. It's a lot more fun than trying to figure out why my app can't find that damn configuration file.

bcoates2• 14 years ago

The big problem with the ppoop paper isn't that OO is bad, it's that it confuses OO vs Procedural with YAGNI vs Extensibility. (also, both the "hacker" and "OO" solutions are lame as OP points out)

If you actually have a reason to believe you need a gold-plated general-case OS identification system then throwing all those patterns at it is no worse than the nested-if spaghetti procedural code that would be the naieve procedural solution.

But in both cases it's just a stupid answer to a stupid question ("How do I overengineer a string->string table lookup?")

ajross• 14 years ago

You're dressing up the scotsman here (the tell being "it confuses OO ..."), and I think completely missing the point of the paper.

Obviously truly complicated systems will need complicated solutions, and OO has some not-completely-insane things to say about solutions like that.

But the real world doesn't see things like that very often. Real world programming is made up of thousands of tiny problems not altogether unlike the hack shown here. And real-world OO nuts, faced with these real-world problems, tend to solve them badly.

So sure, "How do I overengineer a table lookup" is a dumb question, but that's not the question posed. The question is "How do I avoid overengineering a table lookup", and the answer is "avoid OO".

bcoates2• 14 years ago

But the right answer isn't "avoid OO", at least not any more than the answer is "avoid if statements". The answer is to use the library function your language already provides to solve the problem in front of you and get on with your life. This is something applicable to any paradigm or language.

DanielBMarkham• 14 years ago

I had a good chuckle at the end of the referenced material

"The object-oriented programmers see the nature of computation as a swarm of interacting agents that provide services for other objects. Further, the sophisticated OO programmer lets the system take care of all polymorphic tasks possible. This programmer sees the essence of object oriented programming as the naive object-oriented programmer may not."

Hey Dan! What wrong with the program?

Sorry, my swarm of interacting agents had a polymorphic pile-up on aisle 7. Dangling pointers everywhere. It's not pretty.

Snarky jokes about buzzword soup aside, I love OO. We simply need to be aware that OO lets us "play" at building complicated things when 1000x simpler solutions may be available. OO works best for large-scale, lots-of-people projects. A lot of business projects are like that. Many personal and startup projects are not. The trick in loving any particular tool in the toolbox is knowing when not to use it. So the example is a little bit unfair -- it's tough to create a real-world example program of sufficient complexity to use in OO examples. All the examples look like architecture astronauttery.

ljoshua• 14 years ago

  OO works best for large-scale, lots-of-people projects. ... The trick in loving any particular tool in the toolbox is knowing when not to use it.

Very well put, mirrors my feelings.

genuine• 14 years ago

"OO works best for large-scale, lots-of-people projects."

Nice! But, I think it is the other way around. Throw a lot of people at something with some software architects and you'll probably have a large-scale, lots-of-people, "OO" project.

I worked at a company that was between small and mid size and had ~150 developers. We bought another company that basically did the same with 10x fewer, and that group won out over ours. We had some excellent developers that went on to other excellent shops, and I was proud of the work that we did there and learned a lot about process. It was the best run development team I ever worked for and probably ever will.

I was an "OO" developer, now I'm just a developer. Not because of that learning experience, but because I found Ruby and I no longer see the benefit in intentionally writing overly large applications. Ruby is truely more OO than Java, imo, but I don't write like I used to which I think is what is being called "OO" (lots of packages and interfaces, pattern usage, lots of maven projects).

commentzorro• 14 years ago

Gotta agree with Rob Pike here on this. The path to salvation comes through simplicity not though complexity. Austerity is the way forward. Making do with less is more.

olaf• 14 years ago

I think, OOP-polymorphism added some value to programming languages, people who criticise OOP (and not its more or less useful application), have mostly not understood it. One can use it where it's useful, elsewhere one can use better techniques.

robomartin14• 14 years ago

C'mon kids. Not again.

Tools in your toolbox. Use them as you wish based on whatever criteria fits the moment and the project.

I made hundreds of thousands of dollars with a program I wrote in 8051 assembler. To be fair, it was part of a larger hardware solution. Still, the UI portion of the code was all assembly language.

It wasn't until well after the product was in the market and selling very well that I converted it to C. I did so mainly to make it easier to maintain and expand.

Could this have benefited from OO? Who cares?

To add insult to injury, the workstation portion of the solution was written in --sit down-- Visual Basic! Yeah! VB. Did it matter that it wasn't Visual C++? Nope. Was it ever converted to VC++. Are you friggin kidding me? Nope. It was making plenty of money as it was.

Plenty of other projects were done using other languages, such as APL, Forth, Lisp and, yes, C++.

My point is that none of this really matters. People have gone to the moon without OO. Whole banking systems have been run without OO. OO has its place. And, when applied correctly, it can be a lot of fun to work with.

Digging through one of the links in the posted article there's an article that suggests new programmers should be taught Python without the OO stuff. What? Crazy.

Every new programmer needs to start with C. In fact, I am convinced that every new programmer needs to start with C and be tasked with writing an RTOS on a small memory-limited 8 bit processor. And then write several applications that run within that RTOS.

Then give them a budget of n clock cycles and m memory bytes and have them create a solution for a particular problem that barely fits within these constraints.

I would then expose them to Forth and ask that the re-write the same RTOS and applications.

Then I'd move them up to Lisp.

From there move into one of the OO languages. My first OO language was C++, but I suppose today I might opt to teach someone Java or something like that. Definitely not Objective-C. Keep it simple.

The above progression will expose a new programmer to tons of really valuable ideas and approaches to solving problems.

Then I'd get serious and ask them to write something like a genetic solver on a workstation in all of these languages and optimize each solution for absolute top performance (generations per second) first and absolute minimal memory footprint as second batch. Lots of invaluable lessons in that exercise.

Now you have a programmer that can identify which technology to use under what circumstance and for what reason. This is a programmer who knows how to get a 100x or 1000x performance gain out of a piece of code or how to get something done 10x faster at the expense of raw performance. Here's a programmer who understands exactly what is happening behind the code.

And, in the end the most important thing still is data representation. You can make a program 100 times harder to write if you choose the wrong representation for the problem being solved. Just like the first article points out: search a small table and the "hacker" solution is almost trivial.

bad_user9• 14 years ago

You're arguing against what exactly? Rob Pike's opinion is consistent to what you've said. The long comment implies that you do care.

robomartin14• 14 years ago

Arguing against continuing to have these pointless discussions on HN every 57.3 days.

Of course I care. It's what I do. I just don't see a point in people getting lost in language, editor, IDE --whatever-- discussions. They just don't matter. One can write absolutely-brilliant or absolutely-shit code using any tool one might care to name.

gilgoomesh• 14 years ago

I would argue that Rob Pike is casting bigoted accusations at "OO zealots" (whoever they are).

He says:

OO zealots are afraid of data. They prefer statements or constructors to initialized tables. They won't write table-driven tests.

Who the fuck is Rob Pike talking about? The article he links at the top does not touch on these points. He's created a straw man and is attacking it.

I think Grandpa Rob is getting sick of all the kids on his lawn.

Tyrant5052• 14 years ago

Jeez, can you be my woz?

robomartin14• 14 years ago

Sure, are you my Steve?

dxbydt• 14 years ago

User1: Lets talk about OOP vs FP

User2: I made hundreds of thousands of dollars with assembler

User1: umm...

User2: Then I made hundreds of thousands of dollars with VB

User1: umm...

User2: Then I made hundreds of thousands of dollars with C

User1: umm...

User2: Then I made hundreds of thousands of dollars with VC++

User1: umm...

User2: Then I made hundreds of thousands of dollars with APL

User1: umm...

User2: Then I made hundreds of thousands of dollars with Forth

User1: umm...

User2: Then I made hundreds of thousands of dollars with Lisp

User1: umm...

User2: Then I made hundreds of thousands of dollars with Python

User1: umm...

User2: Then I made hundreds of thousands of dollars with RTOS

User1: Does HN stand for Hacker-News or Hundreds-Of-Thousands-Of-Dollars-News ?

User2: umm...

pretoriusB3• 14 years ago

Jealous much?

Because you keep playing the "100s of 1000s of dollars" tune, oblivious to the fact that he only talks about making said amount with his assembler program.

He doesn't write that rewriting it in C made him 100s of 1000s of dollars -- just that he rewrote it to be easier to maintain. And VB was just the front-end for said project.

Plus, all the rest as mentioned as tools, without mentioning money at all ("plenty of other projects where made in APL, Forth, Lisp" etc).

Then you go on to miss the rest 70% of his comment, which isn't about money at all, but discusses a rather "hardcore", old-school way of teaching programming.

jwdunne• 14 years ago

Why is this comment ranking above the much more insightful and beneficial thread started by malandrew? It's partly a question of how HN works but I assumed comments with the highest karma filter up to the top? If that's true, I must also question the community: why has this received so many votes?

It only serves to make robomartin look like an idiot by maki g fun of him. He is most definitely not an idiot and this commenter makes it clear that they haven't read the entire comment.

I have a lot to take away from his comment and from the thread I mentioned. I'm sure there are a few here who will also have big take aways. It's content and comments like these that make me love HN. The negativity from the commenter can spiral out of control and fatally harm a community if endorsed. I've seen it happen before to another community I deeply loved and it pains me to be reminded of such negativity.

dysoco• 14 years ago

May I ask what software did you write ? Just out of curiosity.

robomartin14• 14 years ago

I am not inclined to discuss this publicly but would be more than happy to follow-up privately with details.

mitchi2• 14 years ago

Tools in your toolbox. Yea why not. I've always been an OOP composition-only guy. It was always the model that made the most sense to me. It's efficient and clear. I'm amused that just now people are coming out and saying that this is the best model. On the other hand, I've had a project once where I needed to apply a different function to different objects. No need for function pointers with polymorphism, much much easier so I used that. I'm still against templates to this day, although I use some parts of the STL sometimes when I'm lazy ^^

evincarofautumn2• 14 years ago

I’m curious to know: what problems do you perceive with templates that make you loath to use them?

tailrecursion• 14 years ago

Part of the reason it comes up frequently is that a large number of educated, experienced programmers have decided that a toolbox without OOP is a better toolbox, than a toolbox with OOP.

But, it is difficult to throw out a bad tool when there appears to be no alternative that delivers its benefits. When that happens, when a tool is devised that delivers what OOP delivers without the problems -- such as the diamond problem, or the problem of having to decide "where" to put functions, or the problem of generic functions of more than one argument -- then at that time those very problems will become much easier for everyone to acknowledge.

The same thing will happen to classes and synchronous message passing, that happened to inheritance. In that case it took a while but an alternative came in the form of interface subtyping or predicate based subtyping, and then it was easy to see that inheritance was more trouble than it was worth.

robomartin14• 14 years ago

My approach is a bit different probably because I've done a lot of work across a range of disciplines while using different tools. I have yet to run into a problem that was unsolvable due to the tools or language selection made. I don't think the tools or languages have ever caused undue delays, bugs or unreliability in any projects I've had part on. From robotics and low-level real-time embedded to image processing, DBMS and even hardware development (Verilog, VHDL). Not once have the tools and languages been brought up as an issue.

In my experience most problems come from bad design, bad programmers, terrible data representation, incomplete specs, bad management and a myriad of other issues.

Don't get me wrong, I am first in line for a good-solid discussion on how to properly split a bit in two. However, when it comes to the business of making money by creating products that involve some kind of software, well, pick a tool based on experience and focus on delivering a solid product. No excuses.

malandrew• 14 years ago

Can you give links and resources to support accomplishing the "CS curriculum" you suggested?

  Every new programmer needs to start with C. In fact, I am convinced that every new
  programmer needs to start with C and be tasked with writing an RTOS on a small 
  memory-limited 8 bit processor. And then write several applications that run within
  that RTOS.

Besides K&R, which resources will help someone accomplish such a task?

  Then give them a budget of n clock cycles and m memory bytes and have them create a 
  solution for a particular problem that barely fits within these constraints.

ditto

  I would then expose them to Forth and ask that the re-write the same RTOS and 
  applications.

what forth resource are worth learning from? why forth?

  Then I'd move them up to Lisp.

what lisp resources?

  From there move into one of the OO languages. My first OO language was C++, but I 
  suppose today I might opt to teach someone Java or something like that. Definitely 
  not Objective-C. Keep it simple.

robomartin14• 14 years ago

> Can you give links and resources to support accomplishing the "CS curriculum" you suggested?

I'd have to Google it just as you would. Here a few points.

C - Well grab a copy of K&R

Microcontroller: Get over to SiliconLabs (http://www.silabs.com) and grab a development board for something like their C8051C020 along with the free tools. Or you could buy a Keil compiler. Study their sample code in depth.

Lots to learn here: configuring the processor, i/o ports, interrupts, timers, counters, clock frequency, serial I/O ports, etc. Make an LED blink. Then make it blink when you press a button. Output an 8 bit counter to a bank of eight LEDs. Have the LEDs count up and down in binary. Have the LEDs scan left-right-left. Figure out how to read a potentiometer with the A/D. Use the potentiometer to control an output that runs an RC servo. Get creative. Have fun. Google is your friend.

RTOS. Get over to Amazon and get yourself a copy of "MicroC OS II". Once you are done with that book --and fully understand it-- you'll find yourself flying at a different level.

Forth: It's been a while since I've used Forth. "Thinking Forth" used to be a go-to resource. I would imagine it is still of value. Not sure what Forth compilers are available for free today. Google it.

Go over to Amazon and get yourself a copy of "Threaded Interpretive Languages". Either learn a little assembler or use C and the aforementioned microprocessor board to bootstrap your own Forth on the C8051C020. You might want to find yourself a copy of "Embedded Controller Forth For The 8051"

Lisp: http://www.cs.cmu.edu/~dst/LispBook/

I actually learned Lisp while having to customize AutoCAD. They called their flavor of Lisp "AutoLisp". It was a really neat way to learn it because you were dealing with complex graphic entities from the start and Lisp was excellent at manipulating them.

Not sure what the current favorite Lisp implementations might be for different platforms. Google it.

OO Programming: Get a copy of Java and one of the many excellent tutorials out there. Go to Amazon for a copy of "Design Patterns: Elements of Reusable Object-Oriented Software". Read it cover to cover. Five times. While you are at it, get a copy of "Code Complete".

I know this is expensive, but, in general terms, surround yourself with multiple books covering the various subjects. I never buy just one book. I might buy five to ten books covering the subject from different angles. Sometimes you don't necessarily read them cover to cover, but you use them for reference as you move forward. The 'net doesn't always get you there. Searching for solutions on SO does not necessarily teach you what you need to know in order to understand how you got there. Someone can show you the code you need to write an Objective-C class that complies with a Protocol, but, do you really understand the five why's and how's?

For example, if I need to code an FIR (Finite Impulse Response) filter using a new language or on a new platform I can usually do reasonably well hunting for code examples on the 'net. The important part here is that I already know what an FIR filter is and how it is supposed to work. I have implemented them from scratch in anything from hardware to DSP's. So, scouring the 'net for code snippets really becomes a way to help me discover how to express these ideas in this new language rather than me trying to both learn the language and about FIR filters at the same time. Hopefully that makes sense.

I'd much rather hire a programmer that has depth of knowledge in algorithms, patterns and the general subject matter we might be working on (say, as an example, inertial control systems) and tells me that he or she is not fully versed in the language that we have to work with than one who knows the language in his/her sleep but lacks the depth. You can google the language. You can't google the other stuff.

Sorry, this isn't a complete answer. I'd say, above all, as you learn you really have to feed your curiosity with projects you are interested in. If writing a solution for banking doesn't get you excited it is likely that you are not going to be inspired to learn anything new while forced to write that code. If, however, figuring out how to make a robot walk inspires your curiosity, you'll find yourself coding for sixteen hours at a time trying hard to solve problems and learn as you go.

daniel-cussen• 14 years ago

Funny, my three favorite languages are Forth, C and Lisp. Three beautiful, awesome languages.

arethuza• 14 years ago

I have a slight variation on that as my favourites - PostScript, C and Lisp.

robomartin14• 14 years ago

In school I was in love with APL. I got a chance to drop Fortran and sub it with an APL class (which my Physics prof insisted I take) and it was absolutely fantastic. What an eye opener! It kind of screws you up because --as an early stage programmer-- you can easily look at other languages and start thinking that everything else really sucks. Of course, that's not the case.

My list matches yours in probably a slightly different order. I love C because it can be very low level and also allow you to write high level code efficiently. I have written code for countless embedded projects with C as well as used it to optimize computationally intensive portions of iOS applications (where Objective-C would make things 1000x slower).

Forth? I've mostly done robotics with Forth. Wow. What a language. It's a really amazing feeling --if you ever get the chance to do it-- to bootstrap an embedded system using Forth. A little assembly and very soon you are off and running. Write you own screen editor, etc. I had a chance to do that once. It was a blast. There's nothing like writing your own disk controllers and other driver software. Forth makes it possible without a huge amount of pain. Neat.

My list would be: C, Forth, Lisp, APL.

Funny, no OO languages there. OK, I'll add Java.

eternalban2• 14 years ago

> People have gone to the moon without OO.

Let's see:

   - People who went to moon: top 1%
   - People who made the "vessel": top 1%
   - People who wrote the code: top 1%
   - The process of the development: Exacting
   - The funding available: Lavish

   ...

robomartin14• 14 years ago

...for everything else, there's Mastercard.

coliveira3• 14 years ago

Rob Pike is very smart guy, but he works in relative isolation from other programmers. He usually creates his own tools and works with people that are like minded. That is why he thinks it is so easy to just go directly to the code and achieve what he wants writing the right function to solve the right problem.

OO was created to deal with the general issue of organizing lots of code around a reasonable design. It is a tool for industrial level programming, where there are thousands of programmers, many of them with bellow average skills, contributing to a single codebase. In that aspect I think OO has been very successful, because it provides a framework to simplify design decisions.

dsymonds3• 14 years ago

Uh, no. Rob works with a number of other programmers on code that is directly used by thousands of other programmers.

shadowmint• 14 years ago

Does he really?

I was under the impression he worked in a relatively small team working on code thats used by lots and lots of people, but only written by a few people.

The OP's point is that when you have people you dont trust working on your code (and does he really?) there need to be controls somewhere to keep everything from getting screwed up.

OO is one way of doing that; a good set of unit tests + CI is another.

lazyjones• 14 years ago

I would be very proud - and I suggest most people should be - if I had written so many complete, useful and novel tools for myself (and others). It shows great proficiency and understanding of how to get things done. Which is arguably the most important skill a programmer can have (read Linus' C++ rant too ...).

Personally I think - and that mindset was to a significant part shaped at University where this was a bit of a running gag in the 90's because the notion was actually taught - that OO was simply an attempt at getting people who have a more dominant right half of brain ("less intelligent people" if you forgive the conclusion) to structure their code better, because for some reason working with OO patterns and methods supposedly appeals to that half more.

In other words, OO was inflicted upon us to get dumb people to write code too. Yes, it's offensive, but ... make your own observations.

qznc2• 14 years ago

Reminds me of Linus Torvalds. He works on top of a kernel he has (initially) written himself, using a VCS he has (initially) written himself, and using an ancient heavily-customized editor [0,1]. Somehow his tools are more successful than Pike's. However, I doubt we could convince Torvalds to create a programming language.

[0] https://plus.google.com/+LinusTorvalds/posts/iySKQGtkmtb [1] http://git.kernel.org/?p=editors/uemacs/uemacs.git;a=summary

marshray• 14 years ago

The format of the ppoop article is sufficiently similar that I thought it might be a riff on the classic "The Evolution of a Haskell Programmer" http://www.willamette.edu/~fruehr/haskell/evolution.html (itself derived from a similar work).

ufo• 14 years ago

> Every if and every switch should be viewed as a lost opportunity for dynamic polymorphism.

The truly sad thing about OOP is people not embracing the duality between if-statement dispatching (pattern matching) and oop-style dynamic dispatching.

In situations where you have a fixed set of types its better to use switch statements and even in other cases, sometimes its better to still use if statements to avoid scatering your code all over the place (specially if you compiler warns you if you forget to handle on of the cases when updating things)

http://www.c2.com/cgi/wiki?ExpressionProblem

Peaker3• 14 years ago

if-statement dispatching is not pattern matching.

Pattern matching yields more type information than if statements and can match recursively on multiple arguments (which even multi-method dynamic dispatch cannot). However, it always dispatches on a closed sum type, whereas OOP-style dynamic dispatch is on an open sum type, so the mechanisms are useful in different circumstances.

colomon• 14 years ago

Can you expand on this difference?

michaelfeathers• 14 years ago

As a guy who does a fair bit of reading and teaching, I can only sympathize for the writer of the paper Rob is criticizing.

When you come up with examples you have to deal with two conflicting forces. One one hand, they have to be simple enough not be skipped over. On the other hand, they have to be complex enough to seem real. The balance is never right. It doesn't seem fair to criticize on that account. It's too easy.

georgeecollins• 14 years ago

I don't want to argue with anybody-- whatever you think is the right way to program is fine with me but..

The article he pointed to was really funny. I think I worked with guys like that who were so over the moon about OO that they made everything an object, encapsulated a bunch of objects inside an object with no polymorphism. No advantage that I could see except that it became a habit to make everything an object.

Objects did a lot to advance programming and they still can be very useful. Like many people have said here already: use the tool that is appropriate, keep an open find.

But that is a funny code example.

frustratedOOP• 14 years ago

Why is it OK to criticize OOP using non-pure OO languages like Java, C#, or C++? Pure functional nut cases like Don Stewart and Simon Payton-Jones (whose favorite pet example of a dangerous side effect is a nuclear holocaust) don't have to defend FP from critics whose only experience with FP comes from non-pure functional languages like Python, JavaScript, and now Java and C++. Yet here we are again, with another under-informed, overly-prominent person publicly airing his grievances with Java as if all OO languages bear some collective guilt for them.

Smalltalk is not a hard language to learn. Haskell is far, far more complicated. You can download Squeak/Pharo/whatever and learn the language in a few hours. Why in 2012 is Java still such a potent argument against the entire paradigm of OOP, both class-based and prototype-based? Why does OOP alone have to put up with this sort of scurrilous, intellectually lazy and dishonest propaganda against it?

emp• 14 years ago

I agree fully - reading through these comments is frustrating, as the languages mentioned can hardly be called Object Oriented. Learning Smalltalk is something everyone who really wants to understand OOP should do. C++, Java and the like really should be called Class Oriented languages, as demonstrated by the often very deep class hierarchies. It's not about the classes, it's about the communication between objects. Objective-C is far closer to Smalltalk than most of the languages mentioned in these comments.

The downside to learning Smalltalk - the realization that a 30 year old environment is more advanced than whatever modern tools you will need to return to to earn a living.

nsxwolf• 14 years ago

There's nothing ridiculous about the OO pattern in the article Pike is talking about.

When you're trying to demonstrate OO concepts, OO has a disadvantage because it is needlessly complicated for the simple example you're trying to illustrate. The hacker approach is always going to look more sensible than the OO approach.

Once you get into very large enterprise systems the a-ha OO moments really start to pile up.

frozenport2• 14 years ago

OOP's unique feaures can't deal with massively parallel CPUs. In the future the following will not be allowed:

The following are not allowed for the core data in your code.

    Recursion.

    Variables declared with the volatile keyword.

    Virtual functions.

    Pointers to functions.

    Pointers to member functions.

    Pointers in structures.

    Pointers to pointers.

    goto statements.

    Labeled statements.

    try , catch, or throw statements.

    Global variables.

    Static variables. Use tile_static Keyword instead.

    dynamic_cast casts.

    The typeid operator.

    asm declarations.

    Varargs.

http://msdn.microsoft.com/en-us/library/hh388953.aspx

OOP may live at the top level of granularity, but when it does for working with your data, OOP is not compatible. You can choose which module to run with polymorphism, but you data can't be be processed with virtual functions.

wladimir2• 14 years ago

With "in the future" you mean "currently, in a restricted subset of C that runs on massive numbers of very simple cores". Massive parallelism is also possible with somewhat less simple cores; CUDA and OpenCL also started from the "bare subset" philosophy but gradually expanded to allow more flexibility because developers demand it.

And of course massive parallelism is also possible with normal CPUs, in a cluster or in the cloud, and there an entirely different set of restrictions hold, not so much on the programming language but on higher level design.

Whether or not you need to restrict yourself to a subset of C completely depends on your requirements. The future is heterogenous, not homogenous [1].

1. http://herbsutter.com/welcome-to-the-jungle/

frozenport2• 14 years ago

Notice that C++AMP is a language extension designed specifically for heterogeneous computing, and it is where this list comes from.

The article you posted was rather extensive and as somebody who works in HPC, I can say that I disagree with many points in link provided. Also it was too god damn long to read. Most notably, that somebody needs to actually write the cloud implementation, will still require models like OpenACC or CUDA.

There is not reason hat whatever mechanism was used to push parallelism onto the GPU can't be used for moving it onto the cloud.

There is an infinite amount of musing that can be made against and possibly in favor of expanding the acceptable language features in threading kernels. Yet, it is safe to say 3 things.

1) Simple kernels run faster 2) Current specifications are closer to C++AMP's restrict(amp) 3) Cloud computing uses GPUs for the data crunching

aufreak3• 14 years ago

OOP vs FP is better seen, I think, as a duality rather than as a dichotomy. Sort of like wave-particle duality. Sometimes you find it convenient to think "wave", and at other times "particle", but the reality of the system is neither. These are just convenient and equivalent constructs we use.

Some other such dualities are - code vs data, data structures vs algorithms, closures vs objects. Enlightenment lies in seeing the false nature of these dualities. (Now, say "Om" people :)

For another fun view on data structures, checkout the "numerical representations" chapter of Chris Okasaki's "Purely functional data structures" [1] where he draws parallels between number representations and data structures, which I found fascinating.

[1] http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

hackinthebochs• 14 years ago

Probably the most insightful comment on this thread. Well put.

oboizt• 14 years ago

I'm glad for OOP. I'm also glad for functional features in the "cool" languages. Thank you, Scala, for combining the best of both worlds. :)

bsaul• 14 years ago

Rob pike is doing system and middleware design, where concepts are not very numerous and often purely technic-centric.

Oop is made for business and real-world modeling, where the first part of the job is to find a good definition/representation of the concepts you're talking about. When you're talking about a banking system, you really don't care if the underlying memory representation of credit card properties will be a hash dictionary or a struct. Your first concern is to clearly define what it is using the correct words. So that you'll etablish a clear mapping of real-world concepts into programming structures.

When rob pike talks about data, he only sees memory and related algorithmic structure. Because on its field, it really is the only things that matter. The fact that sometimes correct naming and proper conceptual representation is the most important only speaks to someone that does business or real world modeling.

tsahyt• 14 years ago

After reading the article referred to by this, I just had to do this. You know that urge ;)

		def osdiscriminator(string):
			good  = "This is a UNIX box and therefore good"
			bad   = "This is a Windows box and therefore bad"
			unkn  = "This is not a box"
			boxes = {"Linux"      : good,
				 "SunOS"      : good,
				 "Windows NT" : bad,
				 "Windows 95" : bad}

			if string in boxes:
				return boxes[string]
			else:
				return unkn

Easy to extend, simple and therefore maintainable without any inheritance or GoF design patterns. Oh, and about one minute of work.

Edit for formatting

qznc2• 14 years ago

A little trick to spare throw more lines:

    return boxes.get(string, unkn)

Rob Pike on Object Oriented programming

Related Stories