Příspěvky

541

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 01. 08. 2020, 16:06:39 »

Když užs to nakous — je přepodstatnění spíš cast, assertion nebo conversion?

Cast a assertion to není určitě, protože tam se mění jenom náš pohled a věc samotná zůstává beze změny. V té situaci, o kterém jsem mluvil, se doopravdy mění ta samotná věc (mění se množina funkcí ve shluku).

Pojem "conversion" v kontextu IT neznám. Jestli ho myslíš jako obecný pojem, tak jo - je to prostě změna (s důrazem na to, že to není "změna podstaty", protože žádná podstata tam není).

Ještě by mohlo být zajímavý promyslet to, že shluky by se mohly slučovat a dělit. Takže třeba funkční kočka by se mohla rozdělit na funkční ucho, funkční oko a nějakej zbytek

V jedné sci-fi povídce se hnusná mimozemská potvora vydávala za nádhernou ženu, aby ji hlavní hrdina miloval. Ten neodolal, a chtěl vidět jak skutečně vypadá, a zhrozil se. Ale nakonec s ní stejně zůstal, protože byla pěkná (když se maskovala), byla hodná, byla fajn.

U té kočky mě nezajímá její podstata. Zajímá mě, zda vypadá jak kočka, zda se chová jak kočka, a zda - zde narážíme na nevýhody dynamických jazyků - se na ni jako na kočku dá spolehnout.

542

Studium a uplatnění / Re:Office a remote práce po pandemii

« kdy: 01. 08. 2020, 16:01:04 »

To, že neumím rozlišit mezi dvěma objekty, může znamenat:

a. Jsou objektivně k nerozeznání.
b. Moje schopnosti rozlišit tyto dva objekty jsou nedostatečné, ale rozdíl tam je – možná to poznám později, možná to umí rozlišit někdo jiný.

Varianta b je asi celkem častý případ v reálném světě. Máme dvě sklenice vody. Na první pohled stejné, ale voda se může lišit složením, a rozdíl může být v extrémním případě otázkou života a smrti. V OOP podobná situace může nastat, když se budu pokoušet objekty rozlišit bez práce s jejich identitou. V Javě bez ==, != na objektech, bez identityHashCode apod.

V případě mutability to může být ještě zajímavější. Mohu mít dva na první pohled nerozeznatelné objekty se stejným obsahem, ale každý bude na jiné adrese. Časem se jeden z nich změní. Najednou se projeví odlišná identita, která dříve nebyla patrná.

Já k těmto věcem přistupuju podle efektu.

Pokud má objekt identitu, nezajímá mě, jak je to interně implementovaný, ale zajímá mě, že když ho změním, ovlivní či neovlivní to další věci?

V případě Theseovi lodě, záleží na tom, zda je to ta samá loď? V jednom článku na Oslu (navzdory tomu, že je to děsně pavědeckej site) bylo pěkné vyjádření, že zloděj včera ukradl tisícovku, ale dneska (díky výměně buněk, etc) už to není týž člověk co včera. A to mě přivedlo k zamyšlení - jenže tu tisícovku stále má. To, zda je či není týž nikoho nezajímá.

Pokud mám cenný obraz, a udělám z něho nějakým supr přístrojem stoprocentní kopii, tak filozoficky to první je originál a má hodnotu, to druhé je kopie, nemá hodnotu - ale v praxi mě takové otázky zajímat nebudou, a budu se spíše ptát po tom, zda ten obraz někdo koupí (nebo naopak, sběratele trefil šlak, protože zničil vzácný obraz, který byl sice padělek, ale to on nevěděl).

543

Vývoj / Re:CSS selektor podle následujícího elementu

« kdy: 27. 07. 2020, 23:41:26 »

Myslel sem, ze tady se mluvi o "sourozencich" a ne predcich a potomcich.

Sorry za nepřesné vyjádření. Mnou zmiňované omezení se týká i sourozenců. Komponenta může přistupovat jen ke svému vnitřku. A hlavně mi šlo i to, že to omezení v případě komponent je ideové (technicky není problém tam hodit parenta), a tak jsem uvažoval nad tím, zda návrháři css neměli na mysli taky něco takového.

