• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    Diskuze o obzive programovanim pro starsi a pokrocile.
    rozbalit záhlaví
    PJOTRIK
    PJOTRIK --- ---
    FARIN: drag&drop nebo file upload jako argument beru. I kdyz si myslim ze to jde ekvivalentne resit nejakou izolovanou komponentou, ktera tuhle funkcionalitu vyresi a osobne bych vybral tohle reseni. Ale chapu ze to je osobni preference.

    Validace si myslim ze jde stejne dobre resit roundtripem pres server, kde je to megajednoduchy volani, odpadne ti duplikace. Opet, prinejlepsim osobni preference IMO.

    U toho stavu ale nerozumim. Stav muzes resit na serveru, typicky naopak musis (viz KEJML). API je v tomhle reseni ekvivalentni aplikaci, takze server vi, co se ma v UI vyrenderovat a vrati to. Cache na klientu neexistuje, takze invalidace odpada.
    KEJML
    KEJML --- ---
    FARIN: No ale stejně ten složitý stav, který SPA udržuje, musíš nakonec synchronizovat se serverem a server ho musí celý znát, jinak o něj uživatel přijde. Takže máš ve výsledku složitý stav v SPA a stejně složitý stav na serveru.
    FARIN
    FARIN --- ---
    PJOTRIK: složítý je typicka ta aplikace kterou skrz SPA tvoříš, resp. její vnitřní stav. Dokud děláš neco co je spíš web kde jsou od sebe jasně oddělený stránky a dobře to pasuje na model request / response a potřebuješ to obohatit nějakou interaktivitou tak htmlx (případně alpine.js) je hezká přímá možnost bez toho aby člověk musel setupovat nejaký komplikovaný stack.

    Nejde tolik o rychlost (i když SPA je většinou pocitově o něco responzivnější) ale o management stavu. U těch komplexních aplikaci to není tak že by jsi s nějakou uživatelskou akcí vyrenderoval jeden fragment html a ten na stránce vyměnil. Často se změna propisuje do více míst, invaliduje cache apod.

    Navíc přístup všechno na serveru dost naráží třeba u formulářu. Tam řešíš validace, drag&drop reoredring seznamů, file upload přes drop souboru .... stejně to obsluhuješ netriviálně na straně klienta.

    Druhá věc je že ty deklarativní knihovny hezky fungují dokud to jde dobře deklarativně popisovat. A jak se to začne komplikovat tak to jde do špaget. V tohmel jsou knihovny jako React / Svelte univerzálnější a umožnují lepé aplikaci strukturovat a i ten syntax cukřík je tak hezčí.

    Ale možná pod tímhle rozumíš právě to graficky intenzivni UI.
    PJOTRIK
    PJOTRIK --- ---
    FARIN: no a k tomu bych rad slysel argumenty, proc nenahradis? Ja v tom vidim sanci nechat fakt veskerou logiku na serveru a web mit opravdu trivialni.

    Chapal bych nejaky graficky intenzivni UI, ktery musi okamzite reagovat (i kdyz i to Datastar tvrdi ze zvlada dostatecne rychle, nemam vyzkouseno, ale furt tam musis pocitat s latenci site). Ale co je na SPA inherentne slozityho?
    FARIN
    FARIN --- ---
    PJOTRIK: je to fajn na jednoduchý věci. Na složitější SPA nebahradis.
    KEJML
    KEJML --- ---
    PJOTRIK: My jsme backendisti, kteří potřebují rychle prototyp frontendu, tak to kolega poměrně rychle napsal s pomocí htmx a zatím dobrý. Ale produkční kód to není a osobně jsem to mimo základních tutoriálů ještě neviděl vůbec.
    PJOTRIK
    PJOTRIK --- ---
    Ale abych nebyl jenom za zapsklyho dedka - uz chvili se divam na HTMX a Datastar a to vnimam jako zavan opravdu sveziho vetru a zpusob jak by mel fungovat webovy stack. Zadny JSON API, GraphQL, javascriptovy SPA, ale primocara opravdu RESTful aplikace... po 20 letech co jsem utekl pred javascriptem mam znova chut delat i frontend. Delate s tim nekdo, co si o tom myslite?
    KLEINZACH
    KLEINZACH --- ---
    SH_PANDA: tak to me je mentalne 60 a vidim vsude naplasti a hlineny nozicky :)
    CERMI_FOX
    CERMI_FOX --- ---
    BESH: většinou je za tím nějaký designér, který to tak nakreslil, a klient, který to chtěl přesně tak, jak je to nakresleno, a W3C, které nedovoluje (nedovolovalo) dostatečně stylovat formulářové prvky. Zrovna dropdown menu si každý browser renderoval po svém.
    BESH
    BESH --- ---
    LITTLELI: Ad "reseni je slozitejsi nez problem". To mi povidej. Ja ted zrovna videl jedno React reseni dropdown menu s odkazama a byla to hierarchie nekolika komponent, kazda s nejakym vlastnim state a onChange callbackama, kde teda na konci byla implementace Listboxu z @headlessui. Netusil jsem, ze se mi jeste nekdy zasteskne po klasickem CSS ul->li menu, ale tohle bylo na me fakt moc. Proc si to ty lidi delaj. :(
    LITTLELI
    LITTLELI --- ---
    JANFROG: K něčemu to je. Teď ještě všichni kolektivně musí přijít k čemu :-)
    PJOTRIK: Tak to jsem furt 2. Spíš to mám posunutý takhle: Když se hrabu ve starých paperech, tak dopamin se normálně dostavuje. Horší jsou ty nový věci, často mi přijde, že řešení je složitější než problém, který to řeší. Ale furt myslím, že 2 :-)
    SH_PANDA
    SH_PANDA --- ---
    PJOTRIK: tak to mne je porad 23, takze vsechno je exciting a revolutionary ;)
    SUCHRE
    SUCHRE --- ---
    je to jen nastroj a zalezi na definovani promptu. ma-li jazyk dostatecne kvalitni dokumentaci a priklady, coz se mu da podstrcit a adekvatni prompt, uroven odpovedi je na radove lepsi urovni.
    PJOTRIK
    PJOTRIK --- ---
    Jo, je to zajimavy, cekal bych ze se vztah k LLM bude ridit osvedcenym
    1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
    2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
    3. Anything invented after you're thirty-five is against the natural order of things.

    Ale evidentne jsou i mezi nama starsima rozdily ve vnimani, taky mam stejne staryho kolegu, kterej je z chatgpt unesenej, nechava si radit s kodem, dela s nim obrazky do her co chysta pro deti atd. Ja mam k LLM instinktivni neduveru, parkrat jsem to zkusil pouzit prave na nejaky obrazky a nedokazal jsem ziskat nic co by bylo vzdalene pouzitelny, vylozene frustrujici zazitek. Na kod bych si od toho sahat nenechal
    JANFROG
    JANFROG --- ---
    Ja jsem narazil na (pro me) zajimavy fenomen. Pred par mesici me kamarad (byvaly a ted uz zase soucasny kolega) abych mu vysvetlil jednu implemetacni techniku na praci garbage-collectovanymi referencemi ve (unmanaged) VM kodu. V zasade neco jako std::unique_ptr akorat jsou vsechny propojene do linked-listu nebo tak aby se to dalo snadno posbirat kdyz clovek pocita root set.

    Predesilam, ze kamarad fakt neni blbej, programovat umi, a jako VM vyvojare ho respektuji a chodim si k nemu pro nazor kdyz jsem na pochybach nebo v koncich. A jak je take nadsenec do LLM tak hned ze to hodi do ChatGPT (nebo neco podobneho), ze takovou trivku nebude psat sam.

    A hned mi to poslal jako ze to je "dobrej zacatek, ne uplne 100% ale doladi se par radku tady a tam", velke nadseni.

    Ja se na to podival a i kdyz jsem do toho brejlil chvili, prislo mi to dost mimo a ze bude jednodussi to napsat z nuly nez se to snazit opravit - asi nikoho neprekvapi, ze ja jsem spis LLM-skeptik.

    Takze mozna ta kvalita kodu zavisi i na tom, jak moc clovek chce, nebo naopak nechce, aby AI byla dobra :-)
    SEJDA
    SEJDA --- ---
    SULTHAN: ano, udelali jsme copilotu metodu @BeforeEach (JTest) aby nakonec zustala prazdna a ve 20 @Test se opakovalo prvnich 5 radku systematicky :))
    SEJDA
    SEJDA --- ---
    KEJML: ano, taky uz mam par zkusenosti s vymyslenymi funkcemi, anebo s volanim API ktere ma 20 debilnich parametru ve stylu C, aby mi ChatGPT napsal, ze staci predat 4 krasne managovane objekty .. ne ne.
    Ale taky synteza 2 trid, tak aby vytvoril treti ani po zvetseni zadani na 500 slov nepomohla a stale halucinoval ve 3 odpovedich dokola.
    SULTHAN
    SULTHAN --- ---
    Měl jsem v prosinci hodně nevybrané dovolené, takže až dnes jsem bohužel viděl FE testy v typescriptu, který v prosinci pomocí copilotu napsali kluci, kteří normálně píšou BE v kotlinu.

    Děsivá stylistika kódu, špatně použité funkce - třeba array.filter(...)[0] místo array.find(...), duplicitní kód, typ "Any", takže to neházelo typové chyby, skrytý čínský znak ve stringu atd atd.

    Kromě toho napsané způsobem, že je to neudržovatelné.
    KEJML
    KEJML --- ---
    SEJDA: Já nevím, nějaký jednoduchý mechanický věci (často) Copilot zvládne, automaticky doplnit, ale jakmile si ho občas zkusim na něco netriviálního zeptat v chatu, tak příliš často halucinuje, výmýšlí si syntaxi, která by byla logická, ale neexistuje, nebo mi doporučuje použít neexistující knihovny.

    Píšu Kotlin v IntelliJ, pro kontext.
    SEJDA
    SEJDA --- ---
    Mam uz s ChatGPT 3 otevrene konverzace pro 5 programovycich jazku.
    Copilota ve Visual Studio Code i IntelliJ.
    A pomalicku si zacinam zvykat, na programovani tabulatorem.

    Msakrozni je synteza, kterou copilot dosahuje z textu zkopirovaneho z ChatGPT kdy namisto Ctrl+V proste jenom zmacknete .. tabulator.

    Upravit potom 3 radky, tak aby byl zdrojak zajimavejsi/stihlejsi/efektivnejsi, je uz potom o hodne vetsi zabava.

    Az je mi lito mladych programatoru, kteri travi hodiny ve snaze porozumnet, co jim ChatGPT odpovedela, ziskat k tomu background a potom se hodiny pokuset "opravit" svuj preklep ve zdrojaku napsanem copilotem.
    JANFROG
    JANFROG --- ---
    KLEINZACH: Pokud jsou to jen funkce a berou/vraci zakladni typy, da se to udelat IMO celkem bezbolestne s par sablonama.
    Kliknutím sem můžete změnit nastavení reklam