Příspěvky

2116

Vývoj / Re:Za jak dlouho se naučím C++?

« kdy: 13. 06. 2019, 15:51:11 »

He?

Tak to je poprve co slysim, ze se v Jave daji napsat vetsi praseciny nez v C++

Realita je presne opacna, nic jako pointerova aritmentika, multiinheritance, prima sprava pameti apod v Jave neni.

Java vznikla prave jako bezpecne C++ s osmirglovanymi hranami...

Ja hovorím všeobecne o kvalite riešenia, nie o bezpečnosti z pohľadu toho jak umožnuje jazyk manipulovať s pamäťou. V Jave síce pointerova aritmetika a prima sprava pameti sice neni (resp. všetko je pred programátorom skryté), no samo o sobe jde to čo programuješ napísať prasácky, a hlavne tak, že výkon takej aplikácie sakra pokulháva. V C++ když programujem a viem jak programovať v tomto jazyku, tak vo všeobecnosti ľachšie vytvorím kvalitnú aplikáciu, ktorá nebude pri výpočte koľko dní chýba do konca roku žrať pol giga RAMky... (ok to zveličujem, ale princíp je jasný) ale v C++ sú aplikácie určite výkonnejšie a kvalitnejšie v tom zmysle že máš istotu čo ten kód robí (ak tomu rozumieš) a nedochádza tak často k zvláštnym neželaným stavom. V Jave je veľa abstrakcie a docela ľachko sa programátor stratí že čo je na čom jak závislé, a potrebuješ poznať stovky design patternov abys mal istotu že to čo naprogramuješ tak když o pol roka sa k tomu vrátiť a niečo zmeníš, tak že sa celá aplikácia nezosere, a toto spôsobuje dôvod prečo sa vätšina programátorov v Jave snaží to zosratie vyriešiť rôznymi pofidérnymi trikmi (kde práva vzniká nekvalitný kód). C++ na to nieje až tak náchylné. To je prečo môžem povedať že C++ viac tlačí na kvalitné riešenie.

Jenže spotřeba RAM nikoho nezajímá, většina javistů beztak‌ ani pořádně netuší, jak se paměť používá. Čau lidi, giga sem, giga tam, nemáš paměť? Sorry jako, dej si koblihu. Tímhle stylem uvažuje i většina uživatelů 

2117

Vývoj / Re:Za jak dlouho se naučím C++?

« kdy: 13. 06. 2019, 11:06:12 »

kdyby si lidi trosku hlidali alokaci, dealokaci

To je pro většinu příliš intelektuálně náročné.

2118

Vývoj / Re:Za jak dlouho se naučím C++?

« kdy: 12. 06. 2019, 10:06:23 »

Idris: To zní dosti motivačně!

Cikáda: Asi chápu, jak to myslíš. Sehnat práci ve firmě, která je zaplacena tak, že odpovídá náročnosti studia je prý celkem těžké. Programátoři prý nejraději pracují na faktury jako živnost. Je to tak lepší? Já osobně bych preferoval programovat grafiku a hry.

pavels: Je to C++, na což odkazuje i ona kniha. Do budoucna bych se rád naučil i vícero programovacích jazyků

_jenda: 10 minut? To jsi asi špatně pochopil 

Na hry to chce spíše studium fyziky, na to jsou přímo knihy s názvy jako Physics for game developers.

2119

Vývoj / Re:Generovanie spustiteľných súborov z AST

« kdy: 12. 06. 2019, 04:03:29 »

LLVM. Transpilace do C je taky použitelný nápad, pokud není třeba řešit složité runtimové věci jako například GC.

2120

Vývoj / Re:Dotaz ohledně programování c++

« kdy: 12. 06. 2019, 04:00:17 »

Mám na mysli, za jak dlouho je člověk schopný naučit se takovou úroveň, díky které si začne vydělávat!

Znám lidi, co začali vydělávat po měsíci, ale je třeba být realista, půl roku je minimum. Záleží na předchozích znalostech (jiných jazyků).

2121

Vývoj / Re:Má smysl učit se Pascal (Delphi)?

« kdy: 11. 06. 2019, 13:34:50 »

Pro výuku je vhodný jakýkoliv “rozumný” jazyk, Pascal je poměrně rozumný co do syntaxe i paradigmatu.

