Are Procedural Languages Justified?

Several months ago I got into a debate on GotDotNet about the place of procedural languages in our programming world. During the course of the discussion my line of thinking evolved on the subject. At first I felt, why bother with a procedural language, when an OO language such as c# can be used? However since this discussion, I firmly believe that procedural languages have their place in our world. For example,

If you look at Service Oriented Architectures such as WebServices and the tenants associated with SOA. Clemens Vasters discribed the following 4 tenants as PEAC (gotten from theserverside.net and his weblog)

  • Policy-Based Behavior Negotiation
  • Explicitness of Boundaries
  • Autonomy
  • Contract Exchange

The fact that we have explicit boundaries and each method has Autonomy and we are talking about a “Contract“, then do we really need an OO language such as C# to describe our facade? Wouldn't a procedural language be better? Everything about these tenants scream for a procedural implementation. Your underlying implementation could easily call into an OO implementation ; however, why bother with the overhead of an OO language to basically provide a contract to your consumers? Wsdl is, after all, a procedural language.

Other examples include static methods. In many scenarios static methods get abused and used incorrectly. But they also have their place in our world. For example, look at the Convert.ToXXX() methods in .Net. It doesn't make sense to run up an instance of the Convert class just to do a conversion. The designers of the class (IMO) did the right thing and hung a bunch of static methods off the class. However, why not just use a procedural language? If we do this, then how will this affect .Net? Wouldn't it be better to write it in a procedural language such as C#-Light (maybe we call it procedural c# ;) ) that is procedural and we can easily integrate into c# and other languages.

Anyway, just a bunch of rambling thoughts.

-Mathew Nolton

2 Comments

  • I've found that in almost every case, buisness login is better expressed in procedure languages. Not that OO can't do it (or even do it better), but it makes it a lot easier to express a physical process with a procedural language.



  • i agree. most business logic or the language of describing a business process is procedural in nature. when you start getting into implementation details such as figuring out how to best manage state and handling scenarios that leverage patterns and require factoring that OO truly shines.



    however, processes like stateless facades used by SOA and to some extent COM+ that you have to wonder why we use OO languages when a procedural language is so much more straightforward. especially if your facade can call directly into a BLL that does leverage OO. it's not that you can't use OO...but wouldn't it be nice if you didn't have to.



    -Mathew Nolton

Comments have been disabled for this content.