Příspěvky

481

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 04. 04. 2017, 15:50:12 »

Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.

Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?

Jo, to píšu, v C++ to moc elegantně vůbec nejde, ovšem to je trochu subjektivní, "krása" kódu nijak objektivně hodnotit nejde. K hlubšímu zkoumání bych asi doporučil jen STL (a potažmo boost), to je idiomatický kód v C++. A pak možná základní (obecné) třídy clangu, tam je několik velmi hezkých vychytávek ohledně dynamického volání.

kk - mrknu - dik

Není zač. Jinak k tomuto bych doporučil spíše publikace Suttera a Meyerse, já přestal trendy v C++ podrobně sledovat někde u C++11 a teď už skoro máme C++17, takže je možné, že něco opravdu dobrého a doporučeníhodného mi uniklo.

482

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 04. 04. 2017, 15:37:32 »

Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.

Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

zboj - co z c++ knihoven (navrh / kod / api) stoji z tohodle pohledu za prostudovani? QT se mi docela libi z hlediska API ... je to pragmaticky - ty templaty pod tim - v tom sem se zatim raci nevrtal ... boost uz je horsi a vubec proste .... v c++ snad ani hezkej design delat nejde ne?

Jo, to píšu, v C++ to moc elegantně vůbec nejde, ovšem to je trochu subjektivní, "krása" kódu nijak objektivně hodnotit nejde. K hlubšímu zkoumání bych asi doporučil jen STL (a potažmo boost), to je idiomatický kód v C++. A pak možná základní (obecné) třídy clangu, tam je několik velmi hezkých vychytávek ohledně dynamického volání.

483

Vývoj / Re:Zdroje k rozvoji OOP myšlení

« kdy: 04. 04. 2017, 14:13:08 »

Mna by skor zaujimala jedna vec, ze ako viete posudit, ci to, co mate naprogramovane, je dobre, splna OOP alebo sa to aspon k OOP priblizuje. Vedel by niekto popr. odporucit nejaku knizku o OOP?

To je těžké. Jeden nějakou doporučí a další ji zkritizují. Mně je třeba blízký ten přístup jaký má Alan Kay, u nás, co by autory literatury, reprezentovaný zejména pány Čadou a Merunkou.

Jestli je to dobře naprogramované, nebo raději bych použil slovo navržené... to se pozná podle toho, jestli při přidávání nebo úpravě nějaké funkcionality uvažuješ o té funkcionalitě, nebo většinu času zabere dumání, jak k sakru tu prkotinu do toho nacpat, aniž by se to celé muselo překopat nebo aniž by to byla nějaká prasárna. S tím druhým jsem se setkal u většiny projektů v C++, C# nebo Javě.
OOP má obvykle jednu nepříjemnou vlastnost, totiž tu, že násobí jakékoli nešikovnosti, vzniklé v době návrhu architektury. A řekl bych, že ten statičtější přístup (C++, Java) je násobí rozhodně větším koeficientem než ten dynamičtější (Objective C, Ruby).

Osobně považuji za dobře navržený objektový systém např. framework Cocoa. Sám jsem s tím dělal jen párkrát, ale dělalo se mi s tím opravdu velmi příjemně. Lidé, co jsem potkal a měli více příležitostí s tím pracovat, si to ale také velice chválili. Nebo třeba Pharo. Takže inspirace, jak se to dá dobře udělat, bych hledal tady. Když to porovnám třeba s Qt nebo .NET, tak mi to připadá mnohem elegantnější.

Cocoa je skvělý příklad dobrého návrhu, bohužel se s tím člověk ale setká jen na macOS (gnustep je opruz) a navíc to chce ObjC, protože verze pro Swift (hlavně na Linuxu) je galimatyáš. Qt vskutku moc elegantní není (jako nic v C++). .NET bych neviděl tak černě, to je jen běhové prostředí (a jeho základní knihovna není moc OOP). Pro lidi znalé céčka bych doporučil ještě CoreFoundation, to je objektové a multiplatformní (a ukazuje, jak psát objektově v C).

484

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 30. 03. 2017, 14:07:38 »

By se ovsem taky nemelo zapominat na fakt, ze JVM je napsany v C++, ergo cela Java neni nic jinyho nez takovy skriptik pro jednu C++ aplikaci...  ergo byt (treba i senior) Java script-kiddie vubec jeste neznamena umet programovat v C++. Natoz efektivne.

Java je pragmaticky jazyk. Low level java by zrovna vyzerala ako C. C je nevhodny jazyk pre aplikacne kodenie, ale velmi vhodny pre systemove. C ma kompilatory pre vela hw platforiem. Pisat kompilator "protojavy" do strojoveho kodu  by bolo zbytocne plytvanie zdrojmi. Dalo by sa to, ale naco ...  Preto je hotspot pisany v C (a bohuzial aj v C++). Takze super, ze si tu mastite kaspara, ale asi mate malo znalosti.

