If you're a software developer who doesn't live in the stone age, you're going to find yourself doubled over with laughter on reading this ridiculous article written by a machine-code troglodyte "enthusiast" named Richard Mansfield. Object-oriented programming may not be the final word on software development, but the ideas pushed by this guy are so inane as to be grounds for questioning whether he's ever had any actual experience of modern software development on a large scale: who wants to have to know the implementation details of third-party libraries, and how can any thinking person believe that "cut and paste" constitutes a viable technique for code reuse? Yet Mr. Mansfield's rant is littered with such braindead notions.
The really funny thing about people like Richard Mansfield who think procedural programming constitutes the last word on software development is that with C++, Java and C#, it's actually pretty easy to program in a purely procedural style while pretending to be doing OOP: just write one big class, sign all your methods as static, and dump all the logic of your code into the main() function as if you were working with good ole C. Object-oriented programming isn't the problem, OOP languages which allow hidebound programmers to ignore the whole notion of objects are - too many so-called "developers" fail entirely to grasp the benefits of concepts like polymorphism, encapsulation and inheritance at a gut level, and as for design patterns, it's amazing the number of programmers who display an ignorance of something as simple and ubiquitous as the singleton, let alone an abstract factory or a decorator. Mansfield's rant is nothing but a rehash of "Real Programmers Don't Use Pascal" for the 21st century, without any of the self-aware humor of the original.
I suggest that everybody use Objective C as some stage where such concepts are basically built-in.
In terms of procedural programming, by the way, the fact is that most methods are written pretty much like a C function anyway with the same procedural logic. At the design stage, and conceptuallu OO is radically different, in implemetaion of logic you are back to procedural programming ( so C should be taught before C++).
I knew of a guy who was asked to program an version of atoi at an interview, he demurred as he said he was an OO programmer.
They then suggested he wrap it in a class as a static function.
Posted by: eoin | September 24, 2005 at 01:26 PM
"I suggest that everybody use Objective C as some stage where such concepts are basically built-in."
Even better would be for people to start off by learning languages like Smalltalk and Ruby in which *everything* is an object. Once one's mind is set in the procedural way of doing things, it can be pretty difficult to kick the habit.
"In terms of procedural programming, by the way, the fact is that most methods are written pretty much like a C function anyway with the same procedural logic."
Numerical algorithms may necessarily need that approach - a radix sort is a radix sort, a matrix multiply is what it is - but in general I find that OOP principles inevitably impact one's programming style even down to the implementation details of methods. For example, to take advantage of polymorphism, one can make method calls to an interface rather than the classes which implement it - emulating this functionality in a procedural style would be a real headache of function pointers and other nastiness. Heck, even numerical algorithms benefit from templating and generics* - just look at the STL.
"I knew of a guy who was asked to program an version of atoi at an interview, he demurred as he said he was an OO programmer.
They then suggested he wrap it in a class as a static function."
Now there's a clown if ever I saw one - he probably just didn't know how to go about writing such a program, and latched on to any excuse to avoid being pressed on it. Still, I can't say I'd entirely blame him in most contexts for not knowing such stuff, as one of the touted advantages of abstraction, encapsulation, etc, is that they enable code-reuse and thereby reduce the need to reimplement the wheel over and over again, and atoi is a standard part of any libc implementation. Then again, your previous comment about knowing IOKit inside and out suggests you guys get a lot closer to the metal than the average business or web-app jockey, so the guy ought to have been prepared for such queries before coming in for the interview.
*Admittedly, these aren't features of "traditional" Smalltalk-style OOP, though only OOP languages seem to be implementing them.
Posted by: Abiola Lapite | September 24, 2005 at 01:50 PM
"who wants to have to know the implementation details of third-party libraries"
Me, since any non-trivial piece of code has bugs in it (some more so than others), having the source to them is a very good thing.
Hmm while Mansfield attacks OOP from the 'oldschool' mentality of 'it doesn't work', OOP is also indirectly attacked from above by the trend nowadays for academic language design to be focused on functional models rather than OOP ones. Although it should be noted that OO usually gets added to lanaguages after they have been in the wild for some time, ie. as was the case with O'Haskell, and Ocaml.
Posted by: Factory | September 24, 2005 at 02:54 PM
"Me, since any non-trivial piece of code has bugs in it (some more so than others), having the source to them is a very good thing."
Having the source to code so you can examine it for bugs, and *needing* to know the implementation details just to use it, aren't at all the same thing. As a Gentoo user, I have the source code to Linux and every GNU tool I've ever used available to me on my machine, but I hardly *ever* have to look at them for any reason, unless I'm looking to learn a technique by emulation or something. I don't have the source code to Windows or the .NET Framework, and I do just fine programming to the APIs they expose - especially .NET, which is much nicer to work with than WIN32 or even the Java class libraries, thanks in large part to its elegant OOP-based design.
If the code you're relying on has been properly tested, especially unit-tested, then this whole "bug" issue really shouldn't be an issue anyway - as long as the software meets the contract implied by the API, I really don't have the time to care about anything else. It makes as much sense to expect programmers to understand the inner details of others' code as it would make for car or aircraft engineers to know the fine details of other components other than the ones they're working on - why throw away the advantages of specialization? If I find myself crippled by distrust of the quality of someone else's code, I'm usually better off just looking elsewhere altogether, rather than trying to pore through some crufty, almost incomprehensible codebase looking for obscure errors.
Posted by: Abiola Lapite | September 24, 2005 at 03:15 PM
"Still, I can't say I'd entirely blame him in most contexts for not knowing such stuff, as one of the touted advantages of abstraction, encapsulation, etc, is that they enable code-reuse and thereby reduce the need to reimplement the wheel over and over again, and atoi is a standard part of any libc implementation."
I agree for the most part. In going for interviews as a senior developer I still learned up on silly graduate level type questions ( which is faster a QuickSort or a BubbleSort, and why) even though I use whatever sort function supplied by the libraries, or OS and never ever had to care about sort functions.
In general I would think asking these kind of questions is of little interest: on the other hand atoi is a relatively simple function - and is just a programming challenge, regardless of whether it is in a library or not. Or course people can panic, so you help them along if stuck.
( For my own part I ask no senior engineers these questions as I generally have too many questions about their actual experience in specific areas. I have to assume they can code, I was talking about his lame excuse, really).
In the real world a guy who implemented myAtoi at work because he didn't trust the libc version should be fired: just as you suggested in you last comment it is not his job: it is like finding that the head chef has gone fishing as he is sure he can land a better fish than the suppliers, but meanwhile people are hungry. And this would be true even if here were a better fisherman, which is unlikely.
Posted by: eoin | September 24, 2005 at 07:34 PM
The weird thing about ruby is that now that I'm competent at it, I write much shallower class hierachies and rely a lot more on duck typing. And it feels so good!
I can't imagine why somebody would insist on procedural purity. A lot of modern c is written pseudo oopy, there's a chapter on it in the Practical Statecharts book. Why not just do c++?
I have to agree that somebody who cared more about my knowledge of the standard library's implementation then my knowledge of the various performance/complexity booby traps in e.g. the major network programming cults is not living in the real world. If somebody asked me to implement atoi, I'd consider that an efficient flag that the purpose of the interview was achieved, and answer was in the negative.
I feel the same way about Microsoftian puzzle interviews, though the host probably has a different opinion.
Posted by: Russell L. Carter | September 24, 2005 at 10:53 PM
Actually, I'm no fan of Microsoft-style trick questions myself, though I've met and solved my share of them. As far as assessing programming ability goes, I don't see how such questions could ever serve the intended purpose well: much better to have the interviewee walk one through a few hypothetical programming tasks, to see how he or she thinks.
Posted by: Abiola Lapite | September 25, 2005 at 12:14 AM
Some time back, a company I worked for decided to take a poorly-designed .NET application that depended heavily on a web service, and tried to improve its performance by getting rid of the web service (extracting functionality into the web service had served no real purpose, and the only reason the web service was included in the architecture because it was trendy).
They were going to inline the code from the web service into each of the calling functions - an operation that was estimated to take 2 programmers 3 months.
I suggested a class with static methods that replicated the web service's functionality instead of a system-wide copy and paste and I got praise from management for my "brilliant insight"...
Posted by: Robert | September 25, 2005 at 12:54 AM