Čisté OP Smalltalk, Objective-C

[Kit]

c) PHP dodnes nemá ani datový typ textový řetězec! Namísto toho se musíte tlouct se sekvencí bajtů, dávat tomu nějaký význam a charset. Myslel jsem si, že ve 21. století si takovou nesmyslnost nedovolí žádný programovací jazyk na světě.

Stringy jsou v PHP poněkud nedotažené, ale na funkce mb_*() se dá zvyknout, zejména pokud je zabalíš do objektů. Spíš mi vadí, že samotný string se jako objekt nechová. Třeba zápis $string->length() by nemusel vypadat zrovna nejhůř.

[Reklama]

[prezident]

A možná je Objective/C rychlejší než Swift, protože je nízkoúrovňovější.

to jsou mi věci. na základě čeho si takový dvojitý nesmysl myslíš?

[Kiwi]

Smalltalk bych učil povinně na školách (klidně základních). Podobně jako Pascal sloužil k osvojení strukturovaného přístupu, ač v praxi už není tak použitelný (pokud se chce někdo dnes věnovat C, i tak bych radil nejdřív pascalskou průpravu, snižuje to pak úroveň prasení v C), na žádném jiném jazyku člověk tak dobře nepronikne do objektového programování jako ve Smalltalku. To se zúročí i třeba v C++ nebo v Javě - akorát u toho pak člověk skřípe zubama a uvědomuje si, že ani C++ ani Java fakt objektové nejsou.

Objective C - má smysl prakticky jen pokud máš zájem o vývoj na jablečných platformách. Nebo k prostudování Cocoy, abys viděl, jak má vypadat dobře navržený objektový framework Ale do budoucna se tam spíš bude tlačit asi Swift. Nicméně Smalltalk je pro oba tyto jazyka ta nejlepší prerekvizita.

K tomu, co dále zaznělo:

LISP - slovy Alana Kaye (autora Smalltalku): pokud elektroinženýr by si na tričko nechal natisknout Maxwellovy rovnice, tak inženýr Computer Science by tam měl mít specifikaci LISPu.

Jinak objektový návrh není tak jednoduchý, jak se na první pohled zdá. Často svádí k hledání falešných analogií mezi reálným světem a tím modelovým, což je velmi zrádné. Objekty OOP nemají být přímou analogií reálného světa, ale mají sloužit jako prostředek k jeho modelování na počítači. Z toho pak plynou různá nedorozumění a zdánlivě neřešitelné problémy typu čtverec - obdélník, reálné číslo - komplexní číslo apod. Chybný objektový návrh představuje dalekosáhlejší problém než u strukturovaného.

Předchozí poznatek vede k frustraci z objektového přístupu a hledání nějaké spásy ve funkcionálním přístupu. Důvod - málokdo se v tom orientuje, dělají v tom hlavně akademičtěji orientovaní lidé, jejich programy v těchto jazycích vypadají elegantně, což vede k iluzi, že funkcionální programování je lepší a vyřeší problémy objektového přístupu. Není to tak. Ty programy jsou takové, jako jsou, protože je prostě píšou inteligentnější lidé. Masové rozšíření funkcionálního přístupu by vedlo k daleko větší pohromě než špatně pochopené objekty.  - můj dojem

[SB]

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?

Má opravdovou pozdní vazbu, jejímž důsledkem je jiná koncepce běhu procesu, a to přesunutí rozhodování (tj. zodpovědnosti) od volajícího na volaného. Díky tomu netrpí podtypovým polymorfismem, tj. využití polymorfismu pouze u vzájemně odvozených tříd/rozhraní.
Kvalita jazyku nemá na jeho prosazení výrazný vliv, důležitější jsou další věci okolo.

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?

Vizte výše - přesunutím rozhodování z volajícího na volaného. Důsledkem je jednoduchost řešení některých problémů, např. polymorfismus bez závislostí, jednoduché proxy, jednoduché adaptéry, obecnější metody, ...

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.

Pro pochopení OOP jednoznačně. Má to ale jednu obrovskou nevýhodu: Začnete chápat a vnímat, jak je mnoho používaných jazyků omrdaných, protože je vytvořili prachobyčejní lempli a čuráci, kteří si mysleli, že jsou mistry světa, a tak vynalezli další hranaté kolo. Bude vás to neustále srát, a co horší, je to nevratný proces, takže si dobře rozmyslete, zda do toho půjdete.

[SB]

Č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ě.

To je supr, ale PŘEDEVŠÍM i třídy jsou objekty (metatřídní implementace), to znamená jednotný koncept jako pro instance, jehož důsledkem je, že můžete mimo jiné používat polymorfismus i mezi třídami! Nic takového v Jávce a C# není, tam je třída extra konceptem, se kterým se 1. zachází jinak, 2. strašně komplikuje implementaci jazyku, 3. kurevsky komplikuje sebereflexi a další použití.

