Názory k článku Oslava 55 let od vzniku první implementace jazyka APL

To mě těší. Já ten článek měl připravený už delší dobu, jen jsem čekal na začátek listopadu, aby to padlo na těch 55 let. Na Wolfram se podívám, ale popravdě prozatím jsem v tom moc nedělal (jen samozřejmě semtam dostanu odkaz do jejich moc pěkné dokumentace).

Díky!

S Rustem mám v tomto ohledu zajímavé zkušenosti. V jednom týmu ho chtěli začít používat (rozhodnutí shora), tak se na něj v jednom dílčím projektu přešlo. Od začátku byly náznaky, že to trochu drhne, a po měsíci se zjistilo, že nikdo nic neudělal a lidi se začali přiznávat, že Rust prostě nedávají. Nejdéle mlčeli a mlžili seniorní vývojáři, kteří se dříve chvástali, jak programují od pěti let a VŠ udělal levou zadní. Prostě projekt absolutně zkolaboval, ale na povrch vypluly prozatím skryté lidské vlastnosti.

Jinak co se týká headhuntingu, moje osobní zkušenost je, že vývojáři se zkušenostmi z Rustu mají doménové znalosti hlavně s kryptotechnolo­giemi. Kontejnery ani moc ne, to jsou spíše ti s Go. SQL jsem vždy předpokládal, že zná každý. Opravdu dobrých asi moc nebude (a těch pár je dávno rozebraných).

K tomu SQL - nechci zevšeobecňovat, ale pokud už nabíráš a někdo má v CV napsáno SQL, tak je dobré se v každém případě (i když to nepotřebuješ) zeptat na pár věcí, třeba jestli ví o možnosti constrainů (stačí základní), rozezná typy joinů, nebo úplné základy okolo transakcí. Jsem se totiž setkal s tím, že si tam lidi píšou znalost SQL na základě toho, že si třeba ve škole vyzkoušeli nějakou ORM knihovnu a tím to končilo.

Nevim, kde se vzala predstava, ze uzivatel ORM nemusi znat SQL. ORM slouzi k automatizaci prace s SQL, od constrainu, joinu a transakci vas neodstini. Naopak nauci (donuti), pouzivat best practices.

dopourucuji videa Mika Bayera, autora SQLAlchemy

https://www.youtube.com/watch?v=1Va493SMTcY

To netuším, možná proto, že to tak "pěkně" odstíní od SQL, tak někdo získá pocit, že vlastně nějaký ORM na úrovni "dej mi zákazníky" stačí, že se zbytek dožene v aplikační logice :-). Já to nikdy nebral jako pokus o odstínění, mě SQL nevadí, spíš naopak.

A pěkný videa, díky!

Já teda osobně preferuju SQL, každá vrstva abstrakce nad funkčním a příjemným DSL ve mně vyvolává negativní vzpomínky na neblahé zkušenosti (většinou to buď někde drhne, bývá to pomalé, chybí tomu funkce...).

"příjemným DSL"

zkuste treba tohle vyresit DRY dotazem bez opakovani se

https://www.hackerrank.com/challenges/interviews/problem

v MySQL bez CTE.

ORM umoznuje dekomponovat dotaz na jednotlive casti, konstrukce takovych dotazu, kde se joinuji podobne poddotazy, je mnohem jednodussi.

Proč bez CTE? Dekompozice je jistě užitečná, ale jde stejně dobře i v čistém SQL.

"Proč bez CTE?"

protoze ta stranka pouziva (nejspis?) MySQL 7.

"jde stejně dobře i v čistém SQL."

ok, chci videt ten dotaz

5. 11. 2021, 14:25 editováno autorem komentáře

me nevadi cist SQL, ale psat ho je otrava, lepit dotazy z retezcu je jeste horsi, kazda aplikace (nebo REST API) potrebuje razeni strankovani a pod. GraphQL jeste horsi, s ORM to mate v podstate zadarmo. Dalsi priklad manytomany vazebne tabulky, vytvaret je, rucne je joinovat v dotazech proc? ORM to udela za vas (transparentne).

5. 11. 2021, 13:50 editováno autorem komentáře

Jo, určitě je dobré si to ověřit, kolega se u SQL vždycky ptá právě na JOINy a transakce. Ono do CV si někteří vůbec píšou, co je napadne.

