Coding against coding common denominator, some good justifications?

Question

When do you consider not coding against common denominator so you can just take advantage of your tools unique features(be it for performance or clarity reasons)? What are those examples?

This example comes to mind, and I really like the extra clarity this construct brings to the table:

   select * from person 
   where (lastname,firstname) 
       not in (select lastname,firstname from registered_members)

As opposed to common denominator code:

   select * from person
   where not exists 
        (select * from registered_members 
        where lastname = person.lastname and firstname = person.firstname)

VB.NET's Try Catch When also comes to mind. But since I don't use VB.NET, I don't know if some VB.NET programmers exploits this feature or not.

Answer 1

If I am understanding it correctly, I think the question is backwards. When would you ever NOT want to exploit your tools/language to their full extent? The things that come to mind are:

• Interop (like using common CLR things)

• Learning. Say, if HR forces you to hire a certain level person, you might decide to not use more powerful features.

  Other than that, use them to the fullest extent.

Answer 2

It's reasonable to take advantage of your tools' or platform's unique features when there is a reasonable expectation that these things won't change over time.

People usually recommend making your code as portable as possible because, all other things being equal, it is good if your product is usable on a wide range of platforms. But even if you are targeting a specific platform, these changes often end up occurring unexpectedly:

• Your app becomes successful and there is a desire to target new platforms
• Management decides to move to a new DB backend

However, making your code portable can be hard work and there are legitimate cases where change is unlikely, such as when writing a web app for use by your organisation only. Paul Graham famously wrote the first version of Yahoo Store using Common LISP, which is considered hard to port.

As with most things, choosing the right tradeoff is key.