[HN Gopher] Launch HN: Enso (YC S21) - Visual programming and wo...
___________________________________________________________________
Launch HN: Enso (YC S21) - Visual programming and workflow
automation tool
Hi HN, We are Wojciech and Sylwia, the co-founders of Enso
(https://enso.org). On the tech side, Enso is a visual and textual
programming language (you can switch from graph to code and back).
On the business side, it's a workflow builder that makes it easy
for analysts without a programming background to automate data-
driven processes simply by connecting visual components together.
Our GUI is like an IDE, but with a graph editor alongside the code.
Currently, we're focused on data analysis--data preparation,
blending, and analytics (both in-memory and SQL). You can see a
video of how it works here: https://youtu.be/fQvWMoOjmQk. We used
to be called Luna and were lucky to have a few big threads on HN
over the years [1][2][3][4][5]. Eventually we went into heads-down
mode to make a production version based on customer and user
feedback. Since then, we've drastically improved the product. It is
still rough around the edges, but works much better now. We have
also made a few tutorials
(https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw), and
docs (https://enso.org/docs/syntax). We've added many new
libraries, so you can do many more things with it now. Oh, and we
changed the name to Enso and got accepted to YC! :) The problem we
address is that data analysts still waste up to half of their time
on repetitive manual work that can be automated [6]. To give one
example, a company we're working with hires business users who use
Excel to define data quality rules. These get manually translated
to SQL, then manually translated to Python. This is not only error
prone, it's so slow that it takes them 90 days to introduce a
single new rule. There's 60 days' worth of overhead in this process
--it's insane! Years ago I (Wojciech) led the in-house development
of visual effects (VFX) tools at a motion picture studio. We made
tools like cloud renderers and smoke simulation engines. The
artists using these tools did not have any programming background,
yet they were designing complex algorithms for forces between
particles, light subsurface scattering, things like that. Earlier
generations of these tools had hundreds of config options, buttons,
etc., for masses of different use cases, but this approach got way
too complex and people eventually realized that it falls short when
you need to do anything that the vendor did not think of. Nowadays
they use node-based software (like the Houdini FX) which lets users
draw algorithms as a sequence of data processing steps (these steps
are often referred to as "nodes"). Later, when I was working in
other industries and encountered the same rats' nests of complex
GUIs for solving data processing problems, I realized that the data
analytics/science space was in need of the same breakthrough that
we had already gone through in the VFX space. Most visual
programming languages / workflow-builders do not scale well because
they don't let users express abstractions. Try to build a complex
pipeline and you'll end with an unreadable spaghetti of connections
--it's like coding a web app in assembler. Enso is different
because we allow you to build abstractions to manage the
complexity. As a result, you never have more than 10-20 nodes on
the stage in Enso (nodes are hierarchical). You can create custom
data types, custom components (functions), catch errors, etc. All
this works because under the hood, Enso is a real programming
language. However, naive implementations of such systems are super
slow. Each component may be built of hundreds, sometimes thousands
of lower-level ones. The real trick is making these hierarchical
components run fast. For that you need a dedicated compiler and a
runtime system, and this is a hard technical space. Our system
involves a dedicated JIT compiler based on GraalVM. For details,
see https://enso.org/language#compiler. In case this is interesting
for you, here is our podcast about how the compiler works under the
hood: https://www.youtube.com/watch?v=BibjcUjdkO4. Enso is
interactive, meaning that we recompute the relevant parts of graphs
as parameters change, which shortens feedback loops dramatically.
Like a lot of people on HN, we were inspired by Bret Victor's
classic talk on instant feedback:
https://www.youtube.com/watch?v=8QiPFmIMxFc. We've also put a lot
of effort into extensibility. You can add Java, JavaScript, R, and
Python (soon also Ruby, Scala, Kotlin, Rust, and C) directly into
Enso nodes without the need to write any wrappers and with a close-
to-zero performance overhead. Enso is open source. Our compiler
code is at https://github.com/enso-org/enso and our GUI code at
https://github.com/enso-org/ide. Our business model is based on
selling domain specific libraries, on-premise installations with
enhanced user permission management, and coming soon, a hosted
solution called Enso Cloud, which will be our only non-open-source
codebase. Since this is Hacker News, I should add that all our
alpha releases collect anonymous usage statistics which we use to
improve Enso and prepare it for a stable release. Full details
about that are always in our release notes
(https://github.com/enso-org/ide/releases/latest). Dear HN
friends, we are super excited to show Enso to you. Please, share
with us your thoughts, experiences, ideas and feedback. It is
insanely important to us, as our dream is to make Enso the most
useful data processing platform in your toolbox! Also, in case
you'd like to build your projects on top of Enso, we would love to
help you do it - describe what you have in mind here, and we will
reach out to you: https://airtable.com/shrsnx2mJuRn0MxIS :) ===
Links === [1] _Luna: Visual and textual functional programming
language_ - https://news.ycombinator.com/item?id=11144828 - Feb
2016 (100 comments) [2] _Luna - Visual and textual functional
programming language_ -
https://news.ycombinator.com/item?id=14612680 - June 2017 (310
comments) [3] _Luna 1.0 Beta is out_ -
https://news.ycombinator.com/item?id=16163769 - Jan 2018 (167
comments) [4] _Luna Studio - Visual and textual functional
programming language_ -
https://news.ycombinator.com/item?id=17704989 - Aug 2018 (64
comments) [5] _Luna - A WYSIWYG language for data processing_ -
https://news.ycombinator.com/item?id=20182090 - June 2019 (86
comments) [6] https://www.alteryx.com/e-book/idc-study-the-state-
of-self-s...
Author : wdanilo
Score : 107 points
Date : 2021-07-06 14:05 UTC (8 hours ago)
| sonograph wrote:
| This looks fantastic and I'll dive into this more when work
| abates. Meanwhile, I'm curious if the visual/diagramming
| framework for the Enso language (on this page:
| https://enso.org/language ) is open source as well somewhere?
| wdanilo wrote:
| Thank you! And of course, everything (but the Cloud management)
| is Open Source on our end! You can find our custom WebGL
| rendering engine here (https://github.com/enso-
| org/ide/tree/develop/src/rust/ensogl), our event FRP handling
| system here (https://github.com/enso-
| org/ide/blob/develop/src/rust/lib/fr...) , and other related
| libraries here (https://github.com/enso-
| org/ide/tree/develop/src/rust/lib). They have pretty good
| documentation and a lot of example demo scenes, however, in
| case you'd struggle with using them, join our chat
| (https://discord.gg/enso) and we'd love to help you getting
| started! <3
| jgmmo wrote:
| No offense intended, but I hate the name.
|
| I was a huge fan of the Enso program launcher made by Humanized
| back in the day. Aza Raskin I think it was. I got so excited when
| I saw this said Enso, but alas..
| OoTheNigerian wrote:
| Perhaps say something positive too? People have worked hours on
| end, built stuff and presented it "hacker peers" and this the
| best and only comment you could come up with?
|
| For someone that has done a couple of Show HNs [1][2] I would
| assume you know better.
|
| People plan for their submissions and look forward to reading
| the comments. You can and should do better.
|
| [1] https://news.ycombinator.com/item?id=10799830 [2]
| https://news.ycombinator.com/item?id=9840990
| Chris2048 wrote:
| Why sugar-coat it. This project has the same name as another
| fairly famous one. There's nothing positive in this comment
| either.
| prawn wrote:
| Seems odd to hate a business' name choice purely because you
| were briefly disappointed that something clearly labelled as
| "Visual programming and workflow tool for data science" wasn't
| the "program launcher" you expected?
| ZeroCool2u wrote:
| Congrats on the launch! I really hope you guys have some luck
| unseating some of the rough products in this niche today like
| Alteryx. They're terribly unpleasant to use and Enso seems like a
| huge improvement.
| wdanilo wrote:
| Thank you! We hope for it as well. We really hope that Enso
| would eventually become applicable to a much broader space than
| Alteryx is applicable nowadays. In fact, Enso already provides
| much more powerful toolset in many cases, like unstructured
| data processing, true polyglot support, high-performance
| visualizations, interactivity, true batch-mode, etc. On the
| other hand, we are aware that there are still bugs and that our
| onboarding is far from perfect.
|
| Anyway, I would really love to chat more with you about these
| cases if you'd like too! We are looking forward to work with
| companies in this space and we are providing them with a very
| special deals now, including lifetime discounts, dedicated team
| members building highly tailored libraries, and helping solving
| data-related problems! If that sounds interesting to you,
| please write to me a short message at wojciech.danilo@enso.org
| ! :)
| neolog wrote:
| There is already a visual programming language named Enso. Is
| this related to it?
|
| https://github.com/enso-lang/enso
| wdanilo wrote:
| No, it's not. TBH, we were not aware about it until recently,
| when someone from our community mentioned this project. It
| looks not maintained anymore nowadays, but I think it's a good
| idea to reach out to its authors, tell "hi" and chat about our
| co-existence! I'll do it :)
| neolog wrote:
| Fwiw there was a commit in June 2020
| djedr wrote:
| Hi Wojciech, congratulations!
|
| It's good to see the idea taking more and more shape. I think the
| combination of a text-based and visual language is the only
| viable path to general-purpose visual programming.
|
| This is a vision worth pursuing.
| wdanilo wrote:
| 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 wrote:
| > 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 wrote:
| > 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
| wojciech.danilo@enso.org! <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
| escot wrote:
| Luna was really inspiring to me. I'm really interested to see how
| this goes.
|
| I remember Luna previously having rendering perf issues using a
| canvas element. How is the perf with Enso?
|
| Small thing, I noticed this typo:
|
| > the ease with which you can ready and write code
|
| On: https://enso.org/docs/syntax
| wdanilo wrote:
| Thank you :)
|
| You are absolutely right! Luna was our prototype with several
| issues - slow GUI, low compiler performance, and lack of
| extensibility. That's why we went into heads-down mode for
| almost 2 years to make a production version based on customer
| and user feedback. As a result:
|
| 1. Rendering Performance. We have created a custom WebGL-based
| vector shapes renderer which is really fast (we have tests of
| rendering over a million of points at 60 FPS on my MacBook):
| https://github.com/enso-org/ide/tree/develop/src/rust/ensogl
|
| 2. Computing Performance. We have rewritten the compiler from
| scratch. We used the GraalVM / Truffle framework under the hood
| as our core JIT framework, and we have added tons of custom
| optimizations on top of it (e.g. to efficiently support
| immutable memory, currying, etc). As the result, Enso is right
| now up to 80x faster than Python (benchmarks:
| https://github.com/enso-org/benchmarks).
|
| 3. Extensiblity. The new Enso is a fully polyglot language - it
| allows you to literally copy-and-paste code in Java,
| JavaScript, R, and Python (soon also Ruby, Scala, Kotlin, Rust,
| and C) directly into Enso nodes without the need to write any
| wrappers and with a close-to-zero performance overhead. You can
| even create closures in the visual environment and pass them as
| arguments to functions in e.g. JavaScript, which will call them
| with objects created in JS, which will be understood by the
| Enso nodes! See our videos and compiler section here to learn
| more: https://enso.org/language
|
| Did I answer your questions? :)
|
| --- EDIT ---
|
| Thanks for catching the typo! Fixed :)
| escot wrote:
| Thanks. I downloaded (mac) and played around a bit and have
| some notes below. I'm not a data analyst, just a programmer
| interested in new programming systems.
|
| - On the signup screen I accidentally clicked 'sign in with
| google' then reailzed I didn't want to, and I don't think
| there's a way to go back to the first screen (without
| restarting the app)
|
| - When I go to Help -> Documentation in the mac native menu
| bar I get a link to electronjs documentation, not Enso docs
|
| - The button in the top right that looks like a power button
| was a bit confusing. I didn't understand what it did
| immediately and there's no tooltip to explain it.
|
| - I noticed a bug where if I hit the spacebar multiple times
| quickly to toggle the result view the entire canvas goes
| blank, then comes back if I hit the spacebar again
|
| - I found it a little confusing that the args of a node are
| displayed as a var name even when the exact input is known.
| For example I had the constant `6` as an input to a function
| `n.up_to` which rendered as `number1.up_to` when I expected
| to see `6.up_to`.
|
| - I didn't find it intuitive that you cant (I think) edit
| existing nodes. Do you have to create new ones from scratch,
| or copy/paste somehow?
| wdanilo wrote:
| Thank you for the list! Answering shortly:
|
| > On the signup screen I accidentally clicked 'sign in with
| google' then reailzed I didn't want to, and I don't think
| there's a way to go back to the first screen (without
| restarting the app)
|
| Noted! Will be fixed :)
|
| > When I go to Help -> Documentation in the mac native menu
| bar I get a link to electronjs documentation, not Enso docs
|
| Oh, I was not aware that it is there! We will remove it.
| Thanks for catching it! :)
|
| > The button in the top right that looks like a power
| button was a bit confusing. I didn't understand what it did
| immediately and there's no tooltip to explain it.
|
| One of the things that we are improving now is adding
| hover-labels for buttons with explanation of what they do.
| We also want to make the UX much more approachable by new
| users. It will take us some time (a few weeks, as it's
| planned after fixing stability issues), but it's already on
| our short-term plan to be added!
|
| > I noticed a bug where if I hit the spacebar multiple
| times quickly to toggle the result view the entire canvas
| goes blank, then comes back if I hit the spacebar again
|
| I cannot reproduce it. Would you be so nice and create an
| issue report with a short screen recording and your machine
| spec here, please? https://github.com/enso-org/enso/issues
|
| > I found it a little confusing that the args of a node are
| displayed as a var name even when the exact input is known.
| For example I had the constant `6` as an input to a
| function `n.up_to` which rendered as `number1.up_to` when I
| expected to see `6.up_to`.
|
| This is one of the things we are currently working on! This
| will be much improved in one of the following minor
| releases (we will do a release every week now).
|
| > I didn't find it intuitive that you cant (I think) edit
| existing nodes. Do you have to create new ones from
| scratch, or copy/paste somehow?
|
| You can do it. We use double-clicking to ENTER the
| collapsed nodes. To edit the node use `CMD + Left Mouse
| Button` on the expression (or `ctrl` if you are not Windows
| or Linux). The full list of shortcuts is here:
| https://github.com/enso-
| org/ide/blob/develop/docs/product/sh...
|
| We want to add an icon for that as well, so it will be
| easily discoverable in the future.
|
| I'm really happy that most of these points cover with our
| dev plans! It means that in a few weeks you'll have a much
| better experience <3
| munro wrote:
| I really love the concept of the product! I downloaded it played
| with it a bit, but I found it very unintuitive, and had some
| serious UX issues. I'm on a Mac.
|
| * Scrolling the preview would often pan the entire window
|
| * Panning the window was really sluggish
|
| * It was really hard to drag lines, it felt like I had to be
| pixel perfect--I've been such a big fan of the idea of visual
| editor, but I really started to see what this user was talking
| about with wrist issues [0]
|
| * It was really hard to modify a block of code, I tried mouse
| click + every different modifier I could think of, it felt random
| what allowed me to edit text, and then it kept "exiting" the text
| edit mode.
|
| * Modifying a block of code felt like it was lacking a lot of
| text editing that a modern editor like IntelliJ or VS Code has.
|
| * The auto complete had something weird going on, I don't exactly
| remember, but I think one problem was I couldn't use my mouse to
| scroll the list
|
| * Small things surprised me, like how much white space mattered,
| like if I had an "<operator> .map", it wouldn't work, and I had
| to edit it to be "<operator>.map", which makes sense--but it was
| sooooooo hard to remove that space, because the editor kept
| exiting text editor mode by small user input mistakes
|
| I kept thinking it was just a learning curve, so I really tried
| to not let little things get to me, and read the docs, but in the
| end I just gave up. It was just too hard.
|
| [0] https://news.ycombinator.com/item?id=27706356
| hobofan wrote:
| I hit exactly all of those pain points too!
|
| Tried out Luna, back when it was first announced and had
| horrible performance problems with it back then. Decided to
| give it a second try now, as I still think there is place for a
| tool like it, but it's sad to see that it's still plagued with
| the same performance problems (even though I upgraded machines
| in the meantime).
| wdanilo wrote:
| Luna was our early prototype and it indeed had significant
| performance problems. Our new JIT compiler is able to execute
| the graphs really fast (in fact, in many cases we are up to
| 80x faster than Python nowadays: https://github.com/enso-
| org/benchmarks).
|
| However, sometimes we see that the WebGL is super-slow on
| some machines. May I ask you for more details, please? The
| important bits would be whether you experience the slowdown
| when using the IDE (like dragging, zooming) or when waiting
| for data to be computed? In both cases, we would be more than
| thankful for an issue containing machine spec:
| https://github.com/enso-org/enso/issues .
|
| Enso should work for you with the same visual performance as
| in this video (this was recorded on a few years old MacBook
| Pro): https://youtu.be/fQvWMoOjmQk . If its not this smooth,
| we need to investigate it, because this is something system /
| machine specific.
|
| There is unfortunately no other way for us to improve and
| progress from alpha to beta, so we will be very thankful for
| help here! <3
| wdanilo wrote:
| Hey, thank you for the detailed list of issues.
|
| 1. Some of your points surprised me a lot, including "Scrolling
| the preview would often pan the entire window", "Panning the
| window was really sluggish", and "It was really hard to drag
| lines" - these should not happen. We are heavily testing Enso
| on macOS and these issues are not known. I know I'm asking for
| a lot, but would you be so nice and have a 15 mins call with me
| so I could see how Enso behaves on your end?
|
| 2. Some of these points did not surprise me - our text editor
| is really broken right now and this is one of the things we are
| improving for the next release. That's why we normally do not
| even tell people how to open it! However, if you had any issues
| with editing expressions on nodes (cmd + left mouse button),
| I'd love to know more about that as well.
| munro wrote:
| As I was typing, I was thinking the same thing, it would be
| easier to just show you my process. So I would love to!
| x05x39@gmail.com
| wdanilo wrote:
| Amazing, I'll reach you out! Thank you so much! :)
| dragosbulugean wrote:
| Hi Wojciech and Sylwia, congrats on the launch!
|
| I followed the previous launches as well. I'm curious, what
| triggered the rebrand? Is there a story to it?
| wdanilo wrote:
| Thank you! That's a good question and yes, there is a small
| story to it. There were several problems with the old name. A
| lot of people were confusing "Luna" with "Lua", the name is so
| popular that absolutely good website names are already taken,
| and also, "Luna" has no logical connection to what we do.
|
| On the other hand, the name "Enso" is not similar to any of the
| popular languages names, we have a beautiful https://enso.org
| domain, and also, in Zen, enso (Yuan Xiang , "circular form")
| is a circle that is hand-drawn in one or two uninhibited
| brushstrokes to express a moment when the mind is free to let
| the body create (source: Wikipedia). This is exactly what we
| want Enso to be - a creative canvas with two perfectly
| connected parts - the textual and visual one :)
| kfk wrote:
| Hi there, I think we are both based out of Krakow? Anyway, how
| does Enso fit in the Cloud ecosystem? Basically all data
| analytics is moving over to Cloud the way I see it with CI/CD and
| version control practices becoming more the norm. I know many
| people in Enterprise are still doing local dev in Excel, Alteryx,
| PowerBI, but that process is hard to productionalize in my
| experience.
| wdanilo wrote:
| Hi! Good to see a fellow Krakow citizen! :)
|
| Enso is cloud ready! It has two parts - web-based UI + server-
| side compiler / data crunching engine. The version you are able
| to download from our website just contains both parts glued in
| a single application. We will be releasing Enso Cloud (hosted
| version) soon! However, it is very important for us to have the
| desktop version as well, so everyone can just use it for free
| :)
|
| I hope it makes sense to you? :)
| kfk wrote:
| Yes it does, thanks! Of course I have a lot more questions
| now but I will contact you guys. I like the way you are
| approaching data and I think you have a fresh look compared
| to more classic tools like Alteryx. I hope your pricing will
| make sense as these tools now compete with PowerBI which does
| have some light ETL capability (pbi gives people more than
| enough rope to hang themselves in fact).
| wdanilo wrote:
| I would love to chat about the cases you have in your mind!
| We really want Enso to redefine the data analysis
| environment and thus, we also want it to be accessible to
| the wide audience of customers. That's why we have the free
| Open Source version and we are trying to have a very
| flexible pricing that suits wide range of companies. I'd
| love to talk more about it too! If that works for you,
| please ping me via our chat (https://discord.gg/enso) or
| via email (wojciech.danilo@enso.org)! :)
| chaostheory wrote:
| I've seen this a month or two ago and I was impressed. Love the
| name too because it is much easier to Google vs Luna.
|
| I did run into some issues with running it in Windows. If I have
| time this week, I'll will try to post the issue on GitHub
| wdanilo wrote:
| Thank you <3
|
| I'm really sorry to hear that you had issues with running it!
| In case you do not have enough time to report the issue, just
| make a screenshot and post it on our chat
| (https://discord.gg/enso). We will then create the issue for
| you and we will let you know as soon as it will be resolved. We
| might also ask you for some additional info, but we'll try not
| to take too much time of yours! It is very important to us to
| fix all the issues for the upcoming stable release :)
| dustingetz wrote:
| Can you express closures? Can I see an example of a visual
| closure?
| wdanilo wrote:
| Yes, you can! Enso is a purely functional language with
| currying, immutable memory, algebraic data types, data-flow
| errors, type inferencer, JIT compiler, and even a special kind
| of a monadic type system with auto-lifting (although we do not
| expose the ability to define custom monads to the users yet) :)
|
| You can create closures in multiple ways:
|
| 1. The simplest and most visual is by using currying! If you
| create a node (a visual component) and you do not connect all
| its required inputs, the output of the node is the curried
| function (function with partially applied arguments). You can
| then connect it to other expressions, like `map`.
|
| 2. Another way is to use expressions on nodes. You can use the
| lambda syntax, like `x -> x.noise` to define a lambda. You can
| also make it shorter by using curried operator sections `(.
| noise)`, and even shorter by using the Enso's operator
| precedence as `.noise` and use it for example as `map .noise`.
|
| If you want to learn more about Enso syntax, we have a page
| describing it here: https://enso.org/docs/syntax . Also, if you
| go to our language-focused subpage, please check out the video
| named "Higher order functions". It does not show currying, but
| it shows the usage of the expressions on the nodes:
| https://enso.org/language
|
| Did I answer your question? :)
| infinite8s wrote:
| Currying visual nodes that way is an amazing idea! Did it
| just come about naturally as you were building out the higher
| level language aspects? Most visual UIs choke if everything
| isnt fully wired up.
| wdanilo wrote:
| 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 wrote:
| Yes, thanks that makes sense now that I think about it. I
| never made the connection between visual UIs and
| functional programming!
| wdanilo wrote:
| 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!
___________________________________________________________________
(page generated 2021-07-06 23:00 UTC)