Tym razem zaczynamy od nowego podejścia do wyrażeń regularnych. Co to jest Super-Expressive, czy zastąpi popularne regex-y? Potem płynnie przeskakujemy do JSHint i zmian licencyjnych, które wstrząsnęły światem JS i kończymy nowościami w TypeScript, który przeskoczył ostatnio na wersję 4.0. Zapraszamy na sporą dawkę osobistych opinii i niekoniecznie poważnych analiz tego co dzieje się w społeczności i technologiach JS.

Przydatne Linki

• Super-Expressive: https://github.com/francisrstokes/super-expressive
• JSHint i zło: http://mikepennisi.com/blog/2020/you-may-finally-use-jshint-for-evil/
• TypeScript 4.0: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/

Transkrypt

Bartek Witczak: No witaj Marku

Marek Piechut: No witaj Bartku

Bartek Witczak: Dobrze, dzisiaj w takim razie ja rozpoczynam pierwszym tematem. Chciałem z tobą porozmawiać na tematy biblioteki która dosyć niedawno wyszła a mianowicie Super Expressive czyli biblioteki do budowania wyrażeń regularnych wykorzystujący Fluent Builder pattern. Oczywiście tam ważna jest kolejność. Można sobie budować takie podwyrażenia, których gdzieś dalej można można reużywać w kodzie. No i oczywiście prawie już standardem zawiera typowanie dla TypeScript’u. Chciałem zapytać co ty w ogóle sądzisz o takim rozwiązaniu. Czy to jest dla ciebie bardziej czytelne. Jak to postrzegasz?

Marek Piechut: To jest oczywiście biblioteka dla JS’a.

Bartek Witczak: Dokładnie tak. Czyli może być jakby zarówno na froncie na backendzie. Wszędzie.

Marek Piechut: Ja mam takie mieszane uczucia z jednej strony myślę że to świetnie bo bardzo często widać że projektach takie paczki obrzydliwego kodu, który jest do zastąpienia jednym regexp’em. Bardzo często przy przetwarzaniu jakiegoś tekstu widać takie rzeczy że, ktoś ewidentnie odkrył regexp’y wcześniej to napisał w jednej linijce. Wszystko co tam bardziej rozpropaguje regexp’y moim zdaniem jest regexp’y nowoczesna technologia pewnie 60 lat ale wszystko co będzie propagować, to moim zdaniem jest na plus. Ja rozumiem że nie piszemy regexp’ów’ z kosmosu który się nie da przeczytać. No, ale często wiele if’ów da się zastąpić jednym regexp’em. Jeżeli chodzi o negatywną stronę, no to ja mam tylko ten problem że dla mnie regexp’y są dosyć czytelne osobiście i chociaż wiem, że wielu ludzi nie jest w stanie i dla nich jest to odpychające itd. Z tego wynika moja mieszane uczucia wierzę że z jednej strony fajnie bo będzie więcej kodu działającego na regexp’ach. Mam nadzieję, że nie w miejsce gdzie powinien być, ale z drugiej strony dla mnie regexp’y są czytelne i zrobienie długiej składni do tego samego co już jest. Ma świetną obsługę i lata. Przez lata wszyscy tam poznawali są identyczne między językami programowania. Czy tam mniej lub więcej myślę, że bez przesady, a teraz musi się uczyć czegoś nowego i jest nieprzenaszalne do innych platform i do innych języków. No to jest takie moje zdanie. Ale tak sobie myślę.

Bartek Witczak: Ja się generalnie zastanawiałem nad tym czy jakby problem z regexp’ami jest w momencie tworzenia ich czy w momencie kiedy czytamy co tam zostało stworzone. Bo wydaje mi się że bardzo mało jest regexp’ów w kodzie właśnie bardziej z tego pierwszego powodu czyli po prostu ludzie nie za bardzo potrafią budować regexp’y. To wydaje mi się że jest relatywnie szybko do nauczenia a czytanie już tych regexp’ów wydaje mi się że jest prostsze. Tym bardziej że jeżeli tam, gdzieś jest dobrze zaenkapsulowane w metodę to nie powinno sprawiać trudności. Mnie się wydaje, że nawet w opisie biblioteki jest napisane że dużo łatwiej jest czytać te teksty, a mnie się wydaje że problem nie leży po stronie czytania regexp’ów, tylko bardziej po stronie tworzenia ich.

