Pomóżcie nam poprawić Enso :)

Cześć, nazywam się Sylwia i jestem co-founderem Enso (https://enso.org, Y Combinator S21) :)

Czym jest Enso?

Enso jest wizualno-tekstowym językiem programowania z podwójną reprezentacją stworzonym do interaktywnej analizy danych, definiowania procesów ETL i ich automatyzacji.

Dodatkowo Enso pozwala na używanie bibliotek Javy, JSa, Pythona i R bez dodatkowych wrapperow i z bliskim zeru narzutem na performance. Jest to możliwe dzięki temu, iż JIT kompilator Enso (bazujący na GraalVM), kompiluje te języki do tej samej pośredniej reprezentacji z ujednoliconym modelem pamięci.

Enso jest w 100% Open Source i darmowe do użytku na desktopach. Przygotowujemy właśnie release Enso Cloud, które będzie pozwalało na rozpoczęcie pracy z Enso po pojedynczym kliknięciu, bezpośrednio w przeglądarce.

Czemu tu piszę?

Właśnie wydaliśmy kolejny update do naszego produktu: undo-redo, nowe biblioteki, poprawki stabilizacji oraz performance'u. Enso jest ciągle w fazie alpha, jednak już posiada duże możliwości.

Drodzy, ponieważ jesteśmy startupem wywodzącym się z polskiej sceny bardzo docenilibyśmy Wasze wsparcie - jesteśmy na etapie poprawiania stabilności i użyteczności Enso i wszystkie uwagi są dla nas bardzo cenne – te pozytywne i negatywne (które przewijają się tu czasem w innych wątkach o nas) :)

**Jeżeli podoba Wam się co robimy – dajcie nam znać o use casach w których widzielibyście Enso i kliknijcie gwiazdkę na naszym GitHubie (https://github.com/enso-org/enso :) **Tworzymy technologię mającą szansę zmienić obraz Data Science na świecie i chcemy, by polska marka na międzynarodowej scenie znów zabłysła.

Z use caseów to może dla szkół podstawowych, by uczyć programowania. Taka postać byłaby trochę świeższa niż jakieś stare programy blokowe.

Ewentualnie jako pomost dla różnych DSLi pisanych pod nietechnicznych ludzi, np. języki do określania schematu jak ma się zachować bot w trakcie chatu.

Poza tym brak pomysłów. Zdziwiłbym się bardzo, gdyby ktoś wybrał takie blokowe (chociaż ma to wygląd to odczytanie / edycja zajmuje więcej czasu niż praca z kodem).

Zapytam bez złośliwości: co dokładnie jest startupem? W jaki sposób rozwój języka wpływa na działanie / zyski firmy?
Wybacz, ale samo posiadanie publicznego repo na GitHubie nie czyni z Enso projektu Open-Source na obecnym etapie prac - 18 osób pisało kod, z czego 12 ma więcej niż 1 commita i 95% z nich pracuje dla Was. Pytanie moje zatem - czy zamiast zaoferować komuś pracę, proponujecie udział w projekcie pro bono?
Życzę Wam powodzenia i oby projekt się rozwijał, ale niejasne jest uczestnictwo w nim.

@pprog123: Hej, dzięki za odpowiedź. Co do use casów – pytaliśmy o bardziej konkretne zastosowania w firmach w których np. pracujecie. Zdecydowanie nie idziemy w stronę Ed-techu :) Mamy kilka ciekawych wdrożeń enterprise (banking / pharma / IoT) – w dużym skrócie pracujemy z osobami z takich działek jak marketing, operations, lub finanse i używamy Enso do automatyzacji procesów danych (ściąganie danych z baz danych, blendowanie ich z plikami, czysczenie danych, automatyczna analiza, aktualizacja wyczyszczonych zbiorów danych). Takie workflow w Enso mogą być budowane przez nieprogramistów – ludzi technicznych z mocną wiedzą domenową, np. ex-zaawansowanych użytkowników Excela.

Mamy też kilka firm które na Enso budują rozwiązania z innych działek – np. mamy grupę "Ex-Autodeskowców" którzy rozszerzyli Enso o viewer modeli 3D i pozwalają na analizę instalacji energetycznych swoim klientom.

