Čisté OP Smalltalk, Objective-C

[laik]

1. V čom je OP v jazyku smalltalk čistejšie ako v C# a Jave? A prečo keď je lepšie tak sa nepresadilo?

2. Neni to jedno či zavolám metódu, alebo pošlem správu? Akú mi dáva message passing výhodu oproti volaniu metód?

3. Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

[Reklama]

[mmm]

1. V čom je OP v jazyku smalltalk čistejšie ako v C# a Jave? A prečo keď je lepšie tak sa nepresadilo?

Prosadilo se to. Prosadil se javascript, který vychází ze selfu, který vycházel ze smalltalku. Je to lepší, protože to přidává možnosti navíc.

[JSH]

1. V čom je OP v jazyku smalltalk čistejšie ako v C# a Jave? A prečo keď je lepšie tak sa nepresadilo?

Čisté OOP znamená, že je úplně všechno objekt. Na rozdíl od C# a Javy jsou ve smalltalku třídy i takové věci jako inty a podobně.
A že je něco čisté OOP neznamená automaticky, že je to lepší. A taky jde o to, pro co to má být lepší. Neexistuje jazyk, který by byl všeobecně lepší než nějaký jiný. Jazyky jsou vždycky lepší jen v nějakém konkrétním kontextu.

2. Neni to jedno či zavolám metódu, alebo pošlem správu? Akú mi dáva message passing výhodu oproti volaniu metód?

Částečně je to otázka názvosloví, ale jen částečně. Posílání zpráv je kompletně dynamické. Takže libovolnému objektu je možné poslat libovolnou zprávu. A ten objekt ji může třeba předat dál i když jí vůbec nerozumí.
Je to zase dvojsečné, protože tahle flexibilita znamená že překladač při překladu nemá šanci chytnout ani překlepy.

3. Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

Minimálně pro rozšíření obzorů je to supr. Není moc jazyků, jejichž kompletní syntaxe se vleze na lístek A6. A já jsem si až na Smalltalku uvědomil jakási filosofická omezení OOP jako takového, protože tam je to dotažené až do extrému.

[Kit]

• Smalltalk je mnohem jednodušší a přímočařejší. Vše je objekt, například i číslo. Je mu vyčítána ta jednoduchost - místo typů se používají testy, s čímž mívají typoví onanisté dost velké problémy.
• Posílání zpráv je obecnější variantou volání metody.
• Ano, má význam učit se Smalltalk, zejména z důvodu pochopení principů OOP. I v případě, že v něm nebudeš dál programovat, usnadní ti to práci s ostatními objektovými jazyky.

[JSH]

Je mu vyčítána ta jednoduchost - místo typů se používají testy, s čímž mívají typoví onanisté dost velké problémy.

No tak ty problémy, které jsou cenou za tu flexibilitu, nejsou vůbec malé a to člověk ani nemusí být typový onanista.

- Spoustu triviálních chybek, jako jsou třeba překlepy, odhalí typy tak snadno, že si toho člověk vlastně ani nevšimne.
- A typy samotné jsou i vcelku obstojná dokumentace. Rozumné typy dost redukují potřebné množství okolního textu. A na rozdíl od názvů nebo komentářů vždycky odpovídají aktuálnímu chování kódu.

Záleží na situaci. Někdy ta flexibilita nic nepřinese a zůstává jen ta bolest.

[Reklama]

[Kit]

Je mu vyčítána ta jednoduchost - místo typů se používají testy, s čímž mívají typoví onanisté dost velké problémy.

No tak ty problémy, které jsou cenou za tu flexibilitu, nejsou vůbec malé a to člověk ani nemusí být typový onanista.

- Spoustu triviálních chybek, jako jsou třeba překlepy, odhalí typy tak snadno, že si toho člověk vlastně ani nevšimne.
- A typy samotné jsou i vcelku obstojná dokumentace. Rozumné typy dost redukují potřebné množství okolního textu. A na rozdíl od názvů nebo komentářů vždycky odpovídají aktuálnímu chování kódu.

Záleží na situaci. Někdy ta flexibilita nic nepřinese a zůstává jen ta bolest.

