Názory k článku Programovací jazyk K: důkaz, že mezi námi žijí mimozemšťané
-
Pavel TišnovskýZlatý podporovatelTen emzák se prozradil sám. Jako ještě se dá pochopit, že vznikne něco jako K. Prostě se zmixoval Scheme (odvozeno od LISPu, což je emzácká technologie*) s APL, ale napsat to v céčku stylem ze třetí kapitoly? (https://www.root.cz/clanky/programovaci-jazyk-k-dukaz-ze-mezi-nami-ziji-mimozemstane/#k03)
Navíc s komentářem, že debugger neumí a ani nemusí umět, protože píše v C bez chyby, to se prostě emzák odkopal :-) Superhuman až inhuman ability :p
-
Pavel TišnovskýZlatý podporovatel
To je prave otazka, jestli je ten projekt nesmyslny, kdyz je na trhu od roku 1993, stale se prodava (nebo pronajima) a Kx systems je porad v teto oblasti leader?
-
BuldrZlatý podporovatelSrozumitelnější než Perl, nebo řekněme většina výtvorů v Perlu.
Celý život jsem si vystačil s ASM a C, čili o jazycích toho moc nevím a stejně mi to připadá lepší než Perl :)
-
Žádný jazyk nemá vestavěné ochrany proti prasení. Různé jazyky jen svádí k jiným druhům prasení. Prasoperl vypadá jako zazipovaný, zatímco třeba prasojava připomíná https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
-
Víc než jak vypadá zdrojový kód by mě zajímalo, jak vypadá binár po přeložení. Je rychlejší, menší, odolnější apod. než binár vzniklý z C? Případně pro které aplikace - s výjimkou zmiňované databáze? (Mimochodem, u databáze to souvisí mnohem spíš s jejím návrhem a způsobem použití než s programovacím jazykem, ve kterém je psaná.)
-
Pavel TišnovskýZlatý podporovatel
Používá se to v oblasti investování, různí burzovní boti (pravděpodobně s tím vlastně Kx začalo), plánovaní letecké dopravy (ale to vím jen ze slidů, nic konkréního), něco mají ve farmaceutickém průmyslu a tuším i spolupracují s NASA. V podstatě se K používá tam, kde APL i J - tedy když se jedná o algoritmy nad vektory/maticemi, které je nutné velmi rychle vyvinout a upravovat podle okamžitých požadavků. Turnaround v minutách až hodinách, ne ve sprintech (nebo u vodopádu za 2 roky :-).
Bych řekl, že pravý opak "enterprise SW inženýringu" :-) a to mě na tom dost baví.
-
Pavel TišnovskýZlatý podporovatel
To je dobrá otázka. Řekl bych, že dneska se K používá prakticky jen v toolech Kx systemu a v souvislosti s kdb+ (K je s tou databází spojen). J je asi rozšířenější i do dalších oblastí. Já vím hlavně o financích, pojištění, investicích. Kde ho používáte vy, abych si rozšířil obzory?
-
Já používám J ke zpracování experimentálních dat ve fyzice, speciálně k testování různých hypotéz o tom, co v datech vlastně je či není. Většinou pro to stačí připsat pár řádků kódu a je to. Je to občas legrace, ale trochu i dřina napsat to správně. Můj pocit je, že -- pro samostatně pracujícího člověka -- je to zajímavý a účinný nástroj, ale pro větší akce nevím, nevím. Občas jsem si říkal, jestli to mělo cenu se v tom hrabat. (Mám dojem, že K je jednodušší, ale mám pocit, že komunita kolem toho je menší, speciálně kolem otevřené [což je pro mě zásadní] Kony.). Zajímavé použití je pro problémy typu Project Euler, další příklady jsou uvedené v Rosetta code. Narazil jsem i na výpočty v astronomii: https://www.astro.umd.edu/~jph/J_page.html. Nedávno jsem si všiml, že Rob Pike si hrál také s APL-podobným jazykem: https://github.com/robpike/ivy. Proč vytváří nový jazyk, nevím, nejspíš si testuje, jak by to šlo udělat (Russ Cox pak použil Ivy taky k řešení pár úloh, k dohledání na webu.)
Přestože má J různé balíčky, například 'plot', po čase, myslím, člověk narazí na potřebu, aby balíčky dělaly i něco jiného, než bylo původně zamýšleno, a to je pak třeba netriviální. Já nakonec vytvořené grafy ukládám do souborů a vykresluji gnuplotem, se kterým se dá pracovat výrazně interaktivněji (třeba si zvětšit zajímavou část grafu). [Ale nakonec ani ten gnuplot není občas ideální. Krásné by bylo, myslím si, řešení postavené na smalltalku, kde by se dalo hrábnout kamkoli a připsat potřebné. V nějakém smyslu by smalltalk fungoval jako roury v unixu, ale s možností posílat složitější zprávy.]
-
Pavel TišnovskýZlatý podporovatel
Díky za info!
Já bych si právě rád nějaký APL-like jazyk nasadil u nás v reálných projektech, ale zatím pro to nevidím prostor. Bylo by to určitě něco podobného jako máte vy, tedy nějaké ověřování dat, clustering atd. Akorát my nemáme homogenní data, spíše jsou to nějaké strukturované JSONy a tak, žádné matice :/
Jinak ten jazyk Ivy Rob Pike asi původně psal jenom proto, aby si dokázal, jak to půjde udělat v Go i bez použití generik (je to starší, než Go 1.18), i když podporuje různé datové typy (třeba zlomky jsou fajn). Na přednášce o tom mluví dost "lehce", ve smyslu že je to skutečně "toy project" a přitom ve výsledku je to prakticky plnohodnotný jazyk. Navíc zrovna Ivy bych asi dokázal přímo dostat do naší code base a tak to spojit s naším toolingem.
* https://www.root.cz/clanky/programovaci-jazyky-odvozene-od-apl-bqn-a-ivy-aneb-1-1-10/#k16
-
„I never comment anything because I'm always trying to make it so the code itself is the comment.“
Arthur WhitneyZ tohoto vždy lezu po zdi. Není nic lepšího než muset opravovat po někom nějaký kód a nevědět, jestli to tam napsal schválně kvůli něčemu co tam nenapsal, nebo je to chyba ... a to všechno kvůli ne-komentářovému náboženství.
-
Přesně. A pro toho, co to napsal, je přece z toho kódu vždycky naprosto jasné, co to má dělat. Jenže stejně hnusný protipól je zase povinné komentování. To pak člověk přečte komentář a ví jen to, co se už dověděl ze jmen a typů.
Nevím, jaký přístup je ideální. Možná nechat kód chvíli odležet a pak znova ty komentáře pročíst, aby se člověk vyhnul tunelovému vidění. -
L.Stříbrný podporovatel
Jednak povinné komentování vyžadované ad absurdum jsem ve striktní podobě snad nikde nepotkal. A i tak vám nijak nebrání napsat rozumný komentář.
Ale když jsou komentáře zakázané, tak se dřív nebo později dostanete do situace, kdy budete muset napsat kód o kterém víte, že až se na něj po nějaké době bude někdo koukat (klidně vy sám), tak bude jen blbě čumět a říkat si "Do p*** proč?!"
-
Zakázané komentáře jsem ve striktní podobě taky nikde nepotkal. Ale potkal jsem už dost jak fanatického "samodokumentujícího" kódu, tak hromadu redundantních (obzvlášť doxygen a spol.) komentářů. Je ale pravda, že jakkoliv špatný komentář se dá přinejhorším vždycky smazat, ale vyvěštit z kávové sedliny už je nejde.
-
L.Stříbrný podporovatel
Ono to nemusí být striktní; hádat se v review u každého komentáře, že tenhle je fakt potřeba a tudíž může mít výjimku taky není žádný med.
S poslední větou souhlasím.
-
... kolik komentářů reálně popisuje ty důvody, proč je v kódu zrovna tohle?
Neřekl jsem, že každý komentář má nějakou závratnou informační hodnotu.
Já nečastěji dávám do komentářů v kódu předpoklady za kterých má kód fungovat správně (pokud potřeba), nebo nějaké obecné předpokládané vlastnosti systému (t. č.) na základě kterých je nějaká funkce nebo nějaký blok napsán tak jak je napsán - obvykle tím chci ušetřit hledání celé koncepce 1/2 systému (při programování jsem tím musel strávit poměrně čas a mělo to zásadní význam). Nebo pokud např. řeším nějakou zapeklitost systém<->framework<->Q&A<->Management a rozhodnu se spáchat nějaký hřích, tak to tam dobře napíšu.
Ono se taky občas stává, že na základě takového komentáře se zjistí, že nějaká 3 roky stará čuňárna z prvního crazy release bug fix už dávno není potřeba, přestože se hezky jmenuje a je jasné jak si pohrává např. s poly nebo entitami .... (z praxe)
21. 7. 2022, 16:57 editováno autorem komentáře
-
PS: Když nad tím tak přemýšlím, tak udělám průměrně (odhadem) tak 1-2-3 komentáře za celou feature. Na druhou stranu, máme tam desítky (ne-li stovky) features per project ...
Když nad tím tak přemýšlím dál, tak většinou dělám commenty takové, aby byl případně kód jasný co dělá i z Merge Requestu, bez zkoumání dalších zákoutí systému. Takových zásadních míst zas tolik nebývá.
21. 7. 2022, 17:02 editováno autorem komentáře
-
@Trident Vasco
To pozor jo, já nenapsal že dám koment do Merge Requestu, ale že dělám komenty (v kódu) takové, že i z těch canců kódu v MR jde díky tomu komentu poznat nějaká zajímavá závislost na okolním kódu (bez nutnosti zkoumat okolí MR). To byla úvaha o kritériích co je dobrý koment.
(Celý kontext je o psaní komentářů do kódu - stejně jako to pravidlo na které jsem reagoval na začátku.)
22. 7. 2022, 15:14 editováno autorem komentáře
-
@Trident Vasco
@InkUvedu příklad: mám feature (nějaká třída), která odněkud tahá data, která sice existují z nějakého důvodu (A), ale také prostě t.č. v aplikaci nepřímo vypovídají o nějaké závislosti nebo procesech v aplikaci (B), tak k tomu kusu kódu poznačím, že předpokad aby tato dala byla k něčemu je že data (B) prostě nesou nějakou nepřímou informaci a pokud je někdo změní, tak to ovlivní fungování feature na které pracuji.
Takže když feature přestane záhadně fungovat, nebo někdo bude hledat v kódu odkaz na data (třeba skrz setter), tak ví proč a jak ta data byla použita. To se vleze na dva tři řádky (120 chars per line) přímo nad nějaký blok. A taky pak i hned může vidět která data nasměrovat místo toho, nebo že už feature data nepotřebuje nebo další upgrade.
Když pak někdo prochází Merge Requestem, tak přesně ví o co jde a pokud něco ví o datech (A) a já ne, tak už ve vchvíli MR může vidět problém nebo MR zarazit ...
To byl smysl toho mého komentáře o MR. Možná jsem to nenapsal nejlíp ...
22. 7. 2022, 15:25 editováno autorem komentáře
-
To obecně není moc dobrý nápad:
https://blog.codinghorror.com/the-problem-with-code-folding/
Cituju zásadní část:
Folding is used to mask excessive length. The presence of folded code can lull developers into a false sense of what clean code looks like. Under the cover of folding, you can end up writing long, horrible spaghetti code blocks. If the code needs the crutch of folding to look organized, it's bad code.
22. 7. 2022, 10:07 editováno autorem komentáře
-
Kde to u vás končívá nevím, ale já jsem se s tím za dvanáct let své praxe nesetkal. Za to jsem se, jak jsem psal, setkal se spoustou kódu, který byl rozlámaný na mnoho podfunkcí bez toho, aby to mělo reálný význam kromě fundamentalismu a toho, "že se to tak přece říká", a bylo problém ho nějak spravovat protože byl problém se v tom bludišti vůbec vyznat.
Ono je to jako se vším. Vše musí mít svou míru. Někdy je lepší kód rozsekat, někdy je lepší ho rozčlenit "nadpisy". Ani jedno nelze zavrhovat a přesně tohle je tedy další způsob jak komentáře využít.
-
Bohužel jsem to zažil a dost lidí ty špagety "miluje". Co se týče rozdělení na funkce, nebudu řešit, co je moc a co je málo - konkrétní příklady, kdy se to nehodí znám - ale funkce by měla mít popisný název a v rozumném IDE nebo editoru se v místě volání v tooltipu zobrazí i dokumentace k ní, takže obecně jsem pro funkce.
-
> "že se to tak přece říká"
Dělení na funkce má následující výhody:
- pojmenování
- funkce má argumenty, tudíž jsou zdůrazněny přitékající data, závislosti
- funkce pomáhá k symetrii - tzn: budete mít tendenci vytvářet podobné funkce, s podobnou strukturou
- což pomáhá k extrakci duplicit
- funkce se dá vypnout/nahradit - rychle a čistě, to pomáhá k pohodlnému a bezpečnějšímu refactoringu.22. 7. 2022, 14:01 editováno autorem komentáře
-
Jo. Ale to nikomu s _existujicim_ systemem nepomuze. Stejne jako prijde opravar a rekne ze je neco rozbity.
Nektere systemy prepsat - no spis napsat znova muze zabrat dekadu za podpory stavajiciho a nekde tyhle vydaje proste neprosadite az do chvile kdy to nejde skalovatPokud potrebujete vyresit problem ( a to obcas propadne i k architektovi) musite mit nastroje jak ho resit. Pri komplexite modernich technologii neni vyjimkou kdy mate kolem sebe na stole bordel a monitoru jak v ridicim stredisku NASA. Obcas to vyzaduje i dekompozici a rozlozeni na mensi tym - dle zavaznosti.
-
Já jsem nakonec zjistil, že mě z druhého monitoru akorát bolí za krkem. Člověk má stejně jenom jedny oči a pokud není potřeba opravdu srovnávat nějaká zobrazená data hned vedle s kódem řádek po řádku, tak jsem tento přístup opustil.
Daleko lepší je dát si minutku a porozumět datům (struktura), najít přesně co je potřeba a pak používat Debugger a sledovat přímo data které tudy lezou. Také řádné psaní oproti testům + Debugger celkem eliminuje potřebu druhé obrazovky, i když ji mám a 2x za týden použiji ...Dokonce jsem ve většině případů přestal používat i IDE rozdělené na dvě okna. Stejně člověk píše jenom v jednom. Pokud vyloženě neporovnávám nějaký git, tak to nedělám a soustředím se na to co píši a na to, odkud tahám podklady.
-
Predpokladam pouze v pripade kdy ta umyslna slozitost byla zamerna. Ano zazil jsem takovych lidi vicero. A to u velkych firem. A jeste se verejne vychloubali ze kod zacunaci takovym zpusobem ze maji praci na dalsi rok. Obcas se clovek pozastavi jak umne plytvaji svym talentem na generovani chyb.
Jenomze je spousta lidi kteri zbytecne komplikuji problemy neumyslne. Jedna se o typ inteligentni blbec. Vic akademik nez inzenyr. Dale nechci naznacovat vuci vecnym asakum co bydli u maminky na jiste fakulte :-)
Jsem dalek jakehokoliv titulu, ale povidal kolega co musi ten material ucit v ramci PhD. ze je to dobry ocistec kdyz cte programatorske vyplody studentu. Asi je. Je totiz neuveritelne tolerantni pri code review :-P -
A další díl letního seriálu bude o https://cs.wikipedia.org/wiki/Brainfuck ? :-)
-
Pavel TišnovskýZlatý podporovatel
Ten uz sel https://www.root.cz/serialy/programovaci-jazyky-z-vyvojarskeho-pekla/
Hmm vlastne bych do toho serialu tento clanek mohl prihodit :)
-
RaviseStříbrný podporovatel
Ne poprvé si říkám "zatraceně, to je ale technologie". Ale poprvé si říkám "škoda, že ji nemám k čemu využít, a abych se to učil jenom tak..."
-
Pavel TišnovskýZlatý podporovatel
jo no, aspoň to rozšiřuje obzory. K je jeden z jazyků, který nezapadá do Algolské větve a skutečně ukazuje, že se dá k problematice programování přistoupit úplně z jiné strany.
