

Unix and Object-Oriented Languages - nkurz
http://www.catb.org/~esr/writings/taoup/html/unix_and_oo.html

======
tedunangst
"For example, a+a+a+a can become a*4 and even a<<2 if a is an integer. But if
one creates a class with operators, there is nothing to indicate if they are
commutative, distributive, or associative. Since one isn't supposed to look
inside the object, it's not possible to know which of two equivalent
expressions is more efficient."

But it is ok (expected even?) to look inside the implementation of every
function in a non-OO language?

Explain how I am to know which to choose from the equivalent C code of add(a,
add(a, add(a, a))) or multiply(a, 4)?

There are reasons to dislike aspects of C++, but the "omg operators are hard"
meme is the biggest dumbest straw man around.

~~~
dasil003
The whole article has a whiff of bullshit even if it seems truthy at times.
Yes, OOP is a great fit for GUI programming which helped it rise to
prominence, however the rest of it is spoken like someone who has never really
done any serious OOP.

I think it's fair to say that OOP is not significantly different from
procedural programming, and certainly can't be considered universally better.
It just provides some additional tools for structuring the code and data,
however it doesn't offer any deep and powerful benefits like functional
programming or s-expressions provide.

------
dkarl
What's the clinical terminology for this? Projective collective delusional
narcissism? I'm a Unix programmer, and I disavow this rant. Reading this makes
me ashamed of every time I've thought and spoken this way. (At least I can
thank the author for providing that clarity.) Unix programmers rarely tackle
the kinds of problems that OO approaches are best and most necessary for. When
they do, they usually aren't acting as "Unix programmers" or "systems
programmers." I occasionally write performance-critical code that talks
directly to hardware, and I have written embedded code that runs on that
hardware as well. Of course I wrote lean code without layers of goopy
abstraction. But I don't walk around with my chest puffed out just because
I've written low-level non-OO code, because I've also written GUI applications
using Eclipse RCP, which is plugin-based Java abstraction-on-steroids that
makes architecture astronauts giddy. I would use Eclipse RCP again in a
heartbeat if I needed to produce another heavyweight, complex GUI application.
Looking down on somebody because the best way to do their job is not the best
way to do your job is stupid.

~~~
hvs
I would argue that he does point out that OO is good for certain types of
applications, specifically GUI applications. I do agree with you that the
application paradigm is often overly touted as the epitome of good design, but
that doesn't change the fact that the original design ideas behind Unix were
good ones. On the other hand, I would also argue that modern Unix software (at
least in the Linux world) rarely follows that paradigm. Most desktop
applications in Linux follow precisely the same methodology (and inherit its
flaws) as Windows applications. They are often big, bloated, and slow.

------
hvs
I hoping the resurgence of functional languages will drive this point home,
but I'm certainly not sure that it will. I've worked on large, well-designed
OO systems, and I've worked on awful, convoluted morasses. OO languages are a
tool, but they are no replacement for competent software engineers.
Conversely, I've worked on both types of systems written in imperative
languages as well (that's where we get the concept of "spaghetti code"). OO
just seems to make it easier to make a big mess.

------
TallGuyShort
>> [OOP] can backfire badly if coders end up doing simple things in complex
ways just because they can.

Very true. I'm taking several courses where the vast majority of students have
only been exposed to Java, where as I've come from a C background with
experience in several other languages. I'm shocked at how the other students
have no sense of efficiency or simplicity - everything has to be about making
other classes do the work, and it ends up being a horrible project.

~~~
javanix
I think the trouble with teaching mostly Java-only courses early on in CS
curricula is that it makes it difficult to catch the subtle middle ground
where OO actually makes code more readable/maintainable instead of more
bloated.

Granted, a lot of that comes from experience in OO languages, but I think
using C or another language helps people see that middle ground a lot easier.
It helps make it more obvious where OO would help and where it would just be
needless obfuscation.

