Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: nm 25. 05. 2015, 07:02:24

Název: Použití Objective-C mimo Apple
Přispěvatel: nm 25. 05. 2015, 07:02:24
jednou mi kamarad rekl „nechtel by ses naucit Objective-C ?”

Vim, ze to je neco jako jazyk C/C++ a pouziva se na masinach od applu. A tak jsem si rekl, ze by to nemuselo byt marny a mohl bych se s kamaradem dobre doplnovat, protoze on umi zase C#.

A tak vznasim prvni otazku: "Mohu pouzivat Objective-C taky na jinych masinach nez Apple?"
Název: Re:ObjectiveC
Přispěvatel: Ondra Satai Nekola 25. 05. 2015, 07:25:14
Můžeš, ale není to moc praktické.


U Apple se teď zvolna jde od Objective C ke Swiftu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 25. 05. 2015, 08:46:55
takze kdyz to na jinych masinach nez apple neni prakticke, znamena to, ze Objective-C byl applum sity na miru?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 25. 05. 2015, 08:59:32
Ne. Jenom nemáš jinde většinu API, mizerný tooling a skoro nikdo to nepoužívá.
Býval na tom hůř i překladač a runtime, ale to se snad dalo do kopy, delší dobu to sledují jen z povzdálí
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tomáš Roll 25. 05. 2015, 09:12:29
Objective-C je sadomasochismus.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 25. 05. 2015, 09:30:02
Objective-C je sadomasochismus.

To by bylo na dlouhy flame...
Velka cast problemu je, ze je jiny, nez mainstream. A na rozdil od jinych divnych jazyku je hodne te divnosti vicemene zbytecna. Ale porad je to pricetnejsi jazyk nez trebas C++.

Osobne bych daleko spis hmatnul po Swiftu. Kdybych musel zase neco delat na Macu. Jinak se IMO da vybrat jinde lepe.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: JSH 25. 05. 2015, 10:22:00
Setkal jsi se někdy se Smalltalkem? Měl jsi pocit, že autoři museli hulit nějaké svinstvo? Pak se drž od Objective-C dál.
Pokud se ti Smalltalk líbil, akorát ti přišel z nějakého důvodu nepraktický, pak ti Objective-C doporučím.

I Swift ze Smalltalku dost bere. Spousta WTF věcí začne dávat smysl, když se člověk přepne do Smalltalkoidníhoho myšlení.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pan Jan 25. 05. 2015, 10:38:14
Setkal jsi se někdy se Smalltalkem? Měl jsi pocit, že autoři museli hulit nějaké svinstvo? Pak se drž od Objective-C dál.
Pokud se ti Smalltalk líbil, akorát ti přišel z nějakého důvodu nepraktický, pak ti Objective-C doporučím.

I Swift ze Smalltalku dost bere. Spousta WTF věcí začne dávat smysl, když se člověk přepne do Smalltalkoidníhoho myšlení.

Jen jako zajímavost doplňuji, že autory Smalltalku jsou titíž lidé, kteří jsou také autory slovního spojení "objektově orientované programování".
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Makovec 25. 05. 2015, 10:43:21
Objective-C je přehledné a dobře se v něm píše i čte, pokud ho člověk přijme a nesnaží se ho v duchu překládat do něčeho jiného (to máte jak když se učíte nějaký lidský jazyk).

Pokud vám jde o programování nových věcí pro OS X a iOS, tak cestou vpřed je Swift. Ale bacha, možná v něm nejsou (všude) hranatý závorky, ale jinak je to také svérázné stvoření, komplexnější než Objective-C, já u něj s milou nostalgií vzpomínám na Perl :-)

Jinak jak psal Ondra, jedna věc je jazyk, druhá frameworky a API. To druhé je jenom na Apple OS X a iOS, u Swiftu víc než u Objective-C.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 25. 05. 2015, 12:06:41
A tak vznasim prvni otazku: "Mohu pouzivat Objective-C taky na jinych masinach nez Apple?"

Jinde se vůbec nepoužívá.

Jen jako zajímavost doplňuji, že autory Smalltalku jsou titíž lidé, kteří jsou také autory slovního spojení "objektově orientované programování".

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.

Objective-C je přehledné a dobře se v něm píše i čte

Žádný jiný široce oblíbený jazyk koncept zápisu Objective-C nepřejal, to je dostatečně výmluvné.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pan Jan 25. 05. 2015, 12:23:07
Jen jako zajímavost doplňuji, že autory Smalltalku jsou titíž lidé, kteří jsou také autory slovního spojení "objektově orientované programování".

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.

Bohužel.

Objective-C je přehledné a dobře se v něm píše i čte

Žádný jiný široce oblíbený jazyk koncept zápisu Objective-C nepřejal, to je dostatečně výmluvné.

Je to stejně výmluvné, jako tvrzení, že MS-DOS byl kvalitní systém – na základě jeho značného rozšíření.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 25. 05. 2015, 12:40:40
Zrovna ten zapis je jenom kosmetika... dokud by clovek nechtel takove veci, jako je castecna aplikace / curryovani (nezabihejmez ted do tematu, zda se to lisi a jak).
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tomáš Roll 25. 05. 2015, 12:57:50
Jak říká McNeil v Poradci, je to obyčejná hlavoruční práce.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tomáš Roll 25. 05. 2015, 12:58:33
Sorry, to patřilo vedle.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: mb 25. 05. 2015, 13:52:18
A tak vznasim prvni otazku: "Mohu pouzivat Objective-C taky na jinych masinach nez Apple?"

Jinde se vůbec nepoužívá.
To by som netvrdil. Existuje project http://www.gnustep.org/. A v nom sa pise v Objective-C. Je dost multiplatform.
Pisal som v nom par veci, ale islo hlavne o prechod aplikacii z NEXT-STEPu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 25. 05. 2015, 14:13:06

Dobré myšlenky se různě recyklují a zlepšují v různých jazycích a některé dobré myšlenky vznikly i v Objective-C. Špatné, jako třeba systém zápisu v Objective-C, nikoliv.

www.gnustep.org

Mrtvá koníčková záležitost.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: podlesh 25. 05. 2015, 15:02:37
Objective C na NextSTEP / OpenSTEP se ještě před patnácti lety docela používal na mission critical GUI aplikace (např. řízení letového provozu). Jenomže jak to koupil Apple, tak se na tuhle oblast vykašlal (koneckonců, spousta práce se zárukami a kvalitou)  a všichni začali utíkat směrem k Microsoftu nebo Sunu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Makovec 25. 05. 2015, 15:20:34

Dobré myšlenky se různě recyklují a zlepšují v různých jazycích a některé dobré myšlenky vznikly i v Objective-C. Špatné, jako třeba systém zápisu v Objective-C, nikoliv.

Nikoli, recyklují se primárně věci na které jsou lidé zvyklí, ať už jsou dobré nebo špatné, neobvyklé věci jsou odmítány jaksi z principu. Já netvrdím že způsob zápisu v Obj-C je nejlepší, ale když si na něj člověk zvykne je velmi přirozený a dobře se jak píše, tak čte.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: robotron 25. 05. 2015, 15:20:50
Obj-C s GNUstepem jsem si jednou vybral pro Tvorbu GUI. Obj-C jazyk mi prisel jako velmi rozumne "C s pridanymi objekty", oproti C++ milionkrat jednodussi a pohodovejsi na pocit. GUI genialni.

Co me mrzelo, je prave mala komunita a kuprikladu (5 let zpatky) ne uplne samozrejma instalace prostredi pro widle. (Delal jsem cilovou vec v Linuxu, ale rikal jsem si, ze pro jine veci by bylo dobry mit snadnej export i do ty hruzy.) Zel vetsina lidi byla vcucnuta Qt, kam snad i s dvacetiletym zpozdenim ex post dodelali ty zajimave myslenky z NeXTSTEPu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 25. 05. 2015, 16:17:12
Nikoli, recyklují se primárně věci na které jsou lidé zvyklí, ať už jsou dobré nebo špatné, neobvyklé věci jsou odmítány jaksi z principu. Já netvrdím že způsob zápisu v Obj-C je nejlepší, ale když si na něj člověk zvykne je velmi přirozený a dobře se jak píše, tak čte.

Že jsou programátoři staré struktury tuším. Proč se ve Swiftu přirozený a dobrý zápis z Obj-C hodil do stoupy netuším. Zjevně je v některém tvrzení chyba.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 25. 05. 2015, 16:30:17
kdyz se tedy naucim swift, musim se naucit i objective-C (aspon z casti)?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Makovec 25. 05. 2015, 16:55:45
kdyz se tedy naucim swift, musim se naucit i objective-C (aspon z casti)?

