Is it possible to design and build a procedural (imperative) based application successfully?

Question

Can you provide examples of applications today that are procedural and maintain a high level of integrity and efficiency? Are there any books, tutorials or links that provide examples of how to successfully build and maintain an imperative system? If you were to give guidance in this area, what tips would you give on how it should be structured? I ask because OOP is often presented as a natural progression of procedural programming, but I have trouble believing that is always the case.

Answer 1

While I cant point toward any existing system directly, there are massive amounts of legacy enterprise systems written pre-OO COBOL. Many classic 4GL programs are procedural and are aimed at high integrity systems engineering. Some are well written, others not so much.

Books include "COBOL from Micro to Mainframes", "Enterprise COBOL Programming Guide."

Structural tips on good imperative code are similar to OO techniques: name things well, seperate your concerns, dont repeat yourself, single responsibility principle, dont leave broken windows unmended.

In fact I'd simply suggest reading the "Pragmatic Programmer" would give most people the right idea in any paradigm.

As far as a compelling reason for moving to OO for business oriented applications; procedural languages allow for a transaction script approach to domain logic, whereas OO languages allow for the domain model approach.

Certainly for simple exercises, there is no real need for the use of OO languages, but as soon as complexity rises, the maintainability of OO languages wins over procedural languages low overhead.

Answer 2

Examples of successful procedural applications??

You mean like, say, the Linux kernel? BSD kernel? Apache web server? The vast bulk of the Unix userland utilities? Applications like that?

Of course OOP techniques have value in the organization, maintainability, and abstractions within software, but even today OOP is likely a minority subset of all the code and applications written today.

Consider all of the Java or C# or VB code that while written in a OOP capable programming language, the only reason they're using much OOP technique at all is to interact with external libraries or systems. Meanwhile the applications themselves, while leveraging OOP frameworks, are likely quite procedural in design and implementation.

OOP is a fine paradigm, but in truth it's not really necessary for the bulk of logic in many systems.