• Spoustu triviálních chybek, jako jsou třeba překlepy, odhalí testy docela snadno. Je třeba je psát, ale jeden test může pokrýt více možných překlepů. Zaplevelení zdrojáků množstvím typů zhoršuje čitelnost aplikace a snižuje znovupoužitelnost.
• Testy samotné slouží slouží jako vcelku obstojná dokumentace.

[Miloslav Ponkrác]

1. V čom je OP v jazyku smalltalk čistejšie ako v C# a Jave? A prečo keď je lepšie tak sa nepresadilo?

Smalltalk je čisté, jednoduché objektové programování. Vše je objekt - proměnná, blok kódu, podrpogram, zpráva objektu, cokoli. Neexistuje nic co by nebylo objektem. Díky tomu je to jazyk čistý a velice jednoduchý.

Java ani C# de facto objektové nejsou. Mnoho věcí nejsou v Javě ani C# objekty. Například proměnné typů char, int, a další, které nejsou objekty. Blok kódu není objektem. Metoda třídy není objektem. Podmínkový příkaz není objektem. Cyklus není objektem. Atd. atd. atd. Ve Smalltalku je objektem naprosto všechno - a proto je to logičtější.

De facto při porovnání těchto jazyků je Smalltalk mnohonásobně objektovější než Java/C#. Díky tomu je Smalltalk jednodušší, konzistentnější a mocnější v řadě operací.

Neprosadilo se to proto, že do prosazení Smalltalku nikdo nenalil miliardy dolarů jako v případě Javy Sun nebo C# Microsoft. Představa, že se prosadí lepší, nikoli to čeho se lijí astrnomické sumy - je naivní.

2. Neni to jedno či zavolám metódu, alebo pošlem správu? Akú mi dáva message passing výhodu oproti volaniu metód?

Obojí jsou různé věci, mají různé chování.

a) Poslání zprávy je poslání zprávy - tak jak to v OOP má být. Objektu pošlete zprávu nějakého názvu a parametry. Je na objektu, co s tím udělá.

Objekt u posílání zprávy má jediný vstup/podprogram - kam zaslat zprávu. Je to velice flexibilní a jdou s tím velké kusy. Snadno se tak dělá zasílání zpráv třeba přes počítačovou síť, nebo program může běžet distribuovaně na několika počítačích.

b) Volání metody je pouhé low level volání podprogramu pomocí pointeru. Je to úroveň strojového kódu procesoru. Voláte podprogram (a jen pouhou náhodou ten podprogram má první parameter pointer na data objektu).

Objekt je v tomto případě obrovská kupa vstupů/podprogramů (metod). Každá metoda nezávisle mění objekt a jeho stav. Hůře se nad tím získává kontrola.

Volání metod je úlitba a krok směrem k assembleru a strojovému kódu.

Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

Zkus to a uvidíš. :-)

Smalltalk je jeden z mála jazyků, který naučím i svou mámu, která o programování nemá moc ponětí. Je to tak jednoduchý a konzistentní jazyk, jak se to málokde jinde povedlo.

Ve Smalltalku se programuje velice rychle, až expresně. Určitě násobně rychleji než v Javě či C#.

Smalltalk je ovšem odlišný. Data a stav dat si ukládá mezi spuštěními. Smalltalk je v podstatě objektová databáze (úložiště), a nad tím luxusní grafické prostředí. Smalltalk mění objekty v této databázi pomocí programovacího jazyka. Jinak řečeno, nezapomíná změny a data. Je to jiný přístup.

Dnes už je Smalltalk dost v pozadí. Pokud očekáváš uplatnění ve firmách, tak to vzdej. Mimochodem:

1) programovací jazyk Ruby není nic jiného než zpackaná a trochu nedomyšlená kopie Smalltalku

2) Programovací jazyk Objective C je kříženec C a Smalltalku

[JSH]

• Spoustu triviálních chybek, jako jsou třeba překlepy, odhalí testy docela snadno. Je třeba je psát, ale jeden test může pokrýt více možných překlepů. Zaplevelení zdrojáků množstvím typů zhoršuje čitelnost aplikace a snižuje znovupoužitelnost.
• Testy samotné slouží slouží jako vcelku obstojná dokumentace.

