wdanilo
Joined 12 years ago
Karma
546
Submissions
214
Member since
Oct 5
Recent submissions
Comment · 2 years ago
Hi! Some friends of mine, ex-YC founders were drowning in a flood of emails from investors and clients. To save themselves, they built an internal tool that worked so well, they decided to package it into an app (I was helping them a little bit).
There is a bunch of tools that allow you to create summaries, help writing replies, etc, but Blinkfeed builds the UI/UX around these concepts, delivering something way more refined than anything I've seen. What do you think about it?
Comment · 5 years ago
Congratulations, Arnaud! I really like the idea of your tool. I was using many tools to track dev productivity in the past – with all kind of charts and plots. Somehow, I never got answer to the question "what do we really spend time on? Is this mostly bug fixing, delivering new features, and how does it affect our KPIs?". I like that Echoes focuses exactly on that.
I've got one question – would it be possible in the future to generate some kind of alerts for the managers when for example the technological debt is growing above some threshold?
Comment · 5 years ago
Thank you for the nice words, we do our best! <3
Regarding collaboration, absolutely! Unicorns are born only from group effort :) Join our Discord at https://discord.gg/enso and let's have a chat!
Comment · 5 years ago
That's right, we will be able to cut it down in the future. Let me explain why:
1. Enso compiler bases on GraalVM which is 400Mb (packed)[1].
2. The package contains GraalVM implementations of Python[2], R[3], and JavaScript[4] compilers, which weight 150Mb, 70Mb, and 50Mb respectivelly.
3. The package contains OpenCV library, as Enso has built-in bindings for it, which is 200Mb.
4. The rest (approx 200Mb) are core Enso libraries and tooling.
We will be able to cut it down in the future as soon as we release Enso Marketplace which would allow you to install these things on-demand.
[1] https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm...
[2] https://github.com/oracle/graalpython
Comment · 5 years ago
Btw, I think it's a good time to also announce that we have just started an "Enso Partnership Program" – long story short, if you have an idea of what you want to build on top of Enso, we'd like to help you deliver it! <3 Just tell us what you want to build by filling up this form (https://airtable.com/shrsnx2mJuRn0MxIS) and we will provide you with:
1. Dedicated Enso Expert. We will assign you with a dedicated Enso Expert from our side who will be responsible to help you build your use case and guide you step by step in case you have any problems.
2. Priority Bug Fixing. Enso is currently in alpha stage, so it contains bugs and is rough around the edges. We are working really hard on improving it, but bugs will occur. In case any bug will prevent you from progressing, we will focus on resolving it ASAP. It would normally mean, that you should expect fixing it in hours / days after reporting it!
3. Project Delivery Guidance. We want to guide you how to get your project on track and how to progress trough all of its stages, from the initial planning, trough prototyping, till releasing the working version. Based on our experience, it is best if you will have design / progress calls with the assigned Enso Expert once a week. Normally, 30 minutes call should be more than enough to be sure that everything goes according to the plan.
4. Extended Support. We know how important it is to get help when you are building things. We will try to reply to your questions in max 1 hour after you ask them. Of course, we are not able to cover all timezones right now, but we will do our best, especially in the range of 8 am - midnight CET.
5. Enso stuff. We would love to share with you how we appreciate that you are building things on Enso. We would love to send you some cool Enso stuff (like t-shirts, stickers, hoodies).
Comment · 5 years ago
We're looking forward to your feedback! <3
Comment · 5 years ago
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
Comment · 5 years ago
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!
Comment · 5 years ago
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
Comment · 5 years ago
> 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 [email protected]! <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
Comment · 5 years ago
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 [email protected] ! :)
Comment · 5 years ago
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! :)
Comment · 5 years ago
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 :)
https://www.linkedin.com/in/wojciechdanilo https://twitter.com/wojciech_danilo