Příspěvky

4186

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 03. 06. 2015, 09:47:44 »

To není pravda. Actor model počítá s asynchronním doručováním zpráv (tj. odesílatel nečeká, až bude zpráva doručena a pokračuje ve vykonávání svého kódu), ve Smalltalku (tedy v jazyce, který implementuje OOP tak, jak bylo "původně zamýšleno") je posílání zpráv synchronní (čeká se na odpověď objektu, i kdyby měla být prázdná). To je dost klíčový rozdíl oproti aktorovému modelu.

SmallTalk je prostě nějaká implementace myšlenky. Jestli ideální a implementující všechny původní koncepty, to neumím posoudit. Kay sám říká, že "we changed Smalltalk constantly, treating it always as a work in progress" http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

http://worrydream.com/EarlyHistoryOfSmalltalk/

The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.
Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as "messages" for what essentially are procedure calls rather than one-way notifications).

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

Ale ať nežeru: ok, beru zpět slovo "přesně". V tomhletom se to liší. Šlo mi ale o to, že objekt i aktor jsou oddělené samostatné entity, které komunikují pomocí zpráv.

4187

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 03. 06. 2015, 06:46:41 »

Jak nad tím teď přemýšlím, tak C++ má alternativu k tomu respondsToSelector pomocí dynamic_cast. Akorát má trochu jinou granularitu

Spíš "akorát je to něco úplně jiného" Úplně správný OOP by mělo umožňovat posílat libovolný zprávy objektu, o kterým vůbec nic nevím. Tj. ne dělat type checking za běhu pomocí nějakých signatur, ale prostě poslat zprávu neznámému objektu na druhé straně planety.

Tady jsme zase u toho "OOP odpovídá intuitivnímu vnímání reálného světa" - pokud do něčeho chci praštit kladivem, tak do toho praštím kladivem ať je to cokoli. Nepožaduju od toho, aby to dědilo z IPrastitelneKladivem

A pokud ne, tak co? Bez kuchání si ji můžu akorát tak dát vycpat. Co kdybych tu zprávu poslal přímo původnímu objektu a vybodl se na celý wrapper?

Wrapper může se zprávou udělat něco rozumného. V podstatě stejně jako něco rozumného můžeš udělat s výjimkou. Např. můžeš mít hierarchii vložených objektů - pokud zprávu neumí zpracovat první, hodíš ji druhému, pokud ji neumí ani on, tak třetímu atd. Přičemž nic o těch vložených objektech nemusíš předem vědět, je to úplně obecný algoritmus vytvářející (opravdový) polymorfismus.

Dobře, upřesním dotaz. Nezajímá mě Co?, zajímá mě Proč? Jaké je využití pro univerzální proxy, co jen přeposílá? Vždycky když jsem psal nějaký mezikus, tak jsem napasovával různá rozhraní.
Stejně tak ty wrappery. Když občas píšu nějaký wrapper, tak holt těch pár trampolín napíšu ručně. Je to na pár minut i pro hodně velké třídy.
Jestli se o nich nepíše spíš proto, že nejsou až tak užitečné.