2122

Vývoj / Re:Vyšší typy

« kdy: 10. 06. 2019, 10:07:22 »

Ha, tak už je má od verze 5.1 i Swift, ale v té nejdivnější podobě, typ se uvede jako “some AProtocol”, překladač zná konkrétní typ, akorát uživatel třídy/funkce je udržován v nevědomosti. Tohle žádný jiný jazyk nemá a fakt to je hlavolam.

2123

Studium a uplatnění / Re:FEL SIT vs. Matfyz informatika

« kdy: 07. 06. 2019, 01:31:18 »

Ona ta matika je pro informatiky na MFF o dost lehčí než před 20-30 lety, “lepší průměr” jí rozhodně projde bez problémů.

2124

Studium a uplatnění / Re:Jakým směrem?

« kdy: 31. 05. 2019, 12:34:12 »

uplatnit znalosti z domény ve které pracuju [...] odtamtud se prokousat na pozici samotného vývojáře softwaru

Tohle je ta správná cesta (ne nutně ovšem jediná správná). I dobrý vývojář, který neumí nic jiného (a i takoví jsou v menšině), je jen fachidiot použitelný pouze omezeně. Rozhodně je dobrý nápad začít od pokročilé znalosti své domény a odtud proniknout do programování.

2125

Software / Re:Aký software od Microsoftu používate?

« kdy: 29. 05. 2019, 14:16:01 »

Občas Visual Studio, případně MSVC z promptu. A sem tam Word, ale na macOS.

2126

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 20:20:00 »

Doteraz nikde som nevidel navrhovať Node aplikáciu spôsobom "a ako prvé si zadefinujeme doménový model". Ani definovaním data access objects. O čom točíte?

tak se programovalo před rokem 2000, v dobách nedokonalých verzovacích systémů dávalo smysl x vrstev abstrakce. Někteří tak programují dosud.

Jak to souvisi s verzovacim systemem? Ja mam za to, ze domenovy model je zaklad dobreho OOP designu.

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

Ten clanek je zajimavy, uz jsem ho cetl nekdy driv, ale v podstate mu chybi neco, co jeho hodnoto hodne devalvuje. A to je, v jakem enviromentu ten otycny clovek pracuje. Je totiz velky rozdil v designu komponent zvolenem v Enterprise a designu zvolenem nekde na mensich projektech. A nemysli si, Java se da taky skalovat - nemusis mit automaticky na vsechno byrokraticky napsanych nekolik vrstev abstrakci. Ackoliv nekteri lidi to maji tendenci delat - respektive mame to tendenci delat vsichni, ale projevuje se to ruzne intenzivne. Odpovida to gaussove krivce, programovani je ohromna zatez a zkouska na kognitivni schopnosti jedince.

O spravnosti OOP a toho, jak to dela Java, uz nepochybuju. Muzu srovnat uz 2 enviromenty, v jednom se bastlilo proceduralne (master Javista byl byvaly PHPkar), v druhem se dela OOP - OOP enviroment svou prehlednosti jednoznacne vede.