Rozumim a myslim, ze spis ne. Ale ruku do ohne za to nedam. Predpokladam, ze jde fakt o to "kupredu leva, zpatky ni krok".
Jestli si dobre vzpominam tak treba TeX to resi nekolika pruchody. Pri kazdem generuje krome ciloveho dokumentu taky nejaky metadata pro pristi pruchod. Takze jede porad jen od shora dolu a dokument je cim dal tim hezci a hezci....

OK :-)

544

Vývoj / Re:CSS selektor podle následujícího elementu

« kdy: 27. 07. 2020, 22:45:49 »

Myslel sem, ze tady se mluvi o "sourozencich" a ne predcich a potomcich.

Sorry za nepřesné vyjádření. Mnou zmiňované omezení se týká i sourozenců. Komponenta může přistupovat jen ke svému vnitřku. A hlavně mi šlo i to, že to omezení v případě komponent je ideové (technicky není problém tam hodit parenta), a tak jsem uvažoval nad tím, zda návrháři css neměli na mysli taky něco takového.

545

Vývoj / Re:CSS selektor podle následujícího elementu

« kdy: 27. 07. 2020, 17:33:12 »

By mě zajímalo, zda to byl záměr, nebo se to jen stalo.

Protože to trochu připomíná law of demeter. Když mám strom komponent, tak se mi taky osvědčilo, aby komponenta neviděla do předka, ale jen potomkům.

Jen taková úvaha.

546

Vývoj / Re:Změna pořadí prvků modelu nested set

« kdy: 27. 07. 2020, 17:20:17 »

1) Presouvane prvky oznacit pro tranzit odectenim od nuly

Ono používání záporného čísla nemusí být tak dobrý nápad, jak by se mohlo na první pohled zdát. Nemůžeš pak použít UNSIGNED, a díky tomu vlastně máš poloviční rozsah těch čísel (-2147483648..2147483647 na místo 0..4294967295). Třeba ti to nevadí, neříkám nic. Ale je dobré o tom vědět.

547

Hardware / Re:Jak zachránit disk

« kdy: 22. 07. 2020, 19:04:09 »

Imho je mrtev.

548

O serveru Root.cz / Re:Příliš rozšířený trolling na Root.cz - jednejte rychle!

« kdy: 19. 07. 2020, 00:05:37 »

Proc forum umoznuje zmenu prezdivky?

Tipnu si: nikoho nenapadlo, že bude někdo takhle škodit.

Na druhou stranu, pokud je nutné řešit takový problém, tak dotyčná komunita asi umřela, řekl bych.

549

O serveru Root.cz / Re:Příliš rozšířený trolling na Root.cz - jednejte rychle!

« kdy: 17. 07. 2020, 22:38:31 »

Vážená redakce, jakožto vážený a dlouholetý člen fora jsem zde ustavičně vystavován trollingu některých jeho členů. Situace již začíná být kritická. Musíme tento problém začít řešit, nejen stále nečinně přihlížet.

Obávám se, že to je dobou. Obávám se, že je to neřešitelný problém.

Zaujal jsem strategii, že nemám povinnost se bavit s každým, a některé obvzláště vypečené jedince ingoruji.

Faktem je, že málokdy mám užitek z toho, co se tu dozvím. Brodit se plevelem je náročné.

550

Vývoj / Re:Jak lingvisticky číst zdrojový program?

« kdy: 16. 07. 2020, 02:29:15 »

"V main funkci, mám konstantu MAX. Připravím si proměnné. Projdu v cyklu od nuly do MAX, a do každého prvku pole přidám součet a a b. Hej, kde jsem získal hodnoty a a b?!"

V druhé kole zkouknu typy, případně hodnoty konstant.

Ve třetím kole zkouknu jakého typu je volaná funkce, a že je to zrovna main.

551

Vývoj / Re:Dělení projektu v Rustu

« kdy: 04. 07. 2020, 21:51:09 »

