Příspěvky

346

Studium a uplatnění / Re:Je už neskoro na programovanie?

« kdy: 05. 05. 2017, 14:16:20 »

Čaute, mám 23 a chcel by som sa začať učiť programovať ale na veľa fórach ľudia píšu že to už je neskoro že mnohý začali už v 15. Preto by som rád vedel aj názor tu na fóre. Oplatí sa s tým začať? Rozmýšľal som že najprv skúsim Python. Zaujímala by aj aká je podla vás náročnosť Javy? IT sa venujem nejaký ten rok len základné veci okolo PC a chcel by som sa na niečo náročnejšie zamerať.

Ne, rozhodně není pozdě. A Java je poměrně jednoduchá a pro začátek celkem vhodná, možná i trochu vhodnější než Python.

347

Studium a uplatnění / Re:Je už neskoro na programovanie?

« kdy: 05. 05. 2017, 14:12:59 »

programator je delnicka profese 21. stoleti
velke procento programatoru bude brzo nahrazeno AI

Kéž by byli nahrazeni AI i na fórech jako tohle 

348

Vývoj / Re:Java projekt co Vas bavil

« kdy: 05. 05. 2017, 14:11:42 »

Na jakem projektu v Jave ste pracovali a byl pro Vas zajimavy?

Přepisování data science aplikace do C, aby to bylo použitelné. V Javě zůstal jen glue code, co volal to opravdu důležité přes JNA. Nevýhoda byla, že javisti tomu pak už nerozuměli. Moment, to je vlastně výhoda...

Kdyby tady sly davat lajky(diky bohu, ze takova prasarna tady neni), tak tady by byl prvni co dam
Ale jinak, proc JNA a ne JNI?

JNA kvůli pohodlnosti.

349

Vývoj / Re:Java projekt co Vas bavil

« kdy: 05. 05. 2017, 13:46:02 »

Na jakem projektu v Jave ste pracovali a byl pro Vas zajimavy?

Přepisování data science aplikace do C, aby to bylo použitelné. V Javě zůstal jen glue code, co volal to opravdu důležité přes JNA. Nevýhoda byla, že javisti tomu pak už nerozuměli. Moment, to je vlastně výhoda...

350

Bazar / Re:Koupím PowerMac G5 (2x CPU)

« kdy: 03. 05. 2017, 16:14:45 »

to je to zmateni kdyz pisete MacOS a myslite Mac OS X (leopard). MacOS pro mne znamena devitkou konce a pak az sierra

OS X je teď macOS (s malým m). Apple v tom nadělal brajgl...

351

Bazar / Re:Koupím PowerMac G5 (2x CPU)

« kdy: 03. 05. 2017, 11:28:24 »

Zalíbil se mi design skříně a podle mě by měl mít dost výkonu i na dnešní dobu (když nebudu mít otevřeno milion tabů s fejsbůkem a podobnýma JS věcma).

Problém je hlavně s tím, že na něm rozjedeš jenom hodně historický MacOS a tímpádem nebudeš mít ani aktuální aplikace. S nějakým Linuxem by ale normálně použitelný být mohl, akorát to je opravdu velký, těžký, hlučný a má velkou spořebu, což ti ale asi nevadí

To nadšení pro tu skříň chápu, je fakt pěkná.

OS X 10.5

352

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 16:52:51 »

Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.

Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.

Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.

Ano, a doteď tím trpíme - překladače se chovají divně (mají svou verzi C), asembler je taky proprietární, vše má své ABI (volání mezi Go a C musí přesypávat zásobník do registrů a vice versa), zarovnávat a přehazovat zásobník, halda není halda atd. Jinak ale naprostá pohoda...

353

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 13:05:19 »

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).

Vůbec nejde o akademické články. Akademickým článkům té doby by běžný Pepa kodér vůbec nerozuměl. Jde o texty praktiků, kteří popisovali své zkušenosti a často i řešení problémů, s nimiž se setkali.
Např. zmiňovaný postřeh o nepředvídatelnosti budoucího vývoje SW produktu. Tak na to naráželi už v 70. letech. A řekl bych, že většina z nás se už někdy setkala s poznámkami "reserved for future extensions". A taky tenkrát doporučili, jak se s tím vypořádávat:
1. Řešte jen problém, který máte skutečně řešit dle zadání. Dejte si pozor na dodatečné podmínky, které ve skutečnosti ze zadání neplynou, ale vy jste si je podvědomě dotvořili ve snaze předvídat budoucí vývoj nebo řešení nějak vylepšit, a přitom vedou k potřebě větší abstrakce a komplexity.
2. Pokud obecnější řešení v daném případě nevede k nárůstu komplexity nebo náročnosti na zdroje, není důvodu omezovat se na specifikaci.

