A past present
Let me say it clearly: the way we develop is outdated.
Or, to put it simply, we’re developing with the same modality we had 30 years ago.
But with more tools, platforms and patterns.
With this thought in mind, I see a very deep correlation between the following three things:
Back to the future
Bret Victor did an inspiring talk at the Dropbox’s DBX conference, back in 2013.
The talk is set between the 60s and 70s.
He talks about what computer programming would look like thanks to some extraordinary projects: the NLS system, the Grail system, the Smalltalk editor and Plato.
Long story short, the idea of his talk is that if we had followed and improved such technologies in the late 60s, nowadays we should be able to develop applications like Tony Stark does in Ironman: effortlessly and smartly.
According to this talk, we should have a completely different way of developing these days, instead of writing huge text files without an immediate response on what we’ve done until we run them in a certain environment.
Logic programming and visual implementation
Corey Montella, Chris Granger and their team proposed Eve Lang, a new approach to change things by combining a visual editor embedded into the browser with a logic programming language.
Eve was designed for “literate programming”, a cool concept forged to say that instead of having comments embedded in code, code is embedded in a document.
Eve was also designed to give the freedom to organise the programs based on what developers think and on the ability to weave a narrative of not just what the program does, but why it does it.
All of these concepts lead us to rethink the way we develop.
Nowadays, we’ve tons of tooling and services our applications rely on.
Think about it for a moment: if you were to start building a new API from scratch, how many steps should you take to make it work and make it available to the public?
You’ve to deal with a lot of code boilerplate, third party dependencies, tools like linters, compilers, package managers, and with the most complicated part: the deployment. Choose a cloud platform, find out how to interact with it and finally deploy the first version of your “hello world” API.
Things get more complicated when you need to release new versions of the API, but let’s stop here.
Don’t you think that instead of simplify the development we made it more complicated?
So, what can we do to reverse the trend?
Entering Dark Lang
What if we took things away? (Ellen Chisa)
And that’s exactly what they did.
With “A programming language for a continuous delivery world”, Ellen presents what Dark Lang is and how it is changing the development.
This programming language is in its early stages and is still in beta.
However, Dark is already showing a substantial paradigm shift, providing the user an extremely simple platform for developing backend services.
Instead of spending hours configuring a CI/CD pipeline to publish the application and learn a whole new ecosystem, Dark focuses on simplifying things, providing few but powerful components:
- API Endpoints (REST)
- Background workers (with built in event/queue system)
- Scheduled jobs/cron
- Persistent Datastores (key-value/hashmap)
- REPLs (internal tools)
- Functions (reusable code)
The entire platform is cloud native so you don’t have to think about anything, except implementing the business logic and connecting the components.
It is literally as simple as it seems: point the mouse, choose the component, fill it with what you need and connect it with other components.
A coding challenge story
Let me tell you a story.
I recently had a coding challenge.
I was asked to implement an ETL: fetch 3 different CSV files having the same structure from a S3 bucket and transfer them to a database. The final step required to publish the solution on a known cloud platform.
I solved it using Typescript, Node.js, Postgres and Heroku.
And then I did it again but this time with Dark Lang. Just for fun 😁
This is the repository of my first solution: https://github.com/wilk/outlier-coding-challenge
As you can see, I had to:
- define the project structure using NPM, Git and Typescript
- define a Sequelize model for Postgres
- define the job using an external library to retrieve the data (node-fetch)
- define the Heroku project with a provisioned Postgres instance
- define the environment variables for both local and production environments
And now the solution with Dark Lang, which consists only of the following two screenshots:
With Dark Lang I defined:
- 2 HTTP Rest endpoints
- a worker containing the async logic to parse the CSV data and to transfer it to the database
- a key-value database
- a common function used by the worker
That’s all. The difference is abysmal.
The ETL is the same but there are two substantial differences:
- it took me almost 3 hours to implement the coding challenge with Node.js while only 30 minutes with Dark Lang
Not to mention the HTTP endpoints: if I wanted to have them with the Node.js solution, then I had to setup an Express webserver and define a couple of routes with the related handlers.
More work to do. More tools. More things to know.
A new hope
The path is clear: we have to change the way we build software.
It’s necessary for many reasons: for newcomers approaching computer programming; for companies and their growing development costs; for dissatisfied and frustrated developers.
Dark Lang has enormous potential to lead this revolution: let’s give it a chance!
You may find helpful the following list of Dark resources:
- Slack app tutorial: https://vimeo.com/380770154
- Dark Lang docs: https://darklang.github.io/docs/introduction
- The design of Dark: https://medium.com/darklang/the-design-of-dark-59f5d38e52d2