You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!
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.
Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.
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.
Skill up your serverless game with this hands-on workshop.
My 4-week Production-Ready Serverless online workshop is back!
This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.
We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.
If you enrol now you can also get 15% OFF with the promo code “yanprs15”.
Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.
Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!
Check out my video 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. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!
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.
- All you need to know about caching for serverless applications
- Lambda optimization tip – enable HTTP keep-alive
- You are wrong about serverless and vendor lock-in
- You are thinking about serverless costs all wrong
- Just how expensive is the full AWS SDK?
- Check-list for going live with API Gateway and Lambda
- How to choose the right API Gateway auth method
- CloudFormation protip: use !Sub instead of !Join
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- Guys, we’re doing pagination wrong
- Top 10 Serverless framework best practices
- How to break the “senior engineer” career ceiling
- My advice to junior developers