Enso is a language, an IDE and a platform for data-driven applications. In this article we are going to take a deeper look into it and how it fits in the trend of making programming more accessible. This is not going to be a tutorial on using Enso, but an overview of what you can do with it and the current status of the technology.
The Future of Programming Is Everywhere
Programming is becoming more widespread and accessible to non-developers, with a myriad of tools, languages and smart applications. We have already seen tools like low-code platforms and we are evangelists for the use of DSLs.
The reason is simple: at the highest level, programming is a job that requires both technical competence in defining code and a deep understanding of the nature of the problem at hand. Programmers have the former, but lack the latter; specialists have the latter, but lack the former.
The problem is that programmers cannot become experts at everything and specialists cannot become experts at programming. So the solution is to give specialists tools that allow them to create specialized programs, without the need for them to acquire general programming knowledge.
We have certainly seen excesses, like people basically running entire companies on Excel, but this is the consequence of a real need: doing more things in a smart, flexible and programmatic way. The solution to the excesses are better, more focused tools. Tools designed for specific audiences and/or specific programs. Like Enso, a platform specifically designed for data-driven applications and data scientists.
A platform for data-driven applications
The same creators of Enso, previously worked on Luna, which was just a language. Instead Enso is something more: a language, an IDE, a platform.
Enso is available for Windows, macOS and Linux.
Interestingly, the promise of Enso creators is to empower both data experts and developers. They claim to give data scientists and data analysts great tools to do their job, but also to give developers and SQL experts powerful data analytics tools that can be used with the knowledge they already have.
Do they deliver on their promise? Let’s see.
Enso is an IDE
Enso is at version 2.0, but it is at an alpha stage. It is a version 2, because of previous development on Luna. So, it is like Luna 2.0, but actually Enso 1.0 alpha.
At this point, their primary focus seems to be on the IDE/application that makes Enso a visual programming language. This is what their video tutorials show and the easiest way to use it.
Using this IDE you can create programs such as this one, that takes two CSV files, read their data, filter it and concatenate the results. You create each command by pressing TAB and writing the instruction or selecting it by a list of suggested commands.
In terms of technical features, this IDE is already eminently usable: you can work with images, display locations on a map, read data from popular formats like JSON and CSV, get data from the internet, manipulate and transform tabular or vector data, etc.
There is also an easy way to see the same data as a table, histogram, JSON, etc.
A Smart and Advanced IDE
The environment supports a few nice things that you expect from a contemporary IDE, like syntax highlighting. It properly colors the data used in commands depending on the type. It also provides a sort of IntelliSense to provide intelligent help: suggesting related commands and contextual information when you press TAB.
This environment is designed for data analysts: to quickly create programs to analyze data and immediately see the results live. The end result is a WYSIWYG data processing environment that makes it easy to understand the data you are working with.
One usability issue is that you cannot edit the text of your commands. You can easily change sources, but not literal text. If you made a typo, you have to trash the command and recreate it from scratch.
This is annoying, but it is somewhat mitigated by the fact that you can easily replace a literal used in a command with a variable. For instance, in the following video we change the source used in command, written as a literal text value, with a variable text value.
Enso is a language
The engine behind the IDE is the language. The first thing to know is that it is executed by a JIT compiler on the GraalVM.
This is a smart choice and another example of what you can achieve by taking advantage of modern language tools and platforms. Interestingly, EnsoGL, that is to say the WebGL Engine that powers the IDE, is written in Rust, which is not supported by GraalVM.
If the execution of the language is quite pragmatic, the language itself is more ambitious and academic. Academic is a somewhat scary word in the context of computer programming. In practice, it can mean useful innovations, but also pedantic choices. It is difficult to say which one it is until you try the language and see what everybody else does with it. You can see what I mean by discussing three important features of the language. You can go more in depth by looking at the presentation of the syntax.
Enso is fundamentally a functional language with the addition of some innovations of its own.
Enso has great support for interoperability. For one, you can use import libraries written in other languages, like Java. This is good, but somewhat obvious given its reliance on the GraalVM. What is a great bonus is the support for defining functions in other languages, directly in Enso code.
You can define such functions like any other method, just by prefixing the definition with the
This is an example.
foreign js calculate_volume area (height = 10) = """ return area * height;
This code defines a
calculate_volume method with the parameters area and height. The parameter
height has a default value of
10. The three quotes indicate the beginning of a block literal. There is no end delimiter, the layout of the literal itself determine the end. This is a clever solution that bring us to the importance of whitespace in Enso.
An important aspect of Enso is readability, which is generally great. The code looks clean and easy to understand. That is because you use whitespace to delimit pieces of code and the type can be omitted.
For example, this is how you define a vector literal; elements of the vector can be of any type.
my_vector = [1, 2.0, "text!"]
Whitespace is also meaningful for another reason: it is crucial to define operator precedence. Let me quote the documentation:
In Enso, operator precedence is whitespace-sensitive. An operator without surrounding spaces has higher precedence than an operator with surrounding spaces.
This seems at first a strange idea, but allows long and complex expressions to be written in a visually cleaner way than other languages. This is important for comprehension of expressions on components in the IDE.
You also use whitespace to call functions. What we mean is that you use space in place of parentheses to indicate the arguments in a function call.
This is the kind of approach that you are going to love or hate. There is little redundancy in Enso. You are supposed to know the correct way to do things in order to write and understand Enso code. This also means that tool support is going to be very important for the success of the language. You cannot be productive in a language that requires such precise syntax, unless you have an IDE that supports such precision.
This is why I said that readability is generally great. The code always looks clear and simple, but sometimes it is not easy to understand, given that whitespace has profound implications on how the code behaves.
Features that are more common, at least for a functional language, is the support both for partial application and currying. Basically, you can easily handle functions and compose them like any other type of data.
Now we come to the arcane side of Enso. The Enso type system is complicated. You should really read the documentation if you want to understand it fully. I am going to quote extensively from it because you cannot really do it justice unless you use their own words.
On the spectrum of programming type systems ranging from dynamically typed to statically typed, one likes to think that there is a happy medium between the two. A language that feels dynamic, with high levels of type inference, but lets the users add more type information as they want more safety and compile-time checking.
Enso aims to be that language, providing a statically-typed language with a type system that makes it feel dynamic.
This is clear and sensible. As a goal for a type system, many people would agree that this would be the ideal objective of a type system: a system that is productive like a dynamic one and safe like a static one. To be fair, I personally would also say that recent functional programming languages could already say to have reached that goal.
Laudable as the goal is, understanding how types actually work in Enso is much more complicated than that. The Enso type system is based on atoms, which are small units of type but what does this means?
Enso Put Your PhD to Good Use
Atoms are a novel concept introduced in Enso. They let you define named containers for data, where the data is stored in named fields. For those familiar with Haskell, Scala, or Rust, atoms are like constructors, but unlike in these languages, atoms in Enso can be shared between different algebraic data types. Formally, atoms are product types.
Atoms are both values and types in Enso. They are the most primitive building block for the upcoming Enso type system. For example, the type of Vector 1 2 3 is both Vector 1 2 3 and Vector Number Number Number. You can read more about this and the upcoming type-level design in the Enso design documentation.
Another Enso innovation are sum types, which are basically a way to define smart unions. You can define a base type which can have only a range of possible values. So, you can define a type Shape, which can be of type
The complexity of the type system does not end here. There is a whole set of operators that manipulate types. Enso gives you great power to manipulate types. This effectively makes you able to use the language to enforce all sorts of constraints on data and the results of your calculations. The downside, of course, is the great complexity that you can create.
Innovation Is Complicated
This type system and even its description seem complicated. However, to be fair, precision of terminology does help clarity. If you know what algebraic data types are, it is better to say that, rather than saying “they are classes, but more powerful”. Which seems clearer, but it is just more vague.
This is a testament of the importance of defining the audience. Enso is designed to create data-driven applications. This means that the IDE is accessible to non-programmers, but is for expert data scientists or data analysts. In order to support this flexibility in the IDE, you have to design a language that is quite complex to use and to wrap your head around. So, taking advantage of Enso, as a programmer, would require a bit of effort.
It is not advisable to just use Enso, without understanding the type system. Let’s set aside that obviously the type system is just one aspect of the complexity of using Enso. You need to fully understand the language because it would be easy to undermine the power of Enso (the IDE) if you added custom code that did not fit the Enso philosophy.
This is one of the hidden consequences of giving powerful tools that are easy to use for non-developers. The developer has the hard job of handling all the complexity in place of the end user.
The Language Is Not the Main Focus Right Now
Overall the documentation is good and there are a few videos that effectively work as tutorials, like one that shows how to create custom data visualizations.
The first impact with the documentation is not great, though. Since the first command that you try, to create a new project, is wrong.
Instead of using this, as mentioned in the documentation:
enso.exe new project1 --path ./project1
You should use something like this:
enso.exe new project1 ./project1
To be fair, this is a minor issue. You can solve it simply by looking at the included help.
What is a bit more troubling is a lack of support for common development tools like VS Code. You will not find extensions for Enso and the major IDEs (there is a plugin named Enso for IntelliJ IDEA but it is unrelated).
This is an issue of productivity: you cannot expect developers to keep pace with data scientists without development tools that support them.
This is an understandable limitation at this stage of development. Their main selling point is the IDE, so they concentrate on that. However, I think it is important to mention this information for developers interested in Enso.
This disparity is also seen for the installation process. There are separate ways to install the IDE and the language engine. To install the IDE you just use the installer available for your OS. To install the compiler/engine you can download a portable release for your OS.
This is a choice that reflects how the different audiences should approach Enso. Data analysts can use it and evaluate if it fits their needs right now. Developers must be ready to be flexible and willing to follow its evolution.
Enso is a platform
The final aspect of Enso is the platform. In fact, the plan for Enso is to help data analysts, developers and data scientists work together in harmony. The idea is to support similar workflows:
- data analysts quickly develop models by testing and playing with the data
- data scientists refine these models to make them more effective and performing, so that they can be used at the scale the company needs
- developers support the whole process both by creating custom components for the IDE and by integrating the models created by the data scientists with the rest of the company infrastructure
To help this work, the platform must make it easy to seamlessly integrate custom code with the IDE and to add functionality to the IDE itself. Enso also needs to have a performing backend, to be able to handle dataset with millions of points efficiently.
It is tricky to understand at the moment if Enso can do that.
Given their smart reliance on GraalVM, the performance part seems viable on pure technical grounds.
The language also does support adding custom visualizations and interoperability with other languages. This makes it possible to integrate existing code and quickly port a project on the IDE. For example, you can basically use a Java project with a custom type and then create the proper visualizations to make it usable on the IDE. This is indeed neat.
However, I think it is fair to say that we cannot know for sure whether Enso will work for you, until it starts to actually be used and tested by real data scientists.
Enso is still a work in progress
This is the risk you take if you choose to use a project in the early stages of development. You can be on the cutting edge and have a chance to use a great tool before anybody else. You can effectively shape the tool itself, to steer it to your use case. The drawback is that you do not get to be 100% effective with it, since there are no best practices and there are still plenty of rough edges.
There are companies that would greatly benefit from the success of Enso. There are companies that work extensively with data and whose workflow is still very much ad-hoc. Analysts create models with Python, or even Excel. Then data scientists adapt it to R or have to refine Python code to make it more performing or doing things like wiring it to the testing platform. Finally, developers have to write a lot of custom, glue and backend code to make everything somewhat work. All of this while the three groups complain about each other.
Enso could drastically improve this process by providing one platform to support every actor in a data-driven application. They could serve their interests and allow them to communicate their needs more clearly.
Enso as an Alternative to DSLs
The Enso approach could also solve a problem that we sometimes encounter when proposing DSLs. A DSL is usually well received by the non-developers that are going to use it, because it is a tool designed for them. They can do their job using something that speaks their language and without the attrition that comes with working with developers.
On the other hand, developers sometimes fear and complain about a DSL. They fear to be replaced by it. And they are annoyed that their competence in a general programming language gets wasted. Enso might help partially solve this issue because data analysts will still get their own tool, but developers will need to create the custom code and work their magic to make everything work.
This would not be a perfect solution because developers will still have to learn how to work with Enso. Even if they will be able to reuse existing code written in a language supported by the Enso platform. And asking developers to adopt a new platform and language is not an easy request.
In any case, just like for DSLs, adopting Enso as the cornerstone of your development would require a whole reorganization of company practices. A process that would require the participation of all groups involved. This will not change.
Enso is an IDE, a language, a platform to support data-driven applications.
It is an interesting new approach that tries to merge the approachability of visual programming with enterprise-scale productivity. We cannot say it will succeed, but we can say you should take a look to see if it can work for you.