Vaše články vždycky prolítnu s nadšením, pokaždé mě překvapí něco nového, díky za ně :)
Sám koukám kolik existuje různých programovacích jazyků pro různé účely, člověk jak si programuje na svojem písečku tak má aspoň náhled mimo svoji bublinu.
Pokaždé mě ale nejvíce zajímá, co vlastně drží takové jazyky při životě, jestli se to ve skutečnosti někde s výhodami bežně v praxi používá, nebo jestli to jsou spíše teorie a prakticky se dnes programujou akorát dema.
V tomto případě se v praxi používá, ale asi jen v rámci Julie. Hodně jazyků je ale buď jen pro výzkum (různé funkcionální a überfunkcionální jazyky), nebo se používají ne pro běh programů, ale nějaké pošahané esoterické divnosti (Lean, Agda…). Občas z nich vypadne něco užitečného pro mainstream, třeba Lean nám dal Mimalloc. Nebo letitý Prolog, nejdřív byl jen akademický, pak byl trochu hajp (v souběhu s hajpem OOP, proto vzniknul OO Prolog), to pak upadlo a nakonec v něm napsali v IBM velkou část Watsona a teď zachraňuje životy v medicíně. OCaml zase vydělává miliardy liber jedné nejmenované firmě automatickým obchodováním na burze. IMHO to je vysoce individuální jazyk od jazyka.
O Mercury byl na Rootu kdysi miniseriál (autor zde: https://www.novinky.cz/kultura/salon/clanek/i-my-jsme-mozna-jen-stroje-rika-matematicky-lingvista-ondrej-bojar-40308679).
Díky.
No programovacích jazyků existuje spousta a jak píšete, mnohé z nich jsou určeny pro specifické účely, popř. mají svoji relativně uzavřenou komunitu, takže o nich není tak slyšet (řekněme, že jsou za svým "wow" zenitem, což je příklad Clojure nebo Ruby).
Ale ono je to relativní. Třeba v minulosti se opticky zdálo, že prakticky každý v UK programuje v BBC Basicu - všude o něm byly články, byl součástí osnov atd. Jenže celkově se BBC Micra vyrobilo nějakých 1,5 milionu kusů a řekněme, že jen na polovině někdo reálně programoval (spíš míň).
Dneska je prý 25 milionu vývojářů, takže i relativně "oskurní" jazyky typu OCaml nebo Erlang mají víc vývojářů než minulý mainstream (obskurní myslím v dobrém významu - prostě divné pro lidi co vyjdou ze školy se znalostí Javy).
Vím třeba o firmách, co vyvíjí v Clojure, jedna firma v Common Lispu. Ale mnohdy ty firmy to ani neprezentují, považují to za konkurenční výhodu (psal o tom kdysi Paul Graham).
Jako obvykle pekny clanek. Jen bych si dovolil malou lingvistickou poznamku. Obrat "tecka dvojice" mi prijde sileny, protoze je to jeden pojem slozeny ze dvou podstatnych jmen "tecka" a "dvojice".
V cestine se pouziva jeste obrat "teckovy par", ktery mi prijde jako mnohem vhodnejsi, protoze kombinuje pridavne jmeno "teckovy" a podstatne jmeno "par", coz je naprosto bezna kombinace slovnich druhu.
Budu se snažit. Ale mám zažitou tečka-dvojici, tak jsme se to kdysi učili v nějakém kurzu AutoLISPu (což byla mimochodem na dobu vzniku skvělá věc). Ale je fakt, že ty skripta mohly jen odrážet pojmenování, které zvolil vyučující (asi se dali LISPači v ČSR nebo možná už v ČR spočítat na prstech jedné, dvou ruk :-)
To neni o vysi latky, ta kniha neobsahuje zadne obtizne partie, ale reakce na pokrok v IT. Zaprve, v dobe napsani SICP moc jinych vysokourovnovych jazyku s lexikalnimi uzavery, automatickou spravou pameti atd. neexistovalo. Zadruhe, konstrukce jako slovniky implementovane pomoci spojovych seznamu s O(n) pristupem dnes vubec nedavaji smysl, kdyz maji vsechny jazyky nejakou vestavenou podporu slovniku. Vetsina prikladu v te knize resi triviality, ktere dnes nikoho nenatchnou, tim mene studenty MIT. V Pythonu muzete od zacatku resit mnohem zajimavejsi problemy.
Hmm z 50% souhlasim, ale ten novy kurz ma trosku jiny zamereni. Uz to nevypada jako uvod do computer science (i kdyz vlastne hned na prvni prednasce puvodniho 6.001 rikali, ze to je spatnej nazev), ale uvod do IT engineeringu.
Re triviality: popravde neumim posoudit, co nadchne lidi z MIT (a urcite se to zmenilo), ale treba uz nekdy ve treti hodine se resi symbolicka derivace a to treba snad u nas na VS v prvaku tedy neuci :)
Jako dal jsem ti plus jedna, ale s tím co píšeš výše moc nesouhlasím. Konkrétně s tím, že by Python nabízel nějaké moc pěkné a pokročilé programování. Jasně zápis je docela čitelný když ukážeš funkci, ale jakmile dojde na třídy, tak nic moc a nekonzistencí je spousta. Obecně pro lidi co potřebují zpracovávat data jsou daleko lepší jazyky s přirozeným "flow" jako je R nebo Julia. Konkrétně Pandas i NumPy má tragický API a cokoliv netriviálního v něm vypadá otřesně. Ten jazyk je asi míň kostrbatý než Java, ale oproti Lisp/Scheme jazykům je to otřes. V ML komunitě se snažili utéct ke Swiftu a to oficiálně Google a teď myslím že se pomalu otáčí svět k Julii. Python nikdy nebyl a nebude dobrý jazyk a čím víc lidí v něm bude dělat tím víc se z něj stane cargo kult, který lidi použijí na cokoliv (obecně špatná věc). Disclaimer: Programuji převážně v Pythonu 10 let. Je to trochu emotivní, tak to ber s nadhledem :)
Ten Swift taky není žádná výhra. Můj subjektivní názor je, že v současnosti jsou v této oblasti nejlepší Julia a Rust (podle konkrétního zadání se lépe hodí jeden či druhý). Ovšem Julii chápu jako DSL (jazyk jako takový je obecný, ale zaměření knihoven je úzké), kdežto Rust už není jen DSL pro psaní jádra prohlížeče. Nakonec se bez ohledu na jazyk stejně volají knihovny ve Fortranu, takže na jazyce zas tak moc nezáleží, je to jako v Armaggedonu: “Back off! You don't know the components! — Components. American components, Russian Components, all made in Taiwan!”.
Už několikrát jsem viděl tvůj komentář o Pythonu a Julii. Já Julii zběžně shlédl, Python znám myslím dobře (a je to někdy děs - pass nebo nonlocal je dost divný), ale co ti připadne na Julii tak dobrého. Fakt mě to zajímá, protože evidentně děláš v podobném oboru jako já (datové rámce, pole, statistika, linalgebra, možná nějaký ten graf).
Typový systém Julie je samozřejmě na míle daleko od Pythonu. To by nebyl takový problém, protože v tom R nebo Wolfram také nevyniká, kdyby neměl pro datovou analýzu naprosto nevhodně pojaté objektové paradigma. Pokud máš např. datovou strukturu DataFrame, nemáš v Pythonu jinou možnost než používat Pandas a táhnout desítky více méně nalepených metod (autor Pandas také s tímhle není aktuálně spokojen). Jakékoliv rozšíření znamená dědit, nebo nějak dynamicky měnit tuto třídu. Daleko vhodnější jsou jazyky co umožňují k nějaké struktuře implementovat funkce. Jestli se to pak volá jako f(g(x)) nebo x > f > g asi není tak důležité, ale oboje ti umožní jak Julia, R, tak Wolfram. Stejně vhodná na takovou práci je i Scala nebo Clojure. Mrkni třeba na tato videa od člověka co dělal mimo jiné ve Wolfram Research: https://www.youtube.com/watch?v=_cIFA5GHF58
21. 1. 2022, 17:43 editováno autorem komentáře
Vetsina prikladu v te knize resi triviality, ktere dnes nikoho nenatchnou, tim mene studenty MIT.
Na prvni pohled to tak mozna nevypada, ale ta knizka resi docela pokrocile koncepty hodne pristoupnou formou.
Je potreba si uvedomit, ze je to urcene de facto pro stredoskolaky prichazejici na VS. A pro tyto lidi treba pochopeni rekurze patri k jednem z nejnarocnejsich veci, ktere musi v uvodnich CS kurzech pobrat.
Na to je prace se spojovyma seznama, jak delana. Ano, muzes to ukazovat i v pythonu, ale ponekud to kazi kouzlo, kdyz ty seznamy mas jako builtin datovy typ.
Zadruhe, konstrukce jako slovniky implementovane pomoci spojovych seznamu s O(n) pristupem dnes vubec nedavaji smysl, kdyz maji vsechny jazyky nejakou vestavenou podporu slovniku.
Z pohledu programovani to smysl nedava. Z pohledu vyuky programovani to smysl dava, jednak viz vyse, ale hlavne cilem tech kapitol je ukazat vytvareni abstrakci.
V Pythonu muzete od zacatku resit mnohem zajimavejsi problemy.
Ve srovnani s Lispem nebo Schemem se v Pythonu mnohem hur dela meta-cirkularni interpreter. To je docela dulezita vec, jelikoz to umoznuje presne uchopit a pochopit proces vyhodnocovani vyrazu vcetne takovych veci jako jsou uzavery.
“V Pythonu muzete od zacatku resit mnohem zajimavejsi problemy.”
To je právě ten problém, lidi se takhle vrhnout na “řešení zajímavých problémů”, aniž by měli potřebný základ. S trochou nadsázky to je, jako kdyby začali studenty fyziky učit, jak postavit jaderný reaktor, aniž by před tím podrobně pochopili klasickou mechaniku, elektromagnetismus a ostatní stěžejní části fyziky. Zrovna SICP konceptuálně nestárne, i když by ho mohli upravit třeba pro Haskell (existuje verze pro JS, ale to je skoro zločin).
Jednou bych si od vás rád početl něco o Mathematice (Wolfram). Co jsem četl, tak původní LISP, měl být založen na M-expressions (https://en.wikipedia.org/wiki/M-expression), ale protože někdo vytvořil rychleji funkční verzi s S-expressions, tak to tak zůstalo. Mathematica používá to první a používá zajímavé paradigma (term rewriting ). Jejich engine je volně k dispozici, takže na hraní by to mohlo stačit (https://www.wolfram.com/engine). Srovnání Julie a Wolframu je docela na místě. Tak snad někdy v budoucnu :)
Lisp je s pomocí M-výrazů pěkně a docela čtivě popsán v původním manuálu LISPu 1.5 (http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf) - se slavnými "Maxwellovými rovnicemi softwaru" na straně 13.