331
Vývoj / Re:Učit se Javu nebo C++?
« kdy: 28. 06. 2013, 15:42:57 »
Takhle končí každý flame. Sorry, ale ta otázka si o to přímo řekla.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
332
Vývoj / Re:Učit se Javu nebo C++?
« kdy: 28. 06. 2013, 14:20:42 »
Neznám nikoho, kdo by nebyl totální lama* , a -Wall neměl zaplé.
Každopádně souhlasím s tím, že funkce jako printf, malloc/free, setjmp/longjmp etc. by v C++ kódu být neměly, přestože si překladač stěžovat nebude.
* takovej lempl, že pracovat s ním v týmu, tak zajdu za šéfem s podepsanou výpovědí a "Buď já nebo on půjde do jinýho týmu, anebo mi podepiš tohle a za dva měsíce už mě tu neuvidíš"
Každopádně souhlasím s tím, že funkce jako printf, malloc/free, setjmp/longjmp etc. by v C++ kódu být neměly, přestože si překladač stěžovat nebude.
* takovej lempl, že pracovat s ním v týmu, tak zajdu za šéfem s podepsanou výpovědí a "Buď já nebo on půjde do jinýho týmu, anebo mi podepiš tohle a za dva měsíce už mě tu neuvidíš"
333
Vývoj / Re:Python?
« kdy: 28. 06. 2013, 14:14:20 »
Za sebe říkám, že má smysl Python znát. V práci jsem ho použil jen párkrát (nějaký skripty na čištění databáze, protože po*u*vené aplikačky tam dělaly binec v datech + buildování více-jazyčných MSI balíků; ten druhý pak admin přepsal do shellu, ať si kolegové nemusí kvůli buildování C#ového projektu instalovat python). Na školní projekty jsem jej využíval víc - naposledy asi před 2 měsíci ve statistice - musel jsem přerovnat data, aby je dokázal zpracovat statistický software (statgraphics).
Python má obrovskou výhodu v celkem slušném počtu knihoven, (na skriptovací jazyky) slušnou rychlost, relativně dobrou podporu v různých vývojových prostředích (IntelliJ IDEA/PyCharm, Eclipse...), snadnost používání (= "K cíli vy měla vést pouze 1 cesta a to ta nejvíce zřejmá") a dobrou čitelnost kódu, pokud člověk není vyloženě prase. Dá se v něm najít i pár dobrých věcí, které se dotýkají spíš funkcionálního programování, než imperativního.
Jistě že bych měl raději za sebou JVMko a všechny knihovny (např. Apache Lucene* na zpracování textu, ta je hodně brutální
), na druhou stranu skripty napsané v Groovy nebo Clojure mají obrovskou nevýhodu, že musí počkat, než naběhne JVM a potom ještě běhové prostředí pro tyto jazyky. Ačkoliv se člověk obvykle vejde do 1-2s a při vývoji se dá použít interaktivní konzole/REPL (a tím pádem toto celé odpadá), je to k naštvání při běhu - schválně si zkuste pracovat s project management systémem pro Clojure (leiningen), občas mám pocit, že zapustím kořeny ... ještě, že se dá spustit "lein pom" . V pythonu ten skript běží "hned", byť mnohdy pomaleji.
Nicméně mít práci jen a pouze na pythonu mi nepřipadá jako moc dobrý nápad - především proto, že trpí podobnou nemocí jako mnohé ostatní skriptovací jazyky jménem http://en.wikipedia.org/wiki/Global_Interpreter_Lock, tedy zjednodušeně: i když si vytvoříš více vláken, nikdy nepoběží dvě a více zároveň - v jeden časový okamžik vždy jen a pouze jedno a často se střídají (u pythonu cca 100 instrukcí bajtkódu). OK na vytvoření UI, které má 1 dlouhou operaci na pozadí, u které chcete zobrazit modální dialog "Čekejte prosím ..." s progressbarem a tlačítkem Cancel. Nic víc praktického to neumí. Stejně tak se jedná o dynamicky typovaný jazyk, což (z vlastních zkušeností) pro vývojové týmy čítající více než několik málo dobrých lidí může skončit totální katastrofou. Ale skripty, které se rychle spustí, přečtou si z příkazové řádky, co chceš dělat (argparse modul ... super věc), vezmou něco ze stdin a vyblijou výstup na stdout a stderr, je velmi dobrý.
* možná jsem zvolil špatný příklad, protože u této knihovny je možnost ji volat z Pythonu (byť je stále nutné mít nainstalované JVM)
Python má obrovskou výhodu v celkem slušném počtu knihoven, (na skriptovací jazyky) slušnou rychlost, relativně dobrou podporu v různých vývojových prostředích (IntelliJ IDEA/PyCharm, Eclipse...), snadnost používání (= "K cíli vy měla vést pouze 1 cesta a to ta nejvíce zřejmá") a dobrou čitelnost kódu, pokud člověk není vyloženě prase. Dá se v něm najít i pár dobrých věcí, které se dotýkají spíš funkcionálního programování, než imperativního.
Jistě že bych měl raději za sebou JVMko a všechny knihovny (např. Apache Lucene* na zpracování textu, ta je hodně brutální
), na druhou stranu skripty napsané v Groovy nebo Clojure mají obrovskou nevýhodu, že musí počkat, než naběhne JVM a potom ještě běhové prostředí pro tyto jazyky. Ačkoliv se člověk obvykle vejde do 1-2s a při vývoji se dá použít interaktivní konzole/REPL (a tím pádem toto celé odpadá), je to k naštvání při běhu - schválně si zkuste pracovat s project management systémem pro Clojure (leiningen), občas mám pocit, že zapustím kořeny ... ještě, že se dá spustit "lein pom" . V pythonu ten skript běží "hned", byť mnohdy pomaleji.Nicméně mít práci jen a pouze na pythonu mi nepřipadá jako moc dobrý nápad - především proto, že trpí podobnou nemocí jako mnohé ostatní skriptovací jazyky jménem http://en.wikipedia.org/wiki/Global_Interpreter_Lock, tedy zjednodušeně: i když si vytvoříš více vláken, nikdy nepoběží dvě a více zároveň - v jeden časový okamžik vždy jen a pouze jedno a často se střídají (u pythonu cca 100 instrukcí bajtkódu). OK na vytvoření UI, které má 1 dlouhou operaci na pozadí, u které chcete zobrazit modální dialog "Čekejte prosím ..." s progressbarem a tlačítkem Cancel. Nic víc praktického to neumí. Stejně tak se jedná o dynamicky typovaný jazyk, což (z vlastních zkušeností) pro vývojové týmy čítající více než několik málo dobrých lidí může skončit totální katastrofou. Ale skripty, které se rychle spustí, přečtou si z příkazové řádky, co chceš dělat (argparse modul ... super věc), vezmou něco ze stdin a vyblijou výstup na stdout a stderr, je velmi dobrý.
* možná jsem zvolil špatný příklad, protože u této knihovny je možnost ji volat z Pythonu (byť je stále nutné mít nainstalované JVM)
334
Vývoj / Re:Učit se Javu nebo C++?
« kdy: 27. 06. 2013, 15:31:48 »Nauč se nejprve C++, protože z C++ se dá na Javu zlenivět vždy bez problémů. Zato s přechodem z Javy na C++ mají lidi neskutečné problémy, protože pořádně nechápou pointery, nezajímá je práce s pamětí a bastlí neuvěřitelné zhůvěřilosti - např. už namísto atoi, scanf, printf raději na haldě vytvoří stringstream. Plus si z Javy do C++ přinesou množství návyků, které jsou v C++ vyloženě špatné.
Nemůžu si nerejpnout, že scanf a printf jsou v C++ neuvěřitelné zhůvěřilosti. Jsou to Cčkové funkce, ne C++. Chápu, ty dva jazyky k míchání svádí, ale mělo by se to dělat pouze v dobře odůvodněných případech (např. C wrapper kolem C++ kódu apod)
335
Vývoj / Re:java or c++?
« kdy: 26. 06. 2013, 16:25:19 »
To je dotaz typu "Lidi, poraďte mi, jestli mám topit hnědým nebo černým uhlím" nebo "Jsou lepší nektarinky nebo broskve?". Já jsem si u obojího vybral, Ty by sis možná vybral něco jiného. Ani jedno by nebylo špatně.
C++ je jeden z nejkomplexnějších jazyků, které jsou "mainstream". Java je přeci jen jednodušší, i když taky má "ostré hrany". Jestli jsi na střední, je celkem jedno, co si vybereš - jde tu spíš o tom, jaké prostředí je Ti bližší.
Máš raději programy, které běží přímo nad operačním systémem a mohou si snadno sáhnout na železo? Chceš aby Ti nikdo nekecal jak si urovnáváš data v paměti? Chceš mít volnou ruku v tom tu a tam udělat nějakou prasečinku a tím zrychlit běh svých programů?
Pak zvol C++!
Máš raději prostředí, které Ti poskytne všechno možné, které má knihovny téměř na všechno a při tom nemusíš řešit noční můry jako nekompatibilní ABI různých kompilátorů nebo ruční kompilaci závislostí? Nechceš zbytečně řešit těžko dohledatelné "memory leaky" (= zapomenutá / ztracená data v paměti), prostě ať se o to postará někdo jiný, já jsem tu od programování? Nechceš se zbytečně strachovat, kdy Tě zase jazyk vyliská s naprosto nepochopitelnými a nečitelnými hláškami kompilátoru?
Pak zvol Javu!
V dnešní době také neplatí, že OOP = Java nebo OOP = C++. Objektově orientované programování se naučíš klidně v Object Pascalu nebo Pythonu, je to celkem jedno.
A jinak jestli myslíš brněnský FIT VUT, tak se začni drtit C. Budeš ho v prváku potřebovat (Základy programování), jestli se něco nezměnilo. Jestli chceš jít rovnou na magisterské studium FITu a neumíš programovat (tam je prý celkem jedno, v jakém jazyku projekty děláš - většinou si můžeš vybrat; sice mám tu informaci z první ruky, ale osobně jsem to nezažil, tak to ber s rezervou), bohužel Ti musím s lítostí oznámit, že jsi zbytečně vyhodil peníze za přihlášku.
C++ je jeden z nejkomplexnějších jazyků, které jsou "mainstream". Java je přeci jen jednodušší, i když taky má "ostré hrany". Jestli jsi na střední, je celkem jedno, co si vybereš - jde tu spíš o tom, jaké prostředí je Ti bližší.
Máš raději programy, které běží přímo nad operačním systémem a mohou si snadno sáhnout na železo? Chceš aby Ti nikdo nekecal jak si urovnáváš data v paměti? Chceš mít volnou ruku v tom tu a tam udělat nějakou prasečinku a tím zrychlit běh svých programů?
Pak zvol C++!
Máš raději prostředí, které Ti poskytne všechno možné, které má knihovny téměř na všechno a při tom nemusíš řešit noční můry jako nekompatibilní ABI různých kompilátorů nebo ruční kompilaci závislostí? Nechceš zbytečně řešit těžko dohledatelné "memory leaky" (= zapomenutá / ztracená data v paměti), prostě ať se o to postará někdo jiný, já jsem tu od programování? Nechceš se zbytečně strachovat, kdy Tě zase jazyk vyliská s naprosto nepochopitelnými a nečitelnými hláškami kompilátoru?
Pak zvol Javu!
V dnešní době také neplatí, že OOP = Java nebo OOP = C++. Objektově orientované programování se naučíš klidně v Object Pascalu nebo Pythonu, je to celkem jedno.
A jinak jestli myslíš brněnský FIT VUT, tak se začni drtit C. Budeš ho v prváku potřebovat (Základy programování), jestli se něco nezměnilo. Jestli chceš jít rovnou na magisterské studium FITu a neumíš programovat (tam je prý celkem jedno, v jakém jazyku projekty děláš - většinou si můžeš vybrat; sice mám tu informaci z první ruky, ale osobně jsem to nezažil, tak to ber s rezervou), bohužel Ti musím s lítostí oznámit, že jsi zbytečně vyhodil peníze za přihlášku.
336
Vývoj / Re:SQL dotaz
« kdy: 25. 06. 2013, 15:34:51 »
Co se týče času, tak velmi záleží i na tom, co na "localhostu" právě běží. Jestli máš puštěný Firefox, vývojové prostředí, komunikátor, přehrávač hudby, otevřenou knížku v PDFku (... prostě klasickou sadu softwaru nutného pro vývoj ), tak ten dvoujádrák dostane celkem slušně pokouřit a hodnota "1s" absolutně není vypovídající. (Já mám na domácím stroji Core2Duo s 2GB RAM, Win7 64bit, tam by to bylo mnohem horší kvůli nedostatku paměti; naproti tomu na produkčním databázovým serveru, kde neběží nic jiného - i kdyby to bylo dvoujádro s 4GB paměti ve Virtual Boxu - to poběží mnohem rychleji. Každopádně na 30000 záznamů je 1s na takový select poměrně dost; ale výkon je třeba testovat na produkčním serveru nebo někde, kde se nastavení blíží produkci, ne na vývoji.)
O efektivitě každého dotazu Ti nejvíce řekne příkaz EXPLAIN PLAN (pro přesnou syntaxi na MySQL se podívej do manuálu, ta se může mezi jednotlivými databázemi lišit - na Oraclu je to EXPLAIN PLAN FOR sql dotaz;).
Obecně platí, že nejvíce času (pokud jsou tabulky normalizované) se dá nahnat na dobrém indexování - u.VysetreniID, u.PacID a v.Nazev by měly mít indexy, pokud select provádíš mnohem častěji, než insert nebo update (takový, který změní hodnoty v indexovaných sloupcích). Jinak MySQL podporuje několik enginů pro ukládání tabulek, které se liší rychlostí a vlastnostmi - nejznámější jsou MyISAM a InnoDB. Jeden je rychlejší, ale nepodporuje referenční integritu (nevím, který je který - s MySQL se běžně nesetkávám; každopádně je to k nalezení v dokumentaci). Případně se zamyslet nad datovými typy - přístup k varcharům je pomalejší než k charům atd, nebo nad samotnou strukturou dotazů - skutečně je potřeba selectit 30000 řádků, přestože to aplikačka nemá šanci zobrazit? Nestačilo by 30 a udělat stránkování nebo delay-loading?
Každopádně se velmi těžko radí, pokud sem nedáš ERD (diagram vztahu entit), dotazy, které provádíš, jak často se provádí ... nejvíce Ti o tomto opět řeknou odborné knížky. Kromě oficiálních zdrojů typu Amazon se válí různě po internetu, takže se můžeš do nich i podívat, a metodou try-before-buy zjistit, jestli to za ty peníze stojí ;-) .
), tak ten dvoujádrák dostane celkem slušně pokouřit a hodnota "1s" absolutně není vypovídající. (Já mám na domácím stroji Core2Duo s 2GB RAM, Win7 64bit, tam by to bylo mnohem horší kvůli nedostatku paměti; naproti tomu na produkčním databázovým serveru, kde neběží nic jiného - i kdyby to bylo dvoujádro s 4GB paměti ve Virtual Boxu - to poběží mnohem rychleji. Každopádně na 30000 záznamů je 1s na takový select poměrně dost; ale výkon je třeba testovat na produkčním serveru nebo někde, kde se nastavení blíží produkci, ne na vývoji.)O efektivitě každého dotazu Ti nejvíce řekne příkaz EXPLAIN PLAN (pro přesnou syntaxi na MySQL se podívej do manuálu, ta se může mezi jednotlivými databázemi lišit - na Oraclu je to EXPLAIN PLAN FOR sql dotaz;).
Obecně platí, že nejvíce času (pokud jsou tabulky normalizované) se dá nahnat na dobrém indexování - u.VysetreniID, u.PacID a v.Nazev by měly mít indexy, pokud select provádíš mnohem častěji, než insert nebo update (takový, který změní hodnoty v indexovaných sloupcích). Jinak MySQL podporuje několik enginů pro ukládání tabulek, které se liší rychlostí a vlastnostmi - nejznámější jsou MyISAM a InnoDB. Jeden je rychlejší, ale nepodporuje referenční integritu (nevím, který je který - s MySQL se běžně nesetkávám; každopádně je to k nalezení v dokumentaci). Případně se zamyslet nad datovými typy - přístup k varcharům je pomalejší než k charům atd, nebo nad samotnou strukturou dotazů - skutečně je potřeba selectit 30000 řádků, přestože to aplikačka nemá šanci zobrazit? Nestačilo by 30 a udělat stránkování nebo delay-loading?
Každopádně se velmi těžko radí, pokud sem nedáš ERD (diagram vztahu entit), dotazy, které provádíš, jak často se provádí ... nejvíce Ti o tomto opět řeknou odborné knížky. Kromě oficiálních zdrojů typu Amazon se válí různě po internetu, takže se můžeš do nich i podívat, a metodou try-before-buy zjistit, jestli to za ty peníze stojí ;-) .
337
Vývoj / Re:SQL dotaz
« kdy: 25. 06. 2013, 12:00:20 »kde lidé na několika místech v provozu cvakají údaje
Podle toho, co jsi psal, to vypadalo spíš na nějaký školní projekt.
Pokud je to produkční aplikace, tím spíš bych pořádný návrh databáze nepodceňoval. Časem můžeš zjistit, že jsou některé dotazy, které potřebuješ, pomalé (na malém množství dat se to nemusí projevit + ta databáze může časem narůst i co do počtu tabulek atd) nebo tam budeš mít některá data 2x (anebo u ne-normalizovaných databází se můžou i ztrácet). To, že máš chybu v aplikaci snadno opravíš - sice přesvědčit uživatele, aby si nainstalovali update občas není sranda, ale lze to řešit. Nicméně když se Ti podrbou data, tak to často spravit nelze.
338
Vývoj / Re:Správná technologie pro projekt
« kdy: 24. 06. 2013, 06:37:25 »
Java je sice "stabilní jazyk", ale Java je také "Java Virtual Machine". Nikdo neříká, že nemůžeš použít jiný jazyk pro JVM, např. Clojure, Scala, nebo Groovy. Ve všech jmenovaných máš přístup ke všem knihovnám pro JVM, ať už jsou napsané v čemkoliv (když programuješ v Cčku a chceš použít nějakou knihovnu, taky Tě nezajímá, jestli je DLLko napsané v C, C++, Pasclau ..., pokud má rozumné rozhraní). Jinak pro JVM existují knihovny skoro pro všechno, nevidím důvod, proč ji nepoužít - je-li to Tvůj projekt, volba jazyka je na Tobě a jestli zvolíš přímo jazyk Java nebo alternativu, do toho Ti zaměstnavatel kecat nebude.
Node.js neznám, takže s rozhodováním neporadím.
Node.js neznám, takže s rozhodováním neporadím.
339
Vývoj / Re:SQL dotaz
« kdy: 23. 06. 2013, 13:30:31 »jak mam provest vyse uvedeny dotaz, abych dostal hodnoty a nazvy podle kodu z odpovidajici skupiny ?
Správným návrhem databáze ;-)
Přesně tak. https://en.wikipedia.org/wiki/Database_normalization . To, co, Arthure, popisuješ, smrdí průserem.
Každá aspoň trochu knížka o databázích tomuto věnuje min. 1 kapitolu. Ano, je to opruz (= nudná teorie), ale zrovna tady se to hodí. Osobně doporučuji knihu "A Developer's Guide to Data Modeling for SQL Server" (http://it-ebooks.info/book/2132/), která je velmi hezky napsaná.
340
Windows a jiné systémy / Re:Zesílení zvuku ve Windows
« kdy: 09. 06. 2013, 10:32:02 »
Některé hudební přehrávače, např. VLC, umí zvuk zesílit. Zrovna VLC dvojnásobně, což nám na pasiv reproduktory většinou stačilo.
Ale jinak se připojím k typické radě - pořídit si pořádné repro se zesilovačem.
Ale jinak se připojím k typické radě - pořídit si pořádné repro se zesilovačem.
341
Distribuce / Re:Použitelnost staré nepodporované distribuce
« kdy: 07. 06. 2013, 21:10:11 »
Třeba je to s crackem na prodloužení podpory...
342
Distribuce / Re:instalace nepodporované distribuce
« kdy: 06. 06. 2013, 07:55:12 »
Do toho bych nešel. Jak říkáš, nedá se čekat, že budou fungovat repozitáře a pochybuji o dobré podpoře na komunitním fóru. Stejně tak se nedostaneš k žádným bugfixům, ani těm, které se týkají bezpečnosti. Jestli chceš starý software (někdy se říká "stabilní" ), můžeš zkusit nějakou serverovou distribuci, např. CentOS nebo debian stable
), můžeš zkusit nějakou serverovou distribuci, např. CentOS nebo debian stable
343
Vývoj / Re:Konzistence mezi více verzemi aplikací
« kdy: 04. 06. 2013, 06:47:29 »Co nemate zakaznikov? ...
Právěže je asi mají a chtějí si je udržet.
344
Vývoj / Re:Jak se udržuje konzistence mezi více vývojovými verzemi aplikací
« kdy: 02. 06. 2013, 12:10:24 »
V práci používáme sice TFS, ale SVN/Git na tom bude v tomto ohledu podobně - rozdíly jsou jinde.
Řekněme, že máš větev 27.Release.1, která je u zákazníků / uživatelů. Máš 27.HotFixes.1 pro opravy a 27.QA.1 pro testery. Pro vývoj pak 28.Devel, kde probíhá nový vývoj, 28.QA pro testery.
Objevíš chybu ve verzi 27. Chce to se rozhodnout, zda-li opraviš chybu v nové verzi (28.Devel) a starou necháš tak (jsi-li Microsoft, tak si to můžeš dovolit, neb je to nejlevnější varianta), nebo opravu uděláš v 28.Devel a backportuješ ji do 27.HotFixes.1 a pak opravu vydáš s aktualizací (toto se až tak často nepoužívá pro opravy, spíš pro nové funkcionality, které moc nezávisí na jiných částech kódu) a nebo jestli chybu opravíš v 27.HotFixes.1, což je nejčastější.
Až bude oprava zanesena v 27.HotFixes.1 větvi, mergneš ji do QA větve, opravíš chyby (pokud Ti je tester nahlásí; obecně platí, že pokud 1 tester hlásí "vše OK", dej to jinýmu). Až bude čas na vydání aktualizace, větev 27.QA.1 zkopíruješ, kopie nazveš 27.Release.2 a 27.HotFixes.2 a 27.QA.2. Z 27.Release.2 vydáš aktualizaci. Celý kolečko začíná znovu.
Potom si zkopíruješ 28.Devel, např. na 28.BugFixes. Do ní provedeš merge bugfixů z 27.Release.2 a nechát to testery projít. Po opravách ji mergneš zpět do 28.Devel, rozchodíš, merge do 28.QA a znova testování.
Řekněme, že máš větev 27.Release.1, která je u zákazníků / uživatelů. Máš 27.HotFixes.1 pro opravy a 27.QA.1 pro testery. Pro vývoj pak 28.Devel, kde probíhá nový vývoj, 28.QA pro testery.
Objevíš chybu ve verzi 27. Chce to se rozhodnout, zda-li opraviš chybu v nové verzi (28.Devel) a starou necháš tak (jsi-li Microsoft, tak si to můžeš dovolit, neb je to nejlevnější varianta), nebo opravu uděláš v 28.Devel a backportuješ ji do 27.HotFixes.1 a pak opravu vydáš s aktualizací (toto se až tak často nepoužívá pro opravy, spíš pro nové funkcionality, které moc nezávisí na jiných částech kódu) a nebo jestli chybu opravíš v 27.HotFixes.1, což je nejčastější.
Až bude oprava zanesena v 27.HotFixes.1 větvi, mergneš ji do QA větve, opravíš chyby (pokud Ti je tester nahlásí; obecně platí, že pokud 1 tester hlásí "vše OK", dej to jinýmu). Až bude čas na vydání aktualizace, větev 27.QA.1 zkopíruješ, kopie nazveš 27.Release.2 a 27.HotFixes.2 a 27.QA.2. Z 27.Release.2 vydáš aktualizaci. Celý kolečko začíná znovu.
Potom si zkopíruješ 28.Devel, např. na 28.BugFixes. Do ní provedeš merge bugfixů z 27.Release.2 a nechát to testery projít. Po opravách ji mergneš zpět do 28.Devel, rozchodíš, merge do 28.QA a znova testování.
345
Vývoj / Re:Chci se živit programováním - jak začít?
« kdy: 23. 05. 2013, 07:29:14 »Na magistrovi je predmet Manazerska informatika. Povinne predmety su: Paralelne algoritmy, Funkcionalne programovanie, Matematicke struktury a Teoreticka informatika. Vysvetli mi prosim ta, ako clovek, ktory sa vybral na tento obor vyuzije funkcionalne programovanie - haskell, prolog?
Ano VS skola bavi, ale ako co, nie vzdy kazdeho vsetko/kazdy predmet bavi.
Jestli myslíš magisterské obory na FITu ... tyvole to někdo bere vážně??? Jinak funkcionální programování je pro manažery důležité, aby se dozvěděli, že něco takového existuje a že se s tím dají elegantně řešit určité druhy problémů - nicméně tohle člověk ocení až uvidí kód plnej locků, semaphorů, threadů, kterej v produkčním prostředí hází chyby a v testovacím ne. O tom, co za programovací techniku a jaký jazyk se použije, rozhoduje právě manažer a pokud o tom nic neví, je těžké ho přesvědčit o tom, že bych si chtěl tady napsat skriptík v F#. Samozřejmě ale to funkcionální programování nesmí být takovým stylem, jakým se učí právě na FITu, neb tam Ti to tak leda znechutí (BTW ještě furt platí, že se na zkoušce "programuje na papír", bez jakýchkoliv materiálů, popíšeš dvě A4 kódem a strhávají se body za každou chybějící uzavírací závorku v LISPu?)