Ne, nepíše se o nich proto, že obecnou proxy prostě se statickými jazyky udělat nejde, takže to nikoho nezajímá. Využití je např. takové, že držíš referenci na lokální objekt, ale ten ve skutečnosti předává zprávy libovolně kam (např. balancuje do cloudu apod.). Např. ten Elixir má opravdové posílání zpráv a opravdový dynamický dispatch, takže udělat RPC bránu je záležitost vyloženě pár řádek ( https://github.com/mprymek/bertgate/blob/master/lib/rpc.ex ).

Ten příklad se serializací nebyl úplně šťastný, lepší příklad je volání funkce, jejíž název mám uložený ve stringu. V Pythonu to jde. V C++ to buď nejde vůbec, nebo možná nějakou extra speciální berličkou, o které ví jenom Stroustrup a další dva vyvolení na planetě

4188

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 03. 06. 2015, 06:26:50 »

Actor model se realizoval. Takhle založené OOP zřejmě ne.

Actor model je přesně to, jak bylo OOP původně myšleno.

Tím si buďte jist a mimo jiné proto se v green threads nesmějí používat dlouhotrvající funkce z OS, protože to zablokuje vše.

"Synchronní" není totéž co serializovaný. Synchronní volání je takové, u kterého čekám na dokončení operace. Jelikož u C++-like OOP nepředávám zprávy, ale v rámci svého threadu vlezu do objektu, je každé volání implicitně synchronní, pokud nedělám explicitní skopičiny, abych tomu zamezil (v rámci funkce odpálím nový thread, který operaci provede asynchronně).

A přesně tohle je taky ten důvod, proč se současné OOP blbě paralelizuje - protože takovýhle "objekt" je jenom iluze, šidítko pro programátora - ve skutečnosti nemám objekt jako entitu (jako actor) ale jako úplně normální sadu funkcí bez skutečného zapouzdření, do které mi může vlézt libovolné vlákno, kdykoli se mu zachce. Celé to slavné OOP není nic jiného než obyčejná struktura obsahující callbacky a data. Proto taky lidi říkají, že "objektově se dá programovat i v C a C++ na to vůbec nepotřebujete" - páč struktury jsou i v C a nic víc pro tohle není potřeba.

Dlouhotrvající volání samozřejmě OS thread zablokují, ale to je vlastnost OS, s jazykem to nijak nesouvisí, ten zato nemůže. Proto se taky v Erlangu obvykle tyhle věcí řeší pomocí "portu" - samostatného procesu, se kterým se komunikuje rourou (asynchronně).

4189

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 23:15:46 »

Myšlenka je fajn, ale prakticky nikde se to takto nerealizovalo.

Ale ano, realizovalo. Říká se tomu actor model a začíná to být populární

Podle všeho to jede v jednom vlákně.

V jednom OS vlákně je spouste green threads. Podobně jako v BEAM (Erlang VM), akorát ten umí využít i víc jader, což GNU SmallTalk asi teda neumí, když to tam píšou.

Tedy všechno je synchronní, žádné KayObjekty. Process ve Smalltalku je zjevně stejné šméčko jako procesy ve Win3.1

To, že to běží v jednom OS vlákně přece neznamená, že to je synchronní. Akorát nad tím jedním vláknem je prostě ještě jeden scheduler, který těm green threads přiděluje čas.

Immutable znamená nic než neustálé kopírování a nedá se to nijak obkecat.

Tohle jsme tady už myslím probírali a nemám potřebu to opakovat

4190

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 20:45:18 »

Četl jsem již dříve a pojmem Objekt se tam označuje něco jako samostatně fungující počítač

Ano, přesně tak to bylo myšleno: objekt = samostatná entita. Pořád se mluví o tom, že OOP dobře odpovídá tomu, jak svět vnímáme - jenže to je (jakžtakž) pravda jenom pro to "skutečné OOP" - viz:

Kolemjdoucí řekne Mirkovi: "zvedni ruku!" Mirek to uslyší, rozhoduje se, jestli Kolemjdoucího poslechne, Kolemjdoucí mezitím čte knížku, Mirek posléze ruku zvedne.

vs.

Kolemjdoucí si vleze do Mirka, podívá se, jak se zvedá ruka, zvedne ji, vyleze z Mirka.

, zatímco ve Smalltalku je Objekt soubor dat s metodami a metoda byť volaná na základě zprávy se volá v kontextu volajícího.

Tak detailně SmallTalk neznám, ale pochybuju, že máš pravdu. SmallTalk má plnohodnotný runtime, který může zprávy doručovat jakým způsobem uzná za vhodné. Jestli je to někdy (většinou) prosté volání metody, to je implementační detail, ne vlastnost jazyka. Kdybych chtěl, můžu klidně udělat distribuovanou implementaci (pokud neexituje, nevím), kde to platit nebude.

vlákna tehdy ještě nebyla

Nevím odkdy, ale dneska to rozhodně platí:

GNU Smalltalk uses preemptive green (non-native) threads; that is, multiple Smalltalk processes are run by the virtual machine in one operating system thread.

http://smalltalk.gnu.org/faq/35

Podle mžho skromnýho odhadu se má věc tak, že od začátku byla myšlenka takováhle a pokud se ji podařilo plně implementovat až díky moderním mašinám (protože starší by to nezvládly), tak to na věci nic nemění.

Protože hardware neumí dostatečně rychle kopírovat paměť a obě záležitosti jak messaging, tak přepínání procesů/vláken je mimořádně náročné na kopírování paměti.

Jak Erlang/Elixir, tak Gnu SmallTalk používají non-OS vlákna, takže přepínáním procesů se fakt nemusíš trápit. Si to někdy zkus: pusť si Erlang a v něm padesát tisíc procesů. Zvládneš to i na Raspberry Kopírování je samozřejmě drahé, ovšem od toho právě máme immutable data structures, aby se zas tak moc kopírovat nemuselo

4191

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 19:38:36 »

(offtopic)
zdá se, že je zde mnoho expertů na programovací jazyky, nevíte o nějakém fóru kde se dá rozumně debatovat o vývoji v Haskellu?

Tady!

...jo vlastně "rozumně"... Tak to nevím )