Ne. Frameworky a API (na OS X a iOS) jsou sdílené, ale každý jazyk k nim přistupuje svojí syntaxí.

Nadruhou stranu schopnost číst Obj-C neuškodí pokud by se člověk dostal k legacy projektu nebo si četl vygooglované ukázky použití API a frameworků.

Je ovšem možné používat v jednom projektu oba jazyky, tj. nové věci přidávat ve Swiftu (pochopitelně ne v rámci jednoho souboru zdrojáku :-), ale např. oddědit nebo rozšířit třídu psanou v Obj-C pomocí Swiftu).
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Makovec 25. 05. 2015, 17:00:00
Nikoli, recyklují se primárně věci na které jsou lidé zvyklí, ať už jsou dobré nebo špatné, neobvyklé věci jsou odmítány jaksi z principu. Já netvrdím že způsob zápisu v Obj-C je nejlepší, ale když si na něj člověk zvykne je velmi přirozený a dobře se jak píše, tak čte.

Že jsou programátoři staré struktury tuším. Proč se ve Swiftu přirozený a dobrý zápis z Obj-C hodil do stoupy netuším. Zjevně je v některém tvrzení chyba.

Nehodil, akorát se přizpůsobil starým strukturám které měly z učení se Obj-C ujímání (některé principy Obj-C - a zřejmě SmallTalku který neznám - syntaxe jsou ve Swiftu dotažené do konce).
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: zboj 26. 05. 2015, 00:27:59
Všude, kde jede clang, jde přeložit ObjC. Ovšem knihovny je třeba vzít z nějakého opensource projektu, třeba gnustepu. Nenapadá mě ale moc důvodů, proč to jinde používat, C++(14) je lepší a taky je prakticky všude (pokud už člověk tedy nechce nějaký skriptovací jazyk nebo Javu).
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: robotron 26. 05. 2015, 00:44:56
C++(14) je lepší

Pokud jde C++14 prepnout tak, aby neumoznovalo vsechny ty humusy "klasickyho" C++, pak mozna. Jinak je to zlo a melo by zaniknout.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 26. 05. 2015, 07:48:18
Nehodil, akorát se přizpůsobil starým strukturám které měly z učení se Obj-C ujímání (některé principy Obj-C - a zřejmě SmallTalku který neznám - syntaxe jsou ve Swiftu dotažené do konce).

Žádné přizpůsobení, nesmysly z Obj-C jsou pryč a začali znovu a jinak, jestli převzali 15 % z Obj-C tak je to moc. Hrůzy ze Smalltalku tam již nejsou prakticky vůbec.

Pokud jde C++14 prepnout tak, aby neumoznovalo vsechny ty humusy "klasickyho" C++, pak mozna. Jinak je to zlo a melo by zaniknout.

Umožňuje všechno a pořád, programátor si programovací styl volí dle aplikace. C++ není pro malé děti, nepochopí to.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: r23_ 26. 05. 2015, 08:51:59
C++(14) je lepší

Pokud jde C++14 prepnout tak, aby neumoznovalo vsechny ty humusy "klasickyho" C++, pak mozna. Jinak je to zlo a melo by zaniknout.
V čem? Umožňuje to, co se do něj napíše a to efektivně. Navíc nic lepšího není. C# není špatný, ale je pomalejší a stále vendor-lock.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: hawran diskuse 26. 05. 2015, 08:57:09
 ;D

A poměřování penisků po bambilionosmé může začít ...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: zboj 26. 05. 2015, 20:46:53
C++(14) je lepší

Pokud jde C++14 prepnout tak, aby neumoznovalo vsechny ty humusy "klasickyho" C++, pak mozna. Jinak je to zlo a melo by zaniknout.

"Přepnout" to nejde, ale nemusí se to používat. Nevím, o jaké "hnusy" jde, ale nejpalčivější problém - pointry - C++14 úspěšně eliminovalo.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 30. 05. 2015, 06:38:45
A kdy vlastne vznikl Objective-C? To byl zaveden specialne pro Nextstep pro pocitace NeXT?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: motorola 30. 05. 2015, 07:17:56
To byl zaveden specialne pro Nextstep pro pocitace NeXT?

Speciálně si ho zavedla společnost Apple pro své produkty.
Dlužno dodat, že v době vzniku byla situace slabší, použitelné jazyky by se daly spočítat na prstech jedné ruky.
Proč se to používá dosud nevím.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 30. 05. 2015, 08:15:50
Speciálně si ho zavedla společnost Apple pro své produkty.

NeXT, ne Apple.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 30. 05. 2015, 08:38:00
To jednoho dne vyhodili (asi akcionari) Stevea Jobse z Applu. Tak Jobs zalozil firmu, ktera vyvinula NeXT a Nextstep. Pozdeji Apple vzal Jobse zpatky a on prisel i se vsemi technologiemi z NeXTu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 30. 05. 2015, 09:09:40
Jobse vyhodil board.
Apple nevzal Jobse s NeXTem ale koupil NeXT s Jobsem. Nebyl to zadny aquihire, rict si tehdy Be o mensi penize, tak se Jobs nejspis uz nikdy do Apple nevratil.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pavel Stěhule 30. 05. 2015, 09:27:06
To byl zaveden specialne pro Nextstep pro pocitace NeXT?

Speciálně si ho zavedla společnost Apple pro své produkty.
Dlužno dodat, že v době vzniku byla situace slabší, použitelné jazyky by se daly spočítat na prstech jedné ruky.
Proč se to používá dosud nevím.
Protože se v tom napsala celá platforma - to je kód, který se běžně nepřepisuje - navíc v době svého vzniku se Objective C a související frameworky chápaly jako luxusní zboží - Java byla na tehdejších mašinách pomaloooooučká, C++ příliš statické - a pokud jste chtěli elegantně psát GUI tak to byla magie maker, OOP - vůči tomu bylo Objective C výrazně čistší, kompaktnější. Původní MacOS byl už zastaralý - nové jádro se postavilo na Darvinovi a na kódu, který přišel z NeXT stepu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 31. 05. 2015, 07:07:34
A jak je to s platformou Solaris od Sun microsystems. V cem je to naprogramovany ten operacni system?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pavel Stěhule 31. 05. 2015, 07:26:43
A jak je to s platformou Solaris od Sun microsystems. V cem je to naprogramovany ten operacni system?
C http://en.wikipedia.org/wiki/OpenSolaris
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 01. 06. 2015, 06:39:56
Sun microsystems pry chystal nejaky operacni system napsany v jazyku JAVA (snad krome kernelu). Nevite o tom nekdo neco?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: motorola 01. 06. 2015, 07:20:55
Sun microsystems pry chystal nejaky operacni system napsany v jazyku JAVA (snad krome kernelu). Nevite o tom nekdo neco?

Sun s tím experimentoval a podle předpokladu selhal, rozumný OS v Javě realizovat nejde. Všechny známé úspěšné OS užívají trochu ASM, hodně C, někdy C++.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: perceptron 01. 06. 2015, 07:29:47
javaos to bol
fail to bol

co takto android?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: motorola 01. 06. 2015, 07:36:57
co takto android?

Android OS je normálně v ASM/C/C++. V Androidu Java není, je tam Dalvik.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: eMko 01. 06. 2015, 08:24:14
Sun měl svýho času podporu Javy v hardwaru. Tím pádem (subset) bajtkódu = asm ;-) .

A ano, byl to finanční fail.

BTW v nových verzích Androidu už Dalviku odzvonilo, místo toho je tam ART. Hlavní rozdíl (pro uživatele) je v tom, že se celá aplikace kompiluje do nativního kódu při instalaci. U Dalviku se použil JIT na hodně využívané části, zbytek bajtkódu byl interpretován.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: eMko 01. 06. 2015, 08:26:58
Jak to po sobě čtu, říkám si, že o Dalviku jsem asi neměl mluvit v minulém čase. :-) Hodně lidí (vč. mě) má v kapse Android 4.4, což je poslední verze, kde by (dle plánů) Dalvik měl být.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: motorola 01. 06. 2015, 09:00:24
Sun měl svýho času podporu Javy v hardwaru. Tím pádem (subset) bajtkódu = asm ;-) .

Subsetem bytecode to také skončilo, CPU schopný vykonávat 100 % java bytecode se nikomu komerčně nezdařil a mokrý sen javistů o Java OS se rozplynul.

Hlavní rozdíl (pro uživatele) je v tom, že se celá aplikace kompiluje do nativního kódu při instalaci.

