Abstrakce u OOP

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Abstrakce u OOP
« Odpověď #120 kdy: 13. 06. 2020, 16:09:45 »
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
Kód: [Vybrat]
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?


Re:Abstrakce u OOP
« Odpověď #121 kdy: 13. 06. 2020, 16:21:08 »
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

produkcni kod neni ucebnice programovani pro zacatecniky.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Abstrakce u OOP
« Odpověď #122 kdy: 13. 06. 2020, 16:26:20 »
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

produkcni kod neni ucebnice programovani pro zacatecniky.

Vypadá to, že jsi nepochopil pointu mého přirovnání :-)

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Abstrakce u OOP
« Odpověď #123 kdy: 13. 06. 2020, 16:35:00 »
Však to je správně, na vyšší úrovni se věci chápou lépe, už jen C je abstrakce nad asemblerem, tak nízko se nikdo nerýpe.
Bavíme se o situaci bez komentářů. Několik vrstev abstrakce bez komentářů, proč tam která vrstva je a jakou má zodpovědnost, je naprostá tragédie.
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
Kód: [Vybrat]
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

Klíčové slovo for, závorky, && a další symboly jsou jazykovými konstrukty, které znát musíš, pokud chceš pracovat s C. Jediným neznámým prvkem by mohla být funkce feof(), která není součástí jazyka, ale jeho knihovny stdio.

Re:Abstrakce u OOP
« Odpověď #124 kdy: 13. 06. 2020, 17:03:57 »
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
Kód: [Vybrat]
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
Nevím, kam míříš, ale samozřejmě, že nevěděl. Stejně jako třeba ty asi nebudeš rozumět větě "Flyg vilda fågel, flyg du som kan".

A?


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Abstrakce u OOP
« Odpověď #125 kdy: 13. 06. 2020, 17:15:40 »
To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:
Kód: [Vybrat]
for (i=1;i<61 && feof(h);i++) {...}Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?
Nevím, kam míříš, ale samozřejmě, že nevěděl. Stejně jako třeba ty asi nebudeš rozumět větě "Flyg vilda fågel, flyg du som kan".

A?
Že sice @Idris má pravdu v tom, že do nižších abstrakcí se nešťourá, na druhou stranu jen se samopopisností si nevystačím.

Když prostě nějakou hromadu asembleru nahradím za for() {} tak je to super, ale jen v případě, kdy někde vysvětlím, co ta konstrukce dělá. Jinak je to opravdu "Flyg vilda fågel, flyg du som kan".

Příklad s tím for je pěkný i v tom, že jasně ukazuje jak to zřejmě má fungovat. Jsou to tři písmenka, pro angličtináře nesou význam - což opět pomáhá. Ten význam sám o sobě nic nevysvětlí - na to je třeba nějaká definice, ale pomůže v tom se zorientovat. A hlavně jsou dostatečně krátká, aby nevznikal šum.

IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
« Poslední změna: 13. 06. 2020, 17:17:36 od BoneFlute »

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Abstrakce u OOP
« Odpověď #126 kdy: 13. 06. 2020, 17:57:53 »
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.

Lokální symboly mají být krátké, ideálně jednoslovní. U globálních symbolů s tím nevystačíme, proto používáme slepence podle různých notací (např. v C) nebo v moderních jazycích s pomocí namespace. Zásadou je nepoužívat zkráceniny, ale pro řídicí proměnné cyklu se názvy i, j, k tak zažily, že je zbytečné proti nim bojovat.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Abstrakce u OOP
« Odpověď #127 kdy: 13. 06. 2020, 18:15:29 »

Možná bych se ještě doplnil, že často může pomoct využití kontextu, kdy třeba v rámci nějaké lokálního cyklu nebudu řešit, že ty elementy jsou třeba user, ale budu řešit jejich smysl pojmenování v rámci toho kontextu: first, tail, případně dokonce x v případě, kdy proměnná nemá žádný význam. Pak se někdy opravdu povede bez toho komentáře obejít.

Re:Abstrakce u OOP
« Odpověď #128 kdy: 13. 06. 2020, 18:17:03 »
Když prostě nějakou hromadu asembleru nahradím za for() {} tak je to super, ale jen v případě, kdy někde vysvětlím, co ta konstrukce dělá. Jinak je to opravdu "Flyg vilda fågel, flyg du som kan".
Jo. A taky musí mít ta abstrakce nějakou zřejmou, snadno uchopitelnou logiku. Když zavedeš operátor, kterej bude občas sčítat, občas násobit a sem tam program shodí, ale jenom ve tři hodiny odpoledne, tak to bude taky na prd :)

