Kniha Objektové programování od Čady

[gll]

Většina učebních textů a  kurzů  programování  však  tuto  skutečnost  nebere  v  úvahu  a  je  nadále  koncipována  přede-vším jako kurzy, ve kterých se jejich čtenáři, resp. frekventanti učí především syntaxi použitého jazyka. Opravdu objektový přístup k vývoji programu se proto studenti učí až v nadstav-bových kurzech, kdy ale již mají zažitu řadu zlozvyků, které se musejí postupně odnaučovat.

Myslím si pravý opak. Postupovat se má od konkrétního k obecnému. Nejdřív se pořádně naučit syntax alespoň jednoho jazyka. Až potom řešit nějaká paradigmata. Přeskakování základů produkuje polovzdělance jako zboj.

Teď jde o to, co je zde vlastně to konkrétní a co to obecné. Aby to nevedlo k jevu, jenž znám ze základní a střední školy, kdy převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, přestože jsme se v písemkách z všelijakých těch předbudoucích průběhových časů plácali jak velryby na pláži.

Mně při výuce vyhovuje spíše ten postup, kdy se co nejrychleji vybuduje alespoň hrubá stavba od základů po střechu, která se pak postupně doplňuje o další prvky. Třeba při přednáškách z matematiky na VŠ mě dost demotivovalo, že jsem se musel učit něco, čehož smysl mi v tu chvíli ještě unikal, takže nebylo jasné, k čemu to vlastně bude dobré a co z toho, co se učím, je to podstatné. Teprve když to člověk viděl v souvislostech a v aplikacích, tak mu to začalo dávat smysl a začalo být jasné, proč jsou ty věci definované zrovna tak, jak jsou, a ne jinak, a proč se u nich zkoumají zrovna ty vlastnosti, jaké se zkoumají. Kdyby bývali místo striktního postupu zdola nahoru přednášeli tím iteračním, postupně zpřesňujícím stylem, bylo by mi studium mnohem příjemnější a přínosnější.
Takto jsme se např. na algebře nejdříve učili o lineárních funkcionálech, pak o hermitovských formách, pak o kvadratických formách, pak o skalárním součinu ("forma, která splňuje 1)..., 2)..., 3)... 4)... se nazývá skalární součin..."), pak tam byla jakási definice typu "skalární součin (x, e_i), kde e_i je z báze, se nazývá i-tý Fourierův koeficient..." a teprve o dva roky později na funkcionální analýze člověku docvaklo, proč se to tenkrát v prváku zavedlo takto a že ten Fourierův koeficient z lineární algebry opravdu nějak souvisí s Fourierovými řadami z matematické analýzy.

Tím konkrétním jsem myslel právě praktickou znalost a schopnost řešit konkrétní úlohy.

Začínat s OOP bez znalosti základních konstrukcí v konkrétním jazyce mi přijde jako kdybyste v matematické analýze přeskočil reálná čísla a začal rovnou metrickými prostory. Když mají "znalci OOP" natvrdo vyřešit nějakou úlohu. Například na hackerrank. Většinou těžce pohoří.

Se studiem jazyků bez studia gramatiky také úplně nesouhlasím. Pouhým používáním se sice naučíte komunikovat, ale nikdy se nezbavíte gramatických chyb. Gramatiku musí studovat i rodilí mluvčí.

[Reklama]

[robotron]

(..) převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, (..)

Zato divkam-trojkarkam jde vetsinou konverzace s cizinci na jednicku ;-)

Nicmene Cada je bohuzel priklad kdysi asi velmi chytryho cloveka, kterej se uplne zblaznil. Jeho doporucenim bych dnes prikladal vahu nulovou az nepatrne zapornou.

(Presto jsem samozrejme rad treba na jeho davny serial o NeXTSTEPu v SWN apod., to mi pomohlo sledovat zajimave smery, stejne jako napr. special o UNIXu na konci 1991 v temze casopise. Bez toho a bez Elzetova Bajtu bych se jako clovek mimo EARN i FIDO o Linuxu a o tom, ze neco UNIXoveho chci, asi dozvedel vyrazne pozdeji.)

[zboj]

(..) převážně dívčí část žactva na hodinách cizích jazyků psala písemky, v nichž se zkoušela znalost gramatiky, pravopisu a syntaxe, na jedničky, ale tváří v tvář cizinci byly naprosto nepoužitelné, zatímco my, trojkaři, jsme na žádný nepřekonatelný problém při konverzaci nenarazili, (..)

Nicmene Cada je bohuzel priklad kdysi asi velmi chytryho cloveka, kterej se uplne zblaznil. Jeho doporucenim bych dnes prikladal vahu nulovou az nepatrne zapornou.

Stává se, no.

[Kit]

Začínat s OOP bez znalosti základních konstrukcí v konkrétním jazyce mi přijde jako kdybyste v matematické analýze přeskočil reálná čísla a začal rovnou metrickými prostory. Když mají "znalci OOP" natvrdo vyřešit nějakou úlohu. Například na hackerrank. Většinou těžce pohoří.