Výhody jsou zřejmé, ale popírá to hlavní paradigma Javy Write once run anywhere, to už je spíše jako MSIL od Microsoftu :-)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: perceptron 01. 06. 2015, 09:10:53
Citace
Výhody jsou zřejmé, ale popírá to hlavní paradigma Javy Write once run anywhere, to už je spíše jako MSIL od Microsoftu :-)
ak mate libku ktora ide oproti dostupnemu java api tak mozete zobrat normalny java jar a pouzit ho v androide. zdrojaky tak isto. art je pre appky zmena ktoru si ako vyvojar nevsimnete to sa deje na pozadi.


Název: Re:Použití Objective-C mimo Apple
Přispěvatel: zboj 01. 06. 2015, 09:50:34
Sun microsystems pry chystal nejaky operacni system napsany v jazyku JAVA (snad krome kernelu). Nevite o tom nekdo neco?

Vzhledem k tématu vlákna není myslím od věci menší odbočka: Sun dlouho vyvíjel aktivně i pro Objective-C. Jednak spolu s NeXTem vydal OpenStep (výrazný pokrok oproti NextStepu), jednak prodával software napsaný v ObjC (zejména po akvizici Lighthousu). Až politické rozhodnutí - prosazování Javy - ObjC v Sunu zařízlo. Dost za to mohl i NeXT házením Sunu klacků pod nohy. Sice jim dovolili používat ObjC (jež měli sami licencované od Stepstonu), ale ignorovali jejich žádost o na tehdejší dobu velmi pokročilé vývojové nástroje, hlavně Interface Builder. Kdyby byl býval NeXT vstřícnější, byl by tu dnes možná místo Javy nějaký moderní následník Objective-C.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: nm 02. 06. 2015, 06:19:47
Jobse vyhodil board.
Apple nevzal Jobse s NeXTem ale koupil NeXT s Jobsem. Nebyl to zadny aquihire, rict si tehdy Be o mensi penize, tak se Jobs nejspis uz nikdy do Apple nevratil.

Co je to "board" a "aquihire"?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 02. 06. 2015, 09:14:45
Co je to "board" a "aquihire"?

https://en.wikipedia.org/wiki/Board_of_directors
https://en.wikipedia.org/wiki/Acqui-hiring
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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++:
...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 :(
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: JSH 02. 06. 2015, 12:41:33
Zahraju si na ďáblova advokáta.
Což je přesně ten důvod, proč současný OOP stojí za starou bačkoru - a to je hlavně "zásluha" C++:
Hlavní důvod, proč je současný OOP na pytel, je ten, že se považuje za stříbrnou kulku a cpe se i tam, kam se vůbec nehodí. A Smalltalk je dokonalý příklad tohohle šílenství :
Pokud máš jenom kladivo (jazyk, co umí jenom posílat zprávy objektu), pak všechno začne připomínat hřebík (prostě nějakému objektu pošlu zprávu). Pokud je objektů víc, pak jeden vyberu. Pokud jsou naprosto rovnocenné, pak jeden stejně musím vybrat. Jden objekt sice ví kulové o tom, co je ten druhý přesně zač, ale to nevadí. Programátor si to pohlídá, napíše si na to testy, nebo to prostě někdy za běhu zdechne (ať žije duck typing).

Inu hovada vzaly C++ a dopadlo to špatně. Kdyby vzaly Smalltalk, tak to dopadne trochu jinak, ale taky špatně.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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í :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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 ;)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: JSH 02. 06. 2015, 17:05:55
No, tak už to v objektových jazycích chodí :)
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.

Pokud chci pracovat se dvěma objekty současně (tím nemyslím kolekci, ale třeba kolizi dvou geometrických objektů), tak je představa posílání zpráv přímo na škodu. Naproti tomu volání dynamicky vybrané funkce pořád pasuje bez nějakých mentálních harakiri. Obzvlášť pokud jazyk neomezuje dynamický dispatch na jediný typ (např. Lisp).

Osobně si myslím, že posílání zpráv skončilo na smetišti dějin celkem oprávněně. Volání metod z rozumně specifikovaných rozhraní je podstatně uchopitelnější a zprávy navrch IMO nepřináší vůbec nic.

A když už jsme u toho :
Citace
čímžpádem dnešní programátor vůbec netuší, co je to dynamic dispatch...
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í.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 02. 06. 2015, 18:05:42

Za starou bačkoru to začalo stát až tehdy když se z OOP udělalo náboženství.

Koncept OOP nemá nic společného s konceptem zasílání zpráv, každý může existovat a existují i samostatně.

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.

Co je koncept dynamic dispatch nepřekvapivě znají i v C třeba jako IDispatch::Invoke. Hodila by se k tomu lepší podpora RTTI.

Neskončilo. Jenom ho C++ umrtvilo a teď všichni marně tápou, jak vlastně dělat paralelismus..

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

Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pan Jan 02. 06. 2015, 18:15:27
Za starou bačkoru to začalo stát až tehdy když se z OOP udělalo náboženství.
Souhlas.

Opravdový dynamic dispatch znamená, že dostanu zprávu a rozhodnu se, co s ní udělám

To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.
Analogický příklad bych vymyslel i ve FORTRANu 77. Přesto bych se neodvažoval tvrdit, že F77 je objektový jazyk.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 02. 06. 2015, 18:28:32
Přesto bych se neodvažoval tvrdit, že F77 je objektový jazyk.

Však to po vás nikdo nechce, jelikož se jedná o zasílání zpráv :-) Zasílat zprávy jde asi všude.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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 ;)

Citace
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.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: JSH 02. 06. 2015, 19:08:44
Když říkám dynamic dispatch, tak myslím dynamic dispatch a ne nějakou jeho C++ parodii jako virtuální metody.
A virtuální metody nejsou dynamický dispatch? 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í.
Citace
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...
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č.

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".
Citace
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...
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.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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á :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: v 02. 06. 2015, 19:37:20
(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?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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 :)))
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondra Satai Nekola 02. 06. 2015, 19:52:51
(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?

Beginners a Cafè na haskell.org mi přišly v pohodě.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 02. 06. 2015, 20:12:58
OOP bylo od začátku založeno na posílání zpráv mezi objekty, to je jeho klíčový koncept.

Četl jsem již dříve a pojmem Objekt se tam označuje něco jako samostatně fungující počítač, 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. Pro jistotu ještě jednou KayObject != SmalltalkObject. Ve smyslu KayObject dávají zprávy smysl jako asynchronní messaging mezi procesy, vlákna tehdy ještě nebyla a to tedy nemá se Smalltalkem nic společného.

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

vtable je praktická reakce na zmršený koncept SmalltalkObject.

A proč jsou sdílená modifikovatelná data?

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.

Tak jistě.

Podpora pro časté praktiky přímo v jazyku je vhodná, o tom není sporu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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í:

Citace
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 :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 02. 06. 2015, 23:00:55
Ano, přesně tak to bylo myšleno: objekt = samostatná entita.

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

Tak detailně SmallTalk neznám, ale pochybuju, že máš pravdu.

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

Citace
multiple Smalltalk processes are run by the virtual machine in one operating system thread.

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

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 :)

Erlang už se trochu blíží KayObjektům, díky immutable.
Immutable znamená nic než neustálé kopírování a nedá se to nijak obkecat.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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 :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 02. 06. 2015, 23:53:27
Ale ano, realizovalo.

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

To, že to běží v jednom OS vlákně přece neznamená, že to je synchronní.

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.

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

Bylo by to zbytečné 8)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: JSH 03. 06. 2015, 00:08:21
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.
Deserializace -> dynamic_cast -> volání?

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 a všechny objekty nemají nutně společného předka. Holt nenutí všechno dědit od jedné bázové třídy.
Citace
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 :)
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?
Citace
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á :)
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é.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: čumil 03. 06. 2015, 01:08:17
Pánové pánové. Zase argumentujete o sračkách. Prýmek má pravdu, neměnnost datových struktur právě nevyžaduje skoro žádné kopírování. Ale pod jednou podmínkou, musíme použít rekurzivní struktury. Takže žádné pole, immutable array je nepoužitelný, ale immutable rekurzivní struktura je efektivní. Proč? Při modifikované kopii rekurzivní struktury musíme nově vytvořit pouze páteř dané struktury, která bývá malá (na ni referencemi napojíme zbytek staré verze struktury), no a ani tu páteř nekopírujeme odznova, jen vytvoříme nové reference. Takový ty kecy jak jsou immutable struktury pomalí jdou z tlam amatérů který nevěděj o čem žvaněj. A GC které spravuje jen immutable objekty je mnohem rychlejší než GC které spravuje mutable objekty protože díky neměnnosti dat je možné GC silně optimalizovat. Dám nápovědu protože krom Prýmka by to nikdo nevěděl a začal by fundovaně kecat hovna. Pokud máme neměnná data, je garantováno že data generace X nemohou ukazovat na data mladších generací (X - N) ale pouze jen starších (X + N). A na této garanci je poté GC optimalizováno.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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ě).
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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ě :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: ava 03. 06. 2015, 08:57:33
Actor model je přesně to, jak bylo OOP původně myšleno.

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.