njn. kdysi jsme měli na pohovoru borce, co měl v CV napsanou znalost assembleru. Sice jsme to na pozici nepotřebovali, ale mě to zajímalo, tak jsem se zeptal na nějakou trivku - a vůbec nic, jako vůbec.

Asi si nedovedl představit, že se na to někdo bude ptát. Jeden známý (Čech) si v Americe dával do CV znalost navažštiny. Na jednom pohovoru k němu přivedli nějakého rodilého mluvčího, aby si ověřili, jestli nekecá. Prošel :)

Celkem jo. Byvaly kolega zacinal s rustem kdyz to bylo jeste v plenkach. SQL umi, kontejnery jsem ho naucil ja.
Je to dost rizek typu prijdu naprogramuju odejdu a ono to funguje az do konce sveta. Prirozeny talent.

Naposledy co vim tak si rekl 200kkc a dostal bez diskusi.

8. 11. 2021, 08:40 editováno autorem komentáře

Podle komentářů pod články o jiných jazycích na Rootu je to zjevně jazyk pro lidi, co si myslí, že všechny ostatní jazyky jsou odpad. Tak je v tom nechme. (Zajímavé je, že vývojáři v jiných jazycích ty své tak agresivně jiným nevnucují, dokonce ani ty opravdu pozoruhodné jako Fortran či OCaml :)).

Kdo, kde? Argumentuješ skoro jako Braind. W. ;) Nic podobného jsem tu nikdy nikoho neviděl ani naznačovat.

4. 11. 2021, 19:53 editováno autorem komentáře

Nikdo tu nikdy nehejtoval jiné jazyky? Sorry, nemám čas na další splašky, jdu si psát v Fortranu :)

Je s Tebou legrace, i když se snažíš manipulovat. Tohle fórum je bezva.

Byla by to větší zábava bez hejtů, kdyby si lidi například sdělovali zajímavé postřehy z různých okrajových jazyků. Třeba právě APL či Ocaml, na výběr je jich hodně.

> Byla by to větší zábava bez hejtů, kdyby si lidi například sdělovali zajímavé postřehy z různých okrajových jazyků.

No to mě baví taky. Julia, Haskell, klidně nějaké J, nová Scala, klidně zmiňovaný OCaml. Ale nemyslím si, že dobře míněná kritika je nutně špatná věc. Sám to děláš, koneckonců. Já, coby starý pythonista, sice rostu, když někdo dokola rozpatlává sémanticky významné odsazení (ne že by nemělo nevýhody), ale pokud někdo řekne, že zrovna tohle řešení v Pythonu je nešťastné v tom a v tom a mě to zatím nenapadlo, je to pro mě zajímavé. Přesvědčte mě, že na něco FAKT nemám používat na něco Rust, Python nebo C++ a mám použít Go, budu vděčný. Ukažte mi, proč Java/Scala/Kotlin je fajn řešení (odkaz, který jsem dával k gRPC benchmarku, naznačoval, že Akka gRPC v některých situacích nemá konkurenci) a já budu spokojený.

Jinými slovy, nejsem "sběratel kuriozit", ale zajímají mě praktické výhody a uznám je, kde jsou.

Nemyslím, že by chtěl někdo někoho přesvědčovat, každý svého (ne)štěstí strůjcem. U Rustu mě napadá jen jeden důvod proti, žádný technický, ale prostě jeho náročnost na naučení (viz má zkušenost s týmem popsaná výše). Je skvělé vychválit před šéfem borrow checker a lifetimy atd., ale když se v tom pak lidi plácají a projekt kvůli tomu prakticky stojí, tak je to problém. Nebýt tohoto (a absence podpory Rustu na App Engine a podobných platformách), mohl bych být i zastáncem Rustu (navzdory syntaxi a jiným quirkům).

Jak dopadne projekt, který budou dělat lidé v PHP bez znalosti PHP? Myslím, že ten příklad v tobě zanechal silný dojem, ale problém to nebyl v Rustu ale ve vedení.

Ne, problém byl ve vývojářích. A nevidím v tom nižší inteligenci (jak tu bylo podsouváno), ale spíše lenost či pohodlnost a přístup k práci stylem “nic nového se nechci učit, dejte mi pokoj”. A zrovna u Rustu je vstupní bariéra vyšší a s tímto přístupem neslučitelná.
On to je běh na dlouhou trať, až se bude Rust (i třeba volitelně) více učit na univerzitách, lidi z něj nebudou tak vykulení a v konečném efektu se třeba zvýší obecné povědomí o správě paměti bez GC, životních cyklech instancí apod. I když to je asi jen zbožné přání.