O takie use casy pytała bardziej Sylwia, przepraszamy że tego nie sprecyzowaliśmy! :)

@Pipes: Odpowiadając na pytanie – startupem jest produkt który budujemy na Enso – narzędzie do automatyzacji procesów bazujących na danych. To narzędzie bazuje na naszym języku, co daje nam fajną prędkość przetwarzania danych i rozszerzalność. Ale produktem nie jest język – produktem jest narzędzie do ETL / data-driven process automation.

Co do Open Source – nie zgodzę się z Twoją definicją. Wikipedia, dla przykładu, mówi "Open source is source code that is made freely available for possible modification and redistribution." – więc tak, Enso jest Open Source. I tak, zatrudniamy ludzi którzy zaczynają być dobrymi kontrybutorami – 1/3 teamu tak do nas dołączyła.

Co do "Życzę Wam powodzenia i oby projekt się rozwijał, ale niejasne jest uczestnictwo w nim." – dzięki serdeczne! Uczestnictwo w projekcie bazuje na kontrybucjach lub zatrudnieniu na umowę o pracę lub umowę B2B jeżeli jesteś spoza Polski. Czy to tłumaczy "uczestnictwo w projekcie"? :)

Takie workflow w Enso mogą być budowane przez nieprogramistów – ludzi technicznych z mocną wiedzą domenową, np. ex-zaawansowanych użytkowników Excela.

A czemu ten Enso w takim razie nie jest jakimś odświeżonym excelem? Skoro grupa docelowa to osoby ze swiata ex-excela to sam Enso nie musi sobie tutaj ograniczać zastosowań.

Po prostu niech:

1. ładuje więcej danych niż excel
2. oferuje macra i nagrywa je do enso, a jak ktoś będzie miał chęć zmiany to sobie przeniesie bloczek

W excelu fajne jest to, że to człowiek w nim wymyśla zastosowanie do nowego problemu, a nie odwrotnie.

@pprog123:

A czemu ten Enso w takim razie nie jest jakimś odświeżonym excelem?

Ponieważ nie uważamy GUI Excela za coś najlepszego na świecie :)

W excelu fajne jest to, że to człowiek w nim wymyśla zastosowanie do nowego problemu, a nie odwrotnie.

Masz na myśli, że tutaj nowy problem wymyśla zastosowanie dla człowieka? Czytałem Twoje zdanie kilka razy i mówiąc szczerze, nie do końca rozumiem jaka była myśl pod spodem. Chętnie odpowiem jeżeli będziesz tak miły i ją doprecyzujesz :)

Czytałem Twoje zdanie kilka razy i mówiąc szczerze, nie do końca rozumiem jaka była myśl pod spodem.

Jasne chętnie odpowiem, podrzucam obraz, bo wart jest więcej niż 1000słów.

Ale gdybyś chciał o tym też poczytać to zostawiam link: https://www.notboring.co/p/excel-never-dies

Offtopowo trochę, ale

Jak wpłynęło uczestnictwo w YC na was/wasz produkt?

O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają warunki udziału w postępowaniu w zakresie zdolności technicznej lub zawodowej. Wykonawca spełni ten warunek, gdy wykaże, że posiada wykształcenie informatyczne stopień magister lub wyższy, minimum 15-letnie doświadczenie przy tworzeniu kompilatorów i programowaniu systemowym, minimum 5-letnie doświadczanie programistyczne w C++ przy tworzeniu kompilatorów i programowaniu systemowym, przynajmniej 2-letnie doświadczanie programistyczne w Rust przy tworzeniu kompilatorów i programowaniu systemowym, zaprojektował i stworzył przynajmniej 3 kompletnych implementacji kompilatorów, rozwijał i utrzymywał przynajmniej 5 różnych komercyjnych projektów kompilatorów, posiada komercyjne doświadczenie przy projektowaniu i tworzeniu kompilatorów i ich optymalizacji generujących kod Web Assembly, posiada komercyjne doświadczenie w programowaniu w przynajmniej 3 językach typu Assembler, posiada doświadczenie przy projektowaniu i rozwoju przynajmniej 3 systemów operacyjnych(!!!), posiada doświadczenie przy projektowaniu i rozwoju protokołów sieciowych (mainframes, workstations, and embedded systems), posiada komercyjne doświadczenie przy zarządzaniu projektami informatycznymi oraz posiada doświadczenie w pracy przynajmniej w jednym startupie. Baza Konkurencyjności - Creation of Luna 2.0 compiler