4192

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 19:22:42 »

Opravdový dynamický dispatch je, když můžu objekt získat jakkoli (např. deserializovat z disku) a poslat mu libovolnou zprávu.

Resp. tohle je spíš už důsledek té opravdové dynamičnosti. Jinak dynamický dispatch je to, co jsem psal výš: dostanu zprávu a podle své logiky na ni nějak reaguju.

4193

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 19:20:50 »

A virtuální metody nejsou dynamický dispatch?

Je, ale typicky zmršený.

Dynamický dispatch znamená výběr implementace nějaké operace v runtime. Pokud si index do vtable nazvu selektor, tak se to zas tolik neliší. Akorát překladač nedovolí poslat zprávu, které objekt přímo nerozumí.

No právě. Pokud překladač neumožnuje poslat objektu zprávu, o které s jistotou neví, že jí bude objekt rozumět, tak na tom není nic dynamickýho. Opravdový dynamický dispatch je, když můžu objekt získat jakkoli (např. deserializovat z disku) a poslat mu libovolnou zprávu.

V C++ nemá respondsToSelector IMO moc smysl. Preferuje se to, že se kód nepřeloží před tím že někdy až bude měsíc v úplňku dostane objekt jakousi zprávu, kterou bude muset v runtime kuchat. Nerad píšu unit testy na věci, které může chytit už překladač.

To je samozřejmě legitimní designové rozhodnutí. Akorát to už pak není OOP tak, jak bylo původně myšleno.

Místo forwardInvocation je sice třeba napsat nějaké ty předávací metody ručně, ale zase odpadá kuchání neznámého NSInvocation v runtime. Pokud je těch metod moc, tak to stejně zavání spíš antipatternem "God Object".

Nemusíš je nutně kuchat. Tvůj objekt může být třeba wrapper kolem jiného objektu. Dostaneš zprávu, pomocí respondsToSelector zjistíš, jestli ji obalovaný objekt umí zpracovat a pokud ne, tak něco uděláš, třeba si dáš nohy křížem

Mohl bych poprosit o nějaký příklad použití? Představa, že slepím pár objektů dohromady a zprávy jim budu bez nějakých úprav předávat dál, mi jako návrh kapku smrdí. Bez ohledu na to, jestli je to dispatchem nebo děděním.

Příklad už zazněl: univerzální proxy. Univerzální wrapper, rozšiřující funkcionalitu nějakého objektu o nové zprávy. Objekt, který přepíná dvě implementace - jednu pro případ, že máš připojení na net, jinou pokud nemáš. Atd. atd. atd. Příklady použití lidi neznají a nikde se o nich nepíše právě proto, že v tom zparchantělým C++ a jeho derivátech se to tak napsat nedá

4194

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 18:36:33 »

Koncept OOP nemá nic společného s konceptem zasílání zpráv,

To se velmi mýlíš. OOP bylo od začátku založeno na posílání zpráv mezi objekty, to je jeho klíčový koncept. Že to dnešní programátoři nechápou, to je právě práce C++. Jestli si to nemyslíš, můžeš zkusit Alana Kaye vyškolit o tom, co to je OOP

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Anebo i Joe Armstronga http://www.infoq.com/interviews/johnson-armstrong-oop - pasáž "Is Erlang object oriented?"

To proč se donekonečna zmiňuje mylné zasílání zpráv objektům má pravděpodobně základ v tehdejší implementaci virtuálních metod, vtable v roce 1970 ještě asi nebylo známo, takže pro podporu late binding se volání metod pravděpodobně realizovalo přes zmíněné dynamic dispatch a to je blízké konceptu zasílání zpráv.

Ne, má to základ v tom, že žádné vtable nebylo potřeba, protože se opravdu zasílaly zprávy, nikoli volaly funkce. Vtable je mrzká snaha emulovat zasílání zpráv pomocí volání funkcí. Je to rychlé (což byla motivace), ale vede to tam, kam to vedlo.

Absence předávání zpráv mezi objekty není příčina problémů s paralelismem, tou jsou sdílená modifikovatelná data.

