Less is MORE

Just finished watching an interesting seminar video by the guys from Object Mentor (a consultant company founded by Robert C Martin, the father of agile development) at:

http://www.infoq.com/presentations/polyglot-polyparadigm-programming

The video is about an hour long and covered a large number of topics around using different languages (polyglot) and different programming paradigms (poly-paradigm) to simplify and speed up the software development process. The main thing I took away from this was:

“Less code is better, so less code is more. With less code, all your problems become smaller, be it maintenance, testing or performance.”

which most developers would agree I’m sure, after all, one of the reasons we refractor our code is so we end up with less code.

For young developers like myself, we have come into software development in an era dominated by the object oriented paradigm and a small handful of mainstream OO languages like C++, C# and Java. So for me at least, it’s refreshing to see how other paradigms and languages can be used in conjunction with those I’m familiar with to achieve:

  • greater productivity from the developers
  • more agile and extensible solution

Summary:

If you don’t have the time to watch the video (or simply not interested enough to do so!) then hopefully the list of key points I’ve compiled together would at least give you some idea what it’s all about:

  • There’s no silver bullet in software development
  • OO paradigm not always the best solution for the problem
  • Statically-typed languages (C#, C++, Java, etc.) are compiled for greater speed and efficiency at the cost of lowering productivity
  • Dynamically-typed language (ruby, python, JavaScript, etc.) are interpreted for greater extensibility, agility and productivity at the cost of lowering runtime performance
  • Ola Bini‘s Three layers – Domain layer (Domain Specific Languages), Dynamic layer (JRuby, etc.) and Stable layer (Java, C#, etc.)
  • Scripting languages increases pace of development
  • Aspect-oriented programming makes it easier to deal with cross-cutting concerns
  • Functional programming makes concurrency easier, because:
    • functions are side-effect free and stateless
    • nothing to synchronize, so no locks, semaphores, mutexes
  • Functional programming is cloud computing friendly
  • Functional languages and DSLs are more declarative than imperative
  • Scala is cool!
  • Advantages of the polyglot and poly-paradigm approach are:
    • able to use the best tool for a particular job
    • minimize the amount of code required and keep them closer to the domain
    • better decoupling between components
  • Disadvantages of this approach are:
    • multiple tools, languages, libraries to manage and learn
    • need to manage the different metadata models and overhead of calls between languages
  • It’s nothing new! For example, web developers often have to work in different paradigms and languages on a website
  • Higher end-user expectations and tighter schedules are driving the popularity of higher level languages such as functional and scripting languages
  • Developers have to deal context switching between different languages, so as the application grows larger and more complex, you have to start partitioning the teams (should be second nature to those working in the enterprise world!)

Parting thoughts..

As the presenter stated several times throughout, polyglot and poly-paradigm programming (PPP) has all been done before (despite now being mentioned with unfamiliar terminologies), and I certainly see a lot of familiarity of it in my line of work where in a typical 3-tiered application you’d have:

  • the data access layer using SQL (relational paradigm)
  • the business layer written in C#/Java or other OO languages
  • the UI can be in any number of different languages or paradigms depending on its form (HTML/CSS/Java/C#, etc.)

and numerous scripting languages (Perl, for example) are also used in various places (hell, after all, there are over 5000 applications being actively used within Credit Suisse alone!).

Watching this video has helped me identify with what I already know and put names (polyglot, poly-paradigm) to familiar faces (which is why jargon are important and I keep blogging about buzzwords :-P ), watch it, and see if it can help you too.

Further readings:

Ola Bini’s blog post on writing different layers of code in different languages

Buzzword Buster – Cross-Cutting Concern

Definition:

A Cross-Cutting Concern is a concern your application needs to address that is unrelated to your application’s problem domain, and ‘cuts across’ other concerns. Typical examples include:

  • logging
  • persistence
  • security
  • error handling

They are usually difficult to decompose from the rest of the system and result in tangled code. Addressing these cross-cutting concerns will add a lot of boilerplate code into your application, increasing both the size and complexity of your code.

To ease the pain of dealing with cross-cutting concerns in our applications, Aspect Oriented Programming (AOP) was born and frameworks such as PostSharp (which I’ve blogged about already) provides an effective way of introducing AOP into .Net applications.

Buzzword Buster – DSL

Definition:

A Domain Specific Language (DSL) is a programming language that’s dedicated to a particular problem domain. DSLs are often used to support domain-drive design and modelling. It’s the opposite of general purpose programming languages such as C# or Java.

Advantages:

  • Code looks like domain prose.
  • Easier to understand by everyone.
  • Easier to align with requirements.
  • More succinct (so less code is required!).

Disadvantages:

  • Hard to design, test and debug.
  • Bad API designers make even worse DSL designers!
  • Different people use different terminologies (think mobile in the UK and ‘cell’ in the US) which reduces DSL’s ability to bridge gaps in communication.

Parting thoughts..

  • Industry specific, so from a career and personal development point of view, it’s not attractive to me to specialize myself in DSLs and be locked into one industry.
  • Existing expertise and talent is hard to find (compared to general purpose languages).
  • Additional training required for people new to the industry.

Buzzword Buster – Dependency Inversion Principle

Definition:

Dependency Inversion Principle refers to a specific form of decoupling aimed at rending high-level modules independent of the low-level modules’ implementation details. Its principle states:

  • High-level modules should not depend on low-level modules, both should depend on abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.

Dependency Inversion Principle is often talked about in connection with Inversion of Control or Dependency Injection.

Purpose:

Even in N-tiered applications you can often find tight coupling between the different layers, usually from upper to lower layers but not vice versa. For example, whilst your business layer might be intimately familiar with and dependent on your data access layer, the reverse is not true. This however, still represents a coupling problem and it:

  • makes changes to the data access layer more difficult as it might require changes to the business layer (ripple effect)
  • makes it hard to unit test the different layers in isolation

Dependency inversion (and decoupling in general) allows software architects to design their systems with greater flexibility by loosening up the dependencies between the different layers of their system.

Parting thoughts…

  • Coupling is like radiation, there are harmless background coupling everywhere (say, the core .Net libraries!), but exposure to tight coupling across the service boundaries/between interconnected modules in your application can be hazardous! With that said, without any coupling your system is as good as useless.
  • Tight coupling restricts a system’s ability to change in an industry where the only constant is change!

Further reading:

Loosen Up – Tame Your Software Dependencies For More Flexible Apps (MSDN article by James Kovac)

Robert C. Martin’s article on Dependency Inversion Principle

Design Pattern – Inversion of Control and Dependency Injection (by Shivprasad Koirala)

Buzzword Buster – Spaghetti Code

Definition:

You have Spaghetti code when the flow in your application becomes so complex and tangled it resembles a bowl of spaghetti where the different execution paths are twisted and intertwined it’s hard to make out where they start and end.

In software design, this is usually a danger associated with procedural programming or frequent, unstructured changes to a complex application.

image