Nechci aby se to tu zvrhlo v další flame, takže jen stručně. V tomhle jsem pragmatik. IMO něco snáze odchytí testy, něco zase typy.
I v kompletně dynamických jazycích mají věci (více či méně obecné) typy i ve zdrojáku, nejen za běhu. Vždycky je nějak omezená množina toho, co má smysl předat. Jde jen o to, kdy a jak se tyhle omezení kontrolují. A jakým způsobem jsou tyhle "neformální typy" popsané.
Pokud mám například volit mezi tím, jestli dám parametru typ Path, nebo popíšu v dokumentaci, že funkce očekává cestu k souboru, tak volím jednoznačně první možnost. Škála věcí, které můžu takovéhle funkci předhodit, je hodně omezená.
A znovupoužitelnost je IMHO takový yetti, o kterém každý mluví, ale různí lidé si ho představují různě. Aplikačně specifický kód není znovupoužitelný už z principu. A pomocné věci jsou s rozumným typovým systémem (minimálně nějaká generika) znovupoužitelné dost.

[Miloslav Ponkrác]

No tak ty problémy, které jsou cenou za tu flexibilitu, nejsou vůbec malé a to člověk ani nemusí být typový onanista.

Obecně ovšem jen málokterý programovací jazyk má rozumný typový systém. To platí pro objektové jazyky i jazyky jiných paradigmat.

Ale především: Zavést typový systém na objektovém programování znamená zmrvit a pokřivit OOP. Vždyť se s tím programovací jazyky perou. Právě proto každý OOP jazyk zkouší trochu jinou koncepci.

Dodnes je to s typy na OOP takové vachrlaté. Každý OOP jazyk na to jde jinak. Někde typy spražují s dědičností. Jinde se stejným rozhraním ("duck typing"). Další zase jinak.

[Miloslav Ponkrác]

Pokud mám například volit mezi tím, jestli dám parametru typ Path, nebo popíšu v dokumentaci, že funkce očekává cestu k souboru, tak volím jednoznačně první možnost. Škála věcí, které můžu takovéhle funkci předhodit, je hodně omezená.

A nebo budete ve funkci konstrolovat, jestli jste v parametru dostal cestu k souboru. A hle: Najednou i v dynamickém jazyce máte škálu věcí, které můžete funkci předhodit hodně omezenou.

A znovupoužitelnost je IMHO takový yetti, o kterém každý mluví, ale různí lidé si ho představují různě. Aplikačně specifický kód není znovupoužitelný už z principu. A pomocné věci jsou s rozumným typovým systémem (minimálně nějaká generika) znovupoužitelné dost.

Zkuste ten Smalltalk. Tam uvidíte znovupoužitelnost v úplně jiných dimenzích.

Většina OOP jazyků zprasila objekty dědičností. Chudák dědičnost má vyřešit to, co autoři programovacích jazyků (včetně Javy) nedomysleli. Dědičnost má řešit: 1) znovupoužitelnost, 2) typovou informaci, 3) informaci o interface objektu. Je jasné, že jedna věc nemůže uspokojivě řešit tři odlišné věci - a proto to drhne kam se podíváte.

Smalltalk jako dědičnost má pouze znovupoužitelnost. Na rozdíl od Javy/C#, které se do dědičnosti plete miliarda věcí naráz.

[JSH]

Neprosadilo se to proto, že do prosazení Smalltalku nikdo nenalil miliardy dolarů jako v případě Javy Sun nebo C# Microsoft. Představa, že se prosadí lepší, nikoli to čeho se lijí astrnomické sumy - je naivní.

Ono se to neprosadilo taky proto, že to konzistentní posílání zpráv objektům je ve spoustě případů nekonzistentní se zbytkem světa (nejen programátorského). A díky tomu je IMHO Smalltalk ze začátku dost neintuitivní.

Stačí součet dvou čísel. Prvnímu sčítanci pošlu zprávu. To totálně neodpovídá tomu, jak se učíme o číslech přemýšlet v matice. Už jen to, že v součtu řady čísel není žádné ničím výjímečné. Že o to žádáme jedno z nich je jen omezení jazyka. OOP celkově moc nevyhovuje v situacích, kdy pracujeme s více rovnocennýma entitama, protože se zpráva zasílá vždycky jenom jedné.

