Zajímavý jazyk na diplomku a následné uplatnění v praxi

[UF]

vyhlaseni vyberoveho rizeni

vybral jsem: Scala

gratuluji! neco tak ohavneho jako scalu bych nedoporucil ani svemu nejvetsimu nepriteli!

[Reklama]

[Fernet]

gratuluji! neco tak ohavneho jako scalu bych nedoporucil ani svemu nejvetsimu nepriteli!

Scalu neznám, ale co je na ní tak špatného?

[UF]

gratuluji! neco tak ohavneho jako scalu bych nedoporucil ani svemu nejvetsimu nepriteli!

Scalu neznám, ale co je na ní tak špatného?

navrh? slozitost? vubec ten napad postavit neco takovyho nad jvm a pouzivat javu? zpetna kompatibilita potazmo stabilita? hodne to pripomina jak pejsek s kocickou varili dort

[Inkvizitor]

gratuluji! neco tak ohavneho jako scalu bych nedoporucil ani svemu nejvetsimu nepriteli!

Scalu neznám, ale co je na ní tak špatného?

navrh? slozitost? vubec ten napad postavit neco takovyho nad jvm a pouzivat javu? zpetna kompatibilita potazmo stabilita? hodne to pripomina jak pejsek s kocickou varili dort

Dovoluju si poznamenat, ze existuje:

1. Transpilace do JS (a funguje pokud vim dost dobre a neni tak nenazrana jako jine podobne snahy nahradit JS nejakym pricetnejsim) - Scala.js

2. Existuje projekt Scala Native, ktery uz JVM take nepotrebuje.

Ano, Scala je hodne drsny jazyk a spojuje OOP a FP. Kompilace je pomalejsi nez u nekterych jinych jazyku. Nicmene na diplomku, nauceni zajimavych konceptu? Podle me skvela volba. A pouziva se, ne ze ne.

[tisnik]

FYI: https://www.tiobe.com/tiobe-index/

sice nemame verit statistikam, ktere si nezfalsujeme sami ale Tiobe ma (bohuzel?) funkci sebenaplnujiciho se proroctvi, protoze to studuji i manazeri

[Reklama]

[Daniel Kozak]

3) Docela dost jsem programoval v Jave takze to bude hezke navazovani. nepujde (doufam) o totalni swich jako by to bylo v pripade napr C++

Tak to je vtip ze ano?

[mikrom]

téma: prakticky jde o práci se souborama, zpracování XML... nic vyjimečnýho. ovládání z konzole, žádné gui, žádný web. O

Tak, specialne na veci ako spracovanie textovych suborov, parsovanie a generovanie roznych formatov bol uz davno vytvoreny jazyk: perl - je to najlepsi jazyk na spracovanie textovych formatov. Je nainstalovany skoro vsade a ma najlepsi repozitar volne dostupnych modulov. Dalsie podobne skriptovcie jazyky su: tcl, python, ruby, groovy (v mnohom a inspirovali tiez hlavne Perlom).

Inac nechapem preco nechces pouzit Javu. Dneska je to najviac pouzivany jazyk - a su k tomu k dispozicii najlepsie kniznice.
Scalu co spominas som nikdy neskusal - stacilo mi ked som si o nej nieco precital a pozrel par zdrojakov a pripadala mi tak hnusna a prekomplikovana v porovnani s Javou - asi ako v 80. rokoch minuleho storocia Ada v porovnani s Pascalom.
Ak by si uprednostnil java platformu, tak Groovy je fakt dobry skriptovaci jazyk.

V pripade ze hladas nieco exoticke mozno OCaml.  Je to funkcionalny jazyk a podla PLEAC sa da v nom urobit na 100% vsetko co sa da aj v Perle. Preto myslim ze je aj velmi prakticky. (skusal som ho, ale zial nikdy som nemal prilezitost napisat v nom vacsi projekt)

[andy]

Tak, specialne na veci ako spracovanie textovych suborov, parsovanie a generovanie roznych formatov bol uz davno vytvoreny jazyk: perl - je to najlepsi jazyk na spracovanie textovych formatov.

To mi připomíná hlášku "python is an executable line-code, perl is an executable line-noise". V Perl6 je spousta věcí asi jinak než v dřívějších verzích, ale po Haskellu mi dneska jakýkoliv jiný jazyk na parsování čehokoliv připadá jako středověk. Scala je dost funkcionální, nějaké "parser combinator" knihovny by pro to mohly existovat.... (ale rychlý pohled do googlu teda neukazuje, že by to bylo moc jednoduché a flexibilní...). Nicméně tady jde o parsování/generování XMLka, na to v Javě (a tím pádem i Scale) existuje spousta určitě vynikajících knihoven, takže by to nemusela být špatný volba.

[Kit]

téma: prakticky jde o práci se souborama, zpracování XML... nic vyjimečnýho. ovládání z konzole, žádné gui, žádný web. O

Tak, specialne na veci ako spracovanie textovych suborov, parsovanie a generovanie roznych formatov bol uz davno vytvoreny jazyk: perl - je to najlepsi jazyk na spracovanie textovych formatov. Je nainstalovany skoro vsade a ma najlepsi repozitar volne dostupnych modulov. Dalsie podobne skriptovcie jazyky su: tcl, python, ruby, groovy (v mnohom a inspirovali tiez hlavne Perlom).