Jen pro zajímavost, padaly tu otázky na to, jak to má smalltalk s vlákny - vlákna jsou preemptivní, a včetně scheduleru zapouzdřená a přístupná programátorovi (tzn. lze si například implementovat za běhu debugovat a upravovat scheduler vláken - zkuste si to v kterémkoliv jiném prostředí), ale implementačně alespoň ve VisualWorks a myslím že i v Pharu jsou to green threads.

Pozn: Ve smalltalku jsem pár let komerčně dělal, takže trochu vím o čem mluvím.

Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tuxik 03. 06. 2015, 09:13:59
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ě :)

Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury? Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená. Mám takový pocit, že do takové situace, kdy se tohle hodí, se můžeš dostat jenom nějakou prasárnou a řešení tímhle způsobem je už jen další prasárna. Ale jak říkám, programování už se aktivně nevěnuju a možná to nějaký smysl má.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: ava 03. 06. 2015, 09:37:37
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ě :)

Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury? Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená. Mám takový pocit, že do takové situace, kdy se tohle hodí, se můžeš dostat jenom nějakou prasárnou a řešení tímhle způsobem je už jen další prasárna. Ale jak říkám, programování už se aktivně nevěnuju a možná to nějaký smysl má.

Přímo pro programování zákaznických aplikací to tolik užitečné asi není (i když je pěkné mít tu možnost :) ), ale např. ve smalltalku je vývojové prostředí plně reflexivní a také psané ve smalltalku, takže tohle se zcela běžně používá např. pro psaní debuggeru, inspektorů objektů atp.

Vzpomínám si, že jsme měli některé konfiguráky (ne pro koncové uživatele) udělané jen jako smalltalkovský kód uložený v souboru, který se prostě spustil a mohl konfigurovat jak chtěl :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 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

Citace
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/

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

Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tuxik 03. 06. 2015, 09:52:37
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ě :)

Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury? Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená. Mám takový pocit, že do takové situace, kdy se tohle hodí, se můžeš dostat jenom nějakou prasárnou a řešení tímhle způsobem je už jen další prasárna. Ale jak říkám, programování už se aktivně nevěnuju a možná to nějaký smysl má.

Přímo pro programování zákaznických aplikací to tolik užitečné asi není (i když je pěkné mít tu možnost :) ), ale např. ve smalltalku je vývojové prostředí plně reflexivní a také psané ve smalltalku, takže tohle se zcela běžně používá např. pro psaní debuggeru, inspektorů objektů atp.

Vzpomínám si, že jsme měli některé konfiguráky (ne pro koncové uživatele) udělané jen jako smalltalkovský kód uložený v souboru, který se prostě spustil a mohl konfigurovat jak chtěl :)

Tak to jo, tomu rozumím, na debugování to asi smysl má, protože debugování je svým způsbem jedna velká prasárna (myslím systémově, nemyslím, že je špatný něco debugovat :-D ) a ty konfiguráky, moc si to nedokáž představit, ale proč ne :-D
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 09:53:35
Programování se sice už nějakou dobu nevěnuju, ale můžeš mi uvést reálný smysluplný příklad využití téhle fičury?
Už jsem tady asi třikrát zopakoval RPC, mám znovu? :)

Možná při nějakým skriptování dejme tomu, ale pokud tohle chceš přeložit do strojáku, zkus si uvědomit, co to pro překladač znamená.
Pro překladač to znamená buďto to, že umí nějak "inspect" (nevím, jak se to říká česky) objekty - nakouknout do nich za běhu a držet si jejich typové signatury (což dělá Python).

Nebo to pro překladač neznamená vůbec nic a řeší to runtime. V Erlangu je to přesně takhle. Když chci zavolat funkci Mod:fun(1), tak se runtime prostě podívá, jestli má zavedený modul Mod a jestli v něm je funkce fun arity 1. Takže to "Mod" i "fun" může být úplně klidně uložené v proměnné (a tímpádem nakrásně klidně načtené z disku, čili naprosto neznámé v době překladu) a není s tím žádný problém. Samozřejmě je to pak o něco pomalejší než přímé volání pomocí nějakéhotoho CALL nebo JMP nebo jak se to dělá, asm u6 si fakt nepamatuju :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 09:57:29
a ty konfiguráky, moc si to nedokáž představit, ale proč ne :-D
Na tom je právě hezky poznat, jaké krásné možnosti dynamičnost přináší. Spousta softwarů navrhuje nějaký pseudo-programovací-jazyk jenom proto, aby mohly být konfiguráky dostatečně expresivní. Některé zajdou tak daleko, že je ten pseudojazyk dokonce turingovsky úplný. A kdo se má učit nějaký nový složitý formát? Proč, když máme dost programovacích jazyků?

Prostě do konfiguráku dáš úplně normální kód, který se úplně normálně provede a úplně normálně do runtimu zavede nějaké nové třídy/funkce, které pak zavoláš a máš konfigurační parametr. Žádný parser. Žádná nová, supercool syntaxe. Maximální možnosti.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 03. 06. 2015, 10:52:08
Takový ty kecy jak jsou immutable struktury pomalí jdou z tlam amatérů který nevěděj o čem žvaněj.

Doporučuji benchmark třídění 1000000 32-bit int.

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

To jsem rád že jsme si to konečně ujasnili, tedy původní návrh s KayObject je dodnes z technických důvodů použitelný jen těžce.

"Synchronní" není totéž co serializovaný.

Nutným předpokladem asynchronnosti je na sobě nezávislý paralelní běh asynchronních funkcí.
Zavolání funkce a nečekání na výsledek, s tím že dále to pokračuje přes callback nebo doručení zprávy je stále synchronní záležitost.

lepší příklad je volání funkce, jejíž název mám uložený ve stringu. V Pythonu to jde.

Zjevně volně zaměňujete komunikaci mezi procesy a komunikaci uvnitř procesu. Při práci uvnitř procesu nepotřebuji hledat funkci podle názvu, protože znám její adresu rovnou. Při komunikaci mezi procesy to takhle není dost dobře možné, proto se funkce hledá podle názvu.

Když chci zavolat funkci Mod:fun(1), tak se runtime prostě podívá, jestli má zavedený modul Mod a jestli v něm je funkce fun arity 1.

Tohle přesně uvnitř většího projektu nemá co dělat. S RPC problém není.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tuxik 03. 06. 2015, 10:52:08
a ty konfiguráky, moc si to nedokáž představit, ale proč ne :-D
Na tom je právě hezky poznat, jaké krásné možnosti dynamičnost přináší. Spousta softwarů navrhuje nějaký pseudo-programovací-jazyk jenom proto, aby mohly být konfiguráky dostatečně expresivní. Některé zajdou tak daleko, že je ten pseudojazyk dokonce turingovsky úplný. A kdo se má učit nějaký nový složitý formát? Proč, když máme dost programovacích jazyků?

Prostě do konfiguráku dáš úplně normální kód, který se úplně normálně provede a úplně normálně do runtimu zavede nějaké nové třídy/funkce, které pak zavoláš a máš konfigurační parametr. Žádný parser. Žádná nová, supercool syntaxe. Maximální možnosti.

Takže místo konfiguráku použiješ externí knihovnu konfiguračních funkcí :D No... možná pro nějaký vývoj se to hodit může, jinak v tom žádný velký výhody nenacházím :D Asi jako když v PHP pro konfiguraci použiju klasický php skript místo nějaké parsované konfigurace, takže místo parametr=hodnota napíšu $parametr="hodnota"; , což v tomhle konkrétním případě zase tak nevadí a není to moc k nepochopení, jenom když si parametry nastavuje uživatel, kterej PHP nezná, tak nesmí udělat syntaktickou chybu, jinak to shodí celý :D
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 11:26:32
Doporučuji benchmark třídění 1000000 32-bit int.
K čemu? Nikdo netvrdí, že dynamické, asynchronní, paralelizovatelné systémy jsou dobré na number crunching hrubou silou. To je samozřejmě dobré napsat v něčem jiném a s tím něčím jiným komunikovat vstupy a výstupy. Numpy i R funguje přesně takhle, je to jenom lepidlo a vlastní nuber crunching se dělá maximálně optimalizovaně. Proto je takový rozdíl použít v Rku for a apply :)

