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:
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
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
- 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!)
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.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong