Céčko na Marsu; Gedit word completion (diskuse)

[KaiSVK]

Jeeeej super, diky moc, ten plugin som hladal, nasiel som trosku iny, ale tento je o 100% lepsi :) Dik este raz.

Kaio

[KaiSVK]

Este som chcel, v Kate je v highlighting aj zvyraznovanie "Cisco configu". Je nieco take aj pre Gedit? ja som nenasiel

[alblaho]

Tak to já nevím, síťařině takového typu se vyhýbám.

Btw, líbí se mi Kate z KDE4. Až bude KDE4 trochu uležené (za rok?), tak bych se tomu nebránil.

[KaiSVK]

s tym KDE4/Kate velky suhlas...

[Ladicek]

Mne spíš zaujala úplně poslední věta: We don't allow dynamic memory allocation, for example. S takovou se skoro obejdou bez ukazatelů

[Kyosuke]

Ono JPL historicy používalo všelijaké technologie, třeba sondu Deep Space 1 řídil jeden den experimentálně plně autonomní systém s umělou inteligencí psaný v Lispu (který si nechali na míru upravit od tehdejšího Harlequinu, dneska LispWorks), ale pak se přehnala ta COTS vlna, začaly se srážet náklady a výsledek je ten, že dnešní sondy NASA s dostatečně dimenzovanými palubními počítači jedou na VxWorks a palubní software dálkových sond je psaný veskrze v Cčku. Ještě jedna věc je v důsledku těchhle věcí v JPL populární: Tcl. Jako skriptovací jazyk ho cpou snad všude, kde můžou, i do aplikací v Javě, aby se daly rozumně navrhovat , a i do těch vesmírných sond, protože se jeho implementace vejde do několika kilobajtů, takže je takřka blbuvzdorná. Akorát na tu druhou věc jsem měl někde zajímavý odkaz a teď ho nemůžu nají. ;-/

[alblaho]

No VxWorks používají snad všechny nasácké mise na Mars. Prostě se jim to osvědčilo.

Ale stejně bych raději psal palubní soft v Adě. I když jistá příhoda s Ariane ukázala, že samospasitelné to tedy není. Je hezké mít všelijak omezené typy, ale je potřeba si setsakramentsky rozmyslet, jak ty hranice nastavit.

[slush]

> na to se Eclipse a podobní mastodonti moc nehodí.

No tak to prrr... Mozna pises tak prasacky a necitelne (ano, mluvim o divokych dynamickych pretypovanich objektu, napriklad), ze je z tebe code completition hotovej, ale az budes psat neco vetsiho, budu ti pri debugovani a trasovani v geditu drzet palce.

Pydev v eclipse je uplne super, a zrovna code completition je ta posledni vec, kterou bych zminil.

[alblaho]

Prasácky, to znamená že v Pythonu nepíšu Javu ale Python?-) Mít ActiveRecord který vytvoří atributy dynamicky podle záznamu z databáze je prasácké? Udělat nějakou AOP transformaci je taky prasárna? Mít objekt - transparentní proxy je taky prasárna?

Možná Ale Python mám rád, protože v něm jdou jednoduše a elegantně věci, které jsou ve statických jazycích dost přes ruku. Ale všechno něco stojí.

Ale s tím mastodontem jsem to myslel jinak. Já dělám experimenty, převážně s PyPy, zkouším různé přepínače atd. Pydev bych použil, kdybych soustavně dělal na něčem větším a konvenčním, ráno bych to otevřel a večer zavřel.

[Ladicek]

Mít objekt - transparentní proxy je taky prasárna?

Naprosto. V Javě je to jeden z oblíbených způsobů, jak implementovat AOP, a s klidem bych řekl, že ten nejhorší. Nevím teda, jak v Pythonu, ale v Javě se té transparence pořádně dosáhnout nedá, takže this není this a vůbec samé pěkné věci.

[alblaho]

To byl jen nastřelený příklad, kdy relativně rozumný kód vykolejí každý kompletátor kódu.