Marek Piechut: No nie wiem nie do końca się zgodzę z Tobą, bo mi się wydaje że czytanie jest tym prawdziwym problemem. Napisanie regexp’a nie jest szczególnie trudne jak już tam znasz trochę składni, otwierasz dokumentację. Największy koszt jest dla osób, które później muszą czytać te regexp’y. No i tu jest zawsze pytanie czy ta biblioteka to tak naprawdę uprości i pewnie uprości, chociaż podejrzewam że jakieś ogromne regexp’y pewnie będą wyglądały po prostu potwornie. Jest taki modelowy przykład, nie wiem czy widziałeś regexp’a tego który zgodnie ze standardem parsuje maile. To jest taki regexp, którego warto zobaczyć, bo jest warunków brzegowych obsługiwać , które trzeba obsłużyć. Nie wiem czy będzie mniej obrzydliwe przy użyciu tej bibilioteki, ale jest obrzydliwy. To jest moim zdaniem niewątpliwa zaleta że jeżeli nie znasz regexp’ów a otwierasz taki kod z takim builderem to on pewnie jest dużo bardziej czytelny niż regexp’y. Trzeba by było pewnie wrzucić w jakiś parser, jeżeli sie na nich nie znasz. Z pisaniem dla mnie jest troszkę na minus. Ja jestem w miarę obyty z regexpa’mi i mi wygodniej piszecie i czyta regexp’y. Czy odpalam kod w JS czy w czymkolwiek innym to regexp’y są takie same

Bartek Witczak: Z drobnymi różnicami ale większość jest taka sama. Nie wiem czy widziałeś taką prezentację Simple Made Easy. Jakby w polskim do końca nie ma rozróżnienia tych słów simple a easy. I wydaje mi się, że to dosyć dobrze dobrze pasuje, bo w tej prezentacji definiowane jest to Simple jako dosyć prosty problem takiej natury złożoności a easy to jest coś łatwego w użyciu. Patrzymy i możemy łatwo łatwo i trochę mi to po prostu przypomina ten przypadek z tym z tym Super Expressive taką że tak naprawdę regexp’y to co można powiedzieć że jest easy relatywnie. Problem jest dosyć prosty ale używanie tego nie jest super proste to nie do użycia nie jest łatwe. I ta biblioteka jakby stara się zrobić żeby to było właśnie łatwe w tym sensie easy. Nie wiem masz podobne podobne wrażenie? Czy widziałeś tą prezentację bo ona często jakby nie na przykładzie na przykładzie Javy tam chyba żeby mieć systemu takich rzeczy że tak naprawdę Maiven Java’ie easy bo się łatwo odpala. A na tym drugim elemencie masz build system który jest simple w stylu Ant’a. Masz wszystkie instrukcje prosto napisane i jest problem z tym żeby się tego nauczyć. Jeżeli to umiesz, to już jest dla ciebie łatwe. Chodzi o problem który jest przykładem prosty. Czy tak jak Ty mówiłeś, że Ty jakby znasz regexp’y i dla Ciebie to nie jest problem je czytać i pisać, bo one są potem podobne. Naprawdę ta trudność polega na uczeniu się tej składni. A sam problem jest prosty w swojej naturze.

Marek Piechut: No tak , tylko chodzi o to że prawdopodobnie wielkie pokraczne regexp’y też będą wyglądały źle w tej bibliotece. Ale generalnie ona mi się podoba. Dla ludzi którzy na co dzień, nie są z regexp’ami zaznajomieni i dzięki nim mogą napisać jakikolwiek kodu który będzie działał dużo lepiej niż jakiejś tam if’owanie w lewo prawo i będzie pewnie czytelniejszy niż if’owanie, bo przetwarzanie tekstu if’ami często wygląda po prostu okropnie bo tam jest tych if’ów pięćdziesiąt jeden po drugim i sprawdzaniem czy 5 do siódmego znaku to jest taki a ten taki, a ten taki i dojście do tego wzorca jest kłopotliwa. Tutaj pewnie będzie dużo łatwiejsze. Ja myślę że jak ktoś nie próbował się się z regexp’ami to może sobie spokojnie odpalić popatrzeć. Myślę że może być fajnie.

Bartek Witczak: No zdecydowanie.Ja też polecam fajnie, czytelnie to wygląda. Do przetestowania.

Marek Piechut: A potem warto zajrzeć w prawdziwe regexp’y.