A pak třeba takový for cyklus. Ten se řeší taky posláním zprávy číslu (počátečnímu indexu). Tohle byl můj OMGWTF moment. Podobný jsem zažil snad jenom u BDI (belief-desire-intention) popisu vypínače. Tady už fakt sedí to rčení o kladivu a hřebíku. Ano, zatloukat šroubek kladivem je obohacující zkušenost bořící předsudky a paradigmata, ale pravidelně to dělat nechci.

[Kit]

Poslání zprávy je poslání zprávy - tak jak to v OOP má být. Objektu pošlete zprávu nějakého názvu a parametry. Je na objektu, co s tím udělá.

Objekt u posílání zprávy má jediný vstup/podprogram - kam zaslat zprávu. Je to velice flexibilní a jdou s tím velké kusy. Snadno se tak dělá zasílání zpráv třeba přes počítačovou síť, nebo program může běžet distribuovaně na několika počítačích.

PHP tohle umí také, ale když to někde použiji, tak mě budou mít za čuně.

[Miloslav Ponkrác]

Ono se to neprosadilo taky proto, že to konzistentní posílání zpráv objektům je ve spoustě případů nekonzistentní se zbytkem světa (nejen programátorského).

Ono se to neprosadilo pouze proto, že v době kdy byl Smalltalk byly pomalé počítače. Vývoj proto šel směrem k jazykům, které vyždímají z počítače maximální výkon. Nic více a nic méně.

Smalltalk je jazyk pomalejší než C/C++, a to byl tehdy zásek. O ni cjiného nejde.

A díky tomu je IMHO Smalltalk ze začátku dost neintuitivní.

Smalltalk je rozhodně intuitivnější než většina dnešních jazyků. Znovu říkám, že Smalltalk naučím bez problémů neprogramátora. U Javy a C# tak úspěšný nebudu.

Stačí součet dvou čísel. Prvnímu sčítanci pošlu zprávu. To totálně neodpovídá tomu, jak se učíme o číslech přemýšlet v matice.

Což ovšem není vlastnost Smalltalku, ale vlastnost naprosto všech existujících objektových programovacích jazyků na světě, co existovaly, existují a existovat budou. Tedy i té Javy, C# a další.

O tom je celé objektové programování, že pracujete s objekty. OOP je přirozené pro unární operátory. OOP nemá možnost řešit binární a n-nární operátory jinak, než tak jak jste popsal.

Jak myslíte, že bude fungovat metoda add() v Javě či C#? Jak myslíte, že bude fungovat operator+() v C++?

No a co? Myslíte, že běžný člověk bude mít problém s konstrukcí [:x | a + b]?

Už jen to, že v součtu řady čísel není žádné ničím výjímečné. Že o to žádáme jedno z nich je jen omezení jazyka. OOP celkově moc nevyhovuje v situacích, kdy pracujeme s více rovnocennýma entitama, protože se zpráva zasílá vždycky jenom jedné.

Právě jste popsal obecné chování všech objektově orientovaných jazyků. Právě jste popsal základní vlastnosti objektového paradigmatu.

A pak třeba takový for cyklus. Ten se řeší taky posláním zprávy číslu (počátečnímu indexu).

Pokud je to jediné, co můžete Smalltalku vytknout, tak je na tom Smalltalk velice dobře. Navíc je to dost obvyklé řešení funkcionálního světa.

[Miloslav Ponkrác]

PHP tohle umí také, ale když to někde použiji, tak mě budou mít za čuně.

Vy to ale použijete v každém případě, ať chcete nebo nechcete. Vy nemůžete v PHP nepoužít v objektech předávání zpráv. Jestli myslíte, že PHP či Python to vnitřně dělá jinak než Smalltalk, tak se mýlíte.

Vy si pane strašně pletete pojmy a dojmy. Smalltalk používá vnitřně posílání zpráv. Stejně jako PHP. Stejně jako Python. To je vnitřní implementace, ne to co píšete ve zdrojovém kódu.

[borekz]

3. Má zmysel učiť sa smalltalk? čo mi to prinesie oproti bežným objektovým jazykom. Je vývoj v Smalltalku rýchlejší alebo kde je jeho hlavná výhoda.

Výhoda je, že se snáze naučíš Objective/C. To pak můžeš použít pro vývoj pro staré verze MacOS a iOS, které ještě nemají Swift. A možná je Objective/C rychlejší než Swift, protože je nízkoúrovňovější.