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.
- Code looks like domain prose.
- Easier to understand by everyone.
- Easier to align with requirements.
- More succinct (so less code is required!).
- 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.
- 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.
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
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