A proč jsou sdílená modifikovatelná data? Protože se volají funkce, místo aby se zasílaly zprávy. Protože údajně "zapouzdřené" objekty jsou ve skutečnosti jenom funkce běžící synchronně v tom samém vlákně a zaručeně v tom samém paměťovém prostoru. Chceš-li jinak, musíš kolem toho dělat opičárny jako různé reflexe a pseudoreflexe. Když opravdu posíláš zprývy, je ti jedno, jestli objekt žije na tomtéž počítači nebo na druhém konci planety. Neřešíš žádnou shared memory. Prostě pošleš zprávu objektu. Kdo, jak a kam ji doručí je ti jedno.

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.

Tak jistě. Když něco v jazyce nejde, vždycky to můžu nějak nasimulovat, alespoň dikud je jazyk Turingovsky kompletní, že... Jak že to říká ta okřídlená věta? Že můžeš Lisp buď přímo použít nebo ho reimplementovat v jiném jazyce? Tady je to stejný - buď použiješ jazyk s dobrou podporou předávání zpráv, nebo ji budeš špatně reimplementovat. A tohle je hodně špatná implementace.

4195

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 17:27:45 »

Jo jo, čisté OOP uvažování se perfektně hodí pro hromadu komunikujících černých skříněk. Čím dál od tohohle, tím víc to drhne.
Většinu času programátor nezasílá zprávy černým skříňkám, ale pracuje s abstraktními datovými typy. Představa posílaných zpráv je fajn. Volání metody ale imo daleko líp sedí na různé "poloprůhledné" skříňky.

...a proto je nejlepší jazyk Erlang, resp. Elixir, protože vnitřek skříněk je přiměřeně funkcionální (non-pure) a mezi sebou skříňky komunikují čistě asynchronními zprávami

Osobně si myslím, že posílání zpráv skončilo na smetišti dějin celkem oprávněně.

Neskončilo. Jenom ho C++ umrtvilo a teď všichni marně tápou, jak vlastně dělat paralelismus... No, když se střelím do nohy, tak se pak po dvou chodí blbě

Volání metod z rozumně specifikovaných rozhraní je podstatně uchopitelnější a zprávy navrch IMO nepřináší vůbec nic.

Ale přináší! Asynchronnost s možností explicitní synchronizace jenom tam, kde je potřeba. Nebo třeba stupidně snadnou implementaci obecné proxy - bez toho, aby se člověk zbláznil z nějakých reflexí nebo kdovíjakého dědění kdovíjakých rozhraní...

Dnešního programátora by to možná zaskočilo, protože on to zná spíš jako virtuální metody. Po drobném vyjasnění terminologie nebudou mít problém ani ti nešpičkoví.

Když říkám dynamic dispatch, tak myslím dynamic dispatch a ne nějakou jeho C++ parodii jako virtuální metody. Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám, ne že mi překladač vytvoří v paměti tabulku callbacků... Nemám ekvivalent respondsToSelector a forwardInvocation -> nemám dynamic dispatch i kdybych se na hlavu stavěl...
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtForwarding.html

Ono to je právě všechno ze vším - nemám pořádný dynamic dispatch -> nedá se příjemně používat skládání a proxy -> kašlu na skládání a všude používám dědění -> deeper and deeper into the shit...

4196

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 13:41:05 »

A Smalltalk je dokonalý příklad tohohle šílenství :

Sorry, omlouvám se, tohle jsem přehlídl, mluvil jsem o Objective-C... Pro SmallTalk to platí, no - čistota nade vše

4197

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 13:33:44 »

Zahraju si na ďáblova advokáta.

Cyklus for je zpráva, která se posílá počátečnímu indexu.

To seš ovšem hodně blbej ďáblův advokát, protože:

1. pokud chceš rychlou enumeraci, tak použiješ normální c-čkový for

2. když je kolekce objekt a chceš pracovat s celou kolekcí, tak logicky posíláš zprávy kolekci, protože s objekty se komunikuje zprávami

3. i když je kolekce objekt, pořád můžeš komunikovat s jednotlivými objekty, pokud chceš: [myArray objectAtIndex:i]

4. objective-c 2 podporuje iteraci: for (NSString* s in myArray) {...}

Sčítání je zpráva, co se posílá jednomu sčítanci.

Opět: pokud ti to vadí, použiješ čistý C. Proto je Objective C tak fajn, že se dá použít cokoli, co C umí.

