[wdanilo]

Hi, thank you for the nice words! We believe in the same vision. Visual languages are amazing for some applications, however, text-based development is superior in many cases, like low-level algorithm development, API connections, compatibility with version control systems (GIT), etc. I am really happy that we were able to overcome all design problems and make these two representations 100% compatible. TBH, when we were starting Enso, we were not aware how many corner cases and tricky technical details we would need to solve in order to bring it to the world!

[djedr]

> We believe in the same vision.

Certainly. I was struck by it a few years back, around the same time as Luna was in early alpha stage. In fact I found it while doing research for my thesis, based on this vision. I was naive enough to think I had an original idea when I started.

> Visual languages are amazing for some applications, however, text-based development is superior in many cases, like low-level algorithm development, API connections, compatibility with version control systems (GIT),

And the only sensible way around these problems is to integrate both. Just this idea addresses most of the relevant criticisms of visual programming languages. A list of these I compiled at the time was:

• There is a barrier of entry for programmers used to text-based languages. • Essential programming tools are unavailable or cannot be applied: version control, side-by-side (or diff) comparison, change tracking, testing frameworks, build systems. • Visual primitives take up significantly more space than text. • Existing tools are of low quality. • Performance is overall slow. • There are no extensibility mechanisms. • The target group seems to be novice users. • There is no universal visual representation. • VPLs create closed ecosystems.

You might be about to tackle these pretty well. ;)

> I am really happy that we were able to overcome all design problems and make these two representations 100% compatible. TBH, when we were starting Enso, we were not aware how many corner cases and tricky technical details we would need to solve in order to bring it to the world!

I bet. Especially at the level of integration that you're aiming for. My own humble prototype was as simple as I could come up with and already revealed some major issues that a real-world implementation would have to grapple with.

Would you say performance was one of the tricky bits? What was the most tricky?

[wdanilo]

> Certainly. I was struck by it a few years back, around the same time as Luna was in early alpha stage. In fact I found it while doing research for my thesis, based on this vision. I was naive enough to think I had an original idea when I started.

That's quite a story! I don't know what you do now in your life, but sharing the same vision is absolutely crucial for our team and if you are up to talk about collaboration, I'd love to chat with you! If so, ping me at [e-mail]! <3

> And the only sensible way around these problems is to integrate both. Just this idea addresses most of the relevant criticisms of visual programming languages. A list of these I compiled at the time was [...] You might be about to tackle these pretty well. ;)

100% this! This is what I was trying to express in one of the parts of our blurb text of this post. Most visual languages are ... not really languages. They lack abstraction mechanisms and love. A love that is needed to make a production-ready tool. Textual languages are working really well because we put a great amount of love in developing them. We have seen a lot of visual languages solving domain specific problems much better than textual ones – Sidefx Houdini for example. And we believe that with much more dose of love, we are able to apply visual programming everywhere where people are processing data that can be visualized and where interactivity of the creation process matters :)

> I bet. Especially at the level of integration that you're aiming for. My own humble prototype was as simple as I could come up with and already revealed some major issues that a real-world implementation would have to grapple with.

I believe that anyone who tried implementing something similar would totally understand it! This is also one of the reasons the criticism appears. It is hard to develop a robust programming language. I believe that developing visual one is even harder than textual one, as you have this additional graphical UX element, that is not as heavily researched as the textual layer we all know.

> Would you say performance was one of the tricky bits? What was the most tricky?

A lot, lot of things! Including:

- Performance (obviously).

- The way errors and exceptions should propagate (you want to have exceptions in low-level text API, but they do not make sense in the graphical layer). We have special conversion mechanism that allow you to convert exceptions to dataflow errors now.

- The language mechanisms. Algebraic data types, type-theory. For example, Enso has a notion of Atoms – similar to ADTs constructors, but each one being a separate type. Also, Atoms can be shared between types. What's interesting, Enso type system does not have subtyping. Instead, we think about our types like about set of values. So for example, it is correct to write in Enso `1 : 1 : 1 | 2 : Natural : Number : Any` (read `:` as "left side is contained in the set defined by the right side). We designed a lot of stuff around this custom type system in order to make the language extensible, easy to use, and play nicely with foreign typed and untyped languages.

- Memory management. If you want to have a robust visual environment, non-connected nodes cannot influence each other. So Enso structures are immutable. How to make that efficient was very tricky.

- Currying, good support for recursion was tricky as hell. We always wanted Enso to be both powerful and easy to use. Nodes that do not have all connections plugged in are curried functions – which gives you so much power in a very natural fashion. However, in order to make that JIT well in a dynamicaly typed land, is tricky as hell.

- Proper recursion handling. This requires segmented stacks and a lot of low-level utilities you'd not normally get on JVM / GraalVM.

- Visual layer – in order to create really high performance GUI we settled down on implementing our custom WebGL vector shapes rendering system based on Signed Distance Functions rasterization (https://en.wikipedia.org/wiki/Signed_distance_function). The results are amazing, we are able to render thousands of connected nodes in 3-4ms per frame (of course as tests, no one is creating such big scenes - Enso allows you to collapse nodes together to keep workspaces small and well layouted).

And TBH, many, many more! Looking from a time perspective, that was a good technological journey. I cannot be happier that we successfully did it. We would never ever do it without exceptional team of genius developers we have. Hey Enso team! Thank you for that <3