Czy ktoś u was spełnia te wymagania? :)

@pprog123: Mówiłem o tym, że Twoje zdanie "człowiek w nim wymyśla zastosowanie do nowego problemu, a nie odwrotnie" odwrócone brzmi "nowy problem wymyśla zastosowanie dla człowieka" i tej myśli nie rozumiem :)

@WeiXiao: To jest super offtopic i możnaby o tym rozmawiać godzinami. Zrobimy kiedyś spotkanie w Krakowie, chętnie opowiemy o wszystkim.

Nie widzę problemu żeby zapraszać ludzi do testowania produktu oraz dawania feedbacku. Ale (zawsze jakieś jest), ten produkt musi przynosić użytkownikom jakieś korzyści. Teraz pytanie klucz, czy język wizualny jest użyteczny dla programistów czy może bardziej zmierza w kierunku "hajpowanego" teraz nocode'u? Wydaje mi się że to drugie. Jako programista gdybym miał tak sobie przetwarzać dane i zrobić wizualizację to sięgnąłbym po prostu po Pythona (lub JavaScript). Nikt nie chce testować za darmo, mogę poświęcić czas na naukę narzędzie w fazie beta ale muszę też coś z tego mieć. A co może dać graficzny język programowania doświadczonemu programiście, niestety niewiele.

Radzę znaleźć faktyczną docelową grupę użytkowników (analitycy w korpo?, machine learning dla nieprogramistów?, coś innego?) i przedstawić im "elevator pitch" dla tego produktu aka co ja z tego będę miał że będę tego używał...

Tutaj wydaje się np. framework graficzny na raspberry PI czy (już publikowany) homebrew OS miałby większe wzięcie.

Na koniec gratuluję YC, to znaczne osiągnięcie jak na polski startup i życzę powodzenia w drodze do IPO i dominacji nad światem ;)

@Wibowit zainspirował mnie, więc czas na anegdotę z pewnej młodej firemki. Nasz marketningowiec był "ex-zaawansowanym" użytkownikiem Excela. Jako jeden z elementów kampanii marketingowych, służący do wysyłania emaili i śledzenia potem czy ktoś ten email otworzył, ponowień itp. używał toola X (już nie pamiętam co to był dokładnie za produkt). Grunt że integrował się z Salesforce'em i Mailchipem i to działało bez zarzutu.

Problem zaczął pojawiać się po około 12 miesiącach, gdy workflowy marketingowe znacznie się rozrosły (różne typu subskrypcji, 2 typy klientów) oraz pojawiała się potrzeba integracji w drugim kierunku Tool Marketingowy -> Salesforce. Chodziło o proste rzeczy jak zmiana statusu "Leadów" w SF. Zostało to również przez naszego eksperta wyrzeźbione ale zaczęło się załamywać pod własnym ciężarem.

Gdzie tkwił problem? Otóż tool pozwalał wyklikać workflowy ale już nie testy do nich. Coś co wydawać by się mogło, będzie out-of-the-box w XXI wieku. Bez testów i przy workflowach które nie mieściły się nawet na 2 x 4k monitorach, oraz bez możliwości tworzenia abstrakcji (subworkflow) narzędzie bardzo szybko stało się kulą u nogi. Ostatecznie workflowy zostały rozbite, a logika je wywołująca została przeniesiona do kodu gdzie można już było dodać testy itp.

Co ciekawe w tej samej firmie były testy na wysyłkę email'li z samego systemu, ale nie wiem dlaczego między marketingiem a działem testów nie było żadnego kontaktu, i sam workflow marketingowy nie był testowany. A skoro już jesteśmy tutaj to wspomnę jeszcze że wersjonowanie kodu odbywało się w ten sposób że były 2 środowiska test i prod, i jak po ręcznym dłubaniu i ręcznych testach (marketingowiec zarabiał 18k UoP, nie pytajcie skąd wiem ) "działało" to szło na produkcję.

