Although lots of people design object oriented systems, few notice the
reason why them sometimes don’t work as planed. While such systems
were created to reduce complexity, several object oriented design become
extremely complicated. Especially when we start to add design patterns
to solve even simple problems.

Frequently, OO systems are the right solution for the wrong problem. The major problem we face when writing a system is not writing components
themselves. In fact, writing a single component can be done as easily in
an object oriented language as in a procedural language, for example.

The big problem we have is writing interfaces. Interfaces generate the large scale complexity in a system, which is what we want to avoid.

The problem though,is that most programmers think it is ok to use the interface building paradigm when writing code for a single component. And while this is possible, it is not the most efficient or maintainable solution.

What is an OO system?

OO incorporate the notions of interfaces but adds some syntax sugar
to implement dynamic dispatch. This simplifies the creation of interfaces,
the same way COM provides this feature for binary interfaces in C.

Notice that interfaces are a nice feature, but they are not all that we need to
write. So, while it is interesting to write systems with a good interface design, thinking that all you write is an interface is very simplistic.

In my experience, there is a lot of code that benefits from being written in different styles, such as functional or declarative. These components don’t needs to be written using classic object oriented components, and will never be part of the outside interface of a system.

In this type of code, it is just to have free functions that access data stored in data structures or lists, for example.

What About Polymorphism

The other feature, polymorphism, is not really new to OO, because it has been done for decades in other languages, such as C. Just define a pointer to a function and call it instead of of a statically defined function — This is how
DLLs or shared objects work, by the way. There is no real need for a new language just to define what will be called when a function pointer is invoked.

In my opinion, one of the main reasons why people like OO for commercial software is the way it constrains developers.

To create software with OO languages, one has to use classes for dynamic dispatch and interface hiding. But while it is ok to pretend for a while that these are the only important features you need, it quickly gets unconfortable.

Very soon OO people have to go through hoops just to simulate things they cannot do in their framework. Have you ever read about singleton — and why you need a special class to represent something that is not an object?

Have you studied flyweight objects to rediscover that sometimes you need values that are not objects? Have you struggled through the performance issues that exist only because of over reliance on OO?

Well, all of these things could be avoided by understanding that OO is nice as a way of representing interfaces to systems, but is a very poor metaphor to work on the internal implementation — unless you are prepared to go through hoops just to make something simple work.

There several reasons to learn a new language. Lisp is on the languages that I like a lot, although I haven’t been lucky to use it for work.

Here is what I believe are some good reasons to give Lisp a chance:

• It has a very regular syntax: everything is an s-expression (expression with parenthesis), so there is no surprises in terms of syntax. After you learn how to create functions and work with data types, there is not much to worry about.
• It has a huge library: if you decide to use Common-Lisp, the languages comes already with a ton of useful functions.
• It is multi-paradigm: unlike Java that forces you to write OO code, Lisp supports several paradigms: functional, OO, declarative (Prolog style), and even imperative.
• Third-party libraries exist: different from a few years ago, libraries for Lisp are available for most applications. There are a few web sites like clbuild that provide all libraries you need in a simple-to-install package.
• It is a compiled language: unlike languages such as Python and Ruby that are interpreted, Lisp is compiled (to machine language, not to an intermediate language such as Java). This makes it extremely fast compared to other dynamic languages. Its compiler also has options to generate typed expressions, so that you can get the ultimate speed when working with integers and floating point numbers.
• It is a modern language: implementations such as sbcl (available for Windows too), and clojure (for Java) make it possible to create modern applications that are just as fast as any other language (including C).

One of the things that can make the life of programmers harder is the use of a bad framework. The worst thing about frameworks is that they start as an easy way to do your job quickly.

However, after a few months of using that piece of software, we encounter more and more situations where it is making your life difficult, instead of being helpful.

Think, for example, on all the times you had to write a SQL query by hand just to avoid a performance problem on your preferred framework. These are things that add up and make development less pleasurable for experienced programmers.

The Good Side