Dělat to samostatně hned od začátku je ale i velká nevýhoda - v takovém projektu většinou změna jedné věci vyžaduje i změnu jinde. Mít to v 2 repozitářích by znamenalo, že by pro tu změnu museli být třeba 2 commity, pull requesty, atd... Velké projekty spíš volí opak, viz třeba LLVM, Chromium, atd...

To by se dalo částečně řešit použitím git submodules. Knihovna odděleně, ale zároveň jako submodul v hlavním projektu.

Já měl za to, že submoduly se prokázali jako slepá cesta. Používá to někdo intenzivněji?

552

Vývoj / Re:Jazyk nejvhodnější pro začátečníka v programování

« kdy: 23. 06. 2020, 15:02:39 »

http://carlcheo.com/wp-content/uploads/2014/12/which-programming-language-should-i-learn-first-infographic.png

Proč má C# obtížnost tři hvězdičky? Já bych mu dal stěží jednu...

553

Vývoj / Re:Jazyk nejvhodnější pro začátečníka v programování

« kdy: 23. 06. 2020, 15:00:49 »

To je ten typ trolla, co nahodí nesmyslné téma a pak už se baví, jak se lidi hádají.
Když jsem se v 15ti rozhodoval, co dál dělat, c++ byla jasná volba. No dneska už asi ne.

Já začal basicem na didaktiku gama (když pominu ten papírový ABC počítač), na PC pak jazykem C a dnes doporučuji začít Pythonem a po pochopení základů si rozšířit znalosti jazykem C. Pak už dotyčný budš schopen rozhodnout se sám, co dál.

Python na výuku docela dobrej. Ale C a C++ už IMHO nemá smysl. A šel bych rovnou do Rustu.

554

Vývoj / Re:Abstrakce u OOP

« kdy: 13. 06. 2020, 18:15:29 »

Možná bych se ještě doplnil, že často může pomoct využití kontextu, kdy třeba v rámci nějaké lokálního cyklu nebudu řešit, že ty elementy jsou třeba user, ale budu řešit jejich smysl pojmenování v rámci toho kontextu: first, tail, případně dokonce x v případě, kdy proměnná nemá žádný význam. Pak se někdy opravdu povede bez toho komentáře obejít.

555

Vývoj / Re:Abstrakce u OOP

« kdy: 13. 06. 2020, 17:15:40 »

To je docela zajímavý argument, to s tím C jako abstrakcí. Nevím jak ty (@Idris), ale když by si poprvé viděl konstrukci:

Kód: [Vybrat]

for (i=1;i<61 && feof(h);i++) {...}

Věděl by si co ta konstrukce for() {} dělá, jen na základě její samopopisnosti? Aniž by si znal konstrukci &&? Aniž by si znal co znamená EOF? etc?

Nevím, kam míříš, ale samozřejmě, že nevěděl. Stejně jako třeba ty asi nebudeš rozumět větě "Flyg vilda fågel, flyg du som kan".

A?

Že sice @Idris má pravdu v tom, že do nižších abstrakcí se nešťourá, na druhou stranu jen se samopopisností si nevystačím.

Když prostě nějakou hromadu asembleru nahradím za for() {} tak je to super, ale jen v případě, kdy někde vysvětlím, co ta konstrukce dělá. Jinak je to opravdu "Flyg vilda fågel, flyg du som kan".

Příklad s tím for je pěkný i v tom, že jasně ukazuje jak to zřejmě má fungovat. Jsou to tři písmenka, pro angličtináře nesou význam - což opět pomáhá. Ten význam sám o sobě nic nevysvětlí - na to je třeba nějaká definice, ale pomůže v tom se zorientovat. A hlavně jsou dostatečně krátká, aby nevznikal šum.

IMHO podobně by to tedy mělo fungovat i dál: pojmenování symbolu by mělo být krátké tak aby nevznikal šum, ale ne příliš, aby to člověku, který to bude číst pomohlo se v tom zorientovat - aby nemusel skákat na definici. A ta lidská definice tam musí být také, protože z toho vlastního pojmenování to obvykle stačit nebude - páč jinak by se to zvrhlo zase v dlouhý název, který bude ale zase nepříjemný na použití.