[wdanilo]

It did come naturally, kind of! This is the one thing we heavily underestimated when starting Enso – the amount of time that is required to make the language's design consistent in both representations. In fact, our desire to create a REAL programming language with strong math background was a two-sided sword. It took us a significant amount of resources, but at the same time, it provided us with a very consistent and a well working solutions.

The same is applied to our data-flow errors. Think of them like about Haskell's `Either` or Rust's `Result` types, but with automatic lifting (automatic applicative functor lifting). So in Enso, you can have a "broken value", like a string read from a file that could be broken because the file did not exist, but you can still concatenate it with other string WITHOUT using any special syntax, and the result may also be broken. In Rust and Haskell you can do the same, but with a special syntax like `(+) <$> str1 <+> str2`.

I hope it clarifies some things under the hood! :)

[infinite8s]

Yes, thanks that makes sense now that I think about it. I never made the connection between visual UIs and functional programming!

[wdanilo]

I believe that functional programming with immutable memory is the only model you can use in order to create a visual language that you can reason about. E.g. you do not want to allow some nodes (visual components) to affect the execution of other nodes if not connected with each other. There are many more such implications there!