I would be misleading, however, if I didn’t mention situations where having a framework is of great help. In a number of times, having a framework ready to use is just the thing you pray for. Here are three of these situations:

You are working in a domain you don’t know well: when that is the case your best bet is to rely on something that is already in use. Most industries these days have some kind of framework that handles the most common business logic. If you don’t want to become a specialist on this domain, just use the framework and be happy.

A second situation arises when you need to use an unfamiliar programming environment, such as a new language. Most development shops these days use Java for commercial programming, but from time to time you will need to create applications in something different. When that happens, it is nice to have a framework ready for use.

Still another case happens when you know what you’re doing, but you don’t have the time to do it: if you need to have an application ready for tomorrow, for example, there is no way to continue, other than using a framework — And you know, it is nice they exist for when a small application needs to be finished quickly!

So, for me there is no doubt. When you can’t escape such situations, it is better to smile and use your friendly framework.

As a software developer, I came to realize that one of the most important things (after being paid) is to create software that we really enjoy.
During those years, it has become really easy to see the kind of software valued by programmers: editors, compilers, interpreters, and all kinds of little tools that are useful only by other software professionals.
And the reason these programs are written, I came to understand, is not just that we need them. I believe that one of the main reasons this kind of software is so popular is exactly that, to write it, there is no need for external users!
When we create software for ourselves, the obvious advantage it that there is not formal need to elicit requirements.

The Easiest Software to Write?

Writing software for programmers is easy in an important sense: you just need listening to yourself. Writing software for the needs of real users is not so easy: first one needs to interview one, and understand the hidden requirements — what really needs to be done.
Next, you need to worry about user interface… Why bother with this when everything could be solved with a couple of command line arguments?
Just continue thinking like this, and UNIX is reborn. That is right, classical UNIX is the ultimate dream of most programmers: a system that needs no real interface other than the command line.

Who is to Blame?

Programmers are notable for writing this kind of software. And who is to complain? It is much easier to write programs when we don’t need to worry about real requirements. Integration with existing environments is another pain for business software writers: just say no.
Our culture has found the perfect solution for such problems in writing programming tools. No wonder why there are so many computer languages, compilers, editors, and web frameworks. They are fun to write, have challenges that are mostly intellectual, and can be shared among other programmers as a trophy.
Here are some example areas if you are looking for something exciting to write:

While there is a lot of sloppy programmers out there, these are not the only ones that have trouble finishing something. Some programmers strive for perfection in the software they create, and in the process end up spending precious time.

Anything less than perfection feels like it is a waste for such programmers. It is like they cannot move from a task until all possible features have been implemented…

Even if this seems unlikely, a few people operate with a similar mindset: trying to do everything that the software possibly could is similar to strive for perfection.

A simple example of this type of attitude towards programming is designing classes that have all possible methods that a client will ever need. The list of user cases continues to grow, and gets to the point when it becomes unmanageable. Classes that have all possible responsibilities is another symptom of this disease.

Avoiding Perfection

Is not that perfection, or completeness, is bad. The problem is the cost of having “perfect” software.

Software is different from physical materials. While a machine can be designed to look perfect (such as the designs that Apple strives to do), requiring the same from a piece of software would add a lot of functionality that is not essential.

A theoretically perfect software would have a virtually infinite number of features capable of satisfying every need of its users  — even if it is targeted to a specific area. Think of this as an example of combinatorial explosion, or fractal design: the more detail you try to put into an application, the more features it needs to have.

However, from all these features, one can only implement a few in finite time.

There is also a more insidious reason. As the number of features in your application grows, so grows the amount of code you need to implement them. This has two side effects:

• First, you can make more mistakes just because of the enormous surface area for them to appear. This is the classical case of bloat, where more and more features make it difficult to properly maintain the application.
• Second, as the code size increases, your program also becomes sluggish. Eventually, a program with a large number of features is slower and buggier than a more nimble version.

The next time you design an application, think twice about the essential features. Don’t try to make it perfect, make it functional. Your users will thank you.