Houby by se dalo napsat GC s necim, co samo na GC zavisi.

To samozřejmě není pravda.

Příklad? Go. Od verze 1.4 je napsáno samo v sobě... (krásná formulace  )

Samozřejmě se tehdy kompilace skokově zpomalila asi 3x (u velkých projektů), ale nyní je to už zhruba jen 1,5x. Na druhou stranu to má velkou výhodu v jednoduché přenositelnosti a křížových překladech.

Od 1.5

485

Studium a uplatnění / Re:Zkušenosti s ČVUT FJFI

« kdy: 30. 03. 2017, 10:37:14 »

Absolvoval jsem několik online kurzů ze Stanfordu. Například Logika byla v porovnání s MFF výsměch co se týčě obtížnosti. V tom online kurzu jsem dal téměř vše na plný počet. U Mlčka jsem potřeboval několik pokusů a prolezl jsem s odřenýma ušima.

No. A proto absolventi MMF excelují ve vyplňování jakýchsi obskurních testů zatím co absolventi Stanfordu vedou ve všech měřitelných vědeckých i karierních ukazatelích. O absenbci osobního života průměrného mimoně během studia MMF ani nemluvím.

Proč sem pleteš Mezinárodní měnový fond?

486

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 20:57:21 »

A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.

Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad

Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.

ale je stastna - necht jsou vsechny bytosti stastny!

No jo, ale ti, co její výtvory používají, už méně.

hele - ja to chtel po celym dni cteni techdle uletu zakoncit nejak optimisticky ... chapu - nemas den - a chces to na nekoho za kazdou cenu hodit ale ja mam opice docela rad - vlastne sem jedna z nich takze bych byl rad kdybych po dnesku mel take nejake vyhlidky jeste - verim ze opice i lopaty mohou koexistovat v miru!

Tak hodně štěstí s java(megalo)manem

487

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 20:40:53 »

A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.

Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad

Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.

ale je stastna - necht jsou vsechny bytosti stastny!

No jo, ale ti, co její výtvory používají, už méně.

488

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 20:35:21 »

A s sw je to to samé. Kritické aplikace budou postaveny jinak, než ty běžné. Stavět běžné aplikace podle požadavků těch kritických by bylo plýtvání.

Problém je v tom, že každá opice má nevyvratitelný pocit vlastní dokonalosti a chtěla by kritické aplikace dělat stejně, jako dělá ten běžný odpad

Ta největší tragédie je, že opice zhusta neví, že je opice, i když má indicie ze všech stran. Aneb: Ignorance more frequently begets confidence than does knowledge.

489

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 19:00:15 »

btw vetsina aplikaci pametove neustale roste, ne protoze leakuje, ale protoze drzi mnohe data zbytecne (ale lexikalne spravne tj zadna automatika jako GC nepomuze)
programator musi o pameti premyslet jako o vzacnem zdroji. kdyz ne, tak prave programy psane v jazicich s automatickym memory managementem jsou ty nejzravejsi, prave kvuli bezstarostnemu pristupu k pameti.

GC pomůže, může nepoužívanou ale aktivní paměť odsunout na disk. To je mechanismus starý 60 let. Naopak je často spíše problém, že dostupná paměť systému se nevyužívá.

Může mi někdo vysvětlit, proč se tu plete dohromady GC a swapování? Já myslel, že swap je záležitost OS a funguje bez ohledu na tom jestli daná aplikace používá GC či nikoliv. Nebo snad aplikace nevyužívající GC není možné odsunout na disk nebo co (to je spíše řečnická otázka)?

Někdo chtěl spustit off-topic.

490

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 18:59:02 »

No já bych se pustil do těch monád, bude legrace, co?

Nechal bych to být, 99% lidí stejně neví, proč a nač to je.

491

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 18:57:54 »

Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.

Neskutečně blbý byl ten původní kód s několika goto. O tom tvém bez dodatečného kontextu nic říct nejde