A že je něco čisté OOP neznamená automaticky, že je to lepší...

To JE lepší, protože je to jednodušší, neboť primiva k použití objekty (opačně to pochopitelně nejde) vyžadují nějaký způsob konverze, nebo (stejně jako v jiných neobjektových jazycích) mimo objekty stojící samostatné funkce (čisté OOL je nemají), což je další koncept, který opět komplikuje návrh, implementaci i použití jazyku.

Částečně je to otázka názvosloví, ale jen částečně...

To není otázkou názvosloví, to je zcela jiný koncept řízení běhu procesu!

...Je to zase dvojsečné, protože tahle flexibilita znamená že překladač při překladu nemá šanci chytnout ani překlepy.

To je logickým důsledkem. Mimoto ale částečně funguje "type" inference.

...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.

Extrémem jsou jazyky jako Java a C#, protože jsou to slepeniny všelijakých časem pochycených (a často zbytných) konceptů, jejichž důsledkem je slabý poměr schopností ku složitosti. Naopak Smalltalk vynechává vše zbytné  a zůstává u jednoduchosti a přímočarosti.

[Reklama]

[SB]

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.

Jo, a ještě jedna věc: Implementrace Pharo má výborný debugger, ve kterém je možno rovnou doplňovat metody (což jde skvěle dohromady s TDD, kdy při testu vyletí chyba na neexistující metodu), nebo "jen" opravovat chybu, vyčíslovat výrazy, opakovaně znovuspouštět metodu, dokud to nejede. Někdo možná řekne: "To je zbytečné." Ale když podvacáté v nějakém jazyku opravujete chybu, pořád to není ono, a vy musíte 20krát znovu aplikaci (nebo alespoň její kus) přeložit a dolézt znovu na místo chyby, tak vás to začne PĚKNĚ SRÁT. Nevím o jiném jazyku/implementaci (to neznamená, že neexistuje), který by tohle uměl.

[SB]

- 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.

To řeší Smalltalk pojmenováními (názvy), na to nepotřebuje navíc "typy". Mimoto názvy mají být v pořádku vždy, typované jazyky nejsou žádnou výjimkou (jak si mnozí myslejí).

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

To je ale chybou autora, ne jazyku.

[SB]

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.

Pozor, toto je věcí implementace, to bych sem netahal. Pokud vím, komunita kolem Phara pracuje na sestavování image ze samostatných souborů ukládaných v Gitu a bez vývojového prostředí, neboli tak, jak to dělají jiné jazyky. To samo by mohlo zvýšit přístupnost a pochopitelnost pro nováčky.

[Kiwi]

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.

Pozor, toto je věcí implementace, to bych sem netahal. Pokud vím, komunita kolem Phara pracuje na sestavování image ze samostatných souborů ukládaných v Gitu a bez vývojového prostředí, neboli tak, jak to dělají jiné jazyky. To samo by mohlo zvýšit přístupnost a pochopitelnost pro nováčky.

Pochopitelnost pro nováčky přišedší z jiných jazyků. Pro naprosté nováčky (pro něž byl ostatně vymyšlen) je pochopitelnější stávající smalltalkovský koncept, který odpovídá dnešnímu stavu výpočetní techniky lépe, než ten současný standardní koncept ostatních jazyků převzatý ze 60. let, kdy byly počítače ovládany přes dálnopisy a děrné štítky.

[SB]

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í.

OOP je jiným paradigmatem, proto nemůže být stejné jako imperativní, strukturované programování. Anebo jakoby bude, ale potom skončíte s Javou. Je to jako říci: "Chceme něco nového, ale musí to fungovat stejně jako to staré."

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.

