Zrovna minuly tyden jsem si Julii 1.0 projel a moc se mi libi, vnimam to jako takovej kompromis mezi Pythonem a Clojure (LISPem) s vybornym REPL; Matlab vlastne neznam...
Pak me internet obratil na NIM, tomu jsem dal taky tak tyden. Paradoxne me Julia bavi mnohem vic, ackoli je jako general purpose programming language asi min vyuzitelna a taky o dost pomalejsi. I ty striktni typy nejsou vzdycky uplne potreba..
.
Je videt, jakej vliv v programovani hraje to, 'odkud clovek pochazi' a s cim donedavna pracoval.
Julia ma k FP nativne podle me bliz nez prave NIM nebo treba Crystal.
Coz mi pripomina, jak se tesim na dalsi verze RED -> to a Rebol by si tu sve misto take zaslouzily.
Nechtel byste se nekdy v budoucnu venovat kompilaci Julie do nativniho binary?
Diky,
Kdy treba?
Je dost mozny, ze mi toho dost uslo. Pocitani od 1cky, typova striktnost, volani AST a makra. Dost veci se mi na prvni pohled nezdalo, ale tak nejak mi nakonec vlastne vubec nevadi.
Jinak - napada nekoho duvod, proc by Julia nemohla nahradit Python / Scalu pri praci s velkymi daty?
Vynechejme knihovny.
Spark moc neznám. Napadají mě (možná?) rychlejší user defined funkce. Pravděpodobněji vývoj směřuje k lepšímu SQL.
Strojové učení je záležitost specializovaného hardware. V TensorFlow se spouští vektorizované operace na TPU. Vyjímkou jsou funkce jako foldl nebo scan, kde je povoleno jen několik málo operací ze kterých je vygenerován kód pro TPU. Tam by podle mě Julia moc nepomohla.
Dokáže typový systém Julie kontrolovat tvary matic a tenzorů v čase kompilace? AFAIK ne. V mypy se o to chtějí pokusit.
Diky. Ja zase moc neznam Tensorflow.
Mel jsem spis na mysli 'baliky' jako HDP a podobne, protoze https://github.com/JuliaComputing/JuliaDB.jl
A vadí, že ty bloky připomínají Delphi nebo víc vadí, že to připomíná PL/SQL? A ohledně konzistentnosti syntaxe: jak nejdéle dlouho jste se kdo učil syntaxi libovolného jazyka? 2 hodiny? 5 hodin? Pokud je to ten hlavní problém, doporučuji LISP. Tam je syntaxe tak konzistentní, že se dá vysvětlit během 20 vteřin. Ale upřímně: hodnotit auto jenom podle tvaru volantu mi přijde dost alarmující. :)
Mně vadí, že to je nepohodlné na psaní. Mám radši závorky a ještě radši dvojtečku a odsazení jako v pythonu. Preferuji úspornost kombinovanou s přehledností. Lisp přehledný není.
Nevnímám to jako hodnocení auta podle volantu, ale spíš podle toho, jak snadno se používá (zda se do něj nenastupuje střešním oknem) a jaký je z něj výhled. Pro mě je syntaxe podstatnou vlastností jazyka a vyrostl jsem na C, tak mi přehledný a normální přijde tento směr. Perl toho funkčně zvládne hodně, ale jeho syntaxe mi nikdy nedovolila ho přijmout. Python se imho ujal právě díky jednoduché a přehledné syntaxi, z počátku neměl žádné jiné výhody. Já bych to nepodceňoval.
neomezuje se to jen na https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode co jsem se díval, tak to někteří považují za dobrý nápad, například tady pán https://github.com/JuliaLang/julia/issues/552#issuecomment-4425686 už před šesti lety
A pán, který vymyslel https://en.wikipedia.org/wiki/APL_(programming_language) , to asi tehdy taky považoval za dobrý nápad. Už před 70 lety. Ale nejsem si moc jistý, jestli je to ta pravá cesta.
před 51 lety, ne 70 :-). A APL to vzal strašně do extrému, to asi není dobře. Ale například mít možnost použít odmocninu, sumu, integrál, + s kolečkem, x s kolečkem, = se stříškou, dvojitou ~ atd. je pro matematiky učiněný ráj :-) Cpát unicode znaky všude, jak to dělá APL, se to pravda nemusí.
Ono se to dá zapisovat i přes \sqrt<Tab> a navíc je to omezeno jen na některé skupiny znaků (například nejsou povoleny různé typy mezer, hlavně mnou "oblíbené" mezery s nulovou šířkou, které mi uživatelé cpou do souborů atd.). Některá použití mi přijdou pro matematický jazyk Ok, typicky použití alfabety, indexů a různých operátorů typu a ⊕ (samozřejmě pokud to někdo nemusí datlit přes kód znaku).
Ale je jasné, že se to dá zneužít, ostatně stejně jako například v Pythonu:
def fň(α, ð):
return 2*α + ð
nebo v javě:
class fň {
public void Ξψλ() {
}
}