Zdůvodnění je jednoduché. V naprosté většině případů o ta vylepšení nikdo nestojí a vývoj se bude ubírat jiným směrem než si myslíte, ale jejich přítomnost velmi zkomplikuje budoucí modifikace směrem, s nímž se nepočítalo. Jednoduchá věc se dá překopat snadněji než komplikovaná.
Vyčleníte-li někde 4 bajty pro budoucí rozšíření vlastnosti X, 4 bajty pro vlastnost Y a 4 bajty pro vlastnost Z, vemte jed na to, že jich nakonec bude zapotřebí nejméně 5 pro vlastnost X a vyvstane potřeba přidat vlastnost W, co potřebuje 2 bajty, a vlastnost Y už nikdo nepotřebuje, protože děrné pásky odnesl čas. Přestože prostor k obojímu je, technicky to bude hlavolam, protože někdo před lety "myslel" víc, než bylo zdrávo. Je to jen ilustrační příklad, ale na podobné situace jsem ve svém profesionálním životě narážel neustále - komplikované hierarchie tříd, zabránění opakování stejného kódu i za cenu, že se to celé znepřehlední zbytečnými abstraktními mezičlánky a lepidly mezi nimi, jež vydají za 5x tolik kódu, než kdyby se to prostě duplikovalo apod., načež se potom ukáže, že přeci jen ten kód nebude úplně stejný, takže struktury, jež měly zamezit duplikaci kódu, se musejí obcházet a nastavovat jak kaše, protože tím okamžikem ztrácejí smysl, ale zato vydatně překážejí.
Přestože formulace je jednoduchá, realizace je náročná, protože ne každý si umí ty klapky z očí sundat a má cit pro to, co ještě ano a co už ne. Ale rozhodně by přemýšlení o takovýchto věcech měl být dáván větší prostor, než jak nejčistěji aplikovat návrhový vzor XYZ, protože jsem podlehl pocitu, že jde o zázračný všelék, který za mě vyřeší problémy. V knížce to sice vypadá elegantně, možná se to i v konkrétním případě podaří implementovat elegantně, ale jakmile bude třeba do toho trošku hrábnout, stane se z toho podobný zážitek, jako oprava traktoru typu LKT.

Nemohu než (opět) souhlasit, že návrhové vzory nejdou všelék a mnohdy nadělají víc škody než užitku. Jako i jinde mimo IT obecně platí "tonoucí (nekompetentní programátor) se stébla chytá" (a navíc se pak do krve hádá o něčem, čemu ani trošku nerozumí). Jenže s tím nic nenaděláme...

354

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 02. 05. 2017, 12:31:04 »

Možná by se situace vyjasnila, kdyby se místo názvu "ekvivalence" operátoru === zde v diskusi používal název "identita".

To by situaci mohlo ještě zhoršit, protože pojem "identita" se obvykle používá pro funkci (x) -> x. Takže kdyz už, tak "testování identity".

Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.

Ten první operátor by právě vracel

Kód: [Vybrat]

new Bool(true) == new Bool(true) -> true

Radši nezacházej moc daleko do identit, nebo na tebe vytáhnu Theseovu loď   

355

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 12:09:01 »

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Co konkrétně máš namysli tady u toho, o čem jsme se bavili? To je spíš o zkušenosti než o nějaké teorii imho.

Běžný Pepa (nebo Míra)

Já ti dám Míru, ty darebáku!

 

356

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 11:01:22 »

Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.

Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.

Ano, tomu se říká "cargo cult programming" a obávám se, že mnozí, ne-li většina, takto programují a ještě si na tom zakládají.

357

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 10:57:29 »

Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.

Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).

358

Vývoj / Re:Proč je Go tak pomalý?

« kdy: 02. 05. 2017, 00:22:15 »

Zatím zde nepadlo odpověď, proč si tazatel myslí, že je Go pomalejší než Java nebo C#, ačkoliv i z těch benchmarků jednoznačně vyplývá, že to není pravda.

Pokud se ve VM nikdy nespustí GC, tak u některých typů úloh bude Go "pomalejší", protože má nedeterministický alokátor. To je ovšem značně nerealistická situace, v praxi je Go výrazně rychlejší (minimálně v porovnání s Javou, .NET má komplikovanější VM). Takový "benchmark" se dá napsat levou zadní (jen nebude o ničem vypovídat).

359

Vývoj / Re:Webova aplikacia v PHP

« kdy: 01. 05. 2017, 21:29:00 »

Koukám další frikulín co naprosto nic netuší o historii a honí si nad tím, jak programuje v tom "moderním" FP a ne v "zastaralém" OOP Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?

Osobně preferuji OOP, OOP se prosadilo, aby se v C nemusely volit názvy jako tmp_xbs_stuff_create(). Do té doby to byla jen univerzitní hříčka, která vznikla stejně jako FP někdy dávno v minulosti. Ostatně všechny koncepty vznikly někdy v pozdních šedesátých letech a začátku let sedumdesátých.

FP se prosadí zase kvůli multiprocesorovému zpracování a čtení údajů (výsledků z jiných procesorů) z více zdrojů najednou v jednom proudu. Ovšem problém FP je zase pojmenování funkcí, takže to zase povede na konstrukt logická_entita.operace(parametry)

Tak ono to FP pokradmu proniká do mainstreamových (vesměs OOP) jazyků. Jistě se prosadí, ale tak nějak postupně a nenápadně...

Tak ono i prosazování OOP do praxe byl velmi klopotný proces a plný kompromisů. Pamětníci vědí :-)))

Jo, pamatuju, byla to směs OO a procedur...

360

Vývoj / Re:Webova aplikacia v PHP

« kdy: 01. 05. 2017, 20:31:39 »

Koukám další frikulín co naprosto nic netuší o historii a honí si nad tím, jak programuje v tom "moderním" FP a ne v "zastaralém" OOP Když se FP do mainstreamu neprosadilo za tu spoustu desítek let co existuje, proč by se mělo prosadit v blízké budoucnosti?

Osobně preferuji OOP, OOP se prosadilo, aby se v C nemusely volit názvy jako tmp_xbs_stuff_create(). Do té doby to byla jen univerzitní hříčka, která vznikla stejně jako FP někdy dávno v minulosti. Ostatně všechny koncepty vznikly někdy v pozdních šedesátých letech a začátku let sedumdesátých.

FP se prosadí zase kvůli multiprocesorovému zpracování a čtení údajů (výsledků z jiných procesorů) z více zdrojů najednou v jednom proudu. Ovšem problém FP je zase pojmenování funkcí, takže to zase povede na konstrukt logická_entita.operace(parametry)

Tak ono to FP pokradmu proniká do mainstreamových (vesměs OOP) jazyků. Jistě se prosadí, ale tak nějak postupně a nenápadně...