No hele, AOP je samo o sobě "prasárna", nebo minimálně dvojsečná zbraň. Nějakou transformací změníš tisíc míst a pokud ten weaving děláš v Javě nad bajtkódem, tak se nikdy nemůžeš pořádně podívat, co to vlastně udělalo.

Transparentní proxy asi nikdy nebude na 100% transparentní. V dynamických jazycích se to občas použije, protože je to implementace na pár řádek a díky duck typing si ostatní objekty ničeho nevšimnou. Hádám že statická typová kontrola to komplikuje a proto to v Javě nebude žádná slast.

[Kyosuke]

AOP a prasárna? Třeba CLOS s tím, pokud je mi známo, nikdy neměl problémy. A co teprve COP.

[Ladicek]

Problémy s AOP, tedy alespoň v Javě, jsou čistě implementační. Nikdo nezaručí, že transformace proběhne správně a na všech místech, protože veškeré javovské AOP je více nebo méně hack. I když to asi funguje, když si člověk dává pozor. Systémové řešení je podpora AOP na úrovni virtuálního stroje, jak to navrhli u Bey, ale kde je tomu konec…

Jinak prasárna to určitě není, spíš velmi výhodný přístup ve spojitosti s OOP (aspoň tak, jak ho chápe dnešní mainstream, aby mne tu někdo neumlátil CLOSem, že), ke kterému je v podstatě ortogonální.

[Kyosuke]

Nemám důvod mlátit nikoho CLOSem. Původní návrh CLOSu nic podobného neobsahoval, a není to ani součástí oficiální ANSI normy. Aspektové programování vlastně vzniklo jako specializace MOPu - což je rozšiřující API, které umožňuje přeprogramovat chování takřka celého CLOSu (třeba pořadí hledání metod v nadtřídách, to je jedna z těch pro programátoršké smrtelníky srozumitelnějších věcí). Ostatně AOP vymyslel Gregor Kiczales, který toho s Lispem, CLOSem a MOPem má hodně společného. (AOP pak není vlasně víc, než jedna konkrétní aplikace MOPu, který dneska podporují snad všechny implementace Common Lispu, tedy tam je to v podstatě "na úrovni virtuálního stroje" - no, tady spíš "na úrovni modelu jazyka". )

[Ladicek]

Jo, něco podobného jsem čekal, když jsem mluvil o umlácení CLOSem Nechápu, jak to ti Lispaři dělají. Teda chápu, tak nějak vzdáleně… ale asi nikdy se nad tou neuvěřitelnou přizpůsobivostí a jednoduchostí nepřestanu podivovat. A taky to pěkně ničí moje už tak ubohé programátorské sebevědomí

[Miloslav Ponkrác]

"""Mít objekt - transparentní proxy je taky prasárna?"""

"Naprosto. V Javě je to jeden z oblíbených způsobů, jak implementovat AOP, a s klidem bych řekl, že ten nejhorší."

Uvědomuje si ten nebohý javista rozdíl mezi Javou a Pythonem? Například ten propastný rozdíl mnezi statickým a dynamickým typováním? A také důsledky a obrovské odlišnosti z toho vyplývající?

Dokáží javisté někdy skutečně pochopit, že jiné jazyky vypadají jinak, než Java, mají jiné vlastnosti, a z toho vyplývá často i jiný přístup pro vývojáře?

[Ladicek]

Vytrháváte z kontextu, ale neskutečně. Vím velmi dobře, že Python má prostředky, jak elegantně a systémově dosíci téhož, čeho se v Javě dosahuje různými hacky, mezi které patří používání zástupných objektů. Co vede Pythonisty k tomu, aby se k nim taky snižovali, to vskutku netuším. Každopádně mi jistě dokážete objasnit, jak dynamický typový systém pomůže vyřešit problém, do kterého se dostanu, když na zástupném objektu zavolám metodu, která zavolá další metodu na this a ta není "obalena" tou proxy mrchou?

A mimochodem, dokáží někdy zapšklí C++kaři pochopit, že nemají patent na rozum a že Javisté nejsou untermensch?

[alblaho]