Už si přesně nevzpomínám, co to bylo za soft napsaný v Perlu, ale měl problém se zpracováním znaků unicode. Takže program to byl sice hezký, ale pro mne nepoužitelný. Musel bych ho z velké části přepsat, aby fungoval i s češtinou na vstupu.

[Cikáda]

téma: prakticky jde o práci se souborama, zpracování XML... nic vyjimečnýho. ovládání z konzole, žádné gui, žádný web. O

Tak, specialne na veci ako spracovanie textovych suborov, parsovanie a generovanie roznych formatov bol uz davno vytvoreny jazyk: perl - je to najlepsi jazyk na spracovanie textovych formatov. Je nainstalovany skoro vsade a ma najlepsi repozitar volne dostupnych modulov. Dalsie podobne skriptovcie jazyky su: tcl, python, ruby, groovy (v mnohom a inspirovali tiez hlavne Perlom).

Už si přesně nevzpomínám, co to bylo za soft napsaný v Perlu, ale měl problém se zpracováním znaků unicode. Takže program to byl sice hezký, ale pro mne nepoužitelný. Musel bych ho z velké části přepsat, aby fungoval i s češtinou na vstupu.

A za to může Perl, nebo autor...? 

[Kit]

Už si přesně nevzpomínám, co to bylo za soft napsaný v Perlu, ale měl problém se zpracováním znaků unicode. Takže program to byl sice hezký, ale pro mne nepoužitelný. Musel bych ho z velké části přepsat, aby fungoval i s češtinou na vstupu.

A za to může Perl, nebo autor...? 

Samozřejmě za to může autor, protože pochází ze země, ve které mu stačí ASCII a na ostatní nepomyslel. Ovšem u jazyků postavených nad JVM na ně ani myslet nemusí.

[atarist]

Už si přesně nevzpomínám, co to bylo za soft napsaný v Perlu, ale měl problém se zpracováním znaků unicode. Takže program to byl sice hezký, ale pro mne nepoužitelný. Musel bych ho z velké části přepsat, aby fungoval i s češtinou na vstupu.

A za to může Perl, nebo autor...? 

Samozřejmě za to může autor, protože pochází ze země, ve které mu stačí ASCII a na ostatní nepomyslel. Ovšem u jazyků postavených nad JVM na ně ani myslet nemusí.

jakto? Nam sice ASCII nestaci, ale uz jsem videl, jak lidi prasi se znakovymi pary, resp. vubec je neresi (a mozna ani nevi, ze to maji resit).

[Kit]

Nam sice ASCII nestaci, ale uz jsem videl, jak lidi prasi se znakovymi pary, resp. vubec je neresi (a mozna ani nevi, ze to maji resit).

Co si mám představit pod pojmem "znakové páry"? Ligatury?

[mikrom]

Tak, specialne na veci ako spracovanie textovych suborov, parsovanie a generovanie roznych formatov bol uz davno vytvoreny jazyk: perl - je to najlepsi jazyk na spracovanie textovych formatov.

To mi připomíná hlášku "python is an executable line-code, perl is an executable line-noise". V Perl6 je spousta věcí asi jinak než v dřívějších verzích, ale po Haskellu mi dneska jakýkoliv jiný jazyk na parsování čehokoliv připadá jako středověk. Scala je dost funkcionální, nějaké "parser combinator" knihovny by pro to mohly existovat.... (ale rychlý pohled do googlu teda neukazuje, že by to bylo moc jednoduché a flexibilní...). Nicméně tady jde o parsování/generování XMLka, na to v Javě (a tím pádem i Scale) existuje spousta určitě vynikajících knihoven, takže by to nemusela být špatný volba.

To co som napisal ohladne Perlu zneje asi moc resolutne
Haskell moze byt tiez dobry - ale pripada mi, ze je ovela tazsie ho zvladnut ako napr. Perl.

[atarist]

Nam sice ASCII nestaci, ale uz jsem videl, jak lidi prasi se znakovymi pary, resp. vubec je neresi (a mozna ani nevi, ze to maji resit).

Co si mám představit pod pojmem "znakové páry"? Ligatury?

Toto: http://www.unicode.org/glossary/#surrogate_pair

Jde o to, ze Java (tedy zakladni jazyk nad JVM) pouziva UTF-16, tj. nektere znaky jsou tvoreny dvema po sobe jdoucimi "chary" ve Stringu, protoze "char" ma 16bitu, kdezto nektere jazyky potrebuji az 21 bitu na znak. Vetsinou to automagicky funguje samo od sebe (coz je jadro problemu - kasle se na to), ale uz jsem videl kod, kde se proste spocita pocet "charu" ve Stringu a prohlasi se to za pocet znaku nebo naopak (vidis jak to mate: char nekdy neni znak).

Kde to dela problemy? Vsude tam, kde specka rika neco ve stylu "jmeno bude na 20 znaku", takze se to kontroluje nekde na strane JavaScriptu (tam to bude pocet Unicode znaku, takze v pohode), potom to nekdo pretahne do Javy, kde tech 15 Unicode znaku muze byt take 30 "charu" (takze to napriklad vyhodi vyjimku) a jak se s tim poperou databaze je uz na delsi vypraveni (btw. DB/2 to ma tak domotane, ze se v tom nevyznaji ani na jejich hotline)