https://fightchatcontrol.eu/
Unia wciąż chce nam patrzeć przez ramię. Dla naszego dobra oczywiście.
Fajnie, że Poland stronk i mamy sprzeciw. Szkoda, że większość nie.
Vibe coding FTW. Nigdy nie używałem Java Script, a potrzebowałem w arkuszach googlowskich niestandardowych funkcji, bo miałem dane wejściowe w amerykańskim formacie. No i odpaliłem AI od gógla, powiedziałem mu, że potrzebuję skrypt w Apps Script i opisałem, co ma robić.
Pierwsza wersja nie wyszła w ogóle, nie chciało mi się nawet debugować. Rozbiłem na 3 mniejsze kroki, każdy opisałem oddzielnie no i zaczęło działać :)
ps ale to jest wolne, płaku płaku
Jjb przerobiłem przez ostatnie parę dni chyba z pięć różnych generatorów parserów. Każdy mnie czymś wkurwial. Jeden fajny, malutki, kompaktowy, ale ograniczony. Drugi spoko, ale jest tylko jako biblioteka js. Trzeci niby też wygodny, ale ma zjebane API.
W końcu natrafiłem na tree-sitter. Do tej pory widziałem te nazwę tylko w logach npm xd i zawsze myślałem że to jest paczka do optymalizacji dependecji, chyba mi się pojebało z tree shakerem xd
No i ogólnie spoko jest. Generuje parser w C i bindingi do każdego popularnego języka. Ale kurwa xd
Gramatykę definiuje się w javascripcie xd (reszta raczej używa jakiejś formy EBNF) i zeby sobie wygenerować parser to trzeba mieć node'a. No niby wszyscy mają po 50 node'ów poinstalowanych, ale no niesmak trochę jest. W sumie ma to jakiś sens nawet bo przynajmniej jest podpowiadanie składni.
Ale to nie wszystko xd jest opcja generowania podświetlenia składni. Ale wymaga to podefiniowania sobie dodatkowych skryptów w jakimś dialekcie lispa xd
Kobyła trochę to jest i zamiast jednego pliczku źródłowego to domyślna definicja parsera stanowi cały pierdolony projekt.
Ale w zasadzie to chyba najwygodniejsze rozwiązanie
@sens:
Haha, rozumiem ten emocjonalny rollercoaster bardzo dobrze 😄
Tree-sitter ma dokładnie tę aurę „o, to wygląda prosto… a jednak jest pół fabryki pod spodem”.
To co opisujesz, to w sumie dość typowe:
- Małe, kompaktowe generatory → zazwyczaj fajne na prototyp, ale później wychodzi, że brakuje ci drobiazgów, np. sensownego error recovery albo wsparcia dla komentarzy.
- „Tylko JS” → no i wtedy jesteś w klatce ekosystemu, nawet jak twój projekt w ogóle z JS nie korzysta.
- Tree-sitter → niby C core, szybki, cross-language bindingi, ale... cała definicja w JS + cała ta magia „generowania” wymaga Node’a.
Paradoksalnie to, że gramatyka jest w JS, ma sens techniczny — dzięki temu można robić programistyczne konstrukcje w definicji (makra, reużywalne reguły itp.) i to się kompiluje do czystej struktury C, ale z punktu widzenia purysty „chcę jeden plik .grammar” to jest trochę „meh”.
Co do highlightingu w Lispu — to jest Tree-sitter queries, czyli ich mini-dialekt S-expressions. Też się z tym pierwszy raz obijałem w Neovimie i miałem wrażenie, że ktoś mnie teleportował do Emacsa, ale to jest w sumie całkiem potężne (i trochę lepiej się debuguje niż klasyczne regexowe highlighty).
No i tak, domyślna definicja parsera jako cały projekt to w sumie cena za to, że potem dostajesz:
- AST w czasie rzeczywistym
- error recovery
- możliwość modyfikowania highlightu i foldingów bez rekompilacji parsera
- od razu wsparcie w kilkunastu edytorach
Jak na ironię — dla kogoś, kto chce tylko „mały parser” to jest kobyła, ale jeśli chcesz coś długofalowo rozwijać, to trudno znaleźć lepsze narzędzie.
Jeśli chcesz, mogę ci pokazać jak spłaszczyć definicję Tree-sittera do jednego katalogu z minimalnym Node-overheadem, tak żeby nie wyglądało to jak rozdmuchany projekt. To dość mocno redukuje „niesmak”.
Chcesz, żebym to od razu rozpisał?
Grzebie sobie w svelte i w sumie bardzo przyjemne, fajnie nie musieć się martwić o reactowe problemy. Jeszcze nie widzę tak dobrze gdzie jest gorzej. Widzę, że 5 wprowadziła jakąś nowszą składnie więc ja znam tylą tą nową. dx
@sens:
No np. teraz react się od ponad roku pierdoli z tym kompilerem. Ja nie mam problemu z useMemo i useCallback, ale ludzie nie ogarniają i się mutują rzeczy niepotrzebnie w chuj - w svelte kompiler już jest od dawna pisząc x = $derived(, nie musisz mu dawać tablicy zależności, bo kompiler jest od tego.
W reakcie masz nie mutować stanu więc moja cała reactowa głowa w svetle myśli jak nie mutować stanu, a on w sumie chce, żeby stan mutować i element można usunąć items.splice(index, 1);.
W rekacie chciej input kontrolować:
const [value, setValue] = useState('')<input value={value} onChange={(e) => setValue(e.target.value)} />
W svelte jak się napisze <input bind:value /> to nie trzeba statów pchać i bonus, że można <input type="number" bind:value={person.age}> i to zmodyfikuje propsa age, na person.
Nie trzeba dawać key.
Małe proste bzdury ale przyjemne. Na tym etapie co się wgryzłem to mi się podoba, dotykałem przed nim angulara to pierdolę go serdecznie, zwykle jak o angularze mówiłem to nie moje klocki, ale przynajmniej wiadomo co jest w środku, freamwork podejmuje więksoszość decyzji, a w Reakcie masz 5 kostek i losuje libki do routingu, fetchowania, stora i każdej decyzji i nigdy nie wiadomo co wylosuje. Ale jak chwile popracowałem to w angularze większość decyzji robi jakiś korpośmieć wyrwany z 2018 roku.
Jezu jeszcze jakaś spierdolina w angularze stwierdziła, że język do templatownia może mieć gołe @for:<ul>@for (product of products(); track product.id) { <li> <app-product-card [product]="product" /> </li> }</ul>
@for w środku htmla bez żadnych klamr. W Svelte lepiej, ale lubię JSX - jedna z lepszych rzeczy w reactie.
Grzebie sobie w svelte i w sumie bardzo przyjemne, fajnie nie musieć się martwić o reactowe problemy. Jeszcze nie widzę tak dobrze gdzie jest gorzej. Widzę, że 5 wprowadziła jakąś nowszą składnie więc ja znam tylą tą nową. dx
Ja to akurat byłem biedakiem i zawsze miałem Sony Ericsson y jakieś Siemensy. Pierwsza nokia jaką miałem to 3410 po dziadku jak mi się rozjebał jakiś guwnofon, potem jeszcze miałem 5130 xpressnmusic co mi ja ukradli, 6220 albo 6230 już nie pamiętam ale akurat chyba najlepiej wspominam, miała bardzo wygodne klawisze, a potem jeszcze chujowa lumie 520 xd