Náhodou, mně se goto líbí, já začínal na basicu :-D nejraději bych do moderních jazyků protlačil povinné číslování řádků. :-D ale fakt mě dojímá, kolik jediných správných postupů v programování existuje :-(

Já nekritizuju goto jako takové, ale když někdo použije padesát návěstí, když stačí jedno, to je na exemplární potrestáni

492

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 18:33:32 »

Mně se fakt libí, že ze 3 řádků vytržených z kontextu se dá přesně říct, co všechno je blbě. Za chvíli mě tu někdo začne buzerovat za to, že mam tlačítko v GUI o kousek vlevo a že to není dostatečně ergonomické :-D RAII a RC je to samý v bledě modré. Má to use cases, ale neznamená to, že to musím použít.

Neskutečně blbý byl ten původní kód s několika goto. O tom tvém bez dodatečného kontextu nic říct nejde

493

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 18:12:56 »

Ne. Data kontroluju při načítání. Proč by funkce měly kontrolovat, jestli jim někdo neposlal null jako parametr? To jako pak budu 80x kontrolovat, jestli ten jeden parametr se náhodou nedeterministicky v RAMce nezměnil na null?

A ty víš, co v těch funkcích je? Co když blbost(30) znamená "načti 30x po sobě hodnotu z analogového čidla"? Posuzuješ kód zcela neznámého účelu takovým způsobem, aby to sedělo na tvoje tvrzení. Já dokážu taky vymyslet případy, kdy to sedí na moje. Rozdíl je v tom, že tvůj postoj je striktní a snaží se vyloučit cokoliv jiného, zatímco já hned na začátku přiznal, že ačkoliv se přikláním k jednomu způsobu, striktně na něm netrvám a dokážu si představit i jiné situace.

Tak asi bylo zřejmé, proč jsem ten příklad dával - že takhle vypadá spousta různých věcí. Například pokud by blbost(30) bylo čtení z analogového čidla a "null" znamenalo, že došlo k chybě, tak bys ten "null" do té funkce kravina() asi poslat neměl. Způsob, jak jsi ten kód napsal, v podstatě simuluje "maybe monad" a to není v C-like jazyku zrovna přehledný způsob programování.

Zásadní problém už zmínil Tuxik - GC se nadužívá.

Co to je "nadužívá"? Ano, je pravda, že spoustu věcí klidně vyřeší RAII nebo ARC. Ale co je špatné na použití GC? V 95% aplikací použití GC žádné problémy nepřinese, na druhou stranu moje zkušenost je, že jak nějakou aplikaci rozšiřuju, tak dřív nebo pozdějc narazím na něco, coby GC velmi snadno vyřešilo.

A Tuxík tady pořád šermuje s free(), takže jeho idea asi je, že i celé RAII/ARC je taky na houby....

1. Nezačínejme s monádami, please, to pak bude dalších 500 příspěvků o ničem.
2. Jak jsem psal, špatné je alokovat paměť na haldě, když by stačil zásobník. Toť vše. Jinak když je dost paměti, tak klidně GC až do aleluja.

494

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 17:46:08 »

Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.

Připadá mi, že v 95% případů člověk prostě žádné problémy nemá. A těch 5% je fakt někdy oříšek, který se někdy vyřeší nastavením GC a někdy třeba i tím, že se GC na některé věci prostě nepoužije. Ale z téhle diskuze mám pocit, jako kdyby GC bylo až na výjimky prakticky nepoužitelné....

Zásadní problém už zmínil Tuxik - GC se nadužívá. Slušný kód v GC/RC jazyce má prostě alokovat vše, co jde, na zásobníku, což není problém v Go, .NET ani ObjC nebo Swiftu. Pak není problém ani relativně jednoduchý GC, protože odpadu je málo. Jen v Javě je problém, pročež pak autoři knihoven, aby mohli napsat efektivní kód, sahají k sun.misc.Unsafe, což sice zabere, ale kód je pak k poblití. Mimochodem nejlépe celé to GC funguje v Go i proto, že o tom, co se alokuje na haldě a co na zásobníku, rozhoduje překladač, takže "programátor", co ani nezná rozdíl mezi haldou a zásobníkem, to nemůže moc pokazit.

495

Studium a uplatnění / Re:Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

« kdy: 29. 03. 2017, 17:26:08 »

Jasně, a když spadne blbost(), tak to pěkně celý popadá na nějaký null pointery, že.... ať žije kvalitní kód...

pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny
Už to vidíš? Co vidíš... chápeš? Nebo je normální testovat raději vstup v programu třeba 80x, před každým voláním? Teda vlastně asi ano... bohužel...

Jojo, to je taky úžasný programování, testovat si na začátku každý funkce, jestli mi někdo neposlal null... Pak z toho vychází opravdu přehledný kód....

To je filosofie Go a ano, je to pragmatické a rozumné, ale jen proto, že můžu alokovat i na zásobníku a protože GC v Go je trojbarevný.

Proč by nemělo být pragmatické používat GC i tam, kde tohle třeba splněno není? Pokud není můj use-case zrovna v konfliktu s GC (možná v 95% případech není), tak proč GC nepoužít?

Protože to zbytečně žere paměť a vnáší nedeterminismus. Ono to nemusí vadit na serveru pro nenáročnou aplikaci, ale na omezeném systému (stačí mobil) je znát právě ten paměťový limit. I když zrovna u Go se dá procentuálně nastavit "agresivita" GC a asi by se většina problémů vyřešila. Pro ObjC zase existoval GC umožňující běh real-timových vláken, ale to už jsou okrajové záležitosti.