Marek Piechut: Ja tutaj mam teraz taki mały przerywnik, mały temat, taki pomiędzy. Później zajmiemy się czymś poważniejszym. Ale nie wiem czy wiesz, od niedawna można używać biblioteki JSHint do czynienia zła, bo usunięto z licencji taką klauzulę, która mówiła „The Software shall be used for Good, not Evil”. No i to by się mogło wydawać, że jest takie tutaj śmichy chichy i tak dalej, ale podobno to straszny ogranicznik dla rozwoju JSHinta, bo okazywało się, że prawnicy w firmach patrzyli na tą klauzulę i mówili „O co Ci chodzi?”, nie wiadomo, teraz trochę strach. Nie wiadomo, czy bierzemy czy nie bierzemy i w wielu firmach biblioteka była zbanowana.

Bartek Witczak: Znaczy, w ogóle jak widziałem tego niusa - bo widziałem tylko, powiedzmy nagłówek - to zupełnie przeszedłem obok tego obojętnie, bo byłem pewny, że to są po prostu jakieś żarty. W sensie, że to, że oni teraz przeszli na MITa i teraz tak wygląda ta licencja. Pomyślałem, że jest to po prostu jakaś ciekawostka i że tak naprawdę nie miało to żadnych konsekwencji, że ten zapis był tam gdzieś ukryty.

Marek Piechut: Właśnie, podobno, że miało bardzo duże…, no i teraz go nie ma i jest trochę łatwiej. Przy okazji w review notce do tej zmiany podali informację, że ze względu na to, że to jest „not breaking change” nie będzie zmiany major version tylko minor version. Także widzisz można będzie wreszcie blockchainy pisać z JShintem.

Bartek Witczak: To jest ciekawe, bo w ogóle są takie fajne zapisy w licencjach. Ja pamiętam, jak FB miał ten zapis w React, że jeżeli ktoś z tego korzysta to nie może sądzić się z Facebookiem, w sensie - nie może wytaczać żadnych procesów Facebook’owi. Też, jakby wydawało się, że to jest coś małego, tak naprawdę dosyć szybko Facebook musiał się wycofać z tej klauzuli i przejść na coś normalnego, bo firmy troszkę się oburzyły.

Marek Piechut: Wiesz to ciężko powiedzieć, że Twój Software służy do czynienia dobra, a nie do zła. Czasami to nie jest aż takie proste. Bartek Witczak: To jest mistrzostwo…Super

Marek Piechut: Trzeci temat na dzisiaj, to jest temat dosyć ciekawy dla mnie, czyli TypeScript 4, który bodajże 2 dni temu się pojawił. Ja czytałem o nim troszkę wcześniej jeszcze, kiedy był tam w becie, ale generalnie rzeczy, które były w becie wchodzą w czwórce. Dla mnie cały ten release 4, który nie jest wcale jakoś szczególnie duży, ale zawiera jedną, taką ogromnie istotną rzecz, która dla mnie zmienia strasznie dużo. I to jest to, że będzie można wreszcie otypować tuple o zmiennej długości, nie znam polskiego słowa niestety na tuple, ale generalnie chodzi o tuple o zmiennej długości. No i wydawało by się, że to nie ma dużego znaczenia - ale jak taki niuans, no bo tam tuple to nie jest takie szczególnie popularne - ale jak się spojrzy na to w ten sposób, że parametry do funkcji w JavaScript są tuple’m to zmienia bardzo wiele. Bo wreszcie będzie można sensownie otypować higher order functions, sensownie otypować wszystkie rzeczy, które operują na funkcjach o nieznanej liście argumentów, tak. Wszystkie funkcje w stylu tam concat, head, tail i tak dalej. Wszystkie będą mogły być sensownie otypowane, tak? Wszystkie funkcje, które robią curring i tak dalej, nie będą musiały teraz robić jakiś przykrych haków albo z ogromną ilością funkcji przeciążonych, albo z jakimiś różnymi wynalazkami. Wreszcie będzie można to sensownie otypować.

Bartek Witczak: Ja to się tym tematem, tych nowości, jakby wcześniej nie interesowałem. Rzeczywiście pamiętam, że mieliśmy trochę problemów właśnie z tymi elementami. Szczególnie właśnie z higher order function i otypowaniem tego prawidłowo, także to na pewno jest dobra wiadomość. Powiesz co jeszcze tam weszło z jakiś nowości?