O spravnosti designu Javy (a C#) uz nepochybuju taky - kdyz to srovnam s Javascriptem. Celkova kvalita knihoven v Javascriptu neni moc dobra.

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Kdyz ctu tyhle clanky, kde nekdo rozporuje OOP, tak jedna z veci je, ze OOP neznamena Java. OOP je tady uz nekolik dekad. A kdovi, mozna bylo toto paradigma vymysleno jeste predtim, nez vznikly pocitace - jak uz to tak u nekterych veci byva, lidi se jimi zabyvaly driv, nez je vubec meli na cem implmentovat. A je vcelku vtipne, kdyz nejaky jednotlivec rozporuje desitky let vyvoje programovaich jazyku - cimz se zabyvali lide chytrejsi nez ja nebo autor clanku. A jak to dneska vypada v popularite jazyku je jasne videt, OOP jazyky vedou.

Kdybys to měřil inteligencí, tak vede Haskell. I ten je ovšem pro Agdaře primitivní, protože má (z jejich pohledu) omezený typový systém.

2127

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 00:09:07 »

V JS bohuzel nic jako Hibernate nemam.

sebevědomé tvrzení od někoho, kdo JS nezná. ORM knihoven je spousta.

  no prave

https://stackoverflow.com/questions/6007353/which-orm-should-i-use-for-node-js-and-mysql

No longer maintained...
No longer maintained...
No longer maintained...
No longer maintained...

Node.js není moc dobrá volba, sám autor tohoto frameworku přešel na Go

2128

Vývoj / Re:Utilita YACC

« kdy: 20. 05. 2019, 12:21:35 »

Základní teorie zde (Knuth): https://www.csee.umbc.edu/courses/331/fall16/01/resources/papers/Knuth67AG.pdf

Jinak by to ale chtělo více informací o té DSL, takto se radí těžko.

2129

Distribuce / Re:CentOS nebo Ubuntu

« kdy: 18. 05. 2019, 21:58:53 »

poněvadž v klasickém českém korporátním prostředí

Proc predpokladat, ze kdyz chce nekdo pracovat v IT, je to automaticky v korporatnim prostredi?

Krome korporatu je bzilion strednich a malych firem.

Znám pár lidí co linux dělaji v malých firmách. Ti co mají ambice se někam posunovat růst většinou volí CentOS. A garážisti jedou Debian.

Možná to tak neni všude ale v mém okolí ano.

Ať už to je jakkoliv, není lepší umět oboje?

2130

Vývoj / Re:Ideálny programovací jazyk

« kdy: 18. 05. 2019, 19:35:33 »

Běžný Franta vůbec nemá co psát typy, pro něj je typová inference.

Vetšinou ne, ale občas mi přijde explicitně napsaný typ jako skvělý způsob dokumentace, komentáře a zpřehlednění kódu obecně.

S těmi knihovnami to je také jednoduché, někdo na úrovni prostě napíše supersofistikovaný kód (hezký příklad: http://ericniebler.com/2013/07/16/f-algebras-and-c/) a běžný Franta ho jen přímo používá, aniž by si nad ním musel lámat hlavu.

V ideálním případě by to tak šlo. Ale občas ten Franta narazí na případy kdy se musí skrz ten supersofistikovaný kód prokrokovat. Nebo třeba udělá nějakou obskurnější chybu a bude hledat, co se vůbec stalo. Pokud ten supersofistikovaný kód může vidět, tak musí být schopný mu i _přiměřeně_ rozumět. To, že by to nebyl schopný napsat, je druhá věc.

Takto jdou napsat třeba obecné monády v C++ (stejně jako v Haskellu) a pak jen implementovat konkrétní třídy, třeba seznam nebo kontinuaci, přičemž join dostanu zadarmo z bind, nebo fmap apod. Bohužel tohle mainstream moc neumí, ani Java, ani C#, ani Swift. A v tom C++ to sice jde, ale hnusně.

Zrovna u monád je to "hnusně" docela vážný zádrhel. Monády mi přijdou jako vzor, který je sice všudypřítomný ale vlastně dělá malé věci. Takový druh vzoru jako byla třeba subrutina, než se to usadilo tak, že už o tom ani neuvažujeme jako o vzoru. Takže ty hnusné kousky kódu se pak vyskytují všude. Není to kýbl hnusu, který by se dal zabalit do nějakého modulu, jako jsou třeba windows.h.

U toho Go - teď trochu odbočuju - vidím jednu velkou výhodu v jednotné volací konvenci. Z praxe - píšu knihovnu pro HPC využívající AVX-512. Normálně bych musel mít i pro amd64 pro různé OS různé verze funkcí v asembleru kvůli odlišným volacím konvencím. V Go rozhoduje jen CPU, pro amd64 napíšu jeden asembler pro všechny OS.

Tak tohle mě zaujalo. Proč je to třeba psát v asm? Co brání použití intrinsik?

Ano, máte pravdu, já jsem to napsal zkratkovitě, samozřejmě je lepší, když uživatel knihovny aspoň zběžně tuší, jak to funguje pod kapotou. Ta hranice není ostrá, je dobře, že to berete s nadhledem.

K tomu SIMD: Intrinsics mají určitou režii (překladač si pořád řídí proměnné, cykly apod.), v asembleru mám absolutní kontrolu. Navíc v tom Go žádné intrinsics nejsou.