OCaml jsem zavrhl, kvůli mizerné podpoře na Windows, jinak je to skvělý jazyk. Mě právě přišlo, že to tady tvrdíte vy, že Rust je nějaký filtr. S Rustem totiž nemám osobně problém, kvůli tomu, že by snad byl nějak intelektuálně náročný, ale že jeho "featury" nepotřebuju. Když chci něco bezpečného ale ne low-level použiju Scalu. Pokud něco rychle nebo zpracovávám data, tak Python/R. Julia/Wolfram pro mě splňuje spoustu nej, ale nedělá v tom moc kolegů. Pro rychlost, použiji C++/Fortran a C++ bych si vybral pro projekty, co potřebují rychlost ale navíc nějak komunikovat nebo nabízet interface skrze Python (docela častý use-case). Prostě není to o inteligenci ale o ergonomii. Třeba Swift se teď tlačí místo Pythonu skrze TensorFlow -- právě kvůli tomu, že je vlastně více ergonomický -- no uvidíme.

Na fyzice (MFF) se Rust začíná normálně objevovat (aktuální zadání):
"""
To solve the task you can use almost any programming language but I recommend to use Fortran or C/C++ or Rust for the best performance together with Gnuplot for plotting.
"""

To byla narážka na komentář výše ohledně použití APL jako filtru (viz též má zkušenost s Rustem v týmu výše). Jinak zrovna pro tu fyziku dává Rust IMHO smysl a určitě bych ho viděl ve výuce raději než Python. Ale to je čistě osobní názor.

OCaml je fajn jako jazyk, ale taky ho nikde nepoužívám kvůli nižší podpoře. Jinak R a Julia jsou fajn, o tom žádná. Bohužel mám zkušenosti jen s R, ale na Julii se už dlouho chystám, trochu jsem si četl o překladači a runtimu a rozhodně je to zajímavé.

Díky za dobré zprávy o Rustu na MFF :)

"zrovna pro tu fyziku dává Rust IMHO smysl a určitě bych ho viděl ve výuce raději než Python" - nic proti názoru (mě taky slepé prosazování jednoho řešení jen proto, že to dělají i jinde, vadí), jen by mě zajímal důvod. Je to kvůli typovému systému?

Zrovna ta Julia by fyziky mohla oslovit, jak výkonem, tak i sémantikou (a vůbec - funkcionálním přístupem, typovým systémem, nakonec to není špatný jazyk).

Kvůli typům v tomto případě zrovna ne, spíše kvůli výkonu (numerické algoritmy).
Julia by pasovala určitě ještě lépe v tomto kontextu.

Já jsem si kdysi dělal benchmark - řešil jsem nějakou utilitu, kterou máme implementovanou v Pythonu, dost se v ní počítá a není nejrychlejší. Porovnával jsem Python, Cython, Julii, Nim, C++ a Rust. Poslední dva jazyky mi dávaly skoro bez práce výrazně nejlepší výsledky (přesný rozdíl si nepamatuju, ale proti Pythonu šlo minimálně o řád). Jasně, nejsem expert v Cythonu nebo Julii a určitě se to dalo ještě vylepšit a věřím, že konkrétně Julia se v tomto vyvíjí a věřím tomu, že pro vědce bude v lecčems bližší. Jenže ji nevnímám jako GPL a investovat do ní se mi moc nevyplatí. Z tohoto hlediska by mě zajímalo, nakolik fyzici potřebují umět "velký" jazyk, který je převážně zaměřen na systémové programování. Pokud ano, Rust bych doporučil. Jinak snad ani ne...

5. 11. 2021, 11:13 editováno autorem komentáře

to je zvlastni, protoze Julia pouziva OpenBLAS, takze asi stejny reseni, na co jsi pravdepodobne prisel v C++. Takze by to melo byt minimalne srovnatelne. Nebo to bylo neco uplne mimo tema matic/poli?

No ono to bylo takové old school procedurální počítání, žádné explicitní maticové operace.

5. 11. 2021, 12:10 editováno autorem komentáře

https://medium.com/codex/is-julia-really-fast-12cd7caef96b