To jsem rád že jsme si to konečně ujasnili, tedy původní návrh s KayObject je dodnes z technických důvodů použitelný jen těžce.
To nevím, čím jsme si to ujasnili, ale nemám potřebu se hádat :)

Nutným předpokladem asynchronnosti je na sobě nezávislý paralelní běh asynchronních funkcí.
Zavolání funkce a nečekání na výsledek, s tím že dále to pokračuje přes callback nebo doručení zprávy je stále synchronní záležitost.
Zkusím to ještě jednou: Erlang VM má vlastní scheduler, který přepíná procesy, které běží naprosto nezávisle. Na jednojaderném stroji jsou samozřejmě ty procesy serializované, protože jaksi je tam prostě jenom jedno jádro. Ale "zevnitř" to člověk nepozná, funguje to pořád stejně ať je to jádro jedno nebo je jich 256.

Zjevně volně zaměňujete komunikaci mezi procesy a komunikaci uvnitř procesu. Při práci uvnitř procesu nepotřebuji hledat funkci podle názvu, protože znám její adresu rovnou. Při komunikaci mezi procesy to takhle není dost dobře možné, proto se funkce hledá podle názvu.
Nic nezaměňuju. Mluvím o tom, že existují systémy, které funkce vyhledávají v runtimu i pokud běží v jednom VM. Že to jde i jinak, o tom není sporu. Já jsem říkal, že pokud se to dělá vždy takhle, dá se vždy použít dynamický dispatch. Pokud se volání překládá na CALL, tak to samozřejmě nejde a žádný dynamický dispatch se nekoná, to je přesně ta pointa, nevím, kde je spor.

Tohle přesně uvnitř většího projektu nemá co dělat.
Existují lidi, kteří si myslí, že má. Beru na vědomí, že ty si to nemyslíš a jsem rád, že to vím :)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 11:29:41
Takže místo konfiguráku použiješ externí knihovnu konfiguračních funkcí :D No... možná pro nějaký vývoj se to hodit může, jinak v tom žádný velký výhody nenacházím :D Asi jako když v PHP pro konfiguraci použiju klasický php skript místo nějaké parsované konfigurace, takže místo parametr=hodnota napíšu $parametr="hodnota"; , což v tomhle konkrétním případě zase tak nevadí a není to moc k nepochopení, jenom když si parametry nastavuje uživatel, kterej PHP nezná, tak nesmí udělat syntaktickou chybu, jinak to shodí celý :D
Jakou externí knihovnu? Prostě zavoláš nějakou obdobu eval(...). Výhodu to má v tom, že máš k dispozici mocný jazyk, který spoustu lidí umí, a nemusíš vymýšlet nový jazyk, který se všichni budou muset naučit. Pratktický příklad: awesome WM má konfiguraci v Lua. XMonad ji má, pokud se nepletu, v Haskellu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: noef 03. 06. 2015, 12:43:20
K tem konfigurakum v prog. jazyce jsem mirne skepticky. Pokud je bezne pouziti (tj. napr. 80% uzivatelu) pouze prirazeni hodnot do promennych (wordpress tusim to tak ma), tak s tim problem neni. Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.

Mnohem horsi mi prijde, kdyz mam Gradle a musim se naucit Groovy a DSL pro konfiguraci, prestoze pisu Java aplikaci (na jednoduchy az stredne slozity buildeni by v pohode stacil nejaky konfigurak ve znamem a jednoduchem formatu). A takove SBT je jeste dal, prestoze je to Scala, tak jejich naduzivani custom operatoru z toho dela uplne novy jazyk  - co mam napr. cekat od operatoru <++=?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 03. 06. 2015, 13:53:54
Zkusím to ještě jednou:

Erlang ano, většina ostatních včetně Smalltalk ne.

Existují lidi, kteří si myslí, že má.

To myslí špatně, hledání metod v rámci jednoho procesu až v runtime je neospravedlnitelný nápad bez podstatné přidané hodnoty, nemůže to být výchozí metoda, dá se akceptovat pouze u specialit. Typická specialita je plugin v jiném jazyce, zde se naopak hodí dynamic binding.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 23:23:58
Erlang ano, většina ostatních včetně Smalltalk ne.
Uniklo ti
Citace
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
?

Jinak green threads má (aspoň podle wiki) docela dost jazyků: http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_other_languages
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 03. 06. 2015, 23:25:17
Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.
Čili používá přesně ten mechanismus, o kterém mluvím? A ptáš se, kdo to používá a proč?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Inkvizitor 03. 06. 2015, 23:45:46
Jakou externí knihovnu? Prostě zavoláš nějakou obdobu eval(...). Výhodu to má v tom, že máš k dispozici mocný jazyk, který spoustu lidí umí, a nemusíš vymýšlet nový jazyk, který se všichni budou muset naučit. Pratktický příklad: awesome WM má konfiguraci v Lua. XMonad ji má, pokud se nepletu, v Haskellu.

Xmonad je de facto knihovna, která se "dokonfiguruje" nahozením v mainu s přidanými parametry/prostředím.

Ne že bych tuhle debatu dopodrobna sledoval, ale konfigurace v "normálním" jazyce je dost ošemetná záležitost, protože se dovnitř dá nainjektovat v zásadě cokoliv, pokud tam není nějaký sandbox. V praxi to asi často nevadí, ale ten princip je (opět bez sandboxu) dost šílený.

U Haskellu ten sandbox dělá typový systém (když vynecháme věci typu unsafe IO nebo FFI), tam mi to ještě nějaký smysl dává.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 00:14:20
Ne že bych tuhle debatu dopodrobna sledoval, ale konfigurace v "normálním" jazyce je dost ošemetná záležitost, protože se dovnitř dá nainjektovat v zásadě cokoliv, pokud tam není nějaký sandbox. V praxi to asi často nevadí, ale ten princip je (opět bez sandboxu) dost šílený.
Není vůbec šílený, pokud se konfigurovaná aplikace spouští s právy toho, kdo ji má právo konfigurovat. Není žádná tragedie, že bys mohl  injektovat kód, který můžeš úplně klidně spustit tak jako tak :) Čili efektivně se nám to prakticky smrskává jenom na to, že by se takhle neměly konfigurovat suid programy, v čemž není sporu ;)

Ale obecně máš samozřejmě pravdu, sandboxing je čistější.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 09:13:11
GNU Smalltalk uses preemptive green (non-native) threads; that is, multiple Smalltalk processes are run by the virtual machine in one operating system thread.

Neuniklo mi nic, zvláště ne "Threads are not preempted after a given amount of time". Slovo preemptive je tam jenom na bulíkování důvěřivých neználků.
Ostatně to je hlavní smysl green threads, eliminace nežádoucího preemptivního přepínání vláken, protože většina jazyků kde se to používá na to není zařízená.
V malé míře se používají také pro minimalizaci přepínání kontextů, ale to není případ bazmeků jako Smalltak.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 09:22:19
Neuniklo mi nic, zvláště ne "Threads are not preempted after a given amount of time". Slovo preemptive je tam jenom na bulíkování důvěřivých neználků.
Ostatně to je hlavní smysl green threads, eliminace nežádoucího preemptivního přepínání vláken, protože většina jazyků kde se to používá na to není zařízená.
V malé míře se používají také pro minimalizaci přepínání kontextů, ale to není případ bazmeků jako Smalltak.
Nějak mi asi uniká, co vlastně chceš tvrdit. Jak je to ve Squeaku máš detailně popsané tady http://wiki.squeak.org/squeak/382 a netuším, v rozporu s čím, co jsem řekl, to má být.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: noef 04. 06. 2015, 09:51:53
Navic je tam primo vazba aplikace v PHP <-> konfigurak v PHP.
Čili používá přesně ten mechanismus, o kterém mluvím? A ptáš se, kdo to používá a proč?
Ne. Zrovna pripad konfigurace WP se mi libi. Konfigurace je opravdu jen vyplneni sablony dodane s WP, ale zaroven pokud je treba neco extra, tak je to mozne dobastlit ve stejnem jazyce jako zbytek applikace.