Láďo, abych se přiznal, tak si nejsem jistý, o čem mluvíš. Předpokládejme tento kód:

class Math(object):
       def cosmos_constant(self):
                return 1

       def pow(self, x):
                return x*x*self.cosmos_constant()

class Proxy(object):
       def __init__(self, target):
                self.target = target
       def __getattr__(self, name):
                print 'logging this call...'
                return getattr(self.target, name)

m = Math()
print m.pow(4)
p = Proxy(m)
print p.pow(5)

A ty bys chtěl, aby se zalogovalo volání té kosmologické konstanty z pow()?

[Ladicek]

Přesně to bych chtěl

[alblaho]

A nechtěl bys toho trochu moc?-) Tohle je prostě vlastnost proxyobjeku a co si ten zastupovaný objekt dělá uvnitř, do toho mu nikdo nekecá.

Proxy je z tohoto pohledu nedokonalá náhražka AOP, potřebuješ pořádný weaving.

[Ladicek]

To není vlastnost, to je riziko Metoda cosmos_constant() se chová odlišně v závislosti na tom, kdo ji volá, což je v tomhle případě vcelku na dvě věci. Představ si, že bys tou proxy chtěl změnit vesmír (nastavit kosmologickou konstantu na 2). Proto jsem psal, že to je prasárna

Na druhou stranu, v některých případech takový zástupný objekt může dobře postačit (třeba takové hrubé trasování, jako ve tvojí ukázce), to uznávám.

[Kyosuke]

Představ si, že bys tou proxy chtěl změnit vesmír (nastavit kosmologickou konstantu na 2).

Něco na tenhle způsob?

kyo@valinor:~> ghci
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude> let 2 + 2 = 5 in 2 + 2
5
Prelude>

[Filip Jirsák]

Metoda cosmos_constant() se chová odlišně v závislosti na tom, kdo ji volá, což je v tomhle případě vcelku na dvě věci.

Nechová se odlišně ta metoda, vždyť jsou to dvě různé metody, ne?

[Ladicek]

No a? Pod slovem transparentní si celou dobu představuju transparentní z pohledu volajícího, kterého existence nějaké proxy vůbec nezajímá. Zavolám-li p.cosmos_constant() a dostanu 2, očekávám, že volání p.pow(2) vrátí 8. Vy ne?

[Filip Jirsák]

Váš objekt Math máte napsán tak, že počítá se svou kosmologickou konstantou (proto třeba self). Kdybyste chtěl, aby počítal s jeho (nějakého cizího objektu), musíte mu ten cizí objekt předat jako parametr. cosmos_constant() buď nemáte nadefinovánu tak, že vrací svou kosmologickou konstantu, nebo ji tak nadefinovánu máte, a pak vytvořená proxy porušuje tento dohodnutý kontrakt. Proxy s tím ale nemá nic společného, kdybyste si ten dohodnutý kontrakt porušil už v implementaci třídy Math, dopadnete stejně.

[Ladicek]

Já vo koze, von vo voze. Marno.

[Filip Jirsák]

v Javě se té transparence pořádně dosáhnout nedá, takže this není this a vůbec samé pěkné věci

Jak to že ne? this je pořád reference na objekt, na kterém je volána aktuální metoda. To že okolo toho objektu je nějaká proxy nemůže ten objekt zajímat. Očekávám, že když v objektu zavolám na this final metodu, provede se úplně to samé, jako bych kód té metody přímo vložil do svého kódu. Pokud tu metodu chci provést na stejném objektu, který referencuje ten, kdo moji metodu vyvolal, musí mi referenci na ten objekt předat. Zkuste si někdy něco napsat v JavaScriptu, abyste viděl, jak to vypadá, když si nikdy nemůžete být jist, co je this.

[Ladicek]

To že okolo toho objektu je nějaká proxy nemůže ten objekt zajímat.

Proto tvrdím, že se nedá dosáhnout plné transparence. Výraz this není this berte proboha trochu s nadsázkou, já přece jenom dobře vím, jak taková proxy funguje