Hezký příklad symbolické optimalizace. Trochu to přípomíná optimalizace v ObjC (runtime 2.0), tam také převádějí extrémně dynamický jazyk na velice efektivní stroják. Holt pokrok nejde zastavit :)

Fyzici potřebují především něco rychlého na numerické úlohy, a to je doména Fortranu (částečně ze setrvačnosti, jinak to je hlavně o knihovnách). Nicméně pokud se chtějí naučit jazyk, který kromě výpočtů mohou použít i v jiných oblastech, hodí se IMHO C++ nebo právě Rust (kvůli výkonu a hlavně hladké možnosti volání stejných knihoven).

Kdyby to někoho zajímalo, tak od verzi Fortran 2008 jsou dostupné koperativní pole (coarrays), což Vám dává možnost paralelizovat úlohy bez nutnosti škaredých direktiv: https://github.com/tkoenig1/coarray-tutorial/blob/main/tutorial.md To může spoustu úloh zrychlit i bez nějakých velkých změn v kódu. Fortran žije!

Zrovna coarrays jsou snad největší inovací ve Fortranu posledních let (nebo dekád?). Jak to bude česky, kopole? :)

Nezačalo to už kdysi jako rozšíření Fortranu pro Craye, tedy pro paralelní výpočty? Tehdy tomu taky říkali coarray, ale (pokud si pamatuju) tak syntaxe byla úplně jiná.

Jinak zrovna Fortran se k tomuto účelu dost dobře hodí.

Nevím, kde přesně to vyrostlo. Jeden čas, jsem sledoval od Cray jazyk Chapel: https://en.wikipedia.org/wiki/Chapel_(programming_language).
, ale popravdě jsem se nijak nepídil po historických detailech.

Jinak Fortran např. umožňuje OOP (trochu nečekaně namísto přístupu skrze tečku pomocí `%` k atributům.), pak zná `pure` funkce (metody) a spoustu věcí, které běžný programátor vůbec netuší, že v něm existují a že tak starý jazyk prošel takovým vývojem a jde v tom spát naprosto čitelný a moderně vypadající software.

V poslední době se pracuje i na interaktivitě: https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/
(BTW Původní autor SymPy.)

Už to tu nebudu plevelit, ale třeba se časem objeví nějaký článek od Vás až bude mít Fortran nějaké výročí :) Pěkný večer všem.

5. 11. 2021, 19:52 editováno autorem komentáře

Na tohle je dobrá kniha od Akina “OOP via Fortran 90/95”. Zajímalo by mě ale, nakolik se OOP mezi kovanými fortranisty používá. Jestli to není jako v Prologu, když se šéfa jedné nejmenované firmy zeptali, na co je dobrý jejich OO Prolog, řekl, že neví, “naši zákazníci chtěli OO Prolog, tak jsme pro ně vyvinuli OO Prolog.” To bylo v době, kdy OOP bylo buzzwordem.

Jo tu knihu mám. Normálně se OOP moc nepoužívá, ať už z důvodu neznalosti nebo že opravdu není potřeba. Fortran má moduly a submoduly, takže zapouzdření probíhá na jiné úrovni. Ale je pěkný vidět, že se to dá do jazyka přidat za běhu, když je dobře navržený ;) Viděl bych to využití právě při architektuře nějaké specifické části softwaru nebo pro dobré napojení na stávající GUI frameworky. Jinak bych to s tím OOP nepřeháněl.

6. 11. 2021, 07:04 editováno autorem komentáře

No právě, Fortran má hezky udělané moduly. V tom mi trochu připomíná OCaml. Ten sice neznám do hloubky, ale matně si vybavuju, že tam na úrovni modulů mají i typové parametry.

Ano OCaml to tak má. Můžete parametrizovat modul, v jeho žargonu funktor: https://www.cs.cornell.edu/courses/cs3110/2012sp/lectures/lec09-functors/lec09.html

By mě zajímalo, jestli to navrhoval nějaký fyzik, silně mi to připomíná parametricitu třeba v některých aproximacích v QM.
BTW Fortran má IMHO hezky řešené typové parametry, včetně kind, defaultních hodnot apod.

No nějaké kopulování mezi poli tam bude :)

Co asi vznikne, když se spustí pole s řezem? Typický příklad hybridizace :)

Když už jsme u Rustu, tak tady pro informaci: https://gist.github.com/Steelbirdy/65f495807d5d312d5627794190353b05 :)
Z Rustu koukám časem bude Agda :)