Jen jsem napsal, ze to neni vselek a pokud se to pouzije spatne (IMO SBT a Gradle, ale mozna jsem zaujaty, protoze jsem byl "nucen" je pouzivat, nezvolil jsem si je), tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON. IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku - a uz je celkem jedno, jestli je to nejaky minoritni jazyk jako Haskell (ktery asi moc adminu a uzivatelu nezna), nebo jazyk vytvoreny jen pro konfiguraci jedne aplikace. Treba LUA je natolik jednoducha a dostatecne podobna nejpouzivanejsim jazykum, ze tam chapu tu volbu. Ale konfiguracni soubory v extremne malo pouzivanych jazycich jako Haskell, Scala nebo Lisp? Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 09:52:18
Nějak mi asi uniká, co vlastně chceš tvrdit.

Pořád to stejné, jazyky s green threads v jednom OS vlákně nic takového jako asynchronnost podporovat nemohou, nelze napsat asynchronní kód přímo v jazyku. Erlang se zdá být v pořádku, spousta jiných včetně Smalltalku ne, Squeak ještě nevím.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 10:04:11
tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON.
Má to opodstatnění tam, kde využiješ větší expresivitu než prostou statickou datovou strukturu. Pokud je celá konfigurace jenom klíč-hodnota, tak to samozřejmě nemá smysl. Ale pokud tam máš nějaké části, které by bylo super generovat nějakou funkcí nebo třeba použít sem tam nějaký ten if, tak to význam má. Nevím, jestli znáš konfiguraci Nagiosu a jeho derivátů, ale to je typický příklad, kde by se to hodilo - je tam hromada spousta struktur, které se liší třeba jenom jednou položkou - typický adept na funkci/makro. V Nagiosu se to řeší šablonami a je to takový horor, že se to málo komu chce psát ručně a radši si to něčím vygeneruje. Pokud by konfigurace byla napsaná v nějakém expresivním jazyce, tak bys to generování nějakým třetím nástrojem nepotřeboval, protože by struktury generoval sám zdroják.

Např. v Elixiru vypadá konfigurační soubor projektu takhle: http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#project-compilation - a podívej se o kousek níž, jak je tam hezky použité to "deps_path(Mix.env)"

IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku
V tomhle jsem se zjevně vyjádřil nesrozumitelně. Myslel jsem to tak, že je fajn, když je jazyk natolik dynamický, že konfiguraci můžeš zapsat v něm samém a nepotřebuješ další formát (a jeho parser) navíc. Nemyslel jsem to tak, že by bylo super, kdyby projekt v céčku měl embedded haskell kvůli konfiguráku :)

Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...
Nadužívání DSLs je zlo, to je jasné. Bohužel to vzniká tak, že když člověk pracuje s jazykem, který DSLs umí dobře, tak je z toho tak nadšený, že to chce mermomoci použít. Znám z vlastní zkušenosti ;)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 10:06:51
Pořád to stejné, jazyky s green threads v jednom OS vlákně nic takového jako asynchronnost podporovat nemohou
To právě nechápu, proč si tohle myslíš. To přece záleží na tom, co umožňuje VM a jak pracuje scheduler. Obecně tahle věta neplatí.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: noef 04. 06. 2015, 10:38:34
tak je to naopak mnohem horsi, nez tam hodit jednoduchou konfiguraci v YAML nebo JSON.
Má to opodstatnění tam, kde využiješ větší expresivitu než prostou statickou datovou strukturu. Pokud je celá konfigurace jenom klíč-hodnota, tak to samozřejmě nemá smysl. Ale pokud tam máš nějaké části, které by bylo super generovat nějakou funkcí nebo třeba použít sem tam nějaký ten if, tak to význam má. Nevím, jestli znáš konfiguraci Nagiosu a jeho derivátů, ale to je typický příklad, kde by se to hodilo - je tam hromada spousta struktur, které se liší třeba jenom jednou položkou - typický adept na funkci/makro. V Nagiosu se to řeší šablonami a je to takový horor, že se to málo komu chce psát ručně a radši si to něčím vygeneruje. Pokud by konfigurace byla napsaná v nějakém expresivním jazyce, tak bys to generování nějakým třetím nástrojem nepotřeboval, protože by struktury generoval sám zdroják.
Jiste, ja nerikam ze to nema svoje misto. A i u pouheho klic-hodnota to muze byt k uzitku, kdyz by bylo v budoucnu potreba neceho pokrocilejsiho. Jen je dulezite, aby pro nastaveni zakladnich vlastnosti to bylo jednoduche a intuitivni a nevyzadovalo to ucit se dalsi jazyk (staci umet prirazeni). Take je nutne odlisit konfiguraci pokrocilych servrovych aplikaci a napr. GUI klikatka, ktere si bude nastavovat "bezny" uzivatel.

Např. v Elixiru vypadá konfigurační soubor projektu takhle: http://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#project-compilation - a podívej se o kousek níž, jak je tam hezky použité to "deps_path(Mix.env)"
Pokud to chapu dobre, tak konfigurace samotna je v Elixiru. Vypada to jako prave ten dobry priklad pouziti - nenutim programatora se ucit dalsi jazyk jen proto, protoze se mi (jako tvurci nastroje) libil.

IMO spatne je, kdyz se konfigurace provadi v jinem jazyce, nez ve kterem je psan cely zbytek projektu. Prijde mi divne se ucit dalsi jazyk jen pro zapsani jednoducheho konfiguraku
V tomhle jsem se zjevně vyjádřil nesrozumitelně. Myslel jsem to tak, že je fajn, když je jazyk natolik dynamický, že konfiguraci můžeš zapsat v něm samém a nepotřebuješ další formát (a jeho parser) navíc. Nemyslel jsem to tak, že by bylo super, kdyby projekt v céčku měl embedded haskell kvůli konfiguráku :)
:)

Navic pokud ke skoro neznamemu funkcionalnimu pristupu jeste pridam DSL s hromadou symbolickych neintuitivnich operatoru (v SBT kupr. %, ##, ---, +++, :=, <<=; to je v podstate novy jazyk) ...
Nadužívání DSLs je zlo, to je jasné. Bohužel to vzniká tak, že když člověk pracuje s jazykem, který DSLs umí dobře, tak je z toho tak nadšený, že to chce mermomoci použít. Znám z vlastní zkušenosti ;)
V nekterych pripadech mohou vlastni symbolicke operatory dost pomoci, bohuzel vetsinou je to presne naopak. Jiz zminovane SBT je toho ukazkou - IMO by to melo byt pristupne v podstate vsem, co neco napsali ve Scale. V nekterych specializovanych knihovnach jako Scalaz to chapu - slouzi k zapisu predevsim matematickych operaci, presto mi teda prijdou unicode jmena divna, asi vec zvyku: ∑, ↦, ∅, ⊥. I tak to ale vytvari dojem slozitosti a znesnadnuje tak pochopeni veci novackum.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 10:54:51
Pokud to chapu dobre, tak konfigurace samotna je v Elixiru. Vypada to jako prave ten dobry priklad pouziti - nenutim programatora se ucit dalsi jazyk jen proto, protoze se mi (jako tvurci nastroje) libil.
Ano - a přesně tak jsem to myslel. U programátorských projektů je to bez debat v pohodě, trochu míň v pohodě je to u vyloženě uživatelských věcí (např. když používám XMonad, tak nemusím nutně umět Haskell zatímco když dělám projekt v Elixiru, tak Elixir zjevně umím). I tak si ale myslím, že použít existující (a jakž-takž rozšířený) jazyk je pořád lepší než vymyslet si tisícíprvní konfigurační formát s expresivitou přesně naladěnou na to, co potřebuju, který změním vždycky když zjistím, že vlastně teď už potřebuju větší expresivitu...