Marek Piechut: To znaczy z jakiś tam ważniejszych rzeczy, które weszły no to jest też taka…upierdliwa dosyć rzecz była, że trzeba było dwa razy typować na przykład pola w klasie, które w konstruktorze były inicjalizowane, także ja tam klas jakoś bardzo nie używam, ale w miejscach gdzie tam trzeba było, musiałeś dwa razy te typy określać, zarówno w konstruktorze jak i w klasie jeszcze raz, tak? A teraz ten kombinator jest trochę bardziej przebiegły i gdzieś tam sobie to ogarnie. Wprowadzili też dla belki identyfikatory w tablach. Nie wiem, będę musiał sprawdzić jak to się nazywa. Co nie wiele zmienia funkcjonalnie z punktu widzenia typowania, ale sprawia, że kod będzie bardziej czytelny też właśnie a propo tych parametrów do funkcji, które czasami są właśnie przez jakieś table przekazywane te argumenty, tak? Bartek Witczak: Yhy. To ogólnie, jak by wygląda na to…, w sensie to już się dosyć mocno dzieje, że ten TypeScript wygląda, że najbardziej rozwija się z tych rzeczy, które powstawały mniej więcej, powiedzmy w podobnym czasie, z tych wszystkich języków czy super setów JSA, które dodają typowanie. Wydaje się, że to zdecydowanie zmienia układ sił, że Microsoft tak mocno w to zainwestował i tak mocno wszedł w ogóle w cały development frontendu, bo to już jakby czwarty duży release TypeScriptu. Cały czas tam są udoskonalenia, cały czas dokładają kolejne fajne rzeczy, na które powiedzmy, że community w innych językach już długo, długo czeka, nie?

Marek Piechut: No, wiesz to jest…TypeScript jest teraz, jakby nie patrzeć, królem tego całego typowanego JavaScriptu, praktycznie przegonił wszystkie pozostałe jakieś pomysły w stylu Elm czy innych tam takich wynalazków. Przegonił też Flow, który był type checker’em, takim typowym dla JavaScriptu, który sam nie był językiem ale tylko type checker’em. Swoją drogą bardzo fajnym, moim zdaniem, no ale przegrał tą batalię z Visual Studio Code, niestety. Nie ma co się oszukiwać - to nie była walka między TipeScript’em a Flow, bo dużo feature’ów których TypeScript nie miał we Flow były wcześniej…

Bartek Witczak: Działały szybciej…

Marek Piechut: …działały szybciej. I jeszcze tam część rzeczy jest takich opaque types i tak dalej, których nie ma ciągle w TypeScript’cie nie ma. No ale Visual Studio Code zmieniła wszystko, jak widać…Wiesz TypeScript jest teraz na topie, także to będzie, to co będzie nas…nam sprawdzać typy w przyszłości, tak?

Bartek Witczak: Ja się spodziewałem po prostu, że trochę więcej ogólnie w takim dużym release, jeżeli mówimy, że to jest TypeScript 4, duży release, spodziewałem się po prostu czegoś większego, większej ilości tych zmian. A wydaje się, że dużo tych zmian zostało wprowadzone w takich… powiedzmy minor wersjach, powiedzmy inkrementalnie a teraz nagle jest 4.0 a tak naprawdę…

Marek Piechut: Ja powiem Ci, że osobiście się cieszę, że to jest mała zmiana, bo parę razy w TypeScript, chyba przy 3.9 nawet też tak było…, te zmiany były, wiesz, minor version a po prostu 2 dni pracy, żeby ogarnąć kod, żeby się kompilował z powrotem, tak. Także, ja akurat się cieszę, że tym razem to jest mała zmiana, a nie jakaś wielka kobyła, która nie będzie kompatybilna z niczym, nie? Także…, ale dla mnie to typowanie argumentu do funkcji, to akurat jest super rzecz. Bo bez nich pisanie, nawet pisanie swoich connect’ów było kłopotliwe, tak. Nie dawało się łatwo otypować tych rzeczy. Im bardziej funkcyjnie pisałeś, tym bardziej to bolało.

Bartek Witczak: Yhy, yhy, jasne…

Marek Piechut: Trzeba było właśnie dużo się gimnastykować, żeby mieć sensownie otypowane funkcje, których argumentów nie znałeś na początku. Teraz będzie z tym dużo łatwiej. Czyli co, instalujemy TypeScript 4?

Bartek Witczak: Zdecydowanie, zdecydowanie..

Marek Piechut: I jedziemy dalej