(P.S. tak mě napadá, v JS určitě takový operátor je, ne? Divil bych se, kdyby nebyl, to by byla první příležitost něco zvorat, kterou by JS nevyužilo ;) )

Příklad s tím for je pěkný i v tom, že jasně ukazuje jak to zřejmě má fungovat. Jsou to tři písmenka, pro angličtináře nesou význam - což opět pomáhá. Ten význam sám o sobě nic nevysvětlí - na to je třeba nějaká definice, ale pomůže v tom se zorientovat. A hlavně jsou dostatečně krátká, aby nevznikal šum.
Tak ideálně by krátký měly být věci, který používáš nejčastěji. Ne zhovadilý "function", ale radši "func" a úplně ideálně "fn" :)

A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.
Vidím to úplně stejně.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Abstrakce u OOP
« Odpověď #129 kdy: 13. 06. 2020, 19:30:27 »
Tak ideálně by krátký měly být věci, který používáš nejčastěji. Ne zhovadilý "function", ale radši "func" a úplně ideálně "fn" :)

Jazyk C šel se zkracováním ještě dál a nedává tam nic.

Re:Abstrakce u OOP
« Odpověď #130 kdy: 13. 06. 2020, 20:31:25 »
IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.

Lokální symboly mají být krátké, ideálně jednoslovní. U globálních symbolů s tím nevystačíme, proto používáme slepence podle různých notací (např. v C) nebo v moderních jazycích s pomocí namespace. Zásadou je nepoužívat zkráceniny, ale pro řídicí proměnné cyklu se názvy i, j, k tak zažily, že je zbytečné proti nim bojovat.
Proč by mělo být zásadou nepoužívat zkráceniny? Takové "cnt", "tmp", "inc", "dec" myslím pochopí každý. Co třeba "rem" nebo "dir"?  Pokud se někde u cyklu vyskytne "n", tak taky každý pochopí. "x" a "y" jsou zažité matematické konvence. Pokud píšu třeba porovnání nebo nějakou podobnou symetrickou operaci, tak "a" a "b" bohatě stačí.

Zažitých zkratek jsou tisíce, nejen to i j k. Rozepsat nějakou zažitou zkratku čtenáři kódu žádnou dodatečnou informaci nedodá.

Re:Abstrakce u OOP
« Odpověď #131 kdy: 13. 06. 2020, 21:00:54 »
Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

produkcni kod neni ucebnice programovani pro zacatecniky.

Vypadá to, že jsi nepochopil pointu mého přirovnání :-)

jo, necetl jsem celou diskuzi.

Re:Abstrakce u OOP
« Odpověď #132 kdy: 13. 06. 2020, 21:29:29 »
Jazyk C šel se zkracováním ještě dál a nedává tam nic.

musíš tam uviesť typ návratovej hodnoty (čo je tiež riadna otrava) moderné jazyky, ktoré používajú Hindley-Milner typový systém si vedia v 99% typ odvodiť automaticky (a tam kde si nevedia sa použije typová anotácia)

mne sa páči jeden príkaz na všetko tak ako to majú ML jazyky napr let:

Kód: [Vybrat]
let x = 5 // (ne)premenná "x" inicializovaná hodnotou 5
Kód: [Vybrat]
let add a b = a + b // funkcia add s dvomi parametrami x a y

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Abstrakce u OOP
« Odpověď #133 kdy: 13. 06. 2020, 23:05:05 »
musíš tam uviesť typ návratovej hodnoty (čo je tiež riadna otrava) moderné jazyky, ktoré používajú Hindley-Milner typový systém si vedia v 99% typ odvodiť automaticky (a tam kde si nevedia sa použije typová anotácia)

Nemůžeš porovnávat C s moderními jazyky. Tenkrát byla potřebná efektivní nadstavba nad assemblerem tak, aby se nemusel pro každý procesor psát program znovu, což bylo splněno. Tehdejší výkon procesorů by na dnešní jazyky asi nestačil.

Škoda jen, že na Fortran se tak nějak pozapomnělo. Už tenkrát měl mnohé, čím se holedbají moderní jazyky.

Re:Abstrakce u OOP
« Odpověď #134 kdy: 14. 06. 2020, 08:17:50 »
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Inheritance, if you look at it with a very jaded eye, inheritance is the declaration of methods and variables in a subscope and it has nothing to do with ISA whatever. :)
Je to o úhlu pohledu. Tohle má moje větší sympatie.