One of my favorite examples of how to create new technology and gain business leverage from it comes from Paul Graham’s book Hackers and Painters. Graham is famous for co-creating Y Combinator as well as Viaweb, which was the foundation for Yahoo! stores.
In one essay, he tells the Viaweb story, and makes a controversial point. Graham asserts that Viaweb’s success was due in large part to the fact that it used the Lisp language. From this, he asserts that all languages are not of equal power. Graham’s point was that some programming languages are better designed to solve certain problems than others.
Lisp fit the capabilities of the application Graham and his co-creators were trying to create. Lisp is a functional programming language that has been around for decades, and has mainly been used for research and AI. The properties of functional languages have been reflected in many modern languages like Python, Ruby, and JavaScript. The team at Viaweb was able to use Lisp to leverage a small programming staff to do an enormous amount of work. Graham specifically points out that a large amount of the code was Lisp macros, which are programs that work to modify the code of the program you are writing. In my view, what Graham is saying is that he was able to use these macros to create a new language out of Lisp that was the perfect fit for what he was solving. For more details about how programs create other programs, see this blog by Graham.
But this idea is highly contentious. When you say that some languages are more powerful than others, it can quickly raise the hackles of computer scientists. And with some reason. In truth, almost any language could be used to implement a solution to a given problem. But the point Graham is making, and that I agree with, is that you have to ask yourself how long creating that solution would take.
In the modern world, we should want to find a good fit between the language we’re using and the problems we’re solving. The better the fit, the more quickly and efficiently we can solve our challenges.
Graham’s perspective is highly relevant to the world of low code development and all the recent attention it has been receiving. Low code can be the right fit for many specific projects that seek to enable a broader group of users to enter the application programming space – a space that will have to get larger in the future. What I’m arguing in this article is that low code systems pick up on Graham’s insight that you want to be able to create a new language that’s well suited to solving your problems. But unlike some of the complaints about Lisp, for example, that it’s only suitable for highly skilled programmers, low code addresses this by offering a simplified way of putting a language to work.
What We Mean When We Say Low Code
Low code development in some ways is a new name for a move towards highly configurable, simplified programming languages that has been going on for decades. Low code draws on domain specific languages, as well as the simplified programming that can be achieved through a visual builder.
Currently, there is a raft of systems used for processes like ETL that all offer environmental transformations for data and business logic so that more people can participate in formerly siloed, specialized processes. And that’s the trick behind low code and any empowering language.
A language becomes more powerful not only when it fits the problem at hand, but also when you find a wide array of people who can address the problem using the language. Accessibility is the key. And that’s behind the push for low code development. It’s actually, therefore, more of an economic argument than a computer science one.
Low code development is the latest effort at simplified programming. And what low code provides is an easier way to express the user interface (UI) and the code for services invoked by the UI, as well as access to and organization of the data used by those services.
The domains that low code is targeted at change the nature of what low code can offer. In some domains, the accessibility of the UI is the primary focus. In other areas, the service domains are paramount. And in others, data connectivity and integration is the primary focus for app development. But what matters is that low code can be the right fit for each of these areas.
Going Deep On Low Code
Over the past few months, I’ve been doing a deep dive into how GE Digital’s Predix Studio represents this low code movement. Predix Studio’s rationale is all about creating a simplified development environment, founded on a base of high quality data integration, which is hugely important for industrial companies trying to bring together a variety of complex data. They want to enable citizen developers — people with technical expertise in a particular domain, who know what they need in an app, but don’t necessarily have extensive coding experience. It’s a low code development environment that is rooted in data integration and helping subject matter experts see what diverse industrial data sources are telling them. One differentiating feature of Predix Studio is the capabilities for integrating diverse data repositories using machine learning to provide assistance.
With data integration in place, which accelerates the work of citizen developers and full-stack developers alike, Predix Studio enables simplified creation of apps, including creation of the UI, application logic, and the application of analytics.
Predix Studio is a low code environment purpose-built for the Industrial Internet of Things (IIoT) space. But there are low code (or no code, even) products out there for a variety of enterprise needs, like low-code Appian for complex business applications, and no-code Agiloft. Low code is a much stronger fit for the IIoT world because it can handle that complexity better than no code.
The case for all of these products is similar, offering five crucial advantages:
- Simplicity: A simplified programming language can allow for the accelerated creation of a solution to business challenges. In the cases mentioned here, code can be generated interactively using the UI. The citizen developer doesn’t have to work with code directly.
- Fit to purpose: A platform that features plugins, configurability, and data integrations that in effect create a domain specific language that is adapted to a problem space, much like Lisp macros.
- Less technical debt: Because of the simplified nature of the coding involved in the application development process, low code creates less technical debt because coding is simplified or eliminated.
- More people involved: Because of the less technical coding environment, you can have a wider group of people participating in the solution, each of whom can bring their unique business and contextual perspective to the issue. That means more relevance and more subject matter expertise.
- Bolstering full-stack developers: Full-stack developers can also become more productive in a low code environment because they can replace many of their previous complex coding efforts with simplified coding structures that provide leverage to do more work in less time. For example, machine learning assisted data integration and the availability of plugins are productivity enhancements that most developers will appreciate.
In my view, because the landscape of data is growing so fast and digital transformation is needed so urgently, the only way to operationalize data is through numerous applications built on the same foundation. As a result, the landscape of apps will have to grow. Every company will have to figure out how they support a diverse set of applications in a low-cost way. I think that the only way to make this possible will be through a low code approach – at least until more automated solutions become available.