A i jakákoliv jiná operace, která pracuje s více věcmi je zpráva, která se posílá jedné z nich.

No, tak už to v objektových jazycích chodí

4198

Server / Re:Výpočet potřebného výkonu stroje pro DB

« kdy: 02. 06. 2015, 11:05:17 »

Tohle je přesně jeden z mála use casů, kde v podstatě s jistotou dává smysl použít "cloud". Pokud nemáš žádný server, nemáš představu, co to bude žrát, a nemáš žádný rozpočet, tak dává smysl pořídit si virtuál u takového poskytovatele, který umožňuje plynulé navyšování výkonu (tj. nenabízí 3 varianty virtuálů, ale můžeš si "libovolně" zvolit jednotlivé prostředky). Pro začátek zvolíš něco menšího a když/až to přestane stíhat, změříš si úzký hrdlo a navýšíš.

Ideální by samozřejmě bylo autoškálování, ale to není žádná sranda a vzhledem k tomu, jak jsi položil dotaz a o jakou oblast jde, bych se do tohodle asi nepouštěl, nebude ti to dobře fungovat a zabiješ strašně moc času řešením platformy místo abys řešil aplikaci.

Třetí možná cesta je použít PaaS (OpenShift, Heroku apod.), kde bys teoreticky měl mít škálování "zadarmo". Jestli to tak je opravdu i v praxi, nebo je to spíš marketingová teorie, to bohužel nemůžu sloužit. Ale kdyby to aspoň trochu fungovalo, bylo by to pro tebe určitě ideální řešení, minimálně v téhle fázi.

4199

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 02. 06. 2015, 09:25:20 »

Autoři Smalltalku sice pojem OOP zavedli, ale zavedením pojmu končí veškeré jejich zásluhy. V současné praxi používané OOP je dost jiné než jejich představy.

Což je přesně ten důvod, proč současný OOP stojí za starou bačkoru - a to je hlavně "zásluha" C++:

• rozjel se fetišismus dědění, kdy se každá blbina nesmyslně roubuje na dědičnost
• naplno se rozproudilo šílenství vícenásobné dědičnosti
• málem se zapomnělo, co je to protokol (naštěstí Java ho vrátila do hry)
• skoro úplně se zapomnělo na skládání
• úplně se zapomnělo na to, že ve skutečném OOP se mají posílat zprávy, ne volat funkce
• čímžpádem dnešní programátor vůbec netuší, co je to dynamic dispatch. Dnešní špičkový programátor se pozná tak, že to ví, ale neuměl by to použít.

...a protože prakticky všichni dnešní programátoři umí OOP v téhle C++kem zmršené formě, nezbývá než v té zmršenosti buď aspoň částečně pokračovat (aby vůbec byl někdo schopný jazyk použít -> Java), zavést něco, co je natolik dynamické, že to původní myšlenku OOP trochu připomíná (ale má to tímpádem svoje jiné problémy -> Python, Ruby) nebo celé slavné OOP hodit přes palubu (Go), což je vůbec nejlepší, co jde v současnosti udělat.

Ad Objective C: jeden projekt, který se snaží do Objective C zhurta obout v původním duchu, je http://etoileos.com/ Bohužel mají málo sil a přiliš velké ambice, takže vývoj je nekonečný a přestávám věřit, že vůbec někdy bude dotažený do něčeho použitelného

4200

Hardware / Re:Home Server - komponenty

« kdy: 29. 05. 2015, 09:18:00 »

Hlavně myslím, že jestli se řeší domácí server, nebude to s těmi výpočty tak zásadní. Co chceš proboha počítat doma tak drsnýho, aby ti na to nestačila běžná mašina? Maximálně tak nějaký úpravy videa, ale ty ti na amatérské úrovni zvládne už i chytřejší kalkulačka, jenom to bude chvilku trvat. Pokud má někdo doma větrnej tunel, nebo vyvíjí vlastní meteorologický modely, pak se mu asi vyplatí cloud, ale to zase nebude řešit na rootu, že si chce hrát s domácím serverem, ne?

Jasně, je to offtopic, ale snad to tak moc neva, nechci rozjíždět žádnou velkou diskusi, jenom by mě zajímalo, jestli to má and něčím podložený, to téma mě zajímá. Právě proto, že dneska jsou už i obyčejný mašiny tak výkonný a levný, že mi ta návratnost cloudu nějak moc nevychází...