Bohužel se mnozí lektoři snaží do těch "základních konstrukcí" nacpat všechny konstrukce daného jazyka. Tedy nejen ty, které jsou potřebné pro splnění objektového úkolu. K objektům se tak často ani nedostanou a třeba k namespaces už vůbec ne. Jiní naopak s namespaces začínají jako s nezbytností, což také nevidím jako správné.

[fernet]

Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.

[Reklama]

[zboj]

Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.

Nic, jsou to dobré knížky.

[Tomáš Roll]

Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.

Koupil jsem si kdysi jeho Návrhové vzory a odložil po dvou stránkách. Styl je infantilní, čekal jsem, kdy si tam udělají kafe.

[javaman ((]

Můžu se jen zeptat, co je na Pecinovského knihách o Javě špatného? Chtěl jsem si ty 2 díly pořídit, ale teď si nejsem jist, zda by to byla dobrá volba.

Obecně je moc svůj. To není nic špatného, ale představ si třeba Kita. Programovat sice neumí, ale vše řeší dost svérázně. Pecinovský je na tom stejně. Lepší tím vůbec neztrácet čas, protože budeš hodiny řešit, proč vymýšlí píčoviny a zároveň proč i příklady v knihách jsou nefunkční.

Jestli ale máš rád na vývoj NB, Vim a preferuješ 10" displej, tak je to stejně jedno a nic horšího se ti s tou knihou už nestane.

[Jerry]

Já myslim, že nejduležitější je pochopit jak se vlastně k OOP došlo a co je nad ním a nezastavit se u oop ale mít schopnost používat to je co před oop i to co je dál za oop - a je toho hodně. To znamená dohledat éru časopisu Bajt, kde jsou popsány techniky těsně před zavedením OOP do C++. Jak se to dělalo. Samozřejmě objektový model je znám už od prvních procesorů. Byly i návrhy objektových procesorů. Normálně se k OOP dostaneš asi po 1500-1700 hodinách výuky programování sám od sebe. To znamená cca po 12-18 měsících práce. A je jedno jestli začínáš v Basicu, Fortranu, C nebo čemkoliv jiným. Ono tě to prostě donutí OOP používat a pak jít dál k Template a Generikám v OOP ale to je všechno úroveň co se učila na vš někde v polovině 90 let.

[Ondra Satai Nekola]

Aha. Na Okounovi ve vláknu o ObjC.

Na rybe uz  jsem nebyl leta. Nekdy nostalgicky kouknu...

[Mirek Prýmek]

Nevim, jestli spamovat vlakno o necem uplne jinem, ale kdyz uz jste s tim zacali... A koneckoncu je to mistni kolorit, tak snad v poho 

Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. [...] Ovšem ne každý to potřebuje, takže se není o čem hádat.

To tvrzeni mi prijde vylozene zhoubne. Protoze uplne zbytecne od FP odrazuje lidi, kteri ho ani nezkusili, popr. ty, kdo ho zkusili a po prvnim zamotani se rychle skoncili, utvrdi v tom, ze udelali dobre. A pritom je dost zavadejici, kdyz uz nechci rict vylozene nepravdive.

V "pragmatickych" FP jazycich, kde jsou povolene side effects (vychazejici ze Standard ML nebo Lispu), je TK vicemene uplne nadbytecna. V pure jazycich typu Haskell se muze hodit na to, ze se na ty konstrukce v jazyce muzu podivat z obecnejsiho pohledu, z jineho uhlu, pochopit, proc je to udelane tak, jak je to udelane. Muze mi to dodat nejaky nadhled apod., ale k praktickemu, skutecnemu, programovani to neni potreba vubec. Uplne bohate staci se naucit to, co v tom jazyce je: ze Functor je typeclass s nejakymi funkcemi a ma splnovat nejake axiomy. Proc, to mi muze byt z praktickeho hlediska uplne putna. Pro nekoho je zabava to zjistit a rozsirit si obzory, ale potreba to neni.

Tak zbytecne nestras lidi!

P.S. pokud by nekdo jo chtel, urcite by pomoci TK slo popsat i OOP - a tvrzeni "k programovani v OOP musite znat TK" by se pak ukazalo ve sve nahote

[zboj]

pokud by nekdo jo chtel, urcite by pomoci TK slo popsat i OOP

To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. 

[Mirek Prýmek]

To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. 

No vidis - a OOPckarum to necpes

[zboj]

To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc. 

No vidis - a OOPckarum to necpes

Předpokládám, že to znají

[zboj]

P.S. Nikdo tu netvrdí, že všichni musí vědět, jak se TK používá ve FP. Zedník taky nepočítá diferenciální rovnice, když má postavit zeď, a je to OK, když zná své místo. Pokud ale někdo píše třeba knihovny pro Haskell, tak by asi měl tušit, vo co go