Language Patterns

I was researching the execution time difference between static and instance method calls today and came across an old Java forum thread about the topic. I was looking for performance information, but everyone in the thread was focusing on “good <abbr title=”object oriented>OO</a> practices”, and I was astonished as to what I was reading. Because of this thread I realized that many “patterns” are created as “good OO practices” because of a flaw or limitation in a language. Then that pattern is said to be correct and good and carried over to any language regardless of whether it has the original language flaw or not.

In this thread they were discussing how you should always use instantiated objects because you will never know what you might need to change the code for later. This threw up two flags in my head:

  1. Why do static methods/classes exist in Java if they aren’t advantages to use in certain situations.
  2. These people have obviously not looked at any dynamic languages like Ruby, Python, Perl, etc…

As for the second point, I will let them slide because the thread was from around 2005, and the dynamic languages were just starting to pick up steam. The first one I can let slide because I understand that even language engineers make mistakes, and could have possibly written a feature that isn’t necessary or good to use (e.g. goto).

But that still leaves me with the problem that this is a language issue not a good OO practice. Java does not allow you to change the behavior of a static method at runtime, or even override it at compile time, but in a language like Ruby you don’t have this limitation. Keep in mind in Ruby you have Class methods not Static methods, but it is basically the same idea. Furthermore you can override any method, class or instance, at runtime in Ruby.

This makes me wonder how many other “good OO practices” have been brought from old languages unnecessarily. I know when I first started writing ActionScript or even C# I fell prey to writing getter and setter methods. This is completely unnecessary but I am sure an experienced Java developer would try to convince you to do it as a good practice. I would imagine even if you convinced him that [insert language here] has the notion of formal properties they would attempt to convince you to do it to make the code more readable, but it is what you would expect to happen.

This really bothers me because if this were the mindset of the original language developers we would probably never have a for loop because a while loop works just fine. That may be a bit of a stretch but I think it is the same mentality. Don’t use the new syntax/feature because the old way is more familiar. If we were to do that, what is the point in writing new languages, or improving old ones. I guess I shouldn’t be surprised that many people fall into this mentality because the programming community up until the last few years had seemed to fall into a rut with language development. “Why develop new language constructs while the old ones work?”.

I guess overall this just further encourages me to learn a new language every once in awhile to make sure I am not falling into this mindset, and make sure I don’t try to make the new language bend to my ideas, but rather bend my ideas to the language. I guess I would equate it to speaking Spanish but not putting your adjective after the noun because that is how we do it in English. I charge you, learn a new language, swap that adjective around. It will probably make you a better developer by giving you a different slant on the problem.

This entry was posted in languages and tagged , , . Bookmark the permalink.

5 Responses to Language Patterns

  1. Michael Sica says:

    Getters/setters (mutator/accessors) is a great concept to use in OO languages because you’ve encapsulated how the end result is produced or modified.

    It’s EVEN GREATER when the language has built in constructs that makes the manual creation of these mutators/accessors unnecessary until you truly need them (without impacting any of the existing code that is referencing the class!).

    The concept is totally sound, it’s just that Ruby, ActionScript, and C# allow you to solve that problem in a different (and easier) way. (My jaw dropped the first time I saw how you can handle that stuff in Ruby!!! I was stoked!!)

  2. Joe says:

    I remember when throwing an exception in a constructor was considered “bad practice” because Microsoft’s compiler didn’t handle that situations properly. Years after the compiler bug was fixed I’d still here people repeating that it was bad practice without considering why. After all, a constructor doesn’t have a return statement or any other obvious way to indicate an error condition. Throwing an exception from one makes perfect sense.

    Someone should compile a list of these faux best practices. Today it seems like a lot of best practices have to do with making things compatible with C’s linkage problems. Maybe if we recognized these kludges as work-arounds then we’d be less likely to keep using them when they’re no longer necessary.

  3. Daniel Roop says:

    I think ultimately we agree, but I don’t think getters/setters are the important feature. I think being able to modify the way something behaves without updating a lot of code is important. In Java you can only accomplish this by creating levels and levels of abstractions ultimately at the bottom a getter/setter method.

    Thanks for your comments. I agree a list would be great. I would take that task on myself, but I doubt I would every get around to doing it, with all the other ‘projects’ I am currently undertaking. I do agree that a considerable amount of our ‘best practices’ come from old C conventions and I would suggest that it goes even beyond linkage problems. Hopefully with the recent resurgance of interest in langauge development we will be able to lose a few more ‘best practices’.

  4. Maxim Porges says:

    Ah, the classic troll of a debate regarding dynamic vs. statically typed languages. Okay, I’ll bite.

    I think that use of certain languages can be equated to use of certain frameworks or tools within a language: use what’s appropriate for the job because of its appropriateness (yes, that’s actually a word – I’m surprised too) rather than your personal preference or familiarity.

    The problem I always feel exists with most dynamic languages is that you can shoot yourself in the foot really fast by not having a compiler to check your code for you. A compiler is not going to catch everything, but it reduces the possibility for errors. So, for example, if I was going to send a robot of some kind to Mars and wanted to reduce the number of possible errors, I would probably use something compiled like Java. Oh, wait, JPL already did that.

    Of course, the use of a compiler puts some shackles on you, and dynamic languages let you shed the shackles for greater power in expression. This is wonderful for developers, and lets you do all sorts of neat tricks at runtime, saving a ton of effort and providing elegance and simplicity in the notation of your solutions and algorithms.

    Unfortunately, the cost of potentially blowing up at runtime due to magically injected mojo still stands. This can be mitigated with unit testing but never completely eliminated. Naturally, the possibility for runtime exceptions still exists in compiled languages, but the likelihood is greatly reduced for obvious reasons. The bottom line is, dynamic languages are awesome for stuff that isn’t mission critical, like making web pages or writing shell scripts. I think the thing that has gotten me really interested recently has been all the Groovying and JRubying going on, allowing me to have my stodgy pocket-protected compiled languages hang out in the same context as faceball-playing, iPhone-owning dynamic languages. Have cake, will eat.

    The one thing that pisses me off more than anything is when language designers put restrictions on the programmers to try to help them stay within the lines of “best practices.” Gee guys, thanks for the condescension, I really don’t know what I’m doing. There is always an edge case. I consider the ternary operator a bad practice for general use, but as we were discussing at work today, it works beautifully in certain cases. Similarly, I guarantee you that somewhere out there there’s a GOTO statement that’s worth its binary weight in processing cycles, so show it some respect. :)

  5. Daniel Roop says:


    Thanks for the insights. I do think the debate between compiled/implemented langues is interesting, and dynamic/static is also interesting. But keep in mind there is a difference between compiled and static. You can compile a dynamic language. Look at JRuby a good chunk is not interpreted, or even Groovy. Unless I am mistaken Groovy can compile down and not be interpretted.

    As for the whole getter/setter debate, you don’t have to be interpretted to take advantge of some of the features that “dynamic” languages give you. For instance Actionscript and C# both have the notion of formal properties, that seems like a somwhat dynamic thing, but it is there. And C# 3.0 will have dynamic typing, meaning the compiler will figure out the type the object should be, and apply that. So you still get all the advantages of a compiled language but without forcing extra keystrokes on the developer.

    From what I understand the mother of all dynamic OO langagues, Smalltalk, has one of the best IDEs around. And can give you code insight, and compile like checking right in the IDE. So I think intepretted or compiled you can solve the problem, it is just a little different.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>