I think this can be summed up very easily. Bad programming is bad programming no matter the language or the technique used. VB has a bad rap because so many bad programmers coded in it. C had lots of good programmers in the beginning. Not use why in either case, but still true.
OO can be equally bad. A language or technique is neither good or bad. Bad use or implementation of them are however bad. Programmers should be aware of the strengths and weaknesses of each that they do. If they don’t then can they really call themselves programmers. I would say they are just coders. Programmers use the strengths from languages and techniques to reduce the weaknesses. If you don’t then you are just a coder pretending to be a programmer.
I just want to work with and for people who care about the long term aspects of their application.
And while those who care about quality, sometimes care so much, that no work gets done, or that’s not about how can we work smoothly together, but whatever they prefer.
I mean i am willing to adjust to their needs, why can’t that be mutual.
Interesting. One reads your post and is reminded of comments I’ve seen before about how one exceptional CuLISP programmer can run circles around a C++ or Java programmer in certain types of productivity, but he will be behind his fellows when it comes to maintenance.
The ‘Universe of Discourse’ blog you pointed to is also interesting. Every once in a while I think that there has been an ‘end of programming language evolution’ reached; I’ve been wondering whether tools for Java would eventually become so varied in their depth and usefulness that pre-generated and wizarded Java would just outrun the other options as far as productivity was concerned… One can point to the entire ‘AJAX as fast and easy as possible’ movement as an implementation that attempts to address problems and inefficiencies created by design flaws.
Java builders are getting continuously more effective… It remains to be seen whether there are big enough efficiencies available on a broad base of problems to warrant a revamp of such a large install and training base.
Unfortunately any tool is only is good as the individual(s) using it. Simple, clean, properly decoupled OOP with flat hierarchies does wonderful things.
Plenty of paradigms are inevitably abused so much in practice that they gain bad reputations. The one thing many coders would do well to be aware of is that every line of code should be part of a thought out whole. The real problem is as it has always been - programmers who spew out code at a relentless pace creating a nest of dependencies and bugs so thick as to die under their own weight.
In my career I have seen spaghetti and duplication of code and concepts in all of its ugliness in a dozen languages. It’s always the worst in the language that is popular at the moment. Mediocre coders write mediocre code and abuse/overuse elements put in place to help them. This was true in assembly, C and certainly C++/C#/Java. Currently some new languages are more exempt because performance limits the code spew that can be generated. As those language implementations get faster this problem will appear in spades there as well.
For most people constraints are good. We could drive at 120 mph on the highway but there is a speed limit to keep us from being reckless. Programmers should be rewarded for simplifying logic and extending functionality at the same time. There is a reason many software projects die under their own weight over time of self-strangulation.
Keep things as simple as possible and no simpler to fulfill requirements. If you’re spewing out code someday you might actually be forced to figure out what that code does. A well thought out less almost always beats a poorly thought out more.
Objects can be an incredibly powerful way to manage large-scale programs. Then again, objects are one reason programs get to be large scale: OOP code is bloated, especially in C++/Java/C#.
When I work in C#, I would kill for the ability to take a private variable and it’s public property wrapper and use a Lisp-style macro to make a one-line declaration out of the whole damn thing. I mean, jeez, how many times do you have to type the same old boilerplate public int Blah { get { return _blah; } set { _blah = value; } } ? Then there’s the endless stream of type declarations and casts – I mean, the functional languages like Haskell and Ocaml are smart enough to infer types, why can’t C-style languages do this?
JavaScript seems to be universally loathed for some reason, but the mixed object-functional idiom you can use pretty easily (and the dynamic typing) makes coding so much simpler. JavaScript code seems to take me less than half the lines and be more than twice as readable than C#.
Maybe for my next job I’ll switch to Python or Ruby – or maybe I’ll try to jump all the way to Haskell.
If I were to start a link blog, I think 90% of the links would be posts about how you should write your programs to solve the problem you are presented first and worry about proper design second. That doesn’t mean you should write hard to maintain code. Strictly OOP doesn’t necessarily equate to easy to maintain code. The other 10% would be links to Penny Arcade and Achewood comic strips.
I agree - OOP has to be used sparingly.
Good rule of thumb: new object oriented (non-static) class should be created only if developer sees clear advantage of OOP approach in this particular case over “static methods” approach.
OOP is very core to Frameworks, the .NET framework would be sloppy without it. OOP can be overkill but even the bad cases (one implementation of an interface) can be because the class needs to be remoted or shared for other purposes. Without OOP we’d still be coding VB MTS COM+, please god no…
There are benefits to calling code in certain ways as well. This is a test of .NET 2.0 calling methods based on MSDN sample from .NET 1.0.
Currently I am the other programmer having to maintain code and fix bugs, and it is hell.
Overkilled OO is a nightmare, as is function blocks of over 300 lines of code that calls other similar lengthed function blocks which only get called from this one spot (and they contain functionality repeated elsewhere).
Code should tell a story in an fairly easy way. All the names should be well thought through. The sentences and paragraphs should not be to long. Don’t repeat yourself. I repeat, don’t repeat yourself.
In coding terms, keep you functions short, your classes focussed, and if a class will be an overkill don’t write it.
I’ve been reading your blog for a while now. I quite enjoy tuning in every morning when I get to work and am sipping my coffee reading what you’ve written. However today I think that I have to disagree with you. OOP is great and I love it, when it’s used correctly. I’ve seen time and time again where as you mentioned “inheritance hierarchies to be brittle and unstable” When you tightly couple software like this you’re 100% right it becomes impossible to use. Impossible to refactor. Impossible to maintain or update without breaking 1 million other things in the code. It’s worth noting that this isn’t good OO. In addition to the principals you mentioned above OO, should be loosely coupled and each object should have a specific job. Even if you have tightly coupled Procedures in a Procedural driven language you’re going to run into the problem of not being able to update or refactor code, add or maintain.
Yes as a software engineer I had the idealogies of OO driven into my head in school. Yet the first language I learned was C. What they didn’t teach us in school was how to write good OO. OO that is loosely coupled and based on a core set of abstract interfaces that are well thought out to provide base functionality can be incredibly powerful. When you need aditional features making additional interfaces through almost a composition approach rather then an inheritance approach prevents you from falling into the trap of inhertiance brittleness. I find that in OO environments everyone wants to inherit inherit inherit. COMPOSITION is most often the best answer.
All that being said. OO is great but it’s not enough on it’s own, engineers need to be aware of Design patterns and other tools. OO is a design tool, not meant to stand entirely on it’s own but be used in conjection with other principals, which together produce solid well designed software. Where needed I’ve incorporated procedural C code into my OO code when I needed the speed trade of and the low levelness of pure C.
I don’t think it’s fair that you take a technology and bash its down sides because people don’t know how to use it correctly.
I forget where I read this now, but someone (it may have been pragmatic programmer) referred to bad OO code as spaghetti with meatballs. I have to agree with you (or of course, what I think you mean of course ) though;
It is applying the principals of OO which is important. In fact I think it is understanding and applying the principals that gives the most benefit in pretty much every methodology from OO to DRY to XP. Without understanding the principals it seems that people leap on the bandwagon and apply it to everything without thinking.
I think what I am trying to say is that too many programmers seem to buy the shiney new tools, whether a methodology or programming language, and think that they are the answer to all of their previous problems and then apply them to everything without thinking about whether it is the right tool for the job. I guess that it is done because it is easier in the short term.
ps. another long time reader, first time comment, I guess this topic gets people fired up :). Keep up the great posts!
Hey Brenda, what do you think your coding down iside those pesky objects? That’s right, procedural code. All OOP does is put what is at the bottom level, procedural code in a neat little isolated package and gives you a methodolgy for defining an iterface between them. I belive the first guy to come up with this idea was Nicholas Wirth with Modula…
) though;