Także @Wojciech Danilo kilka pytań:

• Czy jest sposób żeby automatycznie testować workflowy w Enso?
• Czy jest sposób żeby wersjonować kod w ten sposób że podpinam repo git'a do Enso i wszystkie zmiany będą lądowały jako komity w tym repo?
• Czy mogę tworzyć paczki, czyli kod + konfiguracja (np. klucze do API) którą mogę wrzucić do produkcyjnej instancji Enso tak żeby to deployować podobnie do kodu?

To są rzeczy których życzy sobie każdy rozsądny (i dbający o swój czas wolny) programista. Niestety nie tylko nocode ma tutaj mocne braki, z Saleforcem nie było dużo lepiej.

Tego typu programowanie wizualne mogłoby się sprawdzić przy robieniu gier (tak jak np. w Unreal Engine są Blueprinty). Czyli masz ludka i masz graf zachowań.

Albo jako edytor do materiałów do Three.js (bo toczą się dyskusje na temat tego, że taki edytor jest potrzebny: https://discourse.threejs.org/t/state-of-node-based-shaders-in-three-js-any-good-tutorials/28844/17 ).

Albo w inną stronę - narzędzie do scaffoldowania projektów we frontendzie. Czyli zamiast bawić się w konfigurację Webpacka, to łączyć node'y typu Sass, TypeScript czy inne. Albo żeby dało się stworzyć makiety komponentów React i dodawać logikę za pomocą przeciągania strzałek. (idąc dalej: pełne narzędzie typu no-code, ale to dzisiaj każdy startup próbuje, więc duża konkurencja).

Albo coś dla backendowców - żeby dało się toole na backendzie tak robić, czy usługi kontenerowe tak stawiać, że łączysz strzałkami. No ale to kontrowersyjny pomysł i pewnie by się nie przyjął z tej racji, że ta grupa docelowa lubi sobie czasem coś tam pokonfigurować w terminalu albo popisać w Vimie, bo to ich jara, a nie będą myszą nic robić.

0xmarcin napisał(a):

Także @Wojciech Danilo kilka pytań:

• Czy jest sposób żeby automatycznie testować workflowy w Enso?
• Czy jest sposób żeby wersjonować kod w ten sposób że podpinam repo git'a do Enso i wszystkie zmiany będą lądowały jako komity w tym repo?
• Czy mogę tworzyć paczki, czyli kod + konfiguracja (np. klucze do API) którą mogę wrzucić do produkcyjnej instancji Enso tak żeby to deployować podobnie do kodu?

To są rzeczy których życzy sobie każdy rozsądny (i dbający o swój czas wolny) programista.

Popieram :)

Wojciech Danilo napisał(a):

@pprog123:

A czemu ten Enso w takim razie nie jest jakimś odświeżonym excelem?

Ponieważ nie uważamy GUI Excela za coś najlepszego na świecie :)

Nie chcę krakać, ale 99% które tworzą alternatywę żeby tylko wprowadzić nowe GUI, (a przy tym wprowadzając mało / żadnych nowych funkcji) kończą na niczym.

Wojciech Danilo napisał(a):

@pprog123:

A czemu ten Enso w takim razie nie jest jakimś odświeżonym excelem?

Ponieważ nie uważamy GUI Excela za coś najlepszego na świecie :)

A potem klient chce import danych z exela. Rok temu moja żona pracowała przy imporcie danych z exela. Dziś ja w zupełnie innym projekcie pracuję przy imporcie danych z exela. A nowe GUI mało być wspaniałe, intuicyjne i czytelne. A użytkownik i tak woli to wszystko napisać a exelu a potem zaimportować dane :(

@0xmarcin: Platforma Mendix jest rozwijana i wdrażana w korpo na stanowiska typu LowCode programmer.
btw : https://thenewstack.io/microsoft-excel-becomes-a-programming-language/

@Wojciech Danilo: takie rozwiązanie widziałbym w FaaS,