When your programming paradigm breaks, so does your code

/ This is a quasi-translation of an older post. Enjoy! /

Hands full of paradigms

Without actually thinking about it, we are constantly jumping between programming paradigms. A typical "N layer" application can easily grow this complex before the release:

• JavaScript + HTML + CSS client, communicating via JSON (which is almost JavaScript)
• Java or .NET Back end
• Some legacy services we use through XML Web Services
• Relational database, document store, etc.

Lets count the paradigms here:

• Procedural (JavaSript, Back end, Database Stored Procedures)
• Declarative (HTML, XML, CSS, SQL)
• Functional (JavaScript, Back end)
• Prototypical (JavaScript)
• Object Oriented (Back end)

Isn't it interesting we ended up more paradigms than architectural layers? What if we toss some Domain Specific Languages in? Is it a good or bad thing?

It depends. It certainly gives us the flexibility to implement things where they're the most effective. Need to process the accounts overnight? Stored procedures are here to help. MVC style UI? You can do it in JavaScript with less round trips to the back end server.

On the other hand, there are certain concepts traveling across the whole application stack. These are the "things" our application is all about: products and orders in a web shop. Comments and pictures on a social media site. Stocks, gas tanks, shoes, you name it. These things need to have a representation in every paradigm you have. There will be a table to hold your products, a .NET class to represent them in the processing, an XML representation, a JavaScript object, and some HMTL markup to show them. These are the center of your application and all the code you write deals with them.

At certain points of your architecture, you need to convert them from one paradigm to another.

Those are the points where all hell break loose.

When the worlds collide

While most of the paradigm has some sense of data modeling, their vocabularies can be slightly different. Strings does not exists in the database engines (but there is varchar), while JavaScript has no precise numeric representation (like Decimal types in databases). The struggle continues in the functionality area too, with too many discrepancies to count. The following diagram shows how the different features partially overlap:

The "white zone" in the center is the matching point between your paradigms. This is where you can safely implement your "things".

The "gray zone" on the other hand is covered by some of your paradigms but not all. Using these features is dangerous, but sometimes we take the risk: the feature feels so perfect. Sometimes it worth the effort. Other times we regret taking the unbeaten path. A performance issue or an unforeseen twist in requirements points to the lovechild as the bottleneck of future growth.

What can we do?

• Play safe and never leave the "white zone": will be boring after a while. You will copy paste all day along and then fix copy-paste errors. 
• Play hard and code around: Of course you would never do that, would you? If you did this in the past, there is a fair chance you will end up in the "less feature for the same development effort = end of life-cycle is near" state. Try harder (or safer?) next time.
• Let's buy the perfect framework: For every generic problem there is a generic solution, right? Get Hibernate and solve the Object Oriented vs. Structured paradigm gap instantly. You will end up coding against an API, solve performance issues against an API, and generally live and die by the API of your choice. No silver bullet here. Move along.
• Keep it simple: the only smart way out is to keep the paradigms at the bare minimum. The simplest the architecture, the less paradigm collisions you need to overcome. Over time, there will be guys who want to bring their favorite framework, server, programming language because it is so cool and trendy. Resist them. Show them this blog post. Throw them out of the window if they don't listen. Anything but don't add architectural complexity to the design.

Have you found any other way around this? Let me know in the comments!