There is no such thing as one grand unified full-stack programming language
I was thinking recently about Mel Conway's two lessons regarding programming tools:
Lesson 1. The developer's productivity is best served by a tool set whose behavior throughout the development cycle is strictly consistent with the principle that the program being executed is available without delay after every change and is identical to the source program entered by the developer. (That is, there should be no hint of the existence of a translator.)
Lesson 2. Application languages and algorithm languages are different creatures. The job of a productive application language is not to describe algorithms, but to hide them.
Conway discovered these lessons based on his experience in early computing. Nevertheless, they still hold today.
They say that software architects gravitate towards a particular specialization or a specific flavor of architecture they tend to implement, and the patterns they learn early on trend well into their late careers. In my case, be it trading systems, cloud-based CRM, ERP, or HCM, my work revolves around building one kind of SaaS or another. As a result, the architecture I gravitate to can best be described as a microkernel.
In microkernel architecture, the application is split into two general areas. One is what Conway describes as the algorithms, though I prefer to call it platform. The other is application implemented as plugins for the platform.
The role of the platform is to meet architecture requirements, such as security, scalability, deliverability, testability, reliability, and various other "-ilities". Aside from the primary goal of meeting business requirements, the plugins for the platform support developer productivity needed to evolve business processes rapidly.
In a modern SaaS, the microkernel platform provides the APIs to perform tasks in the application. The plugins are a glue that ties the APIs into meaningful and rapidly evolving business processes.
A trading system may be implemented as a microkernel that provides the basic functionality to execute trades -- and plugins implement customizable trading algorithms. An HCM microkernel may offer a set of APIs required to manipulate HR workflows and run payroll, with pluggable components describing business processes. Amazon's Alexa architecture can be viewed as a platform offering basic functionality needed to implement and run plugins called skills.
The toolchains, including the programming languages required to build the platform vs. the plugins, do not have to be the same. The developer skillsets needed to work on the platform vs. the plugins don't need to overlap.
As Conway would say, a productive application language must offer a quick turnaround. Developers should be able to execute their work without delay after every change, and the code being performed should be identical to what they've written. Conceptually, this idea tends to favor interpreted languages with REPL such as Python or JavaScript and rules out the use of any transpiler such as TypeScript1.
In the past, I implemented two styles of the mechanisms for plugins. One was for a trading system implemented as a Groovy-based DSL to describe trading algorithms. Another was an ERP SaaS platform that supported JavaScript plugins, deployed as AWS Lambda functions behind the scenes. The AWS Lambda-based approach checks many architecture requirements boxes for projects I am working on these days, and it is my preferred approach.
The platform language must meet a different set of goals. Though developer productivity is essential, it must also meet architecture requirements. The platform language must be capable of expressing modern systems concepts such as networking, object serialization, and multi-core processing. In the past, my preference was Java. These days, I love Go.
Meeting the architecture requirements of the platform and developer productivity does not have to be mutually exclusive. However, one should not discount the difference between application developer productivity and platform developer productivity. Whereas the goal of a platform developer is to build reliable infrastructure code, the goal of an application developer is to develop and update business process logic quickly.
Some final thoughts
There is no such thing as one grand unified full-stack programming language or a full-stack developer using a single tool. As a SaaS software architect, I certainly do not see some holy grail from my vantage point. We need to use tools that best meet the needs of the task -- and the needs and the skills of developers who use them.
- When I talk about my distaste for transpilers, I do not generally include web application front-ends. Front-end development nuances are outside of the scope of this article. ↩︎