Whilst fishing around StackOverflow for interesting discussions I came across this question on which programming paradigm is best for which job. There were some interesting arguments put forward, and after doing some more reading here are the two things I took away:
Language != Paradigm
What paradigm (procedural, OO or functional, etc.) you choose to program with does not necessarily equate to your language of choice. For example, C# and Java are predominately associated with OOP because OO is the paradigm both are designed to cater for. However, just because you’re programming in C# doesn’t mean you’re doing OO programming – you can just as easily be writing your program in a procedural or functional style. Indeed, extensions such as LINQ and PostSharp has introduced functional programming and AOP to C#.
(OO vs Function) vs (Dynamic vs Static)
When talking about languages most people think about the different paradigms they’re associated with, but there is a separate dimension to be considered – Dynamic typing vs Static typing. The two dimensions overlap, for example, C# and Java are both OO and statically typed whilst Ruby and Python are both OO and dynamically typed.
So, what do static or dynamic typing mean anyway? To answer that, let me go back to the basics and revisit some of the terms commonly used when describing ‘type’s in programming languages:
A type is a metadata which describes the kind of data stored in a chunk of memory, a type is usually associated with a list of operations that can be performed on the data (methods in OOP, or functions in procedural).
Though the definition of ‘strong typing’ seems to be vague and can vary depends on who you ask, but there are some common themes that are consistent through all the reference materials I have read:
- A strongly typed system has type checking and will throw an error when it finds type mismatch. When the type checking happens depends on whether the language is static or dynamically typed, see below.
- Once assigned, a variable will always behave as a certain type until it is reassigned.
Both C# and Java employ a strongly typed system where all variables must have a defined type, and there are restriction on type conversion. But interestingly, Anders Hejlsberg (lead architect of the C# language) in an interview described strong typing as something that can be toned up or down as opposed to an on or off feature. Here is his original quote from the interview:
Anders Hejlsberg – The thing you realize about typing is that it’s a dial. The higher you place the dial, the more painful the programmer’s life becomes, but the safer it becomes too. But you can turn that dial too far in either direction.
If all this seem a little too vague for you, here is a nice and simple test you can use:
If you can concatenate a string and an int without casting, then it’s not strongly typed.
In a statically typed programming language, the types of variables must be known at compile time. Again, both C# and Java are statically typed languages, though C# 4.0 would soon introduce support for dynamic typing too.
As you’ve no doubt guessed already, a statically typed system are more restrictive and there are greater overhead and effort required on the developers’ part to deal with type mismatches at compile time, there are actually many reasons why it’s beneficial to you:
- Stability – type errors can be caught automatically by the compiler, reducing the chance of a bug slipping into production.
- Readability/Maintainability – more information is provided about how the code is supposed to work, which helps future developers (or yourself!) to understand the purpose and intended usage of a variable.
- Better developer tools – the IDE (or tools like Resharper) will not be able to provide a very useful intellisense support if it doesn’t know what types to expect at compile time.
A programming language is dynamically typed if its type checking is performed at run-time. In dynamic typing, types are associated with values not variables, which means the set of methods and properties you can use on a variable is verified at runtime against the type of the value the variable currently holds (see duck typing).
C# 4.0 is going to include a dynamic keyword to add support for dynamic typing to cover some of the niche areas such as interoperability.
There are a lot of confusions around the different terminologies on the topic of typing, so much so BC Pierce, author of “Types and Programming Languages” said:
I spent a few weeks trying to sort out the terminology of “strongly typed,” “statically typed,” “safe,” etc., and found it amazingly difficult… The usage of these terms is so various as to render them almost useless.
I hope this blog post will help clear some of the confusion you have :-) And to finish what I started, here’s the accepted and my favourite answer from the question which started all this:
Your choice of Paradigm or Model or Approach or Style is based on the answer to the following question:
“How Can I Best Represent This Problem?”
If the problem has objects and relationships, OO. If the problem has algorithms and transformations, maps, filters and reduces, Functional. If the problem is dynamic, changing and flexible, Dynamic. If the problem is static and will scale up rapidly, Static.
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