To je přesně ten minimalismus - než zavádět navíc primitiva a k nim (zcela zbytečné) operátory (mnoho z nás ví, jak je to v Javě či C# složitý, ortogonální koncept a co je kolem toho za ukrutné sraní) jenom proto, aby se to četlo jak ve škole (upozorňuju, že je to okrajová záležitost, přičemž Smalltalk není jazykem pro sčítání čísel), stačí si uvědomit, že stejný výsledek dostanu přičtením jednoho čísla k druhému. For a If to samé. Prostě to nestojí za to.

[SB]

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

Jo? Kolik let jste se učil programovat, než jste mohl pracovat v Javě?

[SB]

Navíc je to dost obvyklé řešení funkcionálního světa.

To mně dost překvapuje. Z funkcionálního světa znám dobře jen Haskell, ale obecně mě nenapadá důvod, proč cpát cyklus dovnitř intu, když to může být samostatná nezávislá funkce. Ve kterém jazyce to tak je?

Opět minimalismus - zavést samostatnou funkci znamená zavést celý nový, ortogonální koncept a tím výrazně zkomplikovat jazyk, přestože to lze řešit prostředníkem a požadavkem na něj.

[listoper]

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.

Jo, a ještě jedna věc: Implementrace Pharo má výborný debugger, ve kterém je možno rovnou doplňovat metody (což jde skvěle dohromady s TDD, kdy při testu vyletí chyba na neexistující metodu), nebo "jen" opravovat chybu, vyčíslovat výrazy, opakovaně znovuspouštět metodu, dokud to nejede. Někdo možná řekne: "To je zbytečné." Ale když podvacáté v nějakém jazyku opravujete chybu, pořád to není ono, a vy musíte 20krát znovu aplikaci (nebo alespoň její kus) přeložit a dolézt znovu na místo chyby, tak vás to začne PĚKNĚ SRÁT. Nevím o jiném jazyku/implementaci (to neznamená, že neexistuje), který by tohle uměl.

Smalltalk ani Pharo neznam takze si nejsem uplne jisty jestli je to totez, ale podle me tohle umi kazdy jazyk kde je REPL.
Takze nejspis vetsina dialektu lispu, s jistymi ustupky asi python, javascript, haskell a kdyz budu mit hodne fantazie tak i shell. Ostatne od Java 9 mame i jshell takze i tam by se o tom dalo mluvit.
Prakticky to pouzivam jen v clojure a emacs lispu takze u ostatnich si nejsem jisty jaky tooling je k dispozici a jak pohodlne se s tim pracuje, ale kdyz musim nekdy pracovat bez REPLu tak se mi chce brecet.

[SB]

Pozor, toto je věcí implementace, to bych sem netahal. Pokud vím, komunita kolem Phara pracuje na sestavování image ze samostatných souborů ukládaných v Gitu a bez vývojového prostředí, neboli tak, jak to dělají jiné jazyky. To samo by mohlo zvýšit přístupnost a pochopitelnost pro nováčky.

Pochopitelnost pro nováčky přišedší z jiných jazyků. Pro naprosté nováčky (pro něž byl ostatně vymyšlen) je pochopitelnější stávající smalltalkovský koncept, který odpovídá dnešnímu stavu výpočetní techniky lépe, než ten současný standardní koncept ostatních jazyků převzatý ze 60. let, kdy byly počítače ovládany přes dálnopisy a děrné štítky.

To ano, ale spíš by to mohlo zjednodušit nasazování aplikací, neboli nedořešený problém nedostatečného vyčlenění vývojového prostředí z image a jeho odstraňování před nasazením.

[SB]

Jo, a ještě jedna věc: Implementrace Pharo má výborný debugger, ve kterém je možno rovnou doplňovat metody (což jde skvěle dohromady s TDD, kdy při testu vyletí chyba na neexistující metodu), nebo "jen" opravovat chybu, vyčíslovat výrazy, opakovaně znovuspouštět metodu, dokud to nejede. Někdo možná řekne: "To je zbytečné." Ale když podvacáté v nějakém jazyku opravujete chybu, pořád to není ono, a vy musíte 20krát znovu aplikaci (nebo alespoň její kus) přeložit a dolézt znovu na místo chyby, tak vás to začne PĚKNĚ SRÁT. Nevím o jiném jazyku/implementaci (to neznamená, že neexistuje), který by tohle uměl.

Smalltalk ani Pharo neznam takze si nejsem uplne jisty jestli je to totez, ale podle me tohle umi kazdy jazyk kde je REPL.
Takze nejspis vetsina dialektu lispu, s jistymi ustupky asi python, javascript, haskell a kdyz budu mit hodne fantazie tak i shell. Ostatne od Java 9 mame i jshell takze i tam by se o tom dalo mluvit.
Prakticky to pouzivam jen v clojure a emacs lispu takze u ostatnich si nejsem jisty jaky tooling je k dispozici a jak pohodlne se s tim pracuje, ale kdyz musim nekdy pracovat bez REPLu tak se mi chce brecet.

Obávám se, že REPL na to stačit nebude - REPL je pouze přeložení nějakého výrazu a spuštění v kontextu zastaveného debuggeru, to má dnes kdejaká implementace. Pharo umí v debuggeru přeložit a nahradit stávající metodu (nebo třeba taky vytvořit novou třídu!) a případně ji znovu spustit. Ukončení aplikace není třeba vůbec používat!
U Pythonu jsem tohoto chování (v PyCharms) nedosáhnul, v Javascriptu (v Eclipse?) mi šlo za blíže neurčených podmínek překládat jednotlivé soubory, ale nějak se změny neprojevovaly, nebo se to všelijak skládalo. O Jávce či C# nemůže být ani řeč, tam jsem k ladění běžně používal spuštění laděného kódu dočasnou úpravou po spuštění aplikace. Jiné jazyky nepoužívám.