Ono totiž se řekne "máme konfiguraci v YAML", jenže jakmile tam chceš vyjádřit něco ne-totálně-triviálního, tak už to vlastně není YAML, ale YAML dodává jenom syntaxi a k tomu je nějaká sémantika/ontologie, která může být pěkně přebujelá, v nejhorším případě vlastně postavíš programovací jazyk s YAMLovou syntaxí, abys měl tu potřebnou expresivitu (viz např. konfigurace http://docs.saltstack.com/en/latest/ kde je použití YAMLu imho už za hranou, protože jakmile tam máš X různých šablon s Y parametry pro Z strojů, tak ten YAML prostě přeteče do basketbalu, jak říká klasik ;) a přehlednost deklarativního formátu je v pytli...

Btw, výhoda toho konfiguráku v Elixiru je v tom, že ty hodnoty můžeš brát odkud chceš a máš k dispozici celý jazyk. Je libo načíst dependencies z webu? Není problém. Z webu přes https s kontrolou certifikátů? Ok. Z webu zašifrovaný AES? Ok. Kdybys měl nějaký deklarativní formát, na všechny tyhle možnosti bys musel vymyslet nějakou spešl položku, kterou by se uživatel musel naučit...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 11:03:40
To přece záleží na tom, co umožňuje VM a jak pracuje scheduler.

Nechápete ani základy, preemptivnost není vlastnost nějakého algoritmu. Podstatu preemptivnosti podporu násilného přerušení vykonávání vlákna bez jeho součinnosti, si v user-space jen tak nenaprogramujete. Jestliže celé VM běží v jednom vlákně, máte smůlu. Nějaké výjimečné pokusy jak to simulovat jsou, ale není to ono.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 11:05:16
.. a preemptivnost je nutná podmínka asynchronního kódu.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: neruda 04. 06. 2015, 11:09:18
a asynchronni kod je nutna podminka existence sveta, jinak bysme se tu vsichni zasekavali.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:09:26
Nechápete ani základy,
Prosím bez silných slov, nepřispívá to kvalitě diskuse.

preemptivnost není vlastnost nějakého algoritmu. Podstatu preemptivnosti podporu násilného přerušení vykonávání vlákna bez jeho součinnosti, si v user-space jen tak nenaprogramujete. Jestliže celé VM běží v jednom vlákně, máte smůlu. Nějaké výjimečné pokusy jak to simulovat jsou, ale není to ono.
Chápu to správně, že postulujete, že obecně není možné něco, o čem jste sám přiznal, že presně to Erlang dělá? Je potřeba o tom vůbec víc diskutovat?

Jak budou vlákna vykonávána je samozřejmě vlastnost VM a jeho scheduleru. Pokud bude scheduler napsaný tak, že jednotlivá vlákna bude přepínat po vykonání jedné pseudoinstrukce (instrukce VM), tak to tak prostě bude dělat. Nerozumím, co se snažíte tvrdit/dokázat.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:09:54
.. a preemptivnost je nutná podmínka asynchronního kódu.
Důkaz prosím.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:14:37
Důkaz prosím.
Možná ho předejdu: mějme VM běžící v jednom vláknu, uvnitř něj jsou VM-vlákna (green threads), která scheduler VM přepíná po vykonání n instrukcí VM. Každé VM-vlákno má svůj mailbox. Instrukční sada VM obsahuje instrukci SEND, která vloží zprávu X do mailboxu procesu Y, a instrukci RECV, která vezme zprávu z vrcholu mailboxu.

Teď bych rád viděl ten důkaz, že takové procesy spolu nemůžou komunikovat asynchronně.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: v 04. 06. 2015, 11:16:27
Důkaz prosím.
Možná ho předejdu: mějme VM běžící v jednom vláknu, uvnitř něj jsou VM-vlákna (green threads), která scheduler VM přepíná po vykonání n instrukcí VM. Každé VM-vlákno má svůj mailbox. Instrukční sada VM obsahuje instrukci SEND, která vloží zprávu X do mailboxu procesu Y, a instrukci RECV, která vezme zprávu z vrcholu mailboxu.

Teď bych rád viděl ten důkaz, že takové procesy spolu nemůžou komunikovat asynchronně.

nejdřív přesně definujte asynchronnost
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:19:44
nejdřív přesně definujte asynchronnost
Asynchronnost znamená, že proces X pošle procesu Y instrukci, že má vykonat činnost Z, na výsledek této činnosti proces X nemusí čekat, ale může se klidně pustit do činnosti A a o ukončení činnosti Z procesu Y je informován nepředvídatelně kdykoli v budoucnosti nezávisle na tom, co právě dělá proces X.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: v 04. 06. 2015, 11:23:29
nejdřív přesně definujte asynchronnost
Asynchronnost znamená, že proces X pošle procesu Y instrukci, že má vykonat činnost Z, na výsledek této činnosti proces X nemusí čekat, ale může se klidně pustit do činnosti A a o ukončení činnosti Z procesu Y je informován nepředvídatelně kdykoli v budoucnosti nezávisle na tom, co právě dělá proces X.

a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:26:08
a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)
Řekl jste si o to: proces je zásobníkový automat se dvěma zásobníky a jedním mailboxem ;)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: v 04. 06. 2015, 11:35:14
a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)
Řekl jste si o to: proces je zásobníkový automat se dvěma zásobníky a jedním mailboxem ;)

tak teď by se mělo ukázat, že to nejde naprogramovat mimo kernel... ono to ale asi půjde, mi se to povedlo a to nejsem zrovna hvězdný programátor
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:38:54
tak teď by se mělo ukázat, že to nejde naprogramovat mimo kernel... ono to ale asi půjde, mi se to povedlo a to nejsem zrovna hvězdný programátor
S kernelem to nemá vůbec nic společnýho. VM je prostě VM - má vlastní virtuální čas (krokování). Jediné, čím ho může vnější svět (kernel) ovlivnit, je, že vzdálenost mezi dvěma kroky (instrukcemi) VM bude různě dlouhá v sekundách reálného času. To nás ale vůbec nezajímá, nemá to žádný vliv na to, co uvnitř VM jde nebo nejde udělat, je to metaúroveň.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: v 04. 06. 2015, 11:44:13
S kernelem to nemá vůbec nic společnýho.

zmínkou o kernelu jsem narážel na toto:

v user-space jen tak nenaprogramujete
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 11:49:00
zmínkou o kernelu jsem narážel na toto:

v user-space jen tak nenaprogramujete

Jo, to je (pro me) nepochopitelne michani zakladni urovne s metaurovni.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 13:03:47
Pokud bude scheduler napsaný tak, že jednotlivá vlákna bude přepínat po vykonání jedné pseudoinstrukce (instrukce VM), tak to tak prostě bude dělat.

Pro kód interpretovaný VM-MPrymek jsem nucen souhlasit, jistě také lze mít za každou nativní instrukcí CALL Scheduler, na takové teoretické filozofování ale nemám čas ani náladu. V realitě většina praktických implementací VM to takto nemá a přepíná vlákna pouze při jisté dávce spolupráce s kódem vlákna.

Mezitím jsem si pročetl Erlang a preemptivní není ani Erlang ;D Thread-switch je tam synchronní záležitost a může nastat pouze mezi jednotlivými redukcemi. Iluze preemptivnosti spočívá v tom že redukce se z povahy jazyka nedá napsat jako časově dlouhá věc. To co trvá dlouho, třeba komunikace s ODBC, se vystrčilo ven z erlang vlákna.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 13:14:49
Mezitím jsem si pročetl Erlang a preemptivní není ani Erlang ;D Thread-switch je tam synchronní záležitost a může nastat pouze mezi jednotlivými redukcemi. Iluze preemptivnosti spočívá v tom že redukce se z povahy jazyka nedá napsat jako časově dlouhá věc. To co trvá dlouho, třeba komunikace s ODBC, se vystrčilo ven z erlang vlákna.
Nejspis tady panuje nejake zasadni nedorozumeni. Cemu rikate "preemptivni" v kontextu kodu vykonavaneho ve VM a jak to souvisi s moznosti asynchronniho posilani zprav?

Samozrejme, ze veci, ktere sahaji mimo VM muzou kod uvnitr VM zaseknout, o tom se snad nemusime bavit, to je jasne, ne?! Proto se to taky "vystrci ven", aby to ty procesy uvnitr VM neblokovalo.

V realitě většina praktických implementací VM to takto nemá a přepíná vlákna pouze při jisté dávce spolupráce s kódem vlákna.
Opet, co presne tim myslite? Ze instrukcni sada toho VM obsahuje nejakou instrukci "SWITCH", ktera preda rizeni scheduleru? Takze kdyz vytvorim bytekod, ktery tu instrukci obsahovat nebude, tak se rizeni scheduleru nepreda? To snad takhle nemuzete myslet, jaky VM to takhle ma?!
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Pan Jan 04. 06. 2015, 13:37:44

Cože? VM si to může zařídit jak chce, pokud jde o plánování. A je buřt jak to má OS, tím klidně může být i CP/M.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 15:23:11
Cemu rikate "preemptivni" v kontextu kodu vykonavaneho ve VM a jak to souvisi s moznosti asynchronniho posilani zprav?

Preemptivní znamená že vlákno se přepne bez čekání na smluvenou činnost ve vlákně. Vykonat asynchronní událost na základě zprávy můžete jen v preemptivním prostředí. Specifikum Erlang jsem popsal.

Takze kdyz vytvorim bytekod, ktery tu instrukci obsahovat nebude, tak se rizeni scheduleru nepreda?

Bingo, pokud vlákno v kooperativním multitaskingu neprovede smluvenou činnost, tak má Scheduler smůlu. Nemusí to být pouze specifický bytecode, mohou to být i vhodné funkce, třeba počátek/konec redukce nebo funkce, alokace nové paměti, volání IO operace a jiné.

To snad takhle nemuzete myslet, jaky VM to takhle ma?!

Volání Scheduleru na základě smluvené činnost mají v Erlangu, pak tady:
http://wiki.squeak.org/squeak/382
The Squeak scheduler is cooperative between threads of the same priority

a tady:
https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/using-concurrent.html
A context switch will occur at the next heap block allocation after the timer expires (a heap block allocation occurs every 4k of allocation)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 15:47:13
Vykonat asynchronní událost na základě zprávy můžete jen v preemptivním prostředí.
Porad nechapu, proc by to tak melo byt. Zpravu proste umistim do mailboxu adresata a odpoved si vyzvednu ze sveho mailboxu. Mezitim si delam co chci. Proc bych k tomu potreboval preemptivni multitasking, to prave nechapu.

Bingo, pokud vlákno v kooperativním multitaskingu neprovede smluvenou činnost, tak má Scheduler smůlu. Nemusí to být pouze specifický bytecode, mohou to být i vhodné funkce, třeba počátek/konec redukce nebo funkce, alokace nové paměti, volání IO operace a jiné.
No to je ale zasadni rozdil. Udelat nejakou explicitni cinnost, jejiz jediny vyznam a smysl je predat rizeni scheduleru je uplne neco jineho nez pravidlo, ze scheduler provede context switch jenom za nejake vhodne prilezitosti (konec funkce atd.)

To, ze ve vlakne dojde k ukonceni funkce prece neni "kooperace se schedulerem" a uz vubec to nema nic spolecneho s moznosti asynchronniho posilani zprav.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 16:45:34
Zpravu proste umistim do mailboxu adresata a odpoved si vyzvednu ze sveho mailboxu. Mezitim si delam co chci.

A ta odpověď se do mailboxu dostala jak ? Vy jste ji tam nedal a protože jste si dělal svoje věci tak adresát se nedostal k CPU. Zřejmě ji tam dali Marťani :-)

No to je ale zasadni rozdil.

Zásadní rozdíl se zcela smaže, když pilný hlupák vrazí do funkce dlouhý výpočet.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 16:53:39
A ta odpověď se do mailboxu dostala jak ? Vy jste ji tam nedal a protože jste si dělal svoje věci tak adresát se nedostal k CPU. Zřejmě ji tam dali Marťani :-)
Coze? Mailbox je proste fronta. Takze vlozim zpravu do fronty (=asynchronne "zavolam") a jdu si delat, co chci. Kdykoli me to napadne, tak v ramci toho "co chci" koukam do sveho mailboxu, jestli mi nahodou mezitim neprisla odpoved. To je asynchronni volani. A zadny "preemptivni VM" k tomu proste neni potreba.

Zásadní rozdíl se zcela smaže, když pilný hlupák vrazí do funkce dlouhý výpočet.
Zasadni rozdil je mezi tim, kdyz explicitne se schedulerem musim kooperovat a kdyz jsou jenom stanovena pravidla, kdy scheduler context switch dela (protoze je to tak treba efektivni, vyhodne, jedoduche atd.) - pravidla, o kterych kod vubec nemusi vedet a jsou mu uplne putna, protoze on z jeho pohledu bezi linearne bez preruseni (coz je definice multitaskingu).

------------------

Hele, uz me to hrani si na kocku a mys fakt nebavi. Porad nevim, co vlastne chcete dokazat, proc a jak, a uz me nebavi se na to ptat porad dokola. Tak nekdy priste nashle...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Ondrej Nemecek 04. 06. 2015, 16:58:00
Já teda nevím, ale není to prostě tak, že Mirek Prýmek se na to dívá z pohledu VM a Kolemjdoucí z pohledu OS případně železa? Mi to tak přijde.

V jednom OS vlákně můžu mít asynchronní akce, nebo ne? Prostě se střídají a nepotřebuju na to ani víc OS procesů ani víc OS vláken. Tak to má třeba javascript.

Nebo mě opravte, jestli jsem mimo.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 16:59:37
jestli mi nahodou mezitim neprisla odpoved.

Takže jak se do mailboxu odpověď nevíte, zůstává v platnosti varianta s Marťany :)

Tak nekdy priste nashle...

Nashledanou, přeji pěkný zbytek dne.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 17:03:17
Já teda nevím, ale není to prostě tak, že Mirek Prýmek se na to dívá z pohledu VM a Kolemjdoucí z pohledu OS případně železa? Mi to tak přijde.
Dyt to rikam: Kolemjdouci mota uroven a metauroven. Jenze ta metauroven nas v tomhle pripade nezajima - jestli VM zastavim zvnejsku (metauroven) na pulhodiny nebo deset let a pak spustim znovu, nema vubec zadny vliv na to, jestli uvnitr VM jde nebo nejde zrealizovat nejaka operace. VM ma vlastni tikani casu a vnejsi cas ho vubec nezajima. Jo, kdyby Kolemjdouci rekl "timhle zpusobem nejde udelat hard realtime", tak to je uplne jina pisnicka...

V jednom OS vlákně můžu mít asynchronní akce, nebo ne? Prostě se střídají a nepotřebuju na to ani víc OS procesů ani víc OS vláken. Tak to má třeba javascript.

Nebo mě opravte, jestli jsem mimo.
Ne, presne takhle to je - VM ma vlastni scheduler a sam VM-vlakna prepina uplne stejne jako OS prepina svoje vlakna. To je jakobych tvrdil, ze na jednojadernem CPU nejde udelat unixova roura...
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 17:05:26
Takže jak se do mailboxu odpověď nevíte, zůstává v platnosti varianta s Marťany :)
Odpoved se do meho mailboxu dostane tak, ze moje vlakno (X) scheduler prerusi, spusti druhe vlakno (Y) a to mi vlozi zpravu do meho mailboxu. Z hlediska  vlakna X je to "z nicehoznic", protoze vlakno X vubec nevi o tom, ze bylo preruseno.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Kolemjdoucí 04. 06. 2015, 17:47:42
Odpoved se do meho mailboxu dostane tak, ze moje vlakno (X) scheduler prerusi, spusti druhe vlakno (Y) a to mi vlozi zpravu do meho mailboxu.

Přeruší ? O žádné přerušení Vaší činnosti jste nežádal ani jste k tomu nedával svolení :) Scheduler to provedl násilně, proti Vaší vůli, preemptivně přepnul do jiného vlákna a pak zase zpět ;)
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Mirek Prýmek 04. 06. 2015, 18:11:32
Přeruší ? O žádné přerušení Vaší činnosti jste nežádal ani jste k tomu nedával svolení :) Scheduler to provedl násilně, proti Vaší vůli, preemptivně přepnul do jiného vlákna a pak zase zpět ;)
Ne, scheduler prepnul kontext, protoze mezitim doslo k ukonceni funkce, alokovani pameti, IO operaci, vyprseni casu, zatmeni mesice, nebo si nekdo prdnul. To mne jako vlakno X vubec nezajima. Mne uplne staci vedet, ze k tomu prepnuti NEKDY dojde. A VUBEC na tom nemusim spolupracovat.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: BoneFlute 04. 06. 2015, 18:14:24
Přeruší ? O žádné přerušení Vaší činnosti jste nežádal ani jste k tomu nedával svolení :)
Tuhle logiku mi vysvětlete. Kde jste vzal implikaci, že by měl o nějak přerušení žádat? Proč by měl dávat svolení?
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: SB 19. 06. 2015, 09:10:01
To jde už dlouho, jenom místo instance.foo(args) napíšete instance.MujSkvelyRozhodovac("Foo", args), volitelně můžete kombinovat s thread-safe queue.

Tohle je PŘESNĚ nepochopení konceptu zasílání zpráv. Mezitímco zpráva znamená výběr řešení problému na straně příjemce, volání je výběr řešení na straně odesilatele. Máte-li zprávu, vypadá zaslání vždy stejně. Máte-li volání, musíte explicitně použít úplně jinou „metodu“ a v případě, že to neuděláte, nejde chování volaného změnit.
Název: Re:Použití Objective-C mimo Apple
Přispěvatel: Tany 25. 06. 2015, 07:15:45
No, asi smažu VirtualBox, protože podle vašeho popisu prostě nemůže fungovat.