Unix and Object-Oriented Languages | Hacker News Reader

Unix and Object-Oriented Languages

catb.org

9 pointsnkurz8 comments

"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.

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.

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.

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.

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.

>> [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.

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.

I think the whole Design Patterns thing is at fault here... People see a problem and try to figure out which DP to plug in, instead of thinking through the problem itself.

Design Patterns can be a good way to think about the problem, but shouldn't be a substitute for thinking either.

Reply on news.ycombinator.com