Following my previous post on multi-language (polyglot) and multi-paradigm (poly-paradigm) development, I thought I’d continue on the same thread for a little and do some comparisons on some of the popular types of programming languages.
An imperative programming language such as C# or Java allows you to specify step-by-step how a problem should be solved using a series of statements which change a program’s state. It’s important to remember that whilst Object Oriented Programming is how we are all taught to do imperative programming these days, it’s not the only way – C and other procedural languages are also imperative languages.
A declarative programming language on the other hand, is a higher level programming language which allows you to express what you want without specifying how to get it. SQL is probably the most widely used declarative language today and in SQL you don’t tell the query analyzer how to go about fetching the data, you just state what data you want to retrieve and it takes care of the rest. It’s also worth nothing that
How they compare:
The benefit of declarative language is that it separates the process of stating a problem from the process of solving it. It’s essentially an extension of design by contract where producers of the declarative input describe what they need and how they need it, allowing producers of the declarative program to determine the best way to get it.
Approximating this in an imperative language is possible because at heart, everything is imperative. The challenge in doing so is that an imperative program operating on declarative input must be prepared to check pre and post conditions and have a plan to deal with every eventuality!
Declarative languages allows for greater extensibility, agility and productivity. Think how quickly you can create a table, input some data and then get the data back in some form or another in SQL and then imagine the time and effort it’d require if you were to implement these in C#.
However, as a user of a declarative language, you have limited or no control over how your inputs are dealt with and therefore have no option but to mitigate the impact of any imperfections/bugs in the underlying language and rely on the providers of the declarative language to address the issues.
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