ChatGPT4 je k nezaplacení (platím si ho). V Pythonu jsem dělal UI s Tkinter (mělo to být hlavně rychle...) a jak mi vygeneroval kód z ruční malůvky mi vyrazilo dech. Nechat ho přepsat kód do jiného layout manageru bylo třešničkou na dortu (fungovalo bez úprav). Já pak už jen řešil detaily chování a business logiku. Pomoc k nezaplacení. Některé modely (ChatGPT3.5, Gemini Pro) jsou pro programování nepoužitelné, ale pokud se použije pokročilý model, tak je to neuvěřitelný pomocník.
Ako to povedať, je to zjednodušenie povedané - neurónová sieť natrénovaná na to, aby predikovala slová na základe predchádzajúceho kontextu.
Jazykový model sa to volá preto, lebo vstup sú slová, výstup sú slová. Ale má v sebe tie informácie uložené vo váhach na synapsiách, len sú neúplné a často aj popletené. V skutočnosti môže znamenať, že novší model bude mať podrobnejšie informácie. Teda ak vyriešia tú strašnú pomalosť nejakou fintou (lepším hw, alebo nejakými lepšími algoritmami 4-ka je už pomalá na hranici znesiteľnosti)
jak mi vygeneroval kód z ruční malůvky mi vyrazilo dech
Jasně, je super, že to dokáže z ruční malůvky navrhnout kód.
Jenže, proč je nutné, aby něco generovalo kód z ruční malůvky? V roce 1997 jsme programovali v Delphi, tam stačilo natahat komponenty, automaticky se připravil kód pro obsluhu toho GUI (na tento kód vůbec nebylo potřeba sáhnout), napsalo se pár řádků kódu pro business logiku a bylo to.
Tedy bylo jednodušší to "malovat" rovnou v Delphi než na papíře/tabuli/tabletu.
Ano, já chápu, že je super zážitek vidět, jak AI něco naprogramuje z malůvky. Na druhou stranu já opravdu budu záměrně velmi otravný s tím "to tady bylo před X lety". Protože mám opravdu pocit, že dnešní IT AI je jen velmi nepovedená náplast na něco, co tady bylo technologicky vyřešené už například před těmi 30 lety. Proto jsem tak otravnej s těma knihovnama apod.
A ja budem este otravnejsi. Dokonca vieme ze sa to velmi nepresadilo. Akoze pocas analyzy sa nieco kresli ale tie kresliace nastroje na programovanie sa proste nepresadili lebo neboli uplne 'vsetko urobitelne'. A to ja patrim k ludom ktory boli priaznivci veci ako 4GL jazyky, FoxPro, Magic, PowerBuilder, Ingres4GL, VisualAge - ktory to mal uplne namakane vratane integriacie z objektovym model systemu OS/2.
Neviem ako teraz, lebo už to nepoužívam, ale Eclipse a Netbeans pre Javu mali dobré editory na vytváranie gui. V Eclipse, ak človek dodržal určitú štruktúru, mohol si dam pridať prvok podľa ľubovôle a editor neprotestoval.
To s tým čmáraním gui na papier si zo srandy vyskúšam, nenapadlo mi chatgpt, takto používať. Už som tomu kadejaké čmáranice podhadzoval, ale kód som z toho nečakal :)
RE: ... nedala ...
Copak oni v Gentoo potřebuji rychle kódit GUIčka?
Jako že mám ty AILike věcičky rád už od raných 90', kdy jsem si na 286ce pohrával s knihovnami na rozpoznání řeči od IBM z OS2, zkoušel přechytračit standardní strojové modely neuronů, sypal data do znalostních tabulek a nadšeně sledoval generace genetických algoritmů, tak docela chápu proč se v Gentoo rozhodli AI generovanému kódu vyhnout.
"Myslím, že je to pro Gentoo v tuto chvíli spíš PR tah," tiez to tak vidim a do buducna sa na tom nic nezmeni. Ak by totizto taky zakaz bol, tak by museli riesit aj porusenia toho zakona a naozaj si neviem predstavit ako by dokazali jednoznacne urcit, ze to bolo generovane AI, pripadne s pomocou AI. Myslim, ze by urobili lepsie, keby boli ticho.
Já nevím, jestli se má jednat o vtip.
Se syntaxí poradí každý IDE za posledních 30 let (víc si nepamatuju ;-)). S parametry funkcí také - i free doplňky do vimu to uměly už před 15 lety. StackOverflow je dobrý možná tak na prozkoumání dalších / jiných možností jak něco udělat, ale rozhodně to není návod na použití čehokoliv a už vůbec ne na copy paste.
Jestli je tento komentář myšlen vážně, tak to říká jediné - děláte to blbě.
To není tak jednoduché - malinký přínos a žádné ztráty. Abyste ten jeden blok za měsíc mohl potvrdit, budete muset trávit čas tím, že budete pročítat a zavrhovat různé navržené bloky kódu, které z nějakého důvodu nevyhovují.
Tohle je dost zásadní problém. Klasické intellisense a podobné nástroje když neví, tak mlčí. LLMka velice rády halucinují kraviny, se kterýma pak musíme my lidi ztrácet čas. Jestli to stojí za to je hodně proměnlivé.
Asi záleží na použití. Pokud je ten blok něco triviálního, kde se jen v konkrétním jazyce interpretuje existující a známý algoritmus, tak to asi není moc potřeba.
Asi nečekám, že mi Github Copilot napíše celou aplikaci nebo něco složitého. Ale možná bude efektivnější jednodušší kusy kódu nechat napsat AI než juniorního programátora. Tak jako tak tam pak někdo musí udělat revizi kódu, ale ten junior za $9.9/měsíc rozhodně pracovat nebude.
Ale určitě je důležité zmínit, že neni programování jako programování. AI určitě hodně pomůže například s webovými aplikacemi, kde ta repetetivnost kódu je hodně vysoká. Dobře to funguje například při psaní automatizací. Dovedu si představit, že to bude generovat větší část unit testů.
Ohrazuji se pouze vůči tomu, když někdo řekne že se mu to nevyplatí. Ta cena je tak směšně malá, že i člověku co se věnuje programování jeden den v měsíci a ušetří mu to napsání opravdu malé části kódu by to mělo být přínosem.
> Ta cena je tak směšně malá
Vždyť jsem to napsal přímo. Nejdůležitější část ceny za použití AI není těch směšných 10$ ale moje člověkohodiny co padnou na codereview toho generovaného kódu.
Aby bylo AI přínos, musí být použitelná dostatečná část generovaného kódu. Aby čas ušetřený psaním toho kódu převážil čas strávený čtením toho generovaného kódu.
'
Tool co ušetří napsání opravdu malé části kódu je i zadarmo drahý, pokud nefunguje naprosto spolehlivě a bezobslužně.
Mluvíš o programátorech, kteří jsou tak hloupí, že si neumí spočítat náklady. Ale existují i programátoři, kteří do dovedou.
Po čase jsem se naučil odhadnout, že na některé problémy není ekonomické se ho ptát. Také jsem se naučil co to znamená, když začne dávat zmatené odpovědi. Stejně tak, jako normálnímu programátoru běží v hlavě na pozadí proces, který zhodnocuje, jestli použití té či oné knihovny, algoritmu, řešení se vyplatí, a zda se na to nemá vykašlat, tak LLM je prostě jen další řešení do řady.
Ale ono nejde o to, že bych potřeboval poradit nějaké jednotlivosti ohledně parametrů nebo tak něco. Byl jsem třeba v situaci, že jsem chtěl napsat úplně nový program, využívat API, které jsem několik let nepotřeboval, takže jsem si ani nepamatoval názvy funkcí apod. Nebo jsem potřeboval vyřešit problém v jazyce ve kterém běžně nedělám a nevěděl jsem jaké na to jsou vhodné knihovny. Tak jsem prostě napsal co to má dělat a ono to vysype během pár sekund několik set řádků funkčního kódu, který bych ručně dával dohromady třeba hodinu a prolejzal tuny dokumentace a SO. Je to prostě řádově rychlejší než do dávat dohromady ručně. Navíc je ten kód idiomatický, což se hodí v případě, kdy ten jazyk nemám ještě zažitý.
S tou funkčností je to právě přijde mi dost často trochu problematické. Jako jo, pro některé případy užití je to fajn, s tím naprosto souhlasím, ale jindy jsem dostával kód, který sice vypadal funkčně ale reálně obsahoval spoustu problémů logikou plynoucí právě z toho, že jde o LLM a nikoliv něco, co by skutečně danou věc reálně chápalo.
Syntax napovidaly editory uz zacatkem 90'
A patlalove, kteri nic neumi, to samozrejme jinak nez lepenim ciziho kodu nezvladaji. Tenkrat se k tomu cizimu kodu nemeli jak dostat, tak jich bylo minimum. Vysledky tomu odpovidaji ... ono to neco dela, ale nikdo nevi co vlastne.
Zrovna takovou patlaninu v C# resim ... na jednech widlich to bezi ... ale neseje, a na druhych ... to z nejakyho duvodu i seje. Logy zadny, konfigurace, kterou to minimalne z casti ignoruje(nastaveni casovace na 15 minut == deje se to kazdych 5 minut), je prosychr v 5 ruznych souborech ruznych formatu ...
Zrovna experimentuju s copilotem a jsem z toho tak nějak rozpačitý. Člověk ho musí hlídat jak ostříž. Je to jako mít k ruce nepoučitelného lempla. To, co se nedá podělat, obvykle zvládne,
Ale důsledně si halucinuje i věci, které třeba Intellisense ví (třeba doplňování includů)
A jak má možnost nakráčet do nějaké neinuitivní pasti, tak to spolehlivě udělá.
Heh, komici.
Priklad, ktery jsem psal prave ted.
Potrebuju zaokrouhlovat cisla counteru do prezentace na WEB GUI
Dotaz do AI:
"Please write javascript function that have number parameter "value" and return human readable string with SI suffic like 123.45M or 123.45k."
Odpoved
function formatNumber(value) {
const absValue = Math.abs(value);
const SI_SYMBOLS = ["", "k", "M", "G", "T", "P", "E"];
const tier = Math.log10(absValue) / 3 | 0;
if (tier === 0) return value.toString(); // No need for a suffix for small numbers
const suffix = SI_SYMBOLS[tier];
const scale = Math.pow(10, tier * 3);
const scaledValue = value / scale;
const formattedValue = scaledValue.toFixed(2);
return formattedValue + suffix;
}
Napsani dotazu cca 10 sekund, kontrola kodu cca 20.
Nic co bych nenapsal sam, ale ne za 30 sekund.
Samozrejme, muzete si jak pitomci psat kazdou trivialitu sami, proc ne.
Ja jsem placeny za odvedenou funkcionalitu a zakaznikovi je srdecne u zadi, kde se kod vzal.
Tohle je přesně to, o čem jsem se tu nedávno hádal s Filipem Jirsákem.
Od tohoto slouží už asi 70 let knihovny. Skutečně není potřeba pro každého zákazníka psát všechno od nuly. Firma si má budovat knihovnu, do které bude strkat všechny tyto jednoduché funkce. Tento konkrétní příklad jsme v kroužku programování psali někdy na základce v pascalu. V roce cca 1994. Jestli je na to v roce 2024 potřeba AI, tak je s IT jako s celkem něco opravdu hodně špatně.
To je pravda. Ještě by to ale chtělo zařídit, aby přestala halucinovat. Myslel jsem, jak budu AI používat a i to dělám, ale u spousty úkolů jsem toho musel nechat protože míra nejistoty, že to, co sepsala je taky pravda je hrozně nízká.
Dokud se člověk ptá obecně a o věci nic neví, je to skvělá věc k zorientování se, ale jakmile člověk začne chtít detailní informace, je potřeba v podstatě všechno ověřovat. A to tak, že je když člověk alespoň trochu tuší rychlejší najít si to sám.
Tenhle komentář taky napsala AI? Se podívej na diskusi níže. Ten příklad rozhodně není v pořádku.
O to víc času ale potom zbyde na řešení opravdu důležitých věcí, takže efektivita práce roste.
Ano, tohle se ví od dob průmyslové revoluce. Jenom je potřeba všechny ty stupně udělat dobře. Až tehdy, kdy jsou udělané dobře, tak je můžu pustit z hlavy a věnovat se něčemu dalšímu. Pokud někdo nějakou fci zbastlí (ať už sám, nebo pomocí AI), tak ten program zhavaruje v nejhorší možnou situaci. A potom nastane fáze řešení problémů. Takže efektivita práce roste pouze v případě, kdy je to uděláno dobře.
pár zásahy
No ale těch pár zásahů má právě udělat ten nástroj.
Možná je to jen můj pohled, který je daný tím, čím se celý život zabývám. Ale já mám počítač od toho, aby mi přísně a nekompromisně pohlídal konzistenci dat, přesně spočítal pár věcí (pro člověka nespočítatelné) a pohlídal moje chyby a moji nepozornost. A tak dále.
Takže nástroj pro generování kódu má sám ohlídat všechny corner-cases, protože ty jsou známy. Má mít katalog všech problémů, které byly v minulosti identifikovány.
Iterovat AI prompt do uspokojivého výsledku je sice hezké (asi, možná, pro někoho), ale já osobně od IT nástroje požaduju spíše to, že na to sám upozorní, případně rovnou dá do kódu kontroly.
Takhle přece postupuje systémový inženýr. Na každou chybu, která se vyskytne, se navrhne řešení, testy atd. a ta chyba už příště buď nestane, vůbec se nedostane do kódu, infrastruktury apod., nebo na ni bude alespoň včas upozorněno.
Heh, to jsou kecy. Zrovna tato funkce slouzi pro zobrazeni prenesenych bajtu na specifickem interface na specifickem device za jeden den.
Vystaveno je to na klasicke MIB tabulce ifXtable, soucet hodnot ifInOctets a ifOutOctets - rozdil hodnot mezi pulnocema.
Uz z definice MIBky tam nemuze byt nic jineho, nez UINT.
Tohle numero si nacte SprinBoot backend, ktery to spolu s jinyma atributama vystavi na REST endpointu.
Pricemz ten REST endpoint neni nic jinyho, nez JSON serializovany Java Bean, ktery ma dany atribut jako typ "int" - opet, vubec neni mozne tam mit neco jineho nez integer.
Vue3 frontend si nacte REST API response, prozene to AI vygenerovanou funkci, ktera je pro tyto potreby NAPROSTO DOSTATECNA.
AI nemuze resit corner cases z jednoduche priciny, ze je nezna. Od toho jsem tu ja, abych AI patricne instruoval.
Popravde uz dlouho jsem nevidel vetsi kktinu, nez pracne zabezpecovat primitivni formatovaci funkci na eventuality, ktere nemuzou nastat.
Už jsem zažil jednoho blba, co něco neošetřil pod záminkou "tohle je int32, to se vejde", a po letech celkem dlouho jsem pak hledal divné chyby v logice, které naprosto neměly zjevnou příčinu.
No když jsem pak přišel na to, že je to proto, že se v upstreamu změnil ten typ na short, tak jsem měl hodně chuť slabomyslného autora onoho kódu nakopat do gluteus maximus. Jenže, ono se to dělá dost těžko, kopat se do vlastní.
Tož tolik k tématu "nemůže nastat".
Spíš jestli to vypadá jako kód, který napsal schopný vývojář, nebo nezkušený/lempl. Protože schopný vývojář se zeptá "Potřebuješ i vstupy v tomhle rozsahu?". A pokud ne, tak tam dá komentář s varováním, assert či něco podobného.
Prostě takové základy vycházející z toho, že 80% práce vývojáře se točí kolem louskání starého a ne psaní nového kódu. Že to není studenský projektík typu odevzdej a zapomeň.
No tak si to tam pridej, nebo rekni AI, at to dodela.
AI si pamatuje kontext, staci ji rikat doplnujici pozadavky, dodela to.
Ted jsem otevrel znovu chatGPT, aktivoval jsem z historie staou session a dolnujici dotaz (presne takhle, i s tema preklepama):
"Please modify the funtion, return "n/a" in case of any error and truvcate value if it is not integer."
Vysledek:
function formatNumber(value) {
// Check if value is a valid number
if (isNaN(value)) return "n/a";
// Truncate non-integer values
value = Math.trunc(value);
const absValue = Math.abs(value);
const SI_SYMBOLS = ["", "k", "M", "G", "T", "P", "E"];
const tier = Math.log10(absValue) / 3 | 0;
if (tier === 0) return value.toString(); // No need for a suffix for small numbers
const suffix = SI_SYMBOLS[tier];
const scale = Math.pow(10, tier * 3);
const scaledValue = value / scale;
const formattedValue = scaledValue.toFixed(2);
return formattedValue + suffixes[suffixIndex];
}
Tady nejde o to, že té AI můžu říct, ať to předělá. To jde i pro kód psaný juniorním lemplem. (mimochodem, mám pocit že furt nepokryl třeba nekonečna). Jde o to, že ho musím hlídat i u takové triviality jako formátování čísla.
Když použiju nějakou oblíbenou knihovnu, tak tam takovéhle pakárny hrozí podstatně míň. Protože ji používají různí lidé různými způsoby. Když místo toho ten kód nageneruju AI, tak musí veškerou údržbu odedřít já.
Je to tak. A takové neblahé paměti třeba jQuery pluginy, to teprve bylo dílo. Přemýšlím, jestli jsem kdy narazil na nějaký, který alespoň nebyl totální bastl. Jenomže problém je, že spoustu z nich psali podobní lidé, jako ti, co si dnes nechají podobnou hrůzu vygenerovat AI a celkem nepřekvapivě jim vůbec nepřijde divné, jak výsledek vypadá.
18. 4. 2024, 14:55 editováno autorem komentáře
Kdysi v začátcích se pracovalo (prasilo) stylem „Něco to dělá, úkol splněn. Prodat a zapomenout.“
Postupně jsme se naučili, že:
číst, kontrolovat, analyzovat cizí kód je mnohem víc vyčerpávající než to napsat znova a úplně jinak a správně,
napsat to nějak a pak opravovat — debugovat — opravovat je mnohem pomalejší než hodit nohy na stůl — dát si kafe — promyslet si to — napsat dobře,
prasit a prodávat se dalo v době kdy žádné updaty neexistovaly a zákazník nevěděl co je to zdroják,
hledat chyby stojí mnohem víc peněz než naučit se je nedělat — tedy používat správné myšlenkové procesy vždy — i v maličkostech,
každý program obsahuje chyby — i triviální na pár znaků může mít hloupé přehlédnutí (třeba zanedbaný předpoklad) vyžadující hodiny času na analýzu kdovíkdy v budoucnu — stačí málo myšlení od autora na začátku a nějaký šikovný šťoural to zkontroluje za autora a ten exploit rád použije,
kdybych takhle dělal mojí práci, omlátí mi to o hlavu a kopnou mě do outputu,
… a mnoho dalšího. Ale kdo nedokáže pochopit historii a poučit se z ní, je odsouzen si ji zopakovat, jak snad všichni víme. AI bude mít smysl až bude inteligentnější a hlavně zodpovědnější než člověk, což jistě bude brzo. Ale ne dnes.
To není o ludditech ale o tom, že AI momentálně není ve stavu, aby generovala kvalitní výstupy. Srandovní jsou hlavně bastliči, co tomuhle říkají výstup své práce. A ti byli i před AI. Jediný rozdíl byl v tom, že tehdy bastlili bez AI, ale jejich pochopení toho, jak vypadá kvalitní kód bylo zcela stejné.
Není potřeba. Úkol už byl přece splněn, tedy můžete řešení hezky zařadit do knihovny, ať to může kterýkoliv programátor na světě použít. Jedna ze základních zásad je, nic nedělat zbytečně dvakrát.
Ano, píšu to jako ironii či satiru. Samozřejmě to nemyslím vážně, takový kód bych v kvalitní knihovně viděl dost nerad.
18. 4. 2024, 14:15 editováno autorem komentáře
Nenapíšu, javascript neznám. Krátce popíšu odlišnosti mojeho postupu pro C++ (případně, na vyžádání, třeba pro bash script nebo makefile nebo něco jiného co jsem ještě nezapomněl :-)).
Jsem samozřejmě zvyklý ne psát, ale přemýšlet v C/C++ a pak specificky dle koncepce projektu a s ohledem na maximální efektivnost. Tedy už zadání automaticky vnímám jinak:
Rozlišuju int a float a jiné typy a podle toho teprve vidím algoritmus.
Zde, neznám projekt, předpokládám tedy že je to počitadlo, nejlépe uint64_t. Ani mě nenapadne použít float funkci jako je třeba logaritmus. Pro float typy bych to řešil asi zase jinak. To vidím ve vteřině, automaticky.
Druhá koncepční chyba v zadání: zaokrouhluje se na konkrétní počet platných číslic, nikdy ne na konstantní počet číslic za desetinnou čárkou. Uvědomím si v průběhu psaní. V jednou vytvořeném kódu bych si této chyby ale už nevšiml.
Použil bych 4 platné, ale dodám pro uvedených 5 platných i když je to moc.
Třetí chyba: locales. Nebudu řešit. Též jsem si uvědomil až při psaní, tedy AI je pro mě překážka, způsobující skryté vady.
#include <string>
#include <unistd.h>
using namespace std;
string formatNumber( uint64_t value ) { // only positive numbers
const char * SI_SYMBOLS = "kMGTPEZYRQ"; // ZYRQ not used for uint64_t
string formatted = to_string(value);
const unsigned length = formatted.length();
if (length > 5) formatted.resize(5); // limit to 5 significant digits
// if (length > 4) formatted.resize(4); // or limit to 4 significant digits
if (length > 3) { // add a decimal point and SI prefix
formatted.insert((length+2) % 3 + 1, ".");
formatted += " ";
formatted += SI_SYMBOLS[(length-4)/3]; // can't overflow for uint64_t
}
return formatted;
}
Pro klasické C by to bylo stejně, jen místo typu string by byly manipulace s bufferem typu char * .
Možností jak to napsat je samozřejmě víc, určitě by to šlo i líp, já to napsal takhle.
V původním kódu též nevidím explicitně ohlídaný či zmíněný rozsah pole SI předpon.
Pole SI předpon v původním programu je pole řetězců. Proč ne jeden řetězec, pole znaků?
Ostatní neohlídané věci už tu byly zmíněné: pro float taky malé předpony, nejen velké a nutná jiná kontrola rozsahu pole. Explicitně určit co se zápornými čísly.
Analýza chyb a nedostatků by mi zabrala víc času než napsat to znova. Na některé nedostatky bych pouhou analýzou nepřišel, ale při psaní bych se jim díky mým postupům vyhnul nebo bych je automaticky vyřešil.
To opravdu při psaní funkce nikdy nepočítáš s možností že bude přepoužitá v jiném kontextu? To že tady taková chyba nenastane je hezké, ale tím že se u „tebou psaného“ kódu nedá spolehnout na to, že nesestřelí program když ho použiju jinde z toho dělá peklo v jakémkoliv rozsáhlejším vývoji.
Další problém generování kódu je ve faktu, že programátor běžně tráví mnohem víc času čtením kódu než jeho psaním. Nechávat to psaní na něčem co nemusí generovat nejčitelnější kód není zrovna ideální nápad.
Další problém generování kódu je ve faktu, že programátor běžně tráví mnohem víc času čtením kódu než jeho psaním.
Tak toto zatím vidím jako jednu z nejvíce relevantních myšlenek v této diskuzi (spolu s licencí, kdy dostanu kód, který může podléhat právům). Kód se nejen píše, ale měl by projít i přes nějaké review, případně ho časem bude číst někdo jiný a bude se snažit pochopit, co původní autor zamýšlel. A pomůže-li to "rádobyautorovi" kódu, že má za půlminuty hotovo, o to více času se stráví v budoucnu hledáním záhadné chyby. Takže stále platí, používat AI s rozumem a brát, že může být dobrý sluha, ale zlý pán.
> Kód se nejen píše, ale měl by projít i přes nějaké review, případně ho časem bude číst někdo jiný a bude se snažit pochopit, co původní autor zamýšlel.
Tohle mimochodem přináší další problémy.
1) psát rozsáhlejší věci s LLM je jako psát s horším juniorem a dělat po něm code reviews. S tím rozdílem, že na rozdíl od reálného juniora se nenaučí programovat líp, takže je to nekonečný cyklus. Protože LLM už z principu nechápe co dělá.
2) kolik lidí reálně baví dělat code reviews víc než psaní kódu? Vtípky na lidi co na 2000 řádkový merge request odpoví LGTM a dají approve jsou běžné. Fakt nevěřím že člověk co si zvykne odklepávat generovaný kód nezačne přehlížet chyby.
3) a tohle bude zajímavé sledovat, pokud se opravdu povede nahradit juniory generátorem, může být za pár let problém shánět seniory.
Z autopsie môžem povedať, že v prípade ChatGPT/Python, je ten kód dobre čitateľný a keď ho trošku pobuzerujem, tak vie aj peknú procedurálnu dekompozíciu spraviť. Možno niekedy na prvú dobrú to nedá, ale dá si dohovoriť. Ak obsluha robota má rada guče, robot guču niekedy dodá.
Samozrejme to používam len na hobby projekty, aby som nebol pozadu.
Náhodou jsem tohle potřeboval pár dní zpátky pro jednoduchý výpočet a i když python určitě má knihovnu na zobrazování suffixu, zbastlil jsem to do cca minuty zcela bez AI:
def prettysize(size) -> str:
s=''
if size > 1024: size /= 1024; s = 'K'
if size > 1024: size /= 1024; s = 'M'
if size > 1024: size /= 1024; s = 'G'
if size > 1024: size /= 1024; s = 'T'
if size > 1024: size /= 1024; s = 'P'
if size > 1024: size /= 1024; s = 'E'
if size > 1024: size /= 1024; s = 'Z'
if size > 1024: size /= 1024; s = 'Y'
return f'{size:14.3f}{s}'
(Za ty středníky se omlouvám.)
Zeptal jsem se AI, co si o tom kodu mysli, jestli ho neudela lip.
A vratila mi tohle:
def prettysize(size) -> str:
suffixes = ['', 'K', 'M', 'G', 'T', 'P', 'E', 'Z', 'Y']
for suffix in suffixes:
if size < 1024:
return f"{size:14.3f}{suffix}"
size /= 1024
return f"{size:14.3f}{'Y'}"
Tenhle kod neprochazi vsechny ify, ale skonci na prvni nule, je tudiz efektivnejsi.
Podle mě to je správný tah.
Největší problém je ta licence. Prostě ani teď nemůžu vzít random kód někde z internetu a použít jeho části, aniž bych nezmínil jeho licenci. Copilot to neřeší, ten napovídá věci z jiných projektů a už několikrát byl přistižen, že dokáže okopírovat celé for cykly...
Takže za mě jo, ale hlavně z těch licenčíních důvodů, protože tam to může mít právní dopad, popř. se může jednat i o porušení patentu v případě, že něco je patentované a copilot si to zaindexuje...
Já třeba dělám teď ve firmě, kde to máme explicitně zakázané přesně z tohoto důvodu.
Ale no tak, pánové, vy se tu v diskuzi chlubíte používáním IDE? Takovou koláčo-pojídačovskou věcí? Skutečný programátor si dovolí použít nanejvýš základní textový editor, který nerozptyluje takovými nesmysly, jako barvičky, ani si nesnaží hrát na chytřejšího a našeptávat. Skutečný programátor přesně ví, jak se která metoda jmenuje, jaké má parametry... ;-)
18. 4. 2024, 19:16 editováno autorem komentáře
Jop, takhle v podstate programuji ja :-)
A pak jsem musel nedavno neco delat ve VS/VSCode a neskutecne me to zpomalovalo - u zavorek musim umazavat rucne tu druhou, naseptavac jsem musel na kazdem slovu zavirat pres escape.. copy paste pokazde vlozeny kus preformatovala a musel jsem to upravovat rucne. Tim ze mam clipboard a selection syncnuty v DM, tak to IDE rozbilo veci tim, ze se to snazilo udeat selection, typicky u Ctrl+F, kdy jsem po otevreni dialogu musel umazat co tam bylo a pak vzit co jsem chtel, a vlozit to tam. Omg... produktivita padla o nekolik radu.
Změna skoro vždycky bolí a je doprovázená dočasným poklesem výkonu. Otázka je, jestli by ses po týdnu, dvou nedostal třeba na 80 % výkonu a za půl roku byl na 150 %, až bys návyky přizpůsobil novému nástroji. Aneb šroubovákem hřebík nezatlučeš, ale můžeš s ním vyrobit věci, které kladivo nikdy nedokáže.
Z doby prvních Pentií si pamatuju vtip:
Sparc (velice pomalu): „Kolik je 3+5 ?“
Pentium okamžitě vykřikne: „17“
Chvíli se nic neděje.
Po chvíli Sparc pomalu povídá: „Vždyť je to špatně. Vždyť to má být 8 .“
Pentium okamžitě vykřikne: „Špatně, ale rychle !“
Já vím, vždy je důležitější být první, ale já osobně mám radši když jsou věci správně a pak se opakovaně používají než když jsou rychle a levně a dělají se pokaždé znova a zase špatně. Zrovna IT je velice vhodné pro opakované používání toho co bylo dobře vymyšlené.
Už současný stav těch hraček, které se používají k práci a které kdesi hluboko v technické podstatě jsou zcela deterministické a vlastně i bezchybné, už současná nespolehlivost a nepředvídatelnost je zoufalá. Jistě, AI funguje. Funguje rychle, levně, efektivně. Ale výsledek je prozatím dost nedůvěryhodný.
Už teď máme nehorázný nadbytek nekvalitního kódu a s AI budeme chrlit těch sraček mnohonásobně víc, protože je to přece tááák snadné a rychlé a vždyť to přece obvykle i funguje. Nelíbí se mi to a myslím že se mi to nelíbí z dobrého důvodu.
Napíšu dotaz třeba do GPT. Ten vygeneruje odpověď. Zkouknu výsledek a řeknu si, že mě nepochopil a upřesním zadání. Kouknu na to, a řeknu si, že toto už by mohlo fungovat. Vložím to do svého projektu a otestuju, jestli to dělá co má. Trochu to přeformuluju, protože to není čitelné. Případně to celé rozepíšu, přepíšeu, etc.
Pak si řeknu, že toto není časově|paměťově|etc optimální, a tak se vrátím k GPT, a řeknu mu ať to zoptimalizuje takto a takto.
Ano, nebudu popírat, že existují programátoři, kteří požádají GPT aby jim napsalo esej o Karlu IV a následně to vloží jako javascriptový kód. Ale to nejsou ani zdaleka všichni.
Stejně tak, jako že existují lidé, kteří si myslí, že "s AI budeme chrlit těch sraček mnohonásobně víc".
Stejně tak, jako že existují lidé, kteří dle svých slov dělají 30let v oboru, a přesto neví nic o DI, obhajují Singletony, a GoF je pro ně svatá kráva.
Dokonce existují lidi, kteří dělají/dělali weby v DW, nebo FP, a přišlo jim to ok.
Ano, setkal jsem se s firmou, která měla projekt tak nehorázně zprasený, protože to dělal jeden programátor, který prostě dělal co uměl. Tan kód nebyl zprasený proto, protože by se ten programátor nesnažil, nebo protože by to jinak nešlo, nebo proto, protože používal nebo nepoužíval AI. Ale protože ta firma nerozuměla tomu co dělá. Neudělala si tým, který by kontroloval kód. Nezáleželo jí, té firmě, na kvalitě.
AI je jen nástroj, stejně jako intelisense, FW, github, SO, indové. Prasata jsme my, kteří to pustíme do produkce.
19. 4. 2024, 17:38 editováno autorem komentáře
Tak pekne to začalo :)
A potom sa to zvrhlo na ad hominem. Ak ide o mňa, viem, že myslíte mňa - nepovažujem GoF vzory za posvätnú kravu. Na to som až moc vzdelaný. Osobne viem, že tie vzory majú ekvivalenty v idiómoch rôznych jazykov veľká časť tých idómov by bez vzorov nevznikla. Vzory sú trošku o inom, než si myslíte. Problém, je že ľudia nerozumejú vzorom a miesto porozumenia, rovno len prepisujú kadejaké divné implementácie. Tie vzory majú aj opis, ten je dôležitý, implementácia je vedľajšia. Taktiež si radím pozrieť knihu "Timeless way of building" od Christophera Alexandra, tam je dobre vysvetlené, čo je to ten vzor.
Ale hovoriť o vzoroch ako o antipartternoch, to je trošku už nezmysel, nemyslíte si? :)
Čo sa týka singletonu som sa hral na diablovho advokáta, ten vzor nemám rád a vyhýbam sa mu. Len nemám rád absolútne vyjadrenia typu "Globálne premenné sú zlé", atď. Všetko sa dá použiť k prospechu aj k neprospechu.
GoF mají dva problémy.
1) Jsou staré.
2) Jsou psané na OOP.
Postupem času se ukázalo, že některé doporučované vzory se projevily jako ne úplně vhodné doporučení. Dokonce se jeví, že ty špatné vzory korenspondují s tím co není obecné ale je psáno přímo na OOP.
Teď co s tímto tvrzením můžete udělat:
1/ Můžete si mě zaškatulkovat jako mladého nezkušeného juniora, který si to musí nastudovat. V tom případě se mějte pěkně. Ne, nemusíte mi nic vysvětlovat.
2/ Nebo si mě můžete označit, že jsem nějakej arogantní blbec, ale i blbec může mít pravdu, a co když fakt mluvím ze zkušeností? V tom případě vám pokorně říkám, že neumím moc vysvětlovat. Tudíž sledujte tuto niku sám. Mrkněte se na kritiku GoF, OOP, a spol.
Chudacci ublizeni. Tak si shrnme kolik stoji cas programatora, co vsechno za den sezere, vypije a vylouci, aby mohl 8h programovat. Do toho sviti, bezi pocitac, vyuziva cloud, mejly, NAS a dalsi sluzby. Urcite ma natriskanou lednici, ktera chladi aby mel studeny piti, jede mu klima/topeni. Vari si kafco, to nekdo dovezl az z Brazilie, nemluve o vode kterou vytoci a stoci. Elektrina je z nemecky z burzy, pac ceska neni, takze preshranicni prechod a tedy ztraty. Pokud jel do prace autem, tak jakou udelal uhlikovou stopu. Obidek si necha dovezt az pod nos, coz opet zneuzil nejaky cmoud nekde, pres cmoud to nekomu dobehlo do tabletu, na zaklade toho mu to uvarili a pak nejaky ruzovista privezl autem.
Hele sorry jako, tady zas nekdo neumi do 5ti pocitat.