Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: headhunter 25. 08. 2017, 16:11:42
-
Nemáte pocit že aj programovacie jazyky / techniky podliehajú módnym trendom?
V 90 rokoch bolo in C++, Turbo Pascal, Delphi a najvačsiu slavu zažívala paradigma OOP spolu s jej nadstavbou komponentovým programovaním... Dobrý programátor musel vedieť C++, tí horší aspoň Object Pascal alebo Visual Basic. OOP z 90tych rokov, nemalo s dnešným ponímaním OOP veľa spoločné aj keď základ bol rovnaký.
Neskor prišla na scénu java. Každý považoval Javu za budúcnosť. Pretože bola multiplatformná. Java sa mala stať univerzálnym jazykom webu a java applety boly prvý pokus o RIA, mala sa presadiť nie len v PC ale aj v inteligentnych chladničkách práčkach a kosačkách, to sda jej síce nepodarilo ale presadila sa aspoň v podnikových aplikáciách.
Potom prišiel Microsoft s LINQ a začal tlačiť niektoré prvky FP do imperatívnych jazykov. Dnes tu máme revolúciu FP jazyky ako Swift, F#, Scala udávajú smer a imperatívne jazyky ich začínajú vykádať. Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
-
Nemáte pocit že aj programovacie jazyky / techniky podliehajú módnym trendom?
V 90 rokoch bolo in C++, Turbo Pascal, Delphi a najvačsiu slavu zažívala paradigma OOP spolu s jej nadstavbou komponentovým programovaním... Dobrý programátor musel vedieť C++, tí horší aspoň Object Pascal alebo Visual Basic. OOP z 90tych rokov, nemalo s dnešným ponímaním OOP veľa spoločné aj keď základ bol rovnaký.
Neskor prišla na scénu java. Každý považoval Javu za budúcnosť. Pretože bola multiplatformná. Java sa mala stať univerzálnym jazykom webu a java applety boly prvý pokus o RIA, mala sa presadiť nie len v PC ale aj v inteligentnych chladničkách práčkach a kosačkách, to sda jej síce nepodarilo ale presadila sa aspoň v podnikových aplikáciách.
Potom prišiel Microsoft s LINQ a začal tlačiť niektoré prvky FP do imperatívnych jazykov. Dnes tu máme revolúciu FP jazyky ako Swift, F#, Scala udávajú smer a imperatívne jazyky ich začínajú vykádať. Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
To není móda, ale vývoj. Za nějakých dvacet let tu bude zas něco jiného.
-
Nemáte pocit že aj programovacie jazyky / techniky podliehajú módnym trendom?
V 90 rokoch bolo in C++, Turbo Pascal, Delphi a najvačsiu slavu zažívala paradigma OOP spolu s jej nadstavbou komponentovým programovaním... Dobrý programátor musel vedieť C++, tí horší aspoň Object Pascal alebo Visual Basic. OOP z 90tych rokov, nemalo s dnešným ponímaním OOP veľa spoločné aj keď základ bol rovnaký.
Neskor prišla na scénu java. Každý považoval Javu za budúcnosť. Pretože bola multiplatformná. Java sa mala stať univerzálnym jazykom webu a java applety boly prvý pokus o RIA, mala sa presadiť nie len v PC ale aj v inteligentnych chladničkách práčkach a kosačkách, to sda jej síce nepodarilo ale presadila sa aspoň v podnikových aplikáciách.
Potom prišiel Microsoft s LINQ a začal tlačiť niektoré prvky FP do imperatívnych jazykov. Dnes tu máme revolúciu FP jazyky ako Swift, F#, Scala udávajú smer a imperatívne jazyky ich začínajú vykádať. Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
tys to tak shrnul clovece azs to uplne zabil ...
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Nenadává se na OOP, ale na programátory, kteří ho neumí a snaží se ho napodobovat.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
FP začali používat lidé, kteří nezvládli OOP. Je to tak správně, FP si zaslouží své místo na slunci.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
To je nesmysl, OOP se bez dědičnosti v pohodě obejde.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Nenadává se na OOP, ale na programátory, kteří ho neumí a snaží se ho napodobovat.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
FP začali používat lidé, kteří nezvládli OOP. Je to tak správně, FP si zaslouží své místo na slunci.
FP těží z módnosti teorie kategorií, na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
Má to zajímavé konotace například k otázce, zda když nějaká matematická teorie popisuje empirická data, zda objekty, které používá k popisu, taky existují v realitě a co to vlastně realita je. Například zda v molekule existují elektronové orbitaly v tvaru s jakými se počítá a operuje. Kategorie popisují realitu jinak, než množiny a objekty. Objekty v teorii kategorií jsou výsledkem nějakého chování, ne samostatné entity. Jsou tak trochu schované za to, jak se projevují. A to lépe odpovídá realitě, protože známe projevy reality, nikoliv její podstatu.
-
Dnes tu máme revolúciu FP jazyky ako Swift
Fakt ? :o
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
To je nesmysl, OOP se bez dědičnosti v pohodě obejde.
Skládání je selektivní ad hoc dědičnost. Vždy něco z vloženého objektu zveřejníte a zvenku se to pak jeví jako děděná vlastnost, děděná z vloženého objektu.
Existuje i v biologii - vložené objekty jsou mitochondrie.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
To je nesmysl, OOP se bez dědičnosti v pohodě obejde.
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
V javascriptu ano.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Nenadává se na OOP, ale na programátory, kteří ho neumí a snaží se ho napodobovat.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
FP začali používat lidé, kteří nezvládli OOP. Je to tak správně, FP si zaslouží své místo na slunci.
FP těží z módnosti teorie kategorií, na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
Má to zajímavé konotace například k otázce, zda když nějaká matematická teorie popisuje empirická data, zda objekty, které používá k popisu, taky existují v realitě a co to vlastně realita je. Například zda v molekule existují elektronové orbitaly v tvaru s jakými se počítá a operuje. Kategorie popisují realitu jinak, než množiny a objekty. Objekty v teorii kategorií jsou výsledkem nějakého chování, ne samostatné entity. Jsou tak trochu schované za to, jak se projevují. A to lépe odpovídá realitě, protože známe projevy reality, nikoliv její podstatu.
A to je hezky nahozená úvaha. Trochu osobní otázka, čemu se věnujete profesně? Opravdu mne to zajímá. Dík.
-
na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
OMG! Jako vystudovaný fyzik musím s politováním konstatovat, že plácáte naprosté nesmysly. Absolutně netušíte, která bije. Jste úplně mimo. Mícháte dohromady hrušky a králíky aniž byste navíc tušil, jak taková hruška či králík vypadá.
Možná by bylo rozumnější se vyjadřovat k něčemu, čemu alespoň náznakově rozumíte. Ne k něčemu, o čem si někde přečtete nějakou volovinu na nějakém pochybném blogu či esoterickém portálu. Tedy pokud to není nějaký váš vlastní myšlenkový průjem.
-
Dnes tu máme revolúciu FP jazyky ako Swift
Fakt ? :o
Swift má rysy FP, ale chybí mu výkonný typový systém. Až přidají typy vyšších řádů (už to je někde v bugtrackeru), bude to pejskokočičí mix Haskellu a ObjC.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Nenadává se na OOP, ale na programátory, kteří ho neumí a snaží se ho napodobovat.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
FP začali používat lidé, kteří nezvládli OOP. Je to tak správně, FP si zaslouží své místo na slunci.
FP těží z módnosti teorie kategorií, na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
Má to zajímavé konotace například k otázce, zda když nějaká matematická teorie popisuje empirická data, zda objekty, které používá k popisu, taky existují v realitě a co to vlastně realita je. Například zda v molekule existují elektronové orbitaly v tvaru s jakými se počítá a operuje. Kategorie popisují realitu jinak, než množiny a objekty. Objekty v teorii kategorií jsou výsledkem nějakého chování, ne samostatné entity. Jsou tak trochu schované za to, jak se projevují. A to lépe odpovídá realitě, protože známe projevy reality, nikoliv její podstatu.
To je trochu přitažené za vlasy, ale třeba v logice se KT používá, takový topos je zajímavá hračka pro matematiky. Nedělal bych si ale iluze, že se dostane do mainstreamu informatiky.
-
Ludia nadávajú na OOP dedičnosť je OUT a FP zažíva renesanciu.
Dědičnost je IN, pokud se používá správně. Bez ní by OOP nebylo prakticky použitelné.
To je nesmysl, OOP se bez dědičnosti v pohodě obejde.
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
-
Dnes tu máme revolúciu FP jazyky ako Swift
Fakt ? :o
Swift má rysy FP, ale chybí mu výkonný typový systém. Až přidají typy vyšších řádů (už to je někde v bugtrackeru), bude to pejskokočičí mix Haskellu a ObjC.
Osobne mam ze swiftu pocit, ze jsou to vykradene nejlepsi (nebo modni?) featury z ostatnich oop jazyku a par funkcionalnich konstruktu. Sam ovsem nic noveho neprinasi ani neposouva odvetvi nikam dal. Kdyby to neudeal Apple, tak by si toho nikdo ani nevsiml.
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
Je to objekt.
-
Dnes tu máme revolúciu FP jazyky ako Swift
Fakt ? :o
Swift má rysy FP, ale chybí mu výkonný typový systém. Až přidají typy vyšších řádů (už to je někde v bugtrackeru), bude to pejskokočičí mix Haskellu a ObjC.
Osobne mam ze swiftu pocit, ze jsou to vykradene nejlepsi (nebo modni?) featury z ostatnich oop jazyku a par funkcionalnich konstruktu. Sam ovsem nic noveho neprinasi ani neposouva odvetvi nikam dal. Kdyby to neudeal Apple, tak by si toho nikdo ani nevsiml.
Odvětví dál neposunul žádný jazyk od Lispu. Ono bohatě stačí mít všechny užitečné konstrukce v jednom jazyce, což Swift má. Nejlepší (ve smyslu elegance a bezpečnosti kódu) jsou v něm analogie typových tříd. Jiná otázka je, kde běží, až se stabilizuje ABI, mohl by být swiftí runtime součástí Linuxů (což je momentálně hudba budoucnosti).
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
Je to objekt.
Podle způsobu použití má typ blíže ke třídám, nemyslíš? Pokud bys chtěl 2 takové objekty, tak použiješ struct jen 1×, jinak bys mezi nimi nemohl provést ani přiřazení.
-
Doporučil bych podívat se na Perl 6. Ten jazyk je dostatečně flexibilní, aby šel ohnout pro jakékoliv paradigma, které bude zrovna v módě.
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
Je to objekt.
Podle způsobu použití má typ blíže ke třídám, nemyslíš? Pokud bys chtěl 2 takové objekty, tak použiješ struct jen 1×, jinak bys mezi nimi nemohl provést ani přiřazení.
Nemyslím, ale jde jen o terminologii, já se držím teorie kategorií, když už se tu s ní začalo. Čili ten kus kódu definuje nějaký objekt a když implemenuju nějaký algoritmus, můžu mezi instancemi objektů posílat zprávy, tudíž mám z definice OO program v OO jazyce. Akorát to posílání se většinou jmenuje volání funkce/metody.
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
Je to objekt.
Podle způsobu použití má typ blíže ke třídám, nemyslíš? Pokud bys chtěl 2 takové objekty, tak použiješ struct jen 1×, jinak bys mezi nimi nemohl provést ani přiřazení.
Nemyslím, ale jde jen o terminologii, já se držím teorie kategorií, když už se tu s ní začalo. Čili ten kus kódu definuje nějaký objekt a když implemenuju nějaký algoritmus, můžu mezi instancemi objektů posílat zprávy, tudíž mám z definice OO program v OO jazyce. Akorát to posílání se většinou jmenuje volání funkce/metody.
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
-
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Ano, je to typ. Je typ třídou nebo objektem?
Fakt, že se denně setkávám s chybně použitou dědičností, vůbec neznamená, že by na dědičnosti samotné bylo něco špatně. Když někdo poruší LSP, tak to samozřejmě špatně je.
Je to objekt.
Podle způsobu použití má typ blíže ke třídám, nemyslíš? Pokud bys chtěl 2 takové objekty, tak použiješ struct jen 1×, jinak bys mezi nimi nemohl provést ani přiřazení.
Nemyslím, ale jde jen o terminologii, já se držím teorie kategorií, když už se tu s ní začalo. Čili ten kus kódu definuje nějaký objekt a když implemenuju nějaký algoritmus, můžu mezi instancemi objektů posílat zprávy, tudíž mám z definice OO program v OO jazyce. Akorát to posílání se většinou jmenuje volání funkce/metody.
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
To je úplně jedno, objekt to je i bez metod. Klidně může být imutabilní.
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
C++ struktura muze mit klidne i metody.
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
To je úplně jedno, objekt to je i bez metod. Klidně může být imutabilní.
Jak tedy nastavíš hodnotu atributu tohoto imutabilního objektu na 42? Bez instanciace to podle mne asi nepůjde. V tom případě ale tvůj objekt "A" není objektem, ale třídou.
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
C++ struktura muze mit klidne i metody.
To souhlasí, ale jak nastavíš či změníš hodnotu atributu "x" ve struktuře "A" třeba i nějakou metodou? Jde to vůbec nebo ten atribut "x" je nutné označit jako static?
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
To je úplně jedno, objekt to je i bez metod. Klidně může být imutabilní.
Jak tedy nastavíš hodnotu atributu tohoto imutabilního objektu na 42?
Od toho je (typový) konstruktor.
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
To je úplně jedno, objekt to je i bez metod. Klidně může být imutabilní.
Jak tedy nastavíš hodnotu atributu tohoto imutabilního objektu na 42?
Od toho je (typový) konstruktor.
No vida, takže struct se nechová jako objekt, ale jako (typová) třída.
-
Nevidím žádnou metodu a ani nevidím atribut, do kterého by se dala uložit nějaká hodnota. Jak vypadá zápis změny stavu u takového objektu? A.x = 42; nebo jak?
To je úplně jedno, objekt to je i bez metod. Klidně může být imutabilní.
Jak tedy nastavíš hodnotu atributu tohoto imutabilního objektu na 42?
Od toho je (typový) konstruktor.
No vida, takže struct se nechová jako objekt, ale jako (typová) třída.
Typová třída je něco úplně jiného, ta nemůže mít instance. Radši opusť C++ a přeber si to v Go, tam se objekty definují pomocí “struct” a jsou polymorfní, takže máš OO jazyk bez dědičnosti (akorát nemá typové třídy à la Haskell).
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
-
No vida, takže struct se nechová jako objekt, ale jako (typová) třída.
Typová třída je něco úplně jiného, ta nemůže mít instance. Radši opusť C++ a přeber si to v Go, tam se objekty definují pomocí “struct” a jsou polymorfní, takže máš OO jazyk bez dědičnosti (akorát nemá typové třídy à la Haskell).
Já si s C++ nezačal. Bavili jsme se o dědičnosti v OOP a ty ses vytasil s C++, který s OOP moc nesouvisí a proto ani nepotřebuje dědičnost.
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Za pár let budou pro děti monády a nelopaty budou řešit co? Toposy? :)
-
No vida, takže struct se nechová jako objekt, ale jako (typová) třída.
Typová třída je něco úplně jiného, ta nemůže mít instance. Radši opusť C++ a přeber si to v Go, tam se objekty definují pomocí “struct” a jsou polymorfní, takže máš OO jazyk bez dědičnosti (akorát nemá typové třídy à la Haskell).
Já si s C++ nezačal. Bavili jsme se o dědičnosti v OOP a ty ses vytasil s C++, který s OOP moc nesouvisí a proto ani nepotřebuje dědičnost.
Bez použití dědičnosti nenapíšeš ani jednu třídu či objekt.
Zajímavé tvrzení, ale zcela mimo. Už jen “struct A { int x }” je typ a dědičnost nikde nepotřebuje. OOP totiž není o dědičnosti.
Hlavně, že jsme si ujasnili, že OOP nepotřebuje dědičnost.
-
Hlavně, že jsme si ujasnili, že OOP nepotřebuje dědičnost.
C++ nepotřebuje dědičnost, zapouzdření a ani polymorfismus.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
jenze to napsal Paul Graham, clovek co nanejvic miluje Lisp a ... Perl. Neni duvod se kvuli tomu rozcilvoat.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Většina. Takže je vůbec nějaký důvod použít je místo Lispu?
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Většina. Takže je vůbec nějaký důvod použít je místo Lispu?
Je, protože ty jazyky umí i jiné věci, které (Common) Lisp neumí, jsou pro většinu lidí lépe čitelné a umožnǔjí stručnější zápis. To co se píše v tom článku jako výhody Lispu, bylo cool možná v 80-tých letech.
-
A jsou ty jiné věci skutečně přínosem, nebo je to jen módní pozlátko?
-
na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
OMG! Jako vystudovaný fyzik musím s politováním konstatovat, že plácáte naprosté nesmysly. Absolutně netušíte, která bije. Jste úplně mimo. Mícháte dohromady hrušky a králíky aniž byste navíc tušil, jak taková hruška či králík vypadá.
Možná by bylo rozumnější se vyjadřovat k něčemu, čemu alespoň náznakově rozumíte. Ne k něčemu, o čem si někde přečtete nějakou volovinu na nějakém pochybném blogu či esoterickém portálu. Tedy pokud to není nějaký váš vlastní myšlenkový průjem.
Ptolemaiův i Koperníkův systém pohybu planet empirická data vysvětlují obojí zhruba stejně nepřesně. Máte dva matematické modely, které popisují empirická data stejně dobře. Které části těch modelů jsou reálné, když to jinak zjistit na aktuální úrovni poznání nejde. Když v modelu existuje nějaký objekt, znamená to, že taková je i realita?
Fyzik realista řekne ano. Ale je to založeno na víře, že tomu tak je.
A kvantový chemik ví, že pracuje s modely orbitalů, jaké se v realitě nevyskytují a přesto je schopen na základě operování s nimi spočítat energetické poměry v molekulách, používají se tvary jaké jsou v atomu vodíku i pro jiné atomy. Matematicky by to vyšlo i s jinými funkcemi.
AI bude vytvářet vlastní modely, které budou interpretovat empirická data, objekty z nich ale nebudou v realitě existovat.
Něco podobného se už stalo, když se AI učila překládat z jednoho do dvou jazyků, vytvořila si vlastní metajazyk, který zcela jistě obsahoval metapojmy, které zahrnovaly sémantický obsah pojmů z obou jazyků a překládala nejdříve do toho metajazyka a z něj do cílového, přitom se naučila překládat přímo mezi cílovými jazyky, aniž by k tomu byla trénována.
Zajímavé pak bude studovat ten metajazyk, ten bude konstituovat v podstatě vlastní svět, s vlastními vztahy, které v realitě nebudou muset existovat, překlad přitom bude sémanticky korektní. Jinak by nebyl možný správný překlad mezi cílovými jazyky, protože každý jazyk do jisté míry trochu jinak sémanticky vymezuje vztahy ale i objekty.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Většina. Takže je vůbec nějaký důvod použít je místo Lispu?
Alan Kay se kdysi vyjádřil v tom smyslu, že tak jako má elektrotechnika Maxwellovy rovnice, tak Computer Science má LISP. V podstatě by budoucí elektrotechniky stačilo naučit matematiku a Maxwellovy rovnice, protože vše ostatní už z nich plyne. V praxi to tak bohužel moc nefunguje ani s maxwellkami, ani s Lispem. Ne, že by to nešlo. Ale problémem je lidský faktor.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Většina. Takže je vůbec nějaký důvod použít je místo Lispu?
Alan Kay se kdysi vyjádřil v tom smyslu, že tak jako má elektrotechnika Maxwellovy rovnice, tak Computer Science má LISP. V podstatě by budoucí elektrotechniky stačilo naučit matematiku a Maxwellovy rovnice, protože vše ostatní už z nich plyne. V praxi to tak bohužel moc nefunguje ani s maxwellkami, ani s Lispem. Ne, že by to nešlo. Ale problémem je lidský faktor.
No spíš by to bylo zdlouhavé, všechno si odvozovat stále znovu a nemuselo by vás napadnout, že z Maxwellových rovnic plyne, že vně koaxiálního kabelu není známo nic o průběhu elektromagnetického pole uvnitř.
Všechny programovací jazyky jsou de facto univerzální lisp, ale zdrcnutý do specializovaných konstrukcí.
-
http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html (http://kuna4.mk.cvut.cz/36jui/PomstaNerdu.html)
článek z devadesátých let. Dnešní nerdi řeší monády. Lisp je pro děti a lopaty. Většina těch popisovaných featur Lispu je dnes naprosto běžná v mainstreamových jazycích. Perl 6 umí vše z těch bodů 1 - 9 a mnohem víc.
Většina. Takže je vůbec nějaký důvod použít je místo Lispu?
Alan Kay se kdysi vyjádřil v tom smyslu, že tak jako má elektrotechnika Maxwellovy rovnice, tak Computer Science má LISP. V podstatě by budoucí elektrotechniky stačilo naučit matematiku a Maxwellovy rovnice, protože vše ostatní už z nich plyne. V praxi to tak bohužel moc nefunguje ani s maxwellkami, ani s Lispem. Ne, že by to nešlo. Ale problémem je lidský faktor.
V exaktních vědách to je vždy matematika + něco. Ovšem vidět podstatné souvislosti, k tomu se musí člověk dopracovat.
-
Na první pohled jsem v přehledu témat četl "Programovanie a modre trenky" a vůbec mi to nepřišlo divné...
Tak mě tak napadá, zda programování v modných trenkách splňuje současné módní trendy...
-
A jsou ty jiné věci skutečně přínosem, nebo je to jen módní pozlátko?
Za módní pozlátko se dá označit cokoliv, i ten Lisp. Objektivně, jiné jazyky umožňují psát stručnější kód, který má blíž ke konvenčnímu matematickému zápisu (infixová notace).
-
V exaktních vědách to je vždy matematika + něco. Ovšem vidět podstatné souvislosti, k tomu se musí člověk dopracovat.
Paradoxně někdy ta matematika z toho dělá neexaktní vědu, když se interpretují matematické struktury, které se v realitě nevyskytují, jako by existovaly :-)))
-
na teorii kategorií se například předělává celá fyzika, motivací k zavedení teorie kategorií bylo, nepohlížet na realitu skrze objekty, i když nakonec jakési objekty jsou i v teorii kategorií, taky snaha zbavit se množin. Jde o nové paradigma, kdy na atom, nebo elektron se nepohlíží jako na kuličku, ale jako na nějakou funkci. Což je docela zajímavé, protože to mění běžné představy o konstrukci hmoty.
OMG! Jako vystudovaný fyzik musím s politováním konstatovat, že plácáte naprosté nesmysly. Absolutně netušíte, která bije. Jste úplně mimo. Mícháte dohromady hrušky a králíky aniž byste navíc tušil, jak taková hruška či králík vypadá.
Možná by bylo rozumnější se vyjadřovat k něčemu, čemu alespoň náznakově rozumíte. Ne k něčemu, o čem si někde přečtete nějakou volovinu na nějakém pochybném blogu či esoterickém portálu. Tedy pokud to není nějaký váš vlastní myšlenkový průjem.
Ptolemaiův i Koperníkův systém pohybu planet empirická data vysvětlují obojí zhruba stejně nepřesně. Máte dva matematické modely, které popisují empirická data stejně dobře. Které části těch modelů jsou reálné, když to jinak zjistit na aktuální úrovni poznání nejde. Když v modelu existuje nějaký objekt, znamená to, že taková je i realita?
Fyzik realista řekne ano. Ale je to založeno na víře, že tomu tak je.
Fyzik, narozdíl od vás, především chápe rozdíl mezi kinematikou a dynamikou. Kinematika nic nevysvětluje, pouze popisuje. Ani jeden z těch systémů pohyb planet nevysvětluje, jak se mylně domníváte, ale oba jej pouze popisují. Liší se pouze počátkem souřadnic. Zatímco starší za něj volí celkem logicky pozorovatele, novější volí (opět celkem logicky) takový bod, aby byl matematický popis co nejjednodušší, tj. Slunce, resp. těžiště Sluneční soustavy. Přejít od jednoho systému k druhému lze prostou transformací souřadnic.
Pomocí kinematiky rozhodnout nejde, to víme dnes stejně dobře, jako to věděli tenkrát. Heliocentristé byli v té době vedeni spíše intuicí, principem Occamovy břitvy, že realitě bude nejspíš odpovídat ten model, který je matematicky jednodušší. Jinými slovy - proč věřit tomu, že středem Vesmíru je Země, kolem níž obíhá Měsíc a Slunce a kolem Slunce ostatní planety, potažmo celý Vesmír, když model se Sluncem uprostřed je mnohem symetričtější a jednodušší? Ovšem důkaz to není. Ten přinesla až dynamika, před kterou už musela rezignovat i církev. Jakmile byla na stole teorie působení gravitace, bylo zřejmé, že geocentrický model nemůže odpovídat realitě, protože je s touto teorií v rozporu, narozdíl od modelu heliocentrického, který do ní krásně zapadal.
A kvantový chemik ví, že pracuje s modely orbitalů, jaké se v realitě nevyskytují a přesto je schopen na základě operování s nimi spočítat energetické poměry v molekulách, používají se tvary jaké jsou v atomu vodíku i pro jiné atomy. Matematicky by to vyšlo i s jinými funkcemi.
A co? Objevujete Ameriku. V kvantovce jde o poznatek starý víc než 80 let, v klasické fyzice nějakých 200 let (diferenciální vs. integrální přístup): různé matematické konstrukce dávající stejné výsledky při popisu jedné a té samé reality. Že se něčemu říká orbitaly je dáno historicky, protože to tak kdysi pojmenoval Bohr. Jestli v tom hledáte něco víc a přicházíte na to, že reálně tam asi žádné elektrony nekolotají kol dokola jako planety, tak vězte, že to fyzici vědí už dávno.
Ostatně i Maxwell používal při popisu elektromagnetického pole jiné konstrukce, než používáme dnes. V jeho modelu založeném na kvaternionové algebře těch rovnic bylo poněkud víc než současné vektorově-analytické 4 (nebo dokonce jediná za použití relativistického tenzorového počtu), používal pojmy jako "proudová trubice", zatímco současné "siločáry" nikoli. Ale snad nikoho by nenapadlo, že ta proudová trubice nebo siločára je nějaký existující objekt! Nebo vás snad ano?
-
<Trololo>
Programovanie a modne trendy?
Letos myslím programátoři nosí plnovous a šálu. ;D
</Trololo>
-
..., používal pojmy jako "proudová trubice", zatímco současné "siločáry" nikoli. Ale snad nikoho by nenapadlo, že ta proudová trubice nebo siločára je nějaký existující objekt! Nebo vás snad ano?
Když vezmu v potaz kvantovou mechaniku, tak ano, ty siločáry si představuji jako objekty. Dokonce podle definice života by mohly být považovány i za živé.
-
<Trololo>
Programovanie a modne trendy?
Letos myslím programátoři nosí plnovous a šálu. ;D
</Trololo>
+1
:-D
-
A jsou ty jiné věci skutečně přínosem, nebo je to jen módní pozlátko?
Za módní pozlátko se dá označit cokoliv, i ten Lisp. Objektivně, jiné jazyky umožňují psát stručnější kód, který má blíž ke konvenčnímu matematickému zápisu (infixová notace).
Konvenční matematický zápis používá současně prefixový, infixový i postfixový zápis, klidně i v jednom vzorečku. K tomu ještě hromadu dalších forem zápisu (horní či dolní index, integrál, zlomek, odmocnina,...) Lisp to sjednotil na prefixový zápis, Forth na postfixový. Ostatní programovací jazyky pro zápis používají guláš, každý trochu jiný. Když k tomu přidáme odlišnou syntaxi L-výrazů a R-výrazů, je dokonalý.
-
Všechny programovací jazyky jsou de facto univerzální lisp, ale zdrcnutý do specializovaných konstrukcí.
To je naprosto pravda, vite kolik stran ma referencni prirucka napr. Javy nebo C++, swiftu, plna specializovanych konstrukci? Stovky stran.
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
-
Všechny programovací jazyky jsou de facto univerzální lisp, ale zdrcnutý do specializovaných konstrukcí.
To je naprosto pravda, vite kolik stran ma referencni prirucka napr. Javy nebo C++, swiftu, plna specializovanych konstrukci? Stovky stran.
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
Navíc se většina aplikací, napsaných v jiných jazycích než Lispu, musí při upgrade restartovat...
-
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
ty čtyři řádky bych chtěl vidět. Můžete je sem postnout?
-
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
ty čtyři řádky bych chtěl vidět. Můžete je sem postnout?
1. syntax: ()
2. call convention: (fun param1 param2)
3. Do not evaluate: quote '
4. list: '(a b c)
Tak a ted umis Lisp, uzivej to moudre.
-
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
ty čtyři řádky bych chtěl vidět. Můžete je sem postnout?
1. syntax: ()
2. call convention: (fun param1 param2)
3. Do not evaluate: quote '
4. list: '(a b c)
Tak a ted umis Lisp, uzivej to moudre.
tak to neni referencni prirucka. Podle toho nic nenaprogramujete.
-
tak to neni referencni prirucka. Podle toho nic nenaprogramujete.
Jaktoze ne?
(+ 1 2) je funkce, validni a spustitelny kod a zaroven je to i cely program, ze ktereho se da vygenerovat binarka. Operatory jsou to stejne co funkce.
-
Vite kolik ma stran referencni prirucka Lispu? Ctyri radky.
ty čtyři řádky bych chtěl vidět. Můžete je sem postnout?
1. syntax: ()
2. call convention: (fun param1 param2)
3. Do not evaluate: quote '
4. list: '(a b c)
Tak a ted umis Lisp, uzivej to moudre.
V dobrem si trosku rypnu: mozna namisto toho posledniho staci dat tecka dvojici. Ale ano, cely LISP je mozne popsat na par radcich. Referencni prirucka by mohla zminit i priklad konkretni UPLNE implementace, coz se pet funkci a tri specialni formy:
funkce: CAR, CDR, CONS, EQ, ATOM
formy: COND, LAMBDA, QUOTE
-
C#, Java, Angular, CSS, JS, HTML to su modne trendy, nie tie kecy co tu maju ludia, ktori tu neustale melu o Haskell, Prolog, Lisp, atd.
-
C#, Java, Angular, CSS, JS, HTML to su modne trendy, nie tie kecy co tu maju ludia, ktori tu neustale melu o Haskell, Prolog, Lisp, atd.
HTML bych jako módní trend moc neoznačoval. Přežil XHTML a bude tady ještě hodně dlouho poté, co ostatní módní trendy zaniknou.
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
A jsou ty jiné věci skutečně přínosem, nebo je to jen módní pozlátko?
Za módní pozlátko se dá označit cokoliv, i ten Lisp. Objektivně, jiné jazyky umožňují psát stručnější kód, který má blíž ke konvenčnímu matematickému zápisu (infixová notace).
Takže nejlepší je teda obfuskovaný Perl? ;D
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Asi tak :D
Ale do toho lidského faktoru bych klidně zahrnul i sebe. Se znalostí Ohmova zákona, Kirchhoffových zákonů a pár dalších blbostí se dá navrhnout třeba zesilovač, ale od maxwellek je k tomu samému zesilovači ještě dlouhá míle. Jako student jsem bez problému uměl maxwellky dostat třeba do podoby vlnové rovnice, dnes však bych to bez nějakého taháku už nedal. Ale ten zesilovač zvládnu pořád.
U LISPu by tomu asi odpovídaly takové ty hračky jako napsat cons, car a cdr jen s pomocí lambdy apod. Nebo hračky... U maxwellek člověk na vlastní oči pozná, že ta fyzika fakt funguje a že ten na první pohled košatý strom různých jevů spojených s elektřinou a magnetismem je fakt celý založen na čtyřech jednoduchých pravidlech a kalibrační podmínce, u LISPu zase, že mi fakt stačí lambda počet, abych tím vyjádřil cokoli, včetně dat.
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot. Smysl bych viděl v tom, že ačkoli to asi nebude takto v praxi používat, ovlivní to způsob jeho uvažování, motivuje ho to hledat nějaké abstraktnější principy v momentech, kdy to vypadá, že nějaký problém je nějak moc fragmentovaný, že ten samý problém se dá uchopit i jinak, úplně jinak, když prvoplánové řešení selhává.
Přístupem "tu más maxwellky, takto se s nimi pracuje, a teď umíš celou elektrotechniku", nebo "tu máš LISP a teď dokážeš vše" by se počet lidí v těchto oborech, kteří by dokázali něco vytvořit, smrsknul na zlomek a poptávku produktů těchto odvětví by nedokázali nasytit ani náznakem. Pravda je, že dnešní situace je spíš opačná, což IMHO taky není dobře, ale pořád je to lepší než ta první varianta. ;)
-
..., používal pojmy jako "proudová trubice", zatímco současné "siločáry" nikoli. Ale snad nikoho by nenapadlo, že ta proudová trubice nebo siločára je nějaký existující objekt! Nebo vás snad ano?
Když vezmu v potaz kvantovou mechaniku, tak ano, ty siločáry si představuji jako objekty. Dokonce podle definice života by mohly být považovány i za živé.
Lidi nepochopěj ani středoškolskou fyziku, ale blábolej o kvantovce nebo relativitě a ještě do toho namotaj "definici života". Radši no comment.
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot.
Takových principů bývá v různých oborech povícero, co třeba obecná teorie relativity se svou diferenciální geometrií? Proti tomu jsou ostatně λ kalkulus nebo teorie kategorií dětská hra (možná proto fyzici obecně nemívají s programováním problémy...).
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
Objekty existují i ve FP, co jiného jsou algebraické datové typy? Je tam ad-hoc i parametrický polymorfismus a protokoly v takovém rozsahu, že mnohé OO jazyky by mohly závidět.
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot.
Takových principů bývá v různých oborech povícero, co třeba obecná teorie relativity se svou diferenciální geometrií? Proti tomu jsou ostatně λ kalkulus nebo teorie kategorií dětská hra (možná proto fyzici obecně nemívají s programováním problémy...).
Když se někdo rozhodne studovat fyziku, má to štěstí, že takových principů pozná více, to dá rozum. :) Proto se na tak hloupou otázku, nač jít studovat fyziku, k čemu se to v praxi bude hodit, tak těžko odpovídá někomu, kdo zatím nepoznal...
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot.
Takových principů bývá v různých oborech povícero, co třeba obecná teorie relativity se svou diferenciální geometrií? Proti tomu jsou ostatně λ kalkulus nebo teorie kategorií dětská hra (možná proto fyzici obecně nemívají s programováním problémy...).
Když se někdo rozhodne studovat fyziku, má to štěstí, že takových principů pozná více, to dá rozum. :) Proto se na tak hloupou otázku, nač jít studovat fyziku, k čemu se to v praxi bude hodit, tak těžko odpovídá někomu, kdo zatím nepoznal...
To není hloupá otázka, člověk těsně před maturitou si ji může klást zcela legitimně. Hloupé je “studovat” softwarové inženýrství a pak se divit, že kdejaký fyzik nebo lingvista píše lepší kód. Ale to odbočuji...
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
Objekty existují i ve FP, co jiného jsou algebraické datové typy? Je tam ad-hoc i parametrický polymorfismus a protokoly v takovém rozsahu, že mnohé OO jazyky by mohly závidět.
Ano, ale ty se projeví jen v interakci, ve vztahu, neexistuji v "klidu", objekt z OOP naopak, s ním pracujete v "klidu", uchopíte ho sám o sobě, a nezajímáte se o jeho interakci s okolím, není definován okolím, naopak, on svým rozhraním ty reakce okolí definuje, objekt konstruujete bez nutné znalosti okolí.
Mě se líbí oba principy, každý se hodí na něco jiného.
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
Objekt existuje, pokud se projevuje. Jaká je jeho vnitřní struktura nebo reálná podoba je vedlejší. Objekt pojmenovaný "atom" má vlastnosti jemu přisuzované a projevuje se v souladu se svým matematickým popisem. Popsán je vlnovou funkcí - ta v realitě neexistuje, je to jen abstraktní objekt. Ale objekt, který je jí modelován, tj. atom, se objektivně a konkrétně projevuje v reálném světě. Pokud jsme k jeho popisu a modelování použili vlnovou funkci a pozorovatelné veličiny, jak je chápe kvantová fyzika, pak samozřejmě budeme sledovat tyto veličiny a konstruovat přístroje, kterými je budeme schopni měřit a nějak názorně zobrazit, tj. interpretovat. Jestli atom vypadá jako kulička, jako mrak, či nemá konkrétní podobu, jak ji chápeme v makrosvětě, je vedlejší. Podstatné je, že ho dokážeme registrovat, změřit veličiny, jež zachycují jeho stav a modelovat jeho chování ve smyslu těchto veličin. Je ale nezbytné si uvědomovat, že pojmenování těch veličin mohou poněkud mást, opět z historických důvodů. U těch nověji objevených, jako je třeba podivnost, snad už nikoho nenapadne si pod tím představovat něco konkrétního. To ovšem neznamená, že podivnost jakožto vlastnost neexistuje. Ani že existuje. Náš model elementárních částic ji vyžaduje. Jiný třeba ne. Ovšem elementární částice sama je objektem, který se navenek projevuje a svými vlastnostmi a projevy odlišuje např. od těch atomů, ale přitom s tím atomem souvisí kompozičně. Nevíme jak ve skutečnosti vypadá, protože "vypadat" je dost makroskopický pojem. Ale liší se a projevuje se.
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
To je jak představovat si čtyřrozměrnou krychli. Taky má hrany a stěny, úhly mezi nimi, ale "vypadá" úplně jinak. Mozkem, který pojem "vypadat" chápe trojrozměrně a navíc makroskopicky, je těžké takový objekt zařadit. To ale neznamená, že by ve čtyřrozměrném světě takový objekt nemohl existovat. Dokázali bychom ho změřit a vypočítat jeho objem. Ale představit si ho jako krychličku by nebylo správné, nicméně pokud by se takový objekt projevoval jako čtyřrozměrná krychle, nic by nám nebránilo ho modelovat matematickým objektem "čtyřrozměrná krychle". Bez ohledu na to, jak by skutečně "vypadal".
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
Objekty existují i ve FP, co jiného jsou algebraické datové typy? Je tam ad-hoc i parametrický polymorfismus a protokoly v takovém rozsahu, že mnohé OO jazyky by mohly závidět.
Ano, ale ty se projeví jen v interakci, ve vztahu, neexistuji v "klidu", objekt z OOP naopak, s ním pracujete v "klidu", uchopíte ho sám o sobě, a nezajímáte se o jeho interakci s okolím, není definován okolím, naopak, on svým rozhraním ty reakce okolí definuje, objekt konstruujete bez nutné znalosti okolí.
Mě se líbí oba principy, každý se hodí na něco jiného.
No nevím, algebraické typy jsou dostatečně uchopitelné a v podstatě mezi nimi a objekty v OOP existuje isomorfismus.
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot.
Takových principů bývá v různých oborech povícero, co třeba obecná teorie relativity se svou diferenciální geometrií? Proti tomu jsou ostatně λ kalkulus nebo teorie kategorií dětská hra (možná proto fyzici obecně nemívají s programováním problémy...).
Když se někdo rozhodne studovat fyziku, má to štěstí, že takových principů pozná více, to dá rozum. :) Proto se na tak hloupou otázku, nač jít studovat fyziku, k čemu se to v praxi bude hodit, tak těžko odpovídá někomu, kdo zatím nepoznal...
To není hloupá otázka, člověk těsně před maturitou si ji může klást zcela legitimně. Hloupé je “studovat” softwarové inženýrství a pak se divit, že kdejaký fyzik nebo lingvista píše lepší kód. Ale to odbočuji...
To "hloupá" mělo být v uvozovkách. "Hloupá" otázka je třeba i proč jablko padá k zemi nebo proč jedna a jedna jsou dvě. Ale umět na to odpovědět je vlastně dost těžké, když tazatel neví nic o fyzice nebo matematice. Prostě hloupá spíš ve smyslu elementární, jako v algebře, když se zkoumá, jestli a+b je b+a, nebo zda daná struktura obsahuje opravdu právě jednu nulu.
-
@ Kiwi
Existují atomy? V našem matematickém popisu ano, v našich představách taky, ale v realitě? Obraz reality si přece skládáme sami, z empiricky naměřených dat. Pokud tedy předpokládáme, že atomy existují, tak zkonstruujeme "elektronový" mikroskop, který je uvidí. Ale existují reálně, není ten obraz jen výsledkem naší interpretace empirických dat, protože máme takovou úvodní představu?
http://technet.idnes.cz/zobrazeni-vazeb-mezi-atomy-v-molekule-mikroskop-ibm-afm-pj8-/veda.aspx?c=A120926_172743_veda_pka
V OOP objekty existují, v FP se bez nich obejdeme, který popis lépe odpovídá realitě. Realita se skládá z objektů a nebo kategorií? Každý z nich nám otevře trochu jiný pohled na realitu. Moderní trendy programování nejsou jen o efektivitě programování, ale taky o objevování nových aspektů reality, nebo nových aspektů, které si do té reality jen promítáme.
Objekt existuje, pokud se projevuje. Jaká je jeho vnitřní struktura nebo reálná podoba je vedlejší. Objekt pojmenovaný "atom" má vlastnosti jemu přisuzované a projevuje se v souladu se svým matematickým popisem. Popsán je vlnovou funkcí - ta v realitě neexistuje, je to jen abstraktní objekt. Ale objekt, který je jí modelován, tj. atom, se objektivně a konkrétně projevuje v reálném světě. Pokud jsme k jeho popisu a modelování použili vlnovou funkci a pozorovatelné veličiny, jak je chápe kvantová fyzika, pak samozřejmě budeme sledovat tyto veličiny a konstruovat přístroje, kterými je budeme schopni měřit a nějak názorně zobrazit, tj. interpretovat. Jestli atom vypadá jako kulička, jako mrak, či nemá konkrétní podobu, jak ji chápeme v makrosvětě, je vedlejší. Podstatné je, že ho dokážeme registrovat, změřit veličiny, jež zachycují jeho stav a modelovat jeho chování ve smyslu těchto veličin. Je ale nezbytné si uvědomovat, že pojmenování těch veličin mohou poněkud mást, opět z historických důvodů. U těch nověji objevených, jako je třeba podivnost, snad už nikoho nenapadne si pod tím představovat něco konkrétního. To ovšem neznamená, že podivnost jakožto vlastnost neexistuje. Ani že existuje. Náš model elementárních částic ji vyžaduje. Jiný třeba ne. Ovšem elementární částice sama je objektem, který se navenek projevuje a svými vlastnostmi a projevy odlišuje např. od těch atomů, ale přitom s tím atomem souvisí kompozičně. Nevíme jak ve skutečnosti vypadá, protože "vypadat" je dost makroskopický pojem. Ale liší se a projevuje se.
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
To je jak představovat si čtyřrozměrnou krychli. Taky má hrany a stěny, úhly mezi nimi, ale "vypadá" úplně jinak. Mozkem, který pojem "vypadat" chápe trojrozměrně a navíc makroskopicky, je těžké takový objekt zařadit. To ale neznamená, že by ve čtyřrozměrném světě takový objekt nemohl existovat. Dokázali bychom ho změřit a vypočítat jeho objem. Ale představit si ho jako krychličku by nebylo správné, nicméně pokud by se takový objekt projevoval jako čtyřrozměrná krychle, nic by nám nebránilo ho modelovat matematickým objektem "čtyřrozměrná krychle". Bez ohledu na to, jak by skutečně "vypadal".
Když už se tu s tím začalo, zajímalo by mě, jak si lidi představují spin :)
-
@ kiwi
No ale zrovna ve fyzice dost dlouho a dobře fungoval pojem éteru. A to se ukázalo na nějakou dobu jako umělý konstrukt bez odrazu v realitě.
A nebo když se zadíváte do obrázku šumu, tak v něm možná uvidíte na malém kousku obličej. Jestli to není tak, že matematický model si z toho empirického šumu vybere zrovna to co potřebuje. Když to bude vyhovovat experimentům, tak to budeme považovat za realitu.
-
Copak éter, ale legendární flogiston... ;D
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
-
... Ne, že by to nešlo. Ale problémem je lidský faktor.
Znamená ten lidský faktor, že to ti matlalové nedokážou ani pochopit, natož pak správně použít?
Myslím si, že každý odborník by měl, každý ve svém oboru, nějaký takový princip poznat a pohrát si s ním, jinak to nebude žádný odborník, ale fachidiot.
Takových principů bývá v různých oborech povícero, co třeba obecná teorie relativity se svou diferenciální geometrií? Proti tomu jsou ostatně λ kalkulus nebo teorie kategorií dětská hra (možná proto fyzici obecně nemívají s programováním problémy...).
Když se někdo rozhodne studovat fyziku, má to štěstí, že takových principů pozná více, to dá rozum. :) Proto se na tak hloupou otázku, nač jít studovat fyziku, k čemu se to v praxi bude hodit, tak těžko odpovídá někomu, kdo zatím nepoznal...
To není hloupá otázka, člověk těsně před maturitou si ji může klást zcela legitimně. Hloupé je “studovat” softwarové inženýrství a pak se divit, že kdejaký fyzik nebo lingvista píše lepší kód. Ale to odbočuji...
To "hloupá" mělo být v uvozovkách. "Hloupá" otázka je třeba i proč jablko padá k zemi nebo proč jedna a jedna jsou dvě. Ale umět na to odpovědět je vlastně dost těžké, když tazatel neví nic o fyzice nebo matematice. Prostě hloupá spíš ve smyslu elementární, jako v algebře, když se zkoumá, jestli a+b je b+a, nebo zda daná struktura obsahuje opravdu právě jednu nulu.
To pak bude většina otázek “hloupých”, zvlášť tady. Těch odpovědí je samozřejmě vždy více druhů, přinejmenším jeden pro laiky a jeden pro zasvěcené. V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů, ale laikovi se to musí předložit jako “šablony” nebo “instanciovatelný typ”.
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Jevgenij Michajlovič Lifšic. Tak se to jméno píše latinkou.
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Jevgenij Michajlovič Lifšic. Tak se to jméno píše latinkou.
Jasně, třeba v anglickém překladu toho opusu magnum...
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Jevgenij Michajlovič Lifšic. Tak se to jméno píše latinkou.
Jasně, třeba v anglickém překladu toho opusu magnum...
To netuším, já to četl rusky. Ale přepisovat do češtiny, jakožto slovanského jazyka, azbuku, tedy písmo jiných slovanských jazyků, přes germánskou angličtinu, v níž se pořádají soutěže ve spellingu, protože její pravopis je tak zprzněný, že pořádně neumí zapsat ani sama sebe, považuji za zhůvěřilost.
-
protože její pravopis je tak zprzněný, že pořádně neumí zapsat ani sama sebe, považuji za zhůvěřilost.
A prepis cizich jmen do rustiny za zhuverilost nepovazujes? :-)
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Jevgenij Michajlovič Lifšic. Tak se to jméno píše latinkou.
Jasně, třeba v anglickém překladu toho opusu magnum...
To netuším, já to četl rusky. Ale přepisovat do češtiny, jakožto slovanského jazyka, azbuku, tedy písmo jiných slovanských jazyků, přes germánskou angličtinu, v níž se pořádají soutěže ve spellingu, protože její pravopis je tak zprzněný, že pořádně neumí zapsat ani sama sebe, považuji za zhůvěřilost.
Nicméně pořád to je latinka.
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Aspoň máš prostor pro přemýšlení, jak se máš vyjádřit, aby tvé sdělení neslo nějakou informaci.
-
Nemáte pocit že aj programovacie jazyky / techniky podliehajú módnym trendom?
Vo vseobecnosti:
Vsetky clovekom vytvorene jazyky podliehaju modnym trendom. Jedine jazyky, ktore nepodliehaju modnym trendom, su mrtve jazyky, t.j. take ktorych jazykove spolocenstvo uz zaniklo alebo je pred vymretim napr. latincina a COBOL. Zivost jazyka a miera zavadzania novych trendov je preto z velkej casti zavisla na pocte aktivnych/zivych uzivatelov.
Zavadzanie FP paradigmy do imperativnych OOP jazykov mi preto pripada ako ked v cestine a slovencine silou mocou uplatnujete japonsky slovosled s prisudkom vzdy a len na konci vety. Ano, da sa to, dokonca to funguje aj na vedlajsie podradovacie vety v suvetiach, ale vacsina jazykoveho spolocenstva v tom nevidi benefit, ked zhruba to iste ide aj po starom so sideeffectami.
-
Nemáte pocit že aj programovacie jazyky / techniky podliehajú módnym trendom?
Vo vseobecnosti:
Vsetky clovekom vytvorene jazyky podliehaju modnym trendom. Jedine jazyky, ktore nepodliehaju modnym trendom, su mrtve jazyky, t.j. take ktorych jazykove spolocenstvo uz zaniklo alebo je pred vymretim napr. latincina a COBOL. Zivost jazyka a miera zavadzania novych trendov je preto z velkej casti zavisla na pocte aktivnych/zivych uzivatelov.
Zavadzanie FP paradigmy do imperativnych OOP jazykov mi preto pripada ako ked v cestine a slovencine silou mocou uplatnujete japonsky slovosled s prisudkom vzdy a len na konci vety. Ano, da sa to, dokonca to funguje aj na vedlajsie podradovacie vety v suvetiach, ale vacsina jazykoveho spolocenstva v tom nevidi benefit, ked zhruba to iste ide aj po starom so sideeffectami.
Furt lepší japonský slovosled než germánské cross-serial dependencies. Nicméně s tím FP tak úplně nesouhlasím, jsa pragmatik jsem pro vše, co zlepší (co do elegance, čitelnosti, názornosti...) kód. Cílem FP v OO jazycích není vymýtit vedlejší efekty, ale zlidštit části kódu. Ale už je pozdě, takže budu toto téma stranou ležet nechat muset.
-
Siločára se neprojevuje. Projevuje se pole a ty siločáry nám umožňují si to neviditelné pole nějak představit. Elektron nejspíš "nevypadá" jako kulička. Ale kulička nám umožňuje si ho nějak představit, protože i ten elektron má vlastnosti, jako je hmotnost, velikost, "moment hybnosti"... Jen si je nelze představovat stejně.
Když u siločáry dojde k rekonexi, tak se projevuje pořádně. Je snad jasné, že jejich vyobrazení je pouze schématické a že jsou ve skutečnosti mnohem hustější. Pro představu nám to však vyhovuje.
Siločáry vnímám jako polní částice, tedy něco mezi zmíněným "neviditelným polem" a rozměrově obrovskou částicí. Jsou kvantovány podobně jako jiné bosony.
Zajímavá “moudra” 8) Nejdříve to asi chce vstřebat Landaua & Lifshitze ;)
Aspoň máš prostor pro přemýšlení, jak se máš vyjádřit, aby tvé sdělení neslo nějakou informaci.
Ty jsi jak Jirsák, nejdřív nasypeš do jednoho příspěvku bez ladu a skladu hromadu akademicky znějící terminologie, a pak kolem sebe kopeš. Nechceš radši napsat něco k PHP (bez siločar)?
-
Nechceš radši napsat něco k PHP (bez siločar)?
Třeba o tom, jak jsou gettery a settery pro programátora škodlivé? Tohle už přece všichni znají.
-
Nechceš radši napsat něco k PHP (bez siločar)?
Třeba o tom, jak jsou gettery a settery pro programátora škodlivé? Tohle už přece všichni znají.
Škodlivé jsou alkohol a drogy, gettery a settery tak maximálně nafukují kód ;)
P.S. Jak jde četba L&L? ;D
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
V podstatě ano, kromě variadických. Akorát je otázka, v jaké kategorii ten funktor je, to může být různé.
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
V podstatě ano, kromě variadických. Akorát je otázka, v jaké kategorii ten funktor je, to může být různé.
no psal jste o kategorii typů, dál je tu otázka co myslíte funktorem
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
V podstatě ano, kromě variadických. Akorát je otázka, v jaké kategorii ten funktor je, to může být různé.
no psal jste o kategorii typů, dál je tu otázka co myslíte funktorem
Funktor má matematicky jasnou definici (viz třeba Wikipedie). Když pominu variadické šablony, tak každá šablona je funktor. Kategorie, na kterých tyto funktory operují, tvoří hierarchii, nicméně většina kódu (99,9%?) se nejspíše pohybuje jen v kategorii typů, to je té nejnižší. Tyto typy se někdy zvou konkrétní a jejich druh (kind) je *. Funktory nad nimi jsou pak druhu *->* (hvězdičky v této standardní notaci označují konkrétní typy). Klidně můžu mít třeba bifunktor *->*->*. Jakmile mám ale například (*->*)->*, jsem už mimo kategorii typů a příslušný funktor není endofunktor (příkladem budiž “template template” v C++).
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
V podstatě ano, kromě variadických. Akorát je otázka, v jaké kategorii ten funktor je, to může být různé.
no psal jste o kategorii typů, dál je tu otázka co myslíte funktorem
Funktor má matematicky jasnou definici (viz třeba Wikipedie). Když pominu variadické šablony, tak každá šablona je funktor. Kategorie, na kterých tyto funktory operují, tvoří hierarchii, nicméně většina kódu (99,9%?) se nejspíše pohybuje jen v kategorii typů, to je té nejnižší. Tyto typy se někdy zvou konkrétní a jejich druh (kind) je *. Funktory nad nimi jsou pak druhu *->* (hvězdičky v této standardní notaci označují konkrétní typy). Klidně můžu mít třeba bifunktor *->*->*. Jakmile mám ale například (*->*)->*, jsem už mimo kategorii typů a příslušný funktor není endofunktor (příkladem budiž “template template” v C++).
pokud funktorem není myšlen objekt implementující operátor volání, tak se tím obvykle myslí kovariantní funktor...
-
V IT taky můžu vysvětlit generické typy správně a precizně pomocí funktorů.
Tak davej, davej, rad se neco priucim. Staci odkaz na priklad s obrazky.
Obrázky jsou pro děti. Jinak se to tu už probíralo dostatečně, generický typ je (endo)funktor (nebo bifunktor, tri- apod. podle počtu parametrů) v kategorii typů. Případně se dá jít výše a uvažovat endofunktor v kategorii funktorů, ale to je jen pro fajnšmekry (a většina jazyků to stejně neumí) - viz článek Generics of higher kind.
čistě intuitivně se mi nezdá, že by každá šablona mohla být funktor...
V podstatě ano, kromě variadických. Akorát je otázka, v jaké kategorii ten funktor je, to může být různé.
no psal jste o kategorii typů, dál je tu otázka co myslíte funktorem
Funktor má matematicky jasnou definici (viz třeba Wikipedie). Když pominu variadické šablony, tak každá šablona je funktor. Kategorie, na kterých tyto funktory operují, tvoří hierarchii, nicméně většina kódu (99,9%?) se nejspíše pohybuje jen v kategorii typů, to je té nejnižší. Tyto typy se někdy zvou konkrétní a jejich druh (kind) je *. Funktory nad nimi jsou pak druhu *->* (hvězdičky v této standardní notaci označují konkrétní typy). Klidně můžu mít třeba bifunktor *->*->*. Jakmile mám ale například (*->*)->*, jsem už mimo kategorii typů a příslušný funktor není endofunktor (příkladem budiž “template template” v C++).
pokud funktorem není myšlen objekt implementující operátor volání, tak se tím obvykle myslí kovariantní funktor...
Přesně, jde o kovariantní funktory.
-
Přesně, jde o kovariantní funktory.
no a ne každá šablona (s jedním parametrem) je kovariantní funktor
-
Přesně, jde o kovariantní funktory.
no a ne každá šablona (s jedním parametrem) je kovariantní funktor
Od kdy ne?
-
Přesně, jde o kovariantní funktory.
no a ne každá šablona (s jedním parametrem) je kovariantní funktor
Od kdy ne?
na to neumím odpovědět
kdyby někoho zajímal příklad, tak mám za to, že v c++ to je např. http://en.cppreference.com/w/cpp/utility/rel_ops/operator_cmp
a v haskellu pak např. hackage.haskell.org/package/contravariant
(a možná kontejner set?)
-
Tak jsem přešetl pár listů tohodle vlákna a začlo se mi mlžit před očima. Jaká móda? Jestli hledáš módu, debatuj o nových adidaskách, nebo o čivavách. Jazyk, který se používá, se používá nejčastěji proto, že je na pořadované řešení nejefektivnější(nebo jeden z). Co se s dobou mění, je akorát % programátorů, kteří inklinujou k nějakému jazyku, a to je osobní preference.
-
Tak jsem přešetl pár listů tohodle vlákna a začlo se mi mlžit před očima. Jaká móda? Jestli hledáš módu, debatuj o nových adidaskách, nebo o čivavách. Jazyk, který se používá, se používá nejčastěji proto, že je na pořadované řešení nejefektivnější(nebo jeden z). Co se s dobou mění, je akorát % programátorů, kteří inklinujou k nějakému jazyku, a to je osobní preference.
Ale kdeze, programuje se v tom, co hezky mlady Rus v cernem rolaku prezentuje na cool konferenci. To, ze to neni nove ani lepsi je uz jedno.
-
Tak jsem přešetl pár listů tohodle vlákna a začlo se mi mlžit před očima. Jaká móda? Jestli hledáš módu, debatuj o nových adidaskách, nebo o čivavách. Jazyk, který se používá, se používá nejčastěji proto, že je na pořadované řešení nejefektivnější(nebo jeden z). Co se s dobou mění, je akorát % programátorů, kteří inklinujou k nějakému jazyku, a to je osobní preference.
Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.
-
Tak jsem přešetl pár listů tohodle vlákna a začlo se mi mlžit před očima. Jaká móda? Jestli hledáš módu, debatuj o nových adidaskách, nebo o čivavách. Jazyk, který se používá, se používá nejčastěji proto, že je na pořadované řešení nejefektivnější(nebo jeden z). Co se s dobou mění, je akorát % programátorů, kteří inklinujou k nějakému jazyku, a to je osobní preference.
Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.
FP je koncepčně jednoduché, že vychází z matematiky je obecně výhoda, když člověk není totální pako i na trojčlenku.
-
Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.
FP je koncepčně jednoduché, že vychází z matematiky je obecně výhoda, když člověk není totální pako i na trojčlenku.
Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.
-
Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.
Ne, pokud člověk není pitomec, který si potřebuje honit triko, tak začátečníkům říká, že v FP:
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
...přičemž tohle ideálně platí absolutně, zatímco u reálných jazyků je to naplněno různou měrou.
Pokud je záhodno to začátečníkovi říct ještě polopatičtěji, použije se analogie s výrobní linkou: program v FP je taková továrna, ve které jsou za sebou poskládané různé stroje - do každého něco pásem jede a něco jiného z něj vypadne.
Zavadzanie FP paradigmy do imperativnych OOP jazykov mi preto pripada ako ked v cestine a slovencine silou mocou uplatnujete japonsky slovosled s prisudkom vzdy a len na konci vety.
S tím se celkem dá souhlasit - pokud se zavádí FP prvky jenom proto, aby tam byly, a nemá to žádný pořádný přínos (například proto, že ostatní rysy jazyka ten kýžený efekt zabijí), je to trochu křeč.
ale vacsina jazykoveho spolocenstva v tom nevidi benefit, ked zhruba to iste ide aj po starom so sideeffectami.
A s tímhle už se souhlasit nedá. FP prvky se nezavádí proto, že by pomocí FP šlo udělat něco, co v OOP nejde, ale proto, že FP programovací styl (!!!!) často vede ke kódu, který dokáže člověk líp pojmout, přemýšlet o něm a dělat o něm závěry ("reason about"), což je samo o sobě velký přínos např. pro spolehlivost (viz Elm vs. JS).
Dají se popsat konkrétní důvody, proč je FP v tomhle vhodnější - jeden z nich např. je, že interakce jsou ("vynuceně") lokální - z principu se nemůže stát, že někde držím nějaká data a kód na úplně druhé straně planety mi je změní pod rukama - tahle eventualita prostě neexistuje, proto s ní nemusím počítat (u OOP musím) a mám přemýšlení o poznání jednodušší.
Imutabilní data jsou podle mě (a nikomu to necpu) silnější nástroj než funkce bez sideefectů. Pokud mám jazyk se striktně imutabilními daty, tak mi to přemýšlení nad kódem dramaticky zjednodušší. Pokud mám jazyk bez sideefectů, tak mi to sice pomůže taky, ale zároveň to přinese obrovské množství problémů při řešení praktických věcí, takže ve finále musím přemýšlet zase hodně :)
-
Dnešním módním trendem je funkcionální programování včetně teorie kategorií. Čím méně srozumitelně podané, tím víc cool.
FP je koncepčně jednoduché, že vychází z matematiky je obecně výhoda, když člověk není totální pako i na trojčlenku.
Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.
Tak jasně, pokud někdo považuje PHP za etalon použitelného jazyka, tak výhodu FP neuvidí nikdy.
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
-
Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
To je velice dobrá analogie. Když si totiž koupíš pořádnou matraci, tak na té "obyčejné" už se nevyspíš. Neboli, jak říká klasik: "Která jednou zkusí, už nechce jinak".
Nemám žádný důvod tě přesvědčovat, programuj si v čem a jak chceš, je to tvůj život :)
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.
nemám rád analogie a ty zatím uvedené mi přijdou fakt blbé, zkuste třeba původní a moderní formulaci maxwellových rovnic
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.
nemám rád analogie a ty zatím uvedené mi přijdou fakt blbé, zkuste třeba původní a moderní formulaci maxwellových rovnic
Ono i pochopení analogie vyžaduje určitou úroveň znalostí v dané oblasti. Někomu analogie pomůže, a pokud to nedocvakne, doporučuju mlčet.
-
Ono i pochopení analogie vyžaduje určitou úroveň znalostí v dané oblasti. Někomu analogie pomůže, a pokud to nedocvakne, doporučuju mlčet.
tak ta vaše:
ve funkcionálním jazyce i v imperativním lze implementovat stejný program, pro stejné vstupy vyprodukují stejné výstupy (bo jsou to typicky turingovsky ekvivalentní jazyky a takové ty věci), ale co modeluje obecná relativita nelze postihnout newtonovým modelem
-
ve funkcionálním jazyce i v imperativním lze implementovat stejný program, pro stejné vstupy vyprodukují stejné výstupy (bo jsou to typicky turingovsky ekvivalentní jazyky a takové ty věci), ale co modeluje obecná relativita nelze postihnout newtonovým modelem
Jenže ten turingovský základ odpovídá matematickému základu, jenž je stejný pro všechny teorie. V programování sice v Javě a spol. můžu implementovat cokoliv vyčíslitelného, ovšem stěžejní je to, že méně elegantně, protože má například slabý typový systém. To samé v Haskellu bude kratší a čitelnější, protože některé věci lze explicitně vyjádřit. Nicméně asi stačí zůstat u toho snadnějšího “reasoning about”, protože to je z praxe a tedy snáze uchopitelné.
FP je v současnosti typický buzzword, což některé popuzuje, jenže v této fázi bylo i OOP. Každý nechť si přebere, je-li FP pro něj.
-
ale co modeluje obecná relativita nelze postihnout newtonovým modelem
No ale je potřeba si uvědomit jednu věc: kdekoli-kdykoli-kýmkoli-měnitelná data jsou takový problém, že se typicky v globálním měřítku ani v ne-FP programech nepoužívají, protože to je prostě neúnosné (~ nelze postihnout Newtonovým modelem).
Šermování turingovskou kompletností je sice hezký, ale je to klasický "v teorii je to pravda, v praxi ne", sloužící jenom k tomu, aby někdo někoho mlátil Turingem po hlavě. C++ templaty jsou údajně taky Turingovsky kompletní (údajně "náhodou", "omylem") a přesto by asi nikdo nebyl schopný v nich napsat třeba Windows nebo Word. Teoreticky to jde, prakticky je to nerealizovatelné, protože to prostě žádný smrtelník nedá.
Takže zpátky k tématu: kdekoli-kdykoli-kýmkoli-měnitelná data by v jakémkoli větším systému žádný smrtelník nedal, proto se vytváří různé bariéry (moduly, subsystémy apod.), které komunikují pomocí nějakého API. A na téhle úrovni je to co? No přece úplně to samý jako erlangovské procesy, které komunikují pomocí zpráv. Aha? Takže i v "normálním", "ne-FP" programování se používá přesně ten samý princip, akorát na jiné úrovni, v jiném měřítku. Čili machrování "nikdy jsem to nepotřeboval" je poněkud mimo mísu. Potřeboval. Akorát jsem o tom nevěděl ;)
-
Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
To je velice dobrá analogie. Když si totiž koupíš pořádnou matraci, tak na té "obyčejné" už se nevyspíš. Neboli, jak říká klasik: "Která jednou zkusí, už nechce jinak".
Nemám žádný důvod tě přesvědčovat, programuj si v čem a jak chceš, je to tvůj život :)
Tak ještě od školních let se orientuji v LISPu a mám ho dost rád, vlastně jsem se ho učil na svém vlastním překladači (IMHO skvělý námět pro různé semestrální projekty, protože je celkem jednoduchý a člověk si procvičí vedle LISPu i další věci).
Spolupracoval jsem nedávno na jednom projektu v Elixiru, ale např. pro embedded věci, což je má doména, je nechutně náročný a tedy naprosto nevhodný. A i tak pozoruji, že to funkcionální paradigma není lidem úplně přirozené, skoro bych řekl, že tak jak většina lidí (bohužel dnes i většina těch počítačových) válčí s matematikou, tak válčí i s FP. Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu, na němž má takový program běžet, takže program sice vypadá elegantně, ale jeho efektivita bývá dost mizerná.
Už jsem v životě zažil OOP hype, FP hype, ale stále mám pocit, že klasické strukturované paradigma je nejlepší kompromis mezi stravitelností pro člověka a pro počítač.
Možná tu výhodu nevidíte, protože jste se nikdy nedostal v psaní kódu k těm oblastem, kde odlišnost FP hraje roli, což jsou typicky paralelní výpočty. Je to jako tvrdit, že obecná teorie relativity nic nepřináší, protože Newtonova koncepce funguje úplně stejně dobře. Ono to je pravda, ale jen za určitých podmínek, jak sám víte. Po překročení Rubikonu ovšem rozdíl mezi nimi bije do očí.
No, pokud budu provádět výpočty nerelativistických jevů, tak je opravdu hloupost nasazovat na to nástroje TR. Ona to může být hloupost i tehdy, pokud relativistické jevy roli izolovaně hrají - viz např. elektromagnetismus.
K paralelním výpočtům jsem se dostal naposledy na VŠ při řešení PDE. Dělali jsme to tenkrát ve Fortranu 90 a popravdě, při vědomí, jak výpočetně neefektivní FP jazyky jsou, by mě asi nenapadlo je k těmto účelům použít. Čekat na výsledek týden nebo měsíc je přeci jen rozdíl. :) I v tom Fortranu se tehdy špekulovalo nad tím, jak ty matice vůbec organizovat, aby se narvaly do paměti jednotlivých jednotek a minimalizovala potřeba rozsáhlých datových přesunů uvnitř nebo dokonce mezi jednotkami. Docela se obávám, že funkcionální jazyk by mi z tohoto hlediska naházel do cesty tolik klacků, že by se z toho na daném HW stal neřešitelný problém.
-
... pozoruji, že to funkcionální paradigma není lidem úplně přirozené, skoro bych řekl, že tak jak většina lidí (bohužel dnes i většina těch počítačových) válčí s matematikou, tak válčí i s FP. Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu, na němž má takový program běžet, takže program sice vypadá elegantně, ale jeho efektivita bývá dost mizerná.
železu, některým lidem a řešeným problémům přirozené není, ale pokud se sejde vhodný problém a vhodní lidi tak je to pecka (z mé zkušenosti jde o haskell s jeho výborným typovým systémem, monádama a pattern matching-em, a příkladem problémů překladače a komunikační protokoly (když to není hard rt))
-
Spolupracoval jsem nedávno na jednom projektu v Elixiru
Skvěle! ;) V ČR?
, ale např. pro embedded věci, což je má doména, je nechutně náročný a tedy naprosto nevhodný.
Na takové použití nikdy nebyl zamýšlen, takže to je jako konstatovat, že kancelářský papír se nehodí na šití balónů :)
A i tak pozoruji, že to funkcionální paradigma není lidem úplně přirozené
Já bych nemluvil o "paradigmatu", ale o konkrétním jazyku. Pod "FP paradigma" si může představit kdo chce co chce a důsledky můžou být jakékoliv. Bavit se dá o konkrétních příkladech, proč třeba někomu nevyhovoval Elixir pro nějaké konkrétní použití. Pak to je smysluplná debata a dá se dojít ke konsensu (jako třeba u těch embedded/constrained zařízení, kde mezi náma není sporu).
A za druhé bych se taky podíval na to, komu to nevyhovuje. Jestli někdo deset let programoval OOP, tak má samozřejmě OOP modelování zažrané do mozku a FP modelování buď neumí vůbec, nebo je to pro něj bolehlav. To ale není vlastnost FP modelování, to je vlastnost toho člověka.
Mně osobně například přijde daleko přirozenější uvažovat nad tím, že když do mlínku na maso vrazím maso, tak z něj vypadne mletý maso, než uvažovat nad tím, jestli obecný čtverec je víc obecný pojem než obecný obdélník nebo naopak ;)
, skoro bych řekl, že tak jak většina lidí (bohužel dnes i většina těch počítačových) válčí s matematikou, tak válčí i s FP.
Já třeba osobně v FP nevidím tolik matematiku, jako spíš (matematickou) logiku nebo klidně i (jazykovědnou) sémantiku - u každého kusu kódu se ptám otázky typu "co je jeho účelem?", "co zná?", "co potřebuje znát?" apod.
Že je FP založené na matematice je taková polopravda - striktně vzato je to pravda a je to dobře, protože chytré hlavy pak můžou o FP programu (nebo jazyku) leccos zajímavého dokázat. Ale mně jako uživateli to může být celkem putna. Opravdu málo kdo (!) je v matice na takové úrovni, aby ty matematické kořeny FP dokázal opravdu ocenit a využít (!). My ostatní Běžní Frantové Programátoři si užíváme úplně jiné věci (jako třeba tu zmíněnou paralelizovatelnost nebo přímočarost kódu).
Jenže to funkcionální paradigma navíc není úplně přirozené ani tomu železu
To je nezpochybnitelná pravda. Na to bych ti řekl, že se nechci přizpůsobovat tomu, jak myslí stroj, chci, aby stroj pochopil, jak myslím já ;) (neber pls doslovně - já mám taky nějakou zkušenost s embedded a přímočarost a lowlevelovitost Cčka umím taky ocenit a užít si, ne že ne)
-
No, pokud budu provádět výpočty nerelativistických jevů, tak je opravdu hloupost nasazovat na to nástroje TR. [...]
K paralelním výpočtům jsem se dostal naposledy na VŠ při řešení PDE. Dělali jsme to tenkrát ve Fortranu 90 a popravdě, při vědomí, jak výpočetně neefektivní FP jazyky jsou, by mě asi nenapadlo je k těmto účelům použít. Čekat na výsledek týden nebo měsíc je přeci jen rozdíl. :) I v tom Fortranu se tehdy špekulovalo nad tím, jak ty matice vůbec organizovat, aby se narvaly do paměti jednotlivých jednotek a minimalizovala potřeba rozsáhlých datových přesunů uvnitř nebo dokonce mezi jednotkami. Docela se obávám, že funkcionální jazyk by mi z tohoto hlediska naházel do cesty tolik klacků, že by se z toho na daném HW stal neřešitelný problém.
Přesně, a zrovna tak je hloupost nenasadit nástroje TR, když o rel. jevy jde. Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.
Výkon je záležitost implementace, ne paradigmatu. V FP už vývoj dost pokročil a efektivitou se blíží běžným OO jazykům. Navíc nic mi nebrání jít cestou Pythonu a využít optimalizované knihovny s funkcionálním API pod glue kódem třeba v Haskellu.
-
Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.
vlastní zkušenost? podělte se
-
Výkon je záležitost implementace, ne paradigmatu. V FP už vývoj dost pokročil a efektivitou se blíží běžným OO jazykům.
Ehm to tedy težko: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=ghc
Tak možná za 10 let...
-
Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.
vlastní zkušenost? podělte se
Ano, vlastní, zpracování dat z vesmírných dalekohledů, konkrétně systém přenášející (pokud možno, tj. soft) real-time záznamy na koncové terminály. Docel peklo...
-
Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.
vlastní zkušenost? podělte se
Ano, vlastní, zpracování dat z vesmírných dalekohledů, konkrétně systém přenášející (pokud možno, tj. soft) real-time záznamy na koncové terminály. Docel peklo...
super :)
tak místo nějakých analogií o gravitaci rozepište tohle, opravdu rád si to přečtu (už jen z toho důvodu, že mě živí komunikační protokoly)
-
Budoucnost je v jazyku C. Vsechny jadra operacnich systemu jsou napsane v cecku, souborove systemy > cecko, drivery > cecko, databaze (oracle) v cecku, ta slavna java virtual machine je napsana v cecku. Vsechny dulezite veci u kterych zalezi na maximalni rychlosti a maximalni stabilite jsou napsane v cecku. Nejpouzivanejsi webovy server na svete (Apache) je napsany v cecku. Takhle bysme mohli pokracovat jeste hodne dlouho.
Nevidim tady zadny modni trend uz 45 let a v pristich 10 letech se to urcite nezmeni. Toto je pohled programatora, samozrejme studentik patlajici webiky a klikaci picovinky muze mit pohled jiny.
-
Jde-li například o masivní paralelismus s komplikovanými daty, je FP spásou z nebes.
vlastní zkušenost? podělte se
Ano, vlastní, zpracování dat z vesmírných dalekohledů, konkrétně systém přenášející (pokud možno, tj. soft) real-time záznamy na koncové terminály. Docel peklo...
super :)
tak místo nějakých analogií o gravitaci rozepište tohle, opravdu rád si to přečtu (už jen z toho důvodu, že mě živí komunikační protokoly)
Tak ono to je v podstatě jednoduché, celé to stojí na CSP, funkce jsou bezestavové (něco jako amazoní lambdy) a jede to na jednom jediném serveru (se 64 jádry a 256 GB RAM). Většinu času se server fláká :) Nejsem astrofyzik, tak k vědeckým aspektům se moc vyjadřovat nemůžu :(
-
Budoucnost je v jazyku C. Vsechny jadra operacnich systemu jsou napsane v cecku, souborove systemy > cecko, drivery > cecko, databaze (oracle) v cecku, ta slavna java virtual machine je napsana v cecku. Vsechny dulezite veci u kterych zalezi na maximalni rychlosti a maximalni stabilite jsou napsane v cecku. Nejpouzivanejsi webovy server na svete (Apache) je napsany v cecku. Takhle bysme mohli pokracovat jeste hodne dlouho.
Nevidim tady zadny modni trend uz 45 let a v pristich 10 letech se to urcite nezmeni. Toto je pohled programatora, samozrejme studentik patlajici webiky a klikaci picovinky muze mit pohled jiny.
Lunochody na Marsu (marsochody? ;D) v céčku nejsou :P
-
Budoucnost je v jazyku C. Vsechny jadra operacnich systemu jsou napsane v cecku, souborove systemy > cecko, drivery > cecko, databaze (oracle) v cecku, ta slavna java virtual machine je napsana v cecku. Vsechny dulezite veci u kterych zalezi na maximalni rychlosti a maximalni stabilite jsou napsane v cecku. Nejpouzivanejsi webovy server na svete (Apache) je napsany v cecku. Takhle bysme mohli pokracovat jeste hodne dlouho.
Nevidim tady zadny modni trend uz 45 let a v pristich 10 letech se to urcite nezmeni. Toto je pohled programatora, samozrejme studentik patlajici webiky a klikaci picovinky muze mit pohled jiny.
Lunochody na Marsu (marsochody? ;D) v céčku nejsou :P
asi spíš jsou (vxworks etc)
-
Nejsem astrofyzik, tak k vědeckým aspektům se moc vyjadřovat nemůžu :(
pište o technických aspektech, jazyk (haskell? erlang?), technologie (STM?), architektura (modelování dat, GADT?), organizace procesů, ...
-
Ano, tohle je ta obvyklá cool věta, která se říká začátečníkům, aby věděli totéž, co předtím. Nenese totiž žádnou informaci o FP.
Ne, pokud člověk není pitomec, který si potřebuje honit triko, tak začátečníkům říká, že v FP:
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Tohle je mi důvěrně známo z XSLT, ale to na skutečné FP zjevně nestačí.
Na reálném FP mi vadí spíš podivně užíváné namespace, i když například Haskell ho má propracované. Pleonasmy mi prostě vadí. Ekosystém je samozřejmě součástí jazyka a pokud mi nevyhovuje, nemohu používat ve větším rozsahu ani ten jazyk. Na drobné utilitky mi to tolik nevadí, ale když je název funkce na půl řádku, tak je to prostě opruz. Kdo má takovou hatmatilku číst?
-
Imutabilní data jsou podle mě (a nikomu to necpu) silnější nástroj než funkce bez sideefectů. Pokud mám jazyk se striktně imutabilními daty, tak mi to přemýšlení nad kódem dramaticky zjednodušší. Pokud mám jazyk bez sideefectů, tak mi to sice pomůže taky, ale zároveň to přinese obrovské množství problémů při řešení praktických věcí, takže ve finále musím přemýšlet zase hodně :)
Imutabilní data se dají bez problémů používat i v OOP - stačí vyházet všechny settery a neměnit vnitřní stavy. Objekty se pak chovají jako virtuální procesory a nemají žádný problém s paralelizací.
-
to na skutečné FP zjevně nestačí.
Z čeho je to zjevné?
ale když je název funkce na půl řádku, tak je to prostě opruz. Kdo má takovou hatmatilku číst?
Vůbec nevím, co myslíš. Jaké názvy na půl řádku? Proč? Kde?
Ajo, ty myslíš org.springframework.aop.framework.AbstractSingletonProxyFactoryBean! Tak to jo, s tím se dá souhlasit, to se číst nedá ;)
-
Imutabilní data jsou podle mě (a nikomu to necpu) silnější nástroj než funkce bez sideefectů. Pokud mám jazyk se striktně imutabilními daty, tak mi to přemýšlení nad kódem dramaticky zjednodušší. Pokud mám jazyk bez sideefectů, tak mi to sice pomůže taky, ale zároveň to přinese obrovské množství problémů při řešení praktických věcí, takže ve finále musím přemýšlet zase hodně :)
Imutabilní data se dají bez problémů používat i v OOP - stačí vyházet všechny settery a neměnit vnitřní stavy. Objekty se pak chovají jako virtuální procesory a nemají žádný problém s paralelizací.
Tady by se myslím dalo dlouze diskutovat o tom, že když udělám z objektů jakési bezstavové kontejnery na funkce, jestli to je vůbec ještě OOP. Rozhodně si takový styl nebude moc rozumět se standardními knihovnami.
-
Imutabilní data se dají bez problémů používat i v OOP
Což všichni víme a nikdo netvrdil opak, takže úplně nedává smysl to konstatovat :)
-
Imutabilní data se dají bez problémů používat i v OOP
Což všichni víme a nikdo netvrdil opak, takže úplně nedává smysl to konstatovat :)
Jsem rád že se mnou souhlasíš, ale mnoho vývojářů se tím vůbec neřídí a naopak tvrdí, že takový objekt nedává smysl.
-
Jsem rád že se mnou souhlasíš, ale mnoho vývojářů se tím vůbec neřídí a naopak tvrdí, že takový objekt nedává smysl.
No je to prostě konstanta, čili nic světoborného. OOP stylem pomocí samých konstant nic rozumně nenaprogramuješ. FP stylem ano. V tom je ten rozdíl.
-
to na skutečné FP zjevně nestačí.
Z čeho je to zjevné?
Například v tom není ani zmínka o monádách, výjimkách, namespacech, curryfikaci, strážích a dalších vymoženostech, kterými funkcionální jazyky oplývají.
Je zajímavé, jak je v módě FP, ale když se zmíním o tom, že používám XSLT, tak se mi blbí začnou smát.
-
Například v tom není ani zmínka o monádách, výjimkách, namespacech, curryfikaci, strážích a dalších vymoženostech, kterými funkcionální jazyky oplývají.
A co má být? Různé jazyky mají různé featury. Pořád nějak nechápu pointu.
Z toho, cos napsal, má třeba Erlang jenom výjímky a stráže, což ani jedno není nijak FP-specifické a kdyby to Erlang neměl, vůbec nic by se nestalo, jenom by se v tom některé věci psaly trochu ukecaněji.
-
Jsem rád že se mnou souhlasíš, ale mnoho vývojářů se tím vůbec neřídí a naopak tvrdí, že takový objekt nedává smysl.
No je to prostě konstanta, čili nic světoborného. OOP stylem pomocí samých konstant nic rozumně nenaprogramuješ. FP stylem ano. V tom je ten rozdíl.
V tom se mýlíš. Do konstruktoru takového konstantního objektu můžeš injektovat různé závislosti a jako celek se to pak chová funkcionálně podle toho, jak to celé sestavíš. Výstup je pak funkcí vstupu.
-
Je zajímavé, jak je v módě FP, ale když se zmíním o tom, že používám XSLT, tak se mi blbí začnou smát.
No tak pokud chci programovat funkcionálně v něčem plném špičatých závorek, co je proslulé naprostou nečitelností, tak stejně preferuju C++ šablony. Pokud se s FP často setkáváš právě v podobě XSLT, tak opravdu rozumím tvé averzi. :)
-
V tom se mýlíš. Do konstruktoru takového konstantního objektu můžeš injektovat různé závislosti a jako celek se to pak chová funkcionálně podle toho, jak to celé sestavíš. Výstup je pak funkcí vstupu.
Konstanta je od toho, že je konstantní, tj. po dobu svého života se nemění. A je úplně jedno, jak ji vytvořím.
const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
je u mě pořád konstanta. Jestli u tebe ne, hádat se o to nebudu, je mi to jedno, jak tomu cheš říkat, OOP stylem se samými takovými objekty stejně nic nenaprogramuješ. Jenom budeš (špatně a zbytečně krkolomně) imitovat funkcionální styl.
-
Například v tom není ani zmínka o monádách, výjimkách, namespacech, curryfikaci, strážích a dalších vymoženostech, kterými funkcionální jazyky oplývají.
A co má být? Různé jazyky mají různé featury. Pořád nějak nechápu pointu.
Z toho, cos napsal, má třeba Erlang jenom výjímky a stráže, což ani jedno není nijak FP-specifické a kdyby to Erlang neměl, vůbec nic by se nestalo, jenom by se v tom některé věci psaly trochu ukecaněji.
Pointa je v tom, že kdybych se držel jen těch dvou zmíněných bodů a nevyužíval doplňujících featur, tak nic kloudného nenaprogramuji a ani nemám šanci pochopit, co napsal jiný programátor. Navíc syntaxe, která je velmi odlišná od strukturovaných jazyků, to chápání cizího programu ještě zhoršuje.
Tím chci sdělit, že znalost matematiky pro úspěšné programování ve fukcionálních jazycích je podmínkou nutnou, nikoli však postačující.
-
V tom se mýlíš. Do konstruktoru takového konstantního objektu můžeš injektovat různé závislosti a jako celek se to pak chová funkcionálně podle toho, jak to celé sestavíš. Výstup je pak funkcí vstupu.
Konstanta je od toho, že je konstantní, tj. po dobu svého života se nemění. A je úplně jedno, jak ji vytvořím.
const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
je u mě pořád konstanta. Jestli u tebe ne, hádat se o to nebudu, je mi to jedno, jak tomu cheš říkat, OOP stylem se samými takovými objekty stejně nic nenaprogramuješ. Jenom budeš (špatně a zbytečně krkolomně) imitovat funkcionální styl.
Funkce jsou ve FP přece také konstanty.
-
Pointa je v tom, že kdybych se držel jen těch dvou zmíněných bodů a nevyužíval doplňujících featur, tak nic kloudného nenaprogramuji
Opakuji: Erlang z těch "doplňujících featur" má dvě - nepodstatné, které sílu jazyka výrazně nemění.
a ani nemám šanci pochopit, co napsal jiný programátor. Navíc syntaxe, která je velmi odlišná od strukturovaných jazyků, to chápání cizího programu ještě zhoršuje.
Fakt?
defmodule Greeter do
def hello(name) do
"Hello, " <> name
end
end
iex> Greeter.hello("Sean")
"Hello, Sean"
Zcela nepochopitelné! :)))
Prosímtě, ujasni si, jestli mluvíš o FP nebo o Haskellu. Navíc mluvit obecně o FP je samo o sobě dost vošajstlich, protože ty jazyy z téhle rodiny jsou tak odlišné, že společně pro ně neplatí skoro nic. Ani ty dvě věty, co tě tak rozlítily :))
Tím chci sdělit, že znalost matematiky pro úspěšné programování ve fukcionálních jazycích je podmínkou nutnou, nikoli však postačující.
Není o nic nutnější než u C nebo Pythonu.
-
defmodule Greeter do
def hello(name) do
"Hello, " <> name
end
end
iex> Greeter.hello("Sean")
"Hello, Sean"
Zcela nepochopitelné! :)))
Pochopitelné je hlavně to, že i v tak krátkém programu se dá udělat chyba. A co kdyby byl jen o trochu složitější, to by bylo!
-
Funkce jsou ve FP přece také konstanty.
No a to jsme přesně u těch pitomých generalizací. Co má znamenat, že "funkce je konstanta"? A co z toho má plynout?
V Erlangu můžu kód hotreloadovat, takže při prvním zavolání fce se mi spustí nějaký kód a při druhém nějaký úplně jiný. Je pak ta fce konstanta? Já nevím. A opět: je mi to celkem jedno :)
Pochopitelné je hlavně to, že i v tak krátkém programu se dá udělat chyba.
...zatímco v ne-FP programu se chyba udělat nedá. Potvrzuje NaN programátorů z "5"ti.
Sorry jako, na tenhle dadaismus už nějak nemám náladu, měj se :)
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
Tovis, super-hrnce rulez! :)
Ja naopak nechapu, jak si muze rikat programator nekdo, kdo je ochoten obetovat tolik efektivity, kvuli nejake "cistote" a pouzivat immutable objekty, a zbytecne vecne nekde neco kopirovat -> kdyz vetsina funkcionalnich jazyku je vzor plytvani.. :D
Ale ted skoro vazne. Cele "funkcionalni paradigma" stoji na "immutable objektech"(pisu to uvozovkach, aby mi tady nekdo nevycital detaily) a cely immutable svet do extremu dovedeny je dost neefektivni. Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat. Jeste lepsi a uplne nejefektivnejsi by bylo,kdybychom umeli barvu zmenit(coz neumime). Ma to spoustu praktickych implikaci, ale ve zjednodusenemem svete(cimz myslim, zjednoduseny svet modelovany softwarem, kde ZATIM (nepotrebujeme/a ani neumime) modelovat vsechny detaily), si zatim muzem tuto "ochcavku" dovolit a usetri nam to spoustu prace(energie)(kterou dela kompl). Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?
-
Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?
To je legitimní otázka. Zkus si prostudovat, jak fungují masivně paralelní processing sytémy typu Hadoop, Spark, Flink. A zkus se potom zamyslet, proč se tam většinou používají immutable data a transformace bez vedlejších efektů.
Samozřejmě existují problémy, které je výrazně efektivnější řešit in situ. Tvrdil někdo opak?
Na ten první problém použiješ funkcionálně laděný přístup, na ten druhý klasický přístup. Kde je problém?
-
Funkce jsou ve FP přece také konstanty.
No a to jsme přesně u těch pitomých generalizací. Co má znamenat, že "funkce je konstanta"? A co z toho má plynout?
Plyne z toho, že funkce pro stejné vstupní parametry dává stejné výstupy. Tedy chová se stejně jako metody v mých immutable objektech, u kterých chování nastavuji konstruktorem a pak už ten objekt neměním.
-
1. je funkce (prakticky) totéž co se tím slovem myslí v matematice - je referenčně transparentní
2. data jsou imutabilní
Zajímavé je, že jsem s proměnnými daty a s procedurami s vedlejšími efekty nikdy žádné zásadní problémy neměl ani v imperativně-procedurálním paradigmatu.
Když čtu o výhodách těchto věcí, tak mi to připomíná telefonické nabídky různých speciálních matrací a postelí, které mají tu výhodu, že člověk na nich spí jako nemluvně a ráno ho nebolej záda. Prodejci nikdy nechtějí pochopit, jak je to možné, že na té nejobyčejnější posteli s nejobyčejnější matrací se vyspím taky úplně normálně a bolest zad znám jen z vyprávění.
Tovis, super-hrnce rulez! :)
Ja naopak nechapu, jak si muze rikat programator nekdo, kdo je ochoten obetovat tolik efektivity, kvuli nejake "cistote" a pouzivat immutable objekty, a zbytecne vecne nekde neco kopirovat -> kdyz vetsina funkcionalnich jazyku je vzor plytvani.. :D
Ale ted skoro vazne. Cele "funkcionalni paradigma" stoji na "immutable objektech"(pisu to uvozovkach, aby mi tady nekdo nevycital detaily) a cely immutable svet do extremu dovedeny je dost neefektivni. Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat. Jeste lepsi a uplne nejefektivnejsi by bylo,kdybychom umeli barvu zmenit(coz neumime). Ma to spoustu praktickych implikaci, ale ve zjednodusenemem svete(cimz myslim, zjednoduseny svet modelovany softwarem, kde ZATIM (nepotrebujeme/a ani neumime) modelovat vsechny detaily), si zatim muzem tuto "ochcavku" dovolit a usetri nam to spoustu prace(energie)(kterou dela kompl). Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?
S tou posedlostí paradigmaty máte úplnou pravdu. Je to stejně hloupé jako posedlost mikrooptimalizacemi, zde na rootu také častá.
Nemáte pravdu s tím kopírováním. Moderní FP jazyky mají tzv. perzistentní datové struktury.
-
Plyne z toho, že funkce pro stejné vstupní parametry dává stejné výstupy.
Ne, to z toho neplyne, to je tvoje DEFINICE pojmu "konstantní fce".
BTW, opět v Erlangu ani Scale tohle neplatí. A pokud se nemýlím, tak ani v Clojure. Ono vůbec těch jazyků, kde to platí striktně, moc není.
Lepší ilustraci toho, jak pitomé jsou generalizace ohledně FP, jsi podat nemohl :)
(Otázka "a co z toho plyne?" pořád zůstává, akorát už asi ani nechci slyšet odpověď, protože jediný, co tady demonstruješ, je, že i v "OOP jazyce" se dá programovat funkcionálním stylem, což není pro nikoho žádný překvápko. Je to stejný jako že i céčku se dá psát objektově. I v assembleru. I když budeš zadávat ed-em stroják, můžeš programovat funkcionálně, objektově, strukturovaně, špagetově... Myslíš, že to někoho překvapuje nebo o co go?)
-
Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?
To je legitimní otázka. Zkus si prostudovat, jak fungují masivně paralelní processing sytémy typu Hadoop, Spark, Flink. A zkus se potom zamyslet, proč se tam většinou používají immutable data a transformace bez vedlejších efektů.
Samozřejmě existují problémy, které je výrazně efektivnější řešit in situ. Tvrdil někdo opak?
Na ten první problém použiješ funkcionálně laděný přístup, na ten druhý klasický přístup. Kde je problém?
:-D Tim (hadoop based...konkretne soucasne nejvic hbase) se zivim. Ac to zni extremne ucelove subejktivne(to je ku*va (ma/z)mrdske slovni spojeni), je to uhel pohledu. Jsou veci na hodne nizke urovni, ktere jsou nemenitelne/immutable(obecne nejsme schopni efektivne menit atom1 -> atom2(ci dokonce nizsi castice)) ... zrovna jako v nasem (makro) svete. Ale z abstraktnejsiho hlediska naopak transformace informace(dat) in situ prinasi temer absurdni(javim, trochu "plytvam extremnimi vyjadrenimi") efektivitu(vim to, protoze jsme dokazali takhle zefektivnit nas system vice nez o dva rady).
Omlouvam se za tyhle extremnni nazory/vyjadreni, umyslne to trochu prehanim, ale muj nazor je, ze cim vic/lepe dokazem abstrahovat nad immutable svet(ktery snad opravdu na nejnizsi urovni immutable je), tim efektivneji dokazem vyjadrovat myslenky/transformace objektu.
-
Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.
Na analogii s autem to sice moc nesedí, ale dám pár příkladů.
Mám kopec vlastností, které se výjímečně, ale nepředvidatelně mění (např. parametry video streamu). Pokud je mám v immutable struktuře, tak mi stačí kontrolovat jenom ukazatel. Bez immutable dat se uifuju.
Pokud chci nějaká data číst z hodně vláken, tak jsou immutable data rozumně výkonné řešení. Zámek mutable dat si budou jednotlivá jádra vyhazovat z cache a výkon půjde do kytek.
Kopírování immutable dat je problém jen v případě, že se jima nedá předejít ještě daleko větší ztrátě výkonu.
-
Ac to zni extremne ucelove subejktivne, je to uhel pohledu.
Není to úhel pohledu. Z jedné strany tečou data dovnitř, z druhé ven. V MapReduce, Sparku, Flinku,... a bambilionech dalších.
Tak asi to teda vypadá, že jsou všichni pitomí a plýtvají energií zatímco by to šlo celý udělat s násobnou efektivitou :)
Doporučoval bych ti, abys do té implementace šel. Lidi ti utrhají ruce, když jim cluster spočítá to samý, akorát místo megawatthodiny spotřebuje tři kilowatthodiny. Tím jsem si celkem jistej :)
-
Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.
Na analogii s autem to sice moc nesedí, ale dám pár příkladů.
Mám kopec vlastností, které se výjímečně, ale nepředvidatelně mění (např. parametry video streamu). Pokud je mám v immutable struktuře, tak mi stačí kontrolovat jenom ukazatel. Bez immutable dat se uifuju.
Pokud chci nějaká data číst z hodně vláken, tak jsou immutable data rozumně výkonné řešení. Zámek mutable dat si budou jednotlivá jádra vyhazovat z cache a výkon půjde do kytek.
Kopírování immutable dat je problém jen v případě, že se jima nedá předejít ještě daleko větší ztrátě výkonu.
Mno.. je treba si uvedomit, ze velmi velmi malokdy potrebujete pristupovat ke stejnym datum paralelne. Typicke multi-threadove/procesni .. proste paralelni zpracovani dat je zaprve pouze cteni dat(kde zamky nejsou potreba) a i kdyby ne, tak se rozdeluji data na casti, ktere se mohou zpracovavat paralelne(konkurencne?) ale nezasahuji do sebe navzajem. Proste polopate mate velkou mnozinu dat-> rozdelite ji na casti a ruzne procesy zpracovavaji ruzne casti dat a opravdu si nelezou do zeli.
Kdyz potrebujete zpracovavat terabyty/petabyty dat, tak opravdu se vam nestava, ze modifikujete stejna data a potrebujete nejake zamky na toto(ani to neni mozne, ty data proste nejsou k dispozici na jednom zeleze)... hlavni ukol je rozdelit data tak, aby mohla byt zpracovavana soucasne vedle sebe.
-
Ac to zni extremne ucelove subejktivne, je to uhel pohledu.
Není to úhel pohledu. Z jedné strany tečou data dovnitř, z druhé ven. V MapReduce, Sparku, Flinku,... a bambilionech dalších.
Tak asi to teda vypadá, že jsou všichni pitomí a plýtvají energií zatímco by to šlo celý udělat s násobnou efektivitou :)
Doporučoval bych ti, abys do té implementace šel. Lidi ti utrhají ruce, když jim cluster spočítá to samý, akorát místo megawatthodiny spotřebuje tři kilowatthodiny. Tím jsem si celkem jistej :)
Narazis na vic veci naraz, streamove zpracovani vs zpracovavani velkych dat. Oboje ma sve specififka a pozadavky na ne nejsou zamenitelne.
-
proste paralelni zpracovani dat je zaprve pouze cteni dat(kde zamky nejsou potreba)
To přece obecně není pravda. Platí to jenom v případě, že mi ta vstupní data nemůže někdo mezi tím přepsat (takže bych jedním vláknem zpracovával generaci 1 a druhým generaci 2 a reducem pak sčítal hrušky s jabkama). Pokud tohle nechci dopustit, tak musím mít buď read lock, nebo imutabilní data.
a i kdyby ne, tak se rozdeluji data na casti, ktere se mohou zpracovavat paralelne(konkurencne?) ale nezasahuji do sebe navzajem. Proste polopate mate velkou mnozinu dat
Aneb o koze a o voze... Pokud mám takové množství dat, že je zpracovávám sto stroji a nejsou mezi nimi žádné vazby, tak samozřejmě funkcionální přístup uvnitř toho jednoho stroje nic nepřinese. Ale to je snad každýmu jasný a o tomhle scénáři vůbec není řeč, ne?
Narazis na vic veci naraz, streamove zpracovani vs zpracovavani velkych dat. Oboje ma sve specififka a pozadavky na ne nejsou zamenitelne.
Ne. Mluvím o tom, že funkcionální přístup "masomlejnek je když mi jde dovnitř maso a ven mletý maso" se prosazuje v čímdál větším množství oblastí. Protože prostě má určité výhody. A zase jiné nevýhody. Nikdo tady snad nikdy netvrdil, že FP je dobrý vždycky, všude, na všechno a se sovětským svazem na věčné časy, ne?
Jediný, co tady děláme, je vyvracení obvyklých výhrad proti FP, které pramení z neznalosti nebo overgeneralizace.
-
(Otázka "a co z toho plyne?" pořád zůstává, akorát už asi ani nechci slyšet odpověď, protože jediný, co tady demonstruješ, je, že i v "OOP jazyce" se dá programovat funkcionálním stylem, což není pro nikoho žádný překvápko. Je to stejný jako že i céčku se dá psát objektově. I v assembleru. I když budeš zadávat ed-em stroják, můžeš programovat funkcionálně, objektově, strukturovaně, špagetově... Myslíš, že to někoho překvapuje nebo o co go?)
Takže jsme se shodli na tom, že i v objektových jazycích lze programovat funkcionálně. Nemám tedy důvod přecházet na nějaký funkcionální jazyk, neboť by pro mne nepředstavoval žádnou přidanou hodnotu. Vše potřebné najdu i v objektových jazycích.
Jen se stále divím, jak tě to překvapuje. Nebo snad ne?
-
Je zajímavé, jak je v módě FP, ale když se zmíním o tom, že používám XSLT, tak se mi blbí začnou smát.
No tak pokud chci programovat funkcionálně v něčem plném špičatých závorek, co je proslulé naprostou nečitelností, tak stejně preferuju C++ šablony. Pokud se s FP často setkáváš právě v podobě XSLT, tak opravdu rozumím tvé averzi. :)
Jaké averzi? XSLT je pro mne krásně čitelné, dobře se mi to píše a je to i rychlé. Naopak mám averzi vůči Smarty, Twigu a podobným zmetkům, které svádí ke strkání business logiky do šablon.
-
Takže jsme se shodli na tom, že i v objektových jazycích lze programovat funkcionálně.
Jistě. I v assembleru. A BASICu. Nenapadlo by mě, že by o tom mohl někdo pochybovat.
Nemám tedy důvod přecházet na nějaký funkcionální jazyk, neboť by pro mne nepředstavoval žádnou přidanou hodnotu.
To z předchozího neplyne.
Konzervu můžu otevírat šroubovákem. Nemám tedy důvod přecházet na otvírák. Q.E.D.
Konktrétně jde o to, že funkcionální jazyk typicky nějaké vlastnosti vynucuje. Tj. jsi nějak omezen, něco nemůžeš. A pokud něco nemůžeš, máš nějakou informaci o tom, že se něco z principu nemůže stát a tedy že neco platí. Čili zkráceně: v důsledku omezení máš víc informací, víc jistoty.
Pokud programuješ FP stylem v jazyce, který žádné FP vlastnosti nevynucuje, žádnou jistotu nemáš. Máš jenom starou dobrou nejistotu.
Už jsem to tady psal víckrát: Erlang vynucuje imutabilní data => máš jistotu, že jakékoliv odkazy (reference) v jakékoliv datové struktuře vedou jenom směrem "dozadu" (ke starším datům) a i od nich dál jenom stejným směrem. Pokud máš imutabilní objekt v jiném jazyce, může obsahovat odkaz na mutabilní data => jistotu nemáš.
-
Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat.
V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.
lakovna <původní_auto >přebarvené_auto
-
V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.
Silně NEdoporučuju používat analogie z reálného světa. Ještě jsem nikde nepotkal referenci na auto. Nikdy se mi nepodařilo autem odjet do práce a zároveň dát referenci manželce, aby vyzvedla děcka ze školy.
-
V reálném světě auto zavezu do lakovny a vyjedu s přebarveným autem.
Silně NEdoporučuju používat analogie z reálného světa. Ještě jsem nikde nepotkal referenci na auto. Nikdy se mi nepodařilo autem odjet do práce a zároveň dát referenci manželce, aby vyzvedla děcka ze školy.
A to máte jenom z toho že se doma nebavíte objektovým ale funcionálním jazykem sakra přece!
-
A to máte jenom z toho že se doma nebavíte objektovým ale funcionálním jazykem sakra přece!
Kdybysme žili v objektovém světě, tak pojedu po dálnici a z ničehožnic to napálím do svodidel, protože manželka zatočila ke škole a zapomněli jsme dát zámek na volant ;)
-
Ale ted skoro vazne. Cele "funkcionalni paradigma" stoji na "immutable objektech"(pisu to uvozovkach, aby mi tady nekdo nevycital detaily) a cely immutable svet do extremu dovedeny je dost neefektivni. Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat. Jeste lepsi a uplne nejefektivnejsi by bylo,kdybychom umeli barvu zmenit(coz neumime).
Záleží na struktuře. V FP jazycích lidé rádi používají stromy, v imperativních hash tabulky. Změna prvku ve stromu má logaritmickou space-složitost - tzn. vyrobíte akorát novou "cestu" k prvku, všechno ukazuje na staré struktury. Není to tak efektivní jako imperativní (kde se změní jeden prvek), ale ani to není tak hrozné.
Jenomže pak třeba přijde něco jako potřeba provést nějaké undo - a v FP najednou máte k dispozici naprosto bez problémů historii změn a to v celkem kompaktní podobě, zatímco v imperativním to začne být docela zajímavý oříšek, pokud nechcete při každé změně dělat plnou kopii původní struktury...
Proc se chcete vzdavat vyhody dostatecnosti tohoto zjednoduseneho modelu(a zni plynouci mensi energeticke narocnosti) na ukor korektnosti ale vetsi (energeticke) narocnosti?
That's the tradeoff... někdy (docela často) jsou tím vzácnějším zdrojem programátoři... a já osobně jsem hodně líný a dělám spoustu chyb, takže čím víc toho po mně počítač je schopen zkotrolovat, tím jsem šťastnější...
-
Už jsem to tady psal víckrát: Erlang vynucuje imutabilní data => máš jistotu, že jakékoliv odkazy (reference) v jakékoliv datové struktuře vedou jenom směrem "dozadu" (ke starším datům) a i od nich dál jenom stejným směrem. Pokud máš imutabilní objekt v jiném jazyce, může obsahovat odkaz na mutabilní data => jistotu nemáš.
Tohle obecně neplatí, jde to zajistit i jinak než imutabilními daty, třeba pouze jednou mutabilní referencí: https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html
-
Tohle obecně neplatí, jde to zajistit i jinak než imutabilními daty, třeba pouze jednou mutabilní referencí: https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html
1. Tohle je opravdu zajímavý, moc se mi to na Rustu líbí.
2. Rust je afaik jediný jakžtakž rozšířený jazyk, který tohle dělá.
3. Kit nemluvil o Rustu.
4. Ale především: mluvil jsem o tom, že Erlang/Elixir ti zabezpečuje, že v datech nemáš kruhové reference (nemůžeš je udělat i kdyby ses na hlavu postavil - prostě na to v jazyku není nástroj). Pokud jsem správně pochopil tenhle rustí mechanismus, jeho smyslem je hlídat uvolňování paměti. Neexistenci kruhových referencí nijak nezaručuje (viz např. https://users.rust-lang.org/t/circular-reference-issue/9097)
Když budeme hnidopiši, tak máš ale pravdu - napsal jsem "pokud máš imutabilní objekt v jiném jazyce", což je špatně. Správně mělo být "pokud máš imutabilní objekt v jazyce, který imutabilitu nevynucuje". Bylo to v té předchozí větě :)
-
1. Tohle je opravdu zajímavý, moc se mi to na Rustu líbí.
2. Rust je afaik jediný jakžtakž rozšířený jazyk, který tohle dělá.
3. Kit nemluvil o Rustu.
4. Ale především: mluvil jsem o tom, že Erlang/Elixir ti zabezpečuje, že v datech nemáš kruhové reference (nemůžeš je udělat i kdyby ses na hlavu postavil - prostě na to v jazyku není nástroj). Pokud jsem správně pochopil tenhle rustí mechanismus, jeho smyslem je hlídat uvolňování paměti. Neexistenci kruhových referencí nijak nezaručuje (viz např. https://users.rust-lang.org/t/circular-reference-issue/9097)
Rust a kruhové reference to je téma, o kterém by se dala napsat diplomka... Obecně Rust kruhové reference nedovoluje. Ve standardním kódu se nedají udělat, neprojde to přes borrow checker a skončí chybou při kompilaci. Jde to ale obejít použitím std::rc::Rc a std::cell::RefCell, nicméně to znamená, že kontrola správnosti kódu se přesune až do runtime. Pokud použiju std::rc::Rc a udělám to z hlediska pravidel borrow checkeru špatně, překladač na to nepřijde, klidně takový kód přeloží a spadne to až v runtime (definovaně). Obecně to ale není rust-way, takhle by se to v Rustu dělat nemělo, lepší je refaktorovat datovou strukturu tak, aby tam kruhové reference nemusely být.
-
Rust a kruhové reference to je téma, o kterém by se dala napsat diplomka... Obecně Rust kruhové reference nedovoluje. Ve standardním kódu se nedají udělat, neprojde to přes borrow checker a skončí chybou při kompilaci. Jde to ale obejít použitím std::rc::Rc a std::cell::RefCell, nicméně to znamená, že kontrola správnosti kódu se přesune až do runtime. Pokud použiju std::rc::Rc a udělám to z hlediska pravidel borrow checkeru špatně, překladač na to nepřijde, klidně takový kód přeloží a spadne to až v runtime (definovaně). Obecně to ale není rust-way, takhle by se to v Rustu dělat nemělo, lepší je refaktorovat datovou strukturu tak, aby tam kruhové reference nemusely být.
Aha, tak takhle detailně do toho nevidím. Dík moc za doplnění.
-
Funkce jsou ve FP přece také konstanty.
Tohle je nesmyslné tvrzení, funkce jsou objekty jako třeba čísla. Konstantní může být tak nanejvýš reference, potažmo přiřazení do proměnné.
-
Funkce jsou ve FP přece také konstanty.
Tohle je nesmyslné tvrzení, funkce jsou objekty jako třeba čísla. Konstantní může být tak nanejvýš reference, potažmo přiřazení do proměnné.
Ve FP nemůže být přiřazení do proměnné, neboť tam žádné nejsou.
-
Funkce jsou ve FP přece také konstanty.
Tohle je nesmyslné tvrzení, funkce jsou objekty jako třeba čísla. Konstantní může být tak nanejvýš reference, potažmo přiřazení do proměnné.
Ve FP nemůže být přiřazení do proměnné, neboť tam žádné nejsou.
Neuhýbej a přiznej, žes napsal blbost.
-
Funkce jsou ve FP přece také konstanty.
Tohle je nesmyslné tvrzení, funkce jsou objekty jako třeba čísla. Konstantní může být tak nanejvýš reference, potažmo přiřazení do proměnné.
Ve FP nemůže být přiřazení do proměnné, neboť tam žádné nejsou.
Neuhýbej a přiznej, žes napsal blbost.
Konstanta je od toho, že je konstantní, tj. po dobu svého života se nemění. A je úplně jedno, jak ji vytvořím.
const x = muj_skvely_konstruktor(moje_jeste,lepsi,parametry)
je u mě pořád konstanta. Jestli u tebe ne, hádat se o to nebudu, je mi to jedno, jak tomu cheš říkat, OOP stylem se samými takovými objekty stejně nic nenaprogramuješ. Jenom budeš (špatně a zbytečně krkolomně) imitovat funkcionální styl.
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
-
Ve FP nemůže být přiřazení do proměnné, neboť tam žádné nejsou.
Máš bordel v tom, co je konstanta, a chceš řešit co je proměnná? Natož to, zda jsou ve FP? V tom máš jasno? :-)
-
Ve FP nemůže být přiřazení do proměnné, neboť tam žádné nejsou.
Máš bordel v tom, co je konstanta, a chceš řešit co je proměnná? Natož to, zda jsou ve FP? V tom máš jasno? :-)
Tak povídej, sděl nám svůj názor na vlastnosti FP.
-
" Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat."
no a tím se i do reálného světa vnesla nekonzistence a je zaděláno na průser - je nutné (ideálně v transakci :-/) změnit údaje ve velkém techničáku, v malém techničáku, megapoctivá ovečka by šla ještě oznámit, aby si MP změnila fotky z radarů :-) apod.
Dtto podobná "jednoduchá změna": osoba.setSurname("Novák"). No v SW jednoduché, v praktickém světě se po této změně ta osoba nachází v dost zvláštním režimu, třeba jí taky nemusí dát na poště její doporučený dopis, problémy v bance apod.apod.
Krátce - mutabilita je dost problematický koncept. Nebudu se moc rozepisovat, protože Rich Hickey o tom dokáže mluvit mnohem líp - https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey. Fakt doporučuju přečíst, jinak budou debaty OOP vs FP dost plytké...
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci? nebo už jenom trolujete?
-
" Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat."
no a tím se i do reálného světa vnesla nekonzistence a je zaděláno na průser - je nutné (ideálně v transakci :-/) změnit údaje ve velkém techničáku, v malém techničáku, megapoctivá ovečka by šla ještě oznámit, aby si MP změnila fotky z radarů :-) apod.
Dtto podobná "jednoduchá změna": osoba.setSurname("Novák"). No v SW jednoduché, v praktickém světě se po této změně ta osoba nachází v dost zvláštním režimu, třeba jí taky nemusí dát na poště její doporučený dopis, problémy v bance apod.apod.
Krátce - mutabilita je dost problematický koncept. Nebudu se moc rozepisovat, protože Rich Hickey o tom dokáže mluvit mnohem líp - https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey. Fakt doporučuju přečíst, jinak budou debaty OOP vs FP dost plytké...
Model v počítači je homomorfní model reality, nemusí být izomorfní. Otázka tedy zní, potřebujeme izomorfní modely reality? Zajistí je imutabilita? A filozofická otázka na to navazující, je náš svět izomorfním modelem ideálů? Kvantová mechanika ukazuje, že nikoliv.
-
" Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat."
no a tím se i do reálného světa vnesla nekonzistence a je zaděláno na průser - je nutné (ideálně v transakci :-/) změnit údaje ve velkém techničáku, v malém techničáku, megapoctivá ovečka by šla ještě oznámit, aby si MP změnila fotky z radarů :-) apod.
Dtto podobná "jednoduchá změna": osoba.setSurname("Novák"). No v SW jednoduché, v praktickém světě se po této změně ta osoba nachází v dost zvláštním režimu, třeba jí taky nemusí dát na poště její doporučený dopis, problémy v bance apod.apod.
Krátce - mutabilita je dost problematický koncept. Nebudu se moc rozepisovat, protože Rich Hickey o tom dokáže mluvit mnohem líp - https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey. Fakt doporučuju přečíst, jinak budou debaty OOP vs FP dost plytké...
Model v počítači je homomorfní model reality, nemusí být izomorfní. Otázka tedy zní, potřebujeme izomorfní modely reality? Zajistí je imutabilita? A filozofická otázka na to navazující, je náš svět izomorfním modelem ideálů? Kvantová mechanika ukazuje, že nikoliv.
Vyborne, diky za potvrzeni, ze ani OOP modeluje pouze subset reality :) Ad kvantova mechanika - na to pozor, ona neni uplna, ma sve jasne dane meze.
-
" Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat."
no a tím se i do reálného světa vnesla nekonzistence a je zaděláno na průser - je nutné (ideálně v transakci :-/) změnit údaje ve velkém techničáku, v malém techničáku, megapoctivá ovečka by šla ještě oznámit, aby si MP změnila fotky z radarů :-) apod.
Dtto podobná "jednoduchá změna": osoba.setSurname("Novák"). No v SW jednoduché, v praktickém světě se po této změně ta osoba nachází v dost zvláštním režimu, třeba jí taky nemusí dát na poště její doporučený dopis, problémy v bance apod.apod.
Krátce - mutabilita je dost problematický koncept. Nebudu se moc rozepisovat, protože Rich Hickey o tom dokáže mluvit mnohem líp - https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey. Fakt doporučuju přečíst, jinak budou debaty OOP vs FP dost plytké...
Model v počítači je homomorfní model reality, nemusí být izomorfní. Otázka tedy zní, potřebujeme izomorfní modely reality? Zajistí je imutabilita? A filozofická otázka na to navazující, je náš svět izomorfním modelem ideálů? Kvantová mechanika ukazuje, že nikoliv.
Pokud vytváříme aplikaci pro registr vozidel či registr obyvatel, tak skutečně volání vozidlo.setColor("modrá") nebo osoba.setSurname("Novák") nedávají smysl. V každém vstupním formuláři do takového registru je těch kolonek mnohem víc.
-
" Vezmete si ze mate auto a chcete mu zmenit barvu ... myslite, ze bude jednodussi mit immutable auto a vytvorit kopii auta s jinou barvou(i v realnem svete)? Ne, jednodussi bude tu barvu prestrikat."
no a tím se i do reálného světa vnesla nekonzistence a je zaděláno na průser - je nutné (ideálně v transakci :-/) změnit údaje ve velkém techničáku, v malém techničáku, megapoctivá ovečka by šla ještě oznámit, aby si MP změnila fotky z radarů :-) apod.
Dtto podobná "jednoduchá změna": osoba.setSurname("Novák"). No v SW jednoduché, v praktickém světě se po této změně ta osoba nachází v dost zvláštním režimu, třeba jí taky nemusí dát na poště její doporučený dopis, problémy v bance apod.apod.
Krátce - mutabilita je dost problematický koncept. Nebudu se moc rozepisovat, protože Rich Hickey o tom dokáže mluvit mnohem líp - https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey. Fakt doporučuju přečíst, jinak budou debaty OOP vs FP dost plytké...
Model v počítači je homomorfní model reality, nemusí být izomorfní. Otázka tedy zní, potřebujeme izomorfní modely reality? Zajistí je imutabilita? A filozofická otázka na to navazující, je náš svět izomorfním modelem ideálů? Kvantová mechanika ukazuje, že nikoliv.
Těchto termínů bych se raději vyvaroval. Ani QM bych do toho nemontoval.
Že počítačový model může být odlišný od reálného světa, se dá krásně ilustrovat na relačním databázovém modelu. Papírová kartotéka se vede odlišně, ale před relačním modelem se databáze modelovaly analogicky papírovým kartotékám, na něž byli tehdy lidé zvyklí. Že pro počítač je přirozenější odlišný model, to nebylo tenkrát tak zřejmé. Ale zároveň by to měla být motivace pro analytiky, navrhující strukturu programu a jeho dat, že intuitivní, přímočarý model reality může být hodně vzdálen optimálnímu abstraktnímu modelu, určenému počítači. Snaha křečovitě vytvářet paralelní abstraktní struktury k reálnému světu se velmi neblaze podepsala na objektovém návrhu - nebál bych se říci - většiny programů.
-
@tisnik
No on je nekonzistentní i ten reálný svět, například v našem makrosvětě světě jeden elektron, odpovídá jakby mnoha elektronům v kvantovém světě, náš makrosvět je neúplným homomorfním obrazem kvantového světa. A kvantový svět, zase neúplným snad homomorfním obrazem světa ideálů, který je pro nás empiricky nepoznatelný :-)
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
-
@tisnik
No on je nekonzistentní i ten reálný svět, například v našem makrosvětě světě jeden elektron, odpovídá jakby mnoha elektronům v kvantovém světě, náš makrosvět je neúplným homomorfním obrazem kvantového světa. A kvantový svět, zase neúplným snad homomorfním obrazem světa ideálů, který je pro nás empiricky nepoznatelný :-)
Ne. Reálný svět je dokonale konzistentní ze své podstaty. Naše fyzikální modely reality nejsou dokonalé, neboť jsou založeny pouze na neúplné informaci o realitě.
XXXmorfismy jsou pojmy algebry, týkají se algebraických struktur. Jejich použití v kontextu, jaký naznačujete, je naprosto nevhodné.
-
@tisnik
No on je nekonzistentní i ten reálný svět, například v našem makrosvětě světě jeden elektron, odpovídá jakby mnoha elektronům v kvantovém světě, náš makrosvět je neúplným homomorfním obrazem kvantového světa. A kvantový svět, zase neúplným snad homomorfním obrazem světa ideálů, který je pro nás empiricky nepoznatelný :-)
Ne. Reálný svět je dokonale konzistentní ze své podstaty. Naše fyzikální modely reality nejsou dokonalé, neboť jsou založeny pouze na neúplné informaci o realitě.
XXXmorfismy jsou pojmy algebry, týkají se algebraických struktur. Jejich použití v kontextu, jaký naznačujete, je naprosto nevhodné.
Morfismy v nejobecnější podobě jsou pojmy z teorie kategorií, algebraické struktury jsou jen speciální případ.
-
@kiwi
No kvantová mechanika a náš pohled z makrosvěta (měření) je typický homomorfismus. Z našeho směru pohledu nedokážeme rozlišit entitu, ze které pochází obraz v našem světě a zřejmě platí, že kvantové entitě odpovídá právě jedna entita v našem světě (rozpad vlnové funkce měřením). A měření je de facto samotná existence každého hmotného objektu v našem světě. Směšné je, že změna v našem světě se nemusí projevit změnou v kvantovém světě. Takže situace je stejná jako v modelování světa počítačem. Tedy co do typu zobrazení.
Zajímavé je, že homomorfismus se nám zdá nepřirozený, ale je i ve světě, který nás obklopuje docela běžný. Komutativnost, kterou porušuje, je spíše jen matematická vlastnost algeber, která často nemá pokrytí v reálném světě a je často iluzorní. Ale školou naučeni proměřovat svět běžnou algebrou, tíhneme k izomorfismu, aby byla komutativnost zaručena, cítíme se tak ve známém prostředí i když odporuje realitě.
A to se samozřejmě promítá i do paradigmatu programování.
Zajímavá přednáška zde https://www.youtube.com/watch?v=JI9-p_dIlB0
-
@tisnik
No on je nekonzistentní i ten reálný svět, například v našem makrosvětě světě jeden elektron, odpovídá jakby mnoha elektronům v kvantovém světě, náš makrosvět je neúplným homomorfním obrazem kvantového světa. A kvantový svět, zase neúplným snad homomorfním obrazem světa ideálů, který je pro nás empiricky nepoznatelný :-)
Ne. Reálný svět je dokonale konzistentní ze své podstaty. Naše fyzikální modely reality nejsou dokonalé, neboť jsou založeny pouze na neúplné informaci o realitě.
XXXmorfismy jsou pojmy algebry, týkají se algebraických struktur. Jejich použití v kontextu, jaký naznačujete, je naprosto nevhodné.
To máte pohled newtonovské fyziky. Fyzikální modely nejsou dokonalé ne proto, že jsou založeny na neúplné informaci o realitě, ale proto, že některé oblasti nejsou poznatelné jako takové a to je jejich fundamentální vlastnost.
-
@ kiwi
Ideálem jsem nemyslel algebraickou strukturu, ale ideál (ideu) v platonském smyslu. Málo kdy se vyjadřuji terminologicky přesně. Moje chyba.
-
Reálný svět je dokonale konzistentní ze své podstaty.
Jaký má tahle věta význam? Vůbec jí nerozumím. Co vlastně o tom reálném světě říká?
-
Reálný svět je dokonale konzistentní ze své podstaty.
Jaký má tahle věta význam? Vůbec jí nerozumím. Co vlastně o tom reálném světě říká?
Reakce na fyzikální modely reálného světa. Naše teorie, naše modely reálného světa nejsou konzistentní, ale to neznamená, že sám reálný svět kvůli tomu není konzistentní. Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem. V našem teoretickém modelu kupř. nejde dohromady kvantovka s obecnou relativitou. Ale v reálném světě žádná nekonzistence v tomto ohledu neexistuje, žádné core dumpy na nás odnikud nevyskakují.
Ale to jsou zase ty páně Nového široké příměry a analogie, podle mě trochu zbytečně obšírné. V tomto jsem přízemní - kvantová teorie se snaží modelovat chování mikrosvěta a tak ji taky beru, ne jako nějakou filosofii. Algebra analyzuje abstraktní, dobře definované matematické objekty a v této oblasti taky chápu její terminologii, přesně zavedenou. Ale nevidím rád, když se tím začne argumentovat při aplikaci na objekty mimo její rámec. Buď tedy nejdřív dokážu, že daný reálný objekt se dá reprezentovat třeba svazem, a pak mohu šermovat izomorfismy, automorfismy dle libosti. Ovšem bez toho je to na úrovni disputace, co by asi tak mohlo být opakem krávy.
-
Reakce na fyzikální modely reálného světa. Naše teorie, naše modely reálného světa nejsou konzistentní, ale to neznamená, že sám reálný svět kvůli tomu není konzistentní.
Ale co by to mělo znamenat, že "svět je konzistentní" nebo "nekonzistentní"?!
Teorie je nekonzistentní (sporná) [sama se sebou] tehdy, když je v ní nějaký rozpor (tvrdí A a zároveň nonA).
Dvě různé teorie můžou být nekonzistentní navzájem, když jedna tvrdí A a druhá nonA.
Model reálného světa může být nekonzistentní s tím světem, jestliže předpovídá A a přitom v reálném světě platí nonA.
Jak by ale mohl být konzistentní nebo nekonzistentní reálný svět [sám se sebou]?! Svět prostě je takový, jaký je. Nic netvrdí. Žádné A a nonA v něm neexistuje. Kritérium konzistence pro něj nemá smysl stejně jako nemá smysl chuť pro zvuk. Svět prostě jenom JE.
-
Reálný svět je dokonale konzistentní ze své podstaty.
Jaký má tahle věta význam? Vůbec jí nerozumím. Co vlastně o tom reálném světě říká?
Reakce na fyzikální modely reálného světa. Naše teorie, naše modely reálného světa nejsou konzistentní, ale to neznamená, že sám reálný svět kvůli tomu není konzistentní. Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem. V našem teoretickém modelu kupř. nejde dohromady kvantovka s obecnou relativitou. Ale v reálném světě žádná nekonzistence v tomto ohledu neexistuje, žádné core dumpy na nás odnikud nevyskakují.
Ale to jsou zase ty páně Nového široké příměry a analogie, podle mě trochu zbytečně obšírné. V tomto jsem přízemní - kvantová teorie se snaží modelovat chování mikrosvěta a tak ji taky beru, ne jako nějakou filosofii. Algebra analyzuje abstraktní, dobře definované matematické objekty a v této oblasti taky chápu její terminologii, přesně zavedenou. Ale nevidím rád, když se tím začne argumentovat při aplikaci na objekty mimo její rámec. Buď tedy nejdřív dokážu, že daný reálný objekt se dá reprezentovat třeba svazem, a pak mohu šermovat izomorfismy, automorfismy dle libosti. Ovšem bez toho je to na úrovni disputace, co by asi tak mohlo být opakem krávy.
No spíše mi tentokrát šlo o vidění homomorfismů kolem sebe a jejich modelování, že jsou docela obvyklé, tvrdím, že lidé díky výchově, tedy znalosti počítání, sklouzávají k izomorfismům, i programátoři, tam kde by stačil homomorfismus, cpou izomorfismus, u "sčítání" a "násobení" chtějí, aby bylo komutativní, když v realitě většinou komutativní je málo co. Takové podvědomé tíhnutí k izomorfismům se zdá býti dnes moderní. A napadlo mě to, když tady někdo požadoval v souvislostí s FP a OOP, aby jimi popisovaný model měl izomorfní vztah k realitě a tím zdůvodňoval nutnost používání imutability.
Jinak v reálném makrosvětě na nás core dumpy vyskakují, je na nich postavena současná elektronika, která právě využívá takového core dumpu - tunelového jevu :-)))
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
Jasně, tímto explicitně cituji M. Prýmka v tomto vlákně ;)
A doplním, když už jsme u toho, že to je funkce A^0->B, čili jak citovaný objasnil, nulární.
-
Reakce na fyzikální modely reálného světa. Naše teorie, naše modely reálného světa nejsou konzistentní, ale to neznamená, že sám reálný svět kvůli tomu není konzistentní.
Ale co by to mělo znamenat, že "svět je konzistentní" nebo "nekonzistentní"?!
Teorie je nekonzistentní (sporná) [sama se sebou] tehdy, když je v ní nějaký rozpor (tvrdí A a zároveň nonA).
Dvě různé teorie můžou být nekonzistentní navzájem, když jedna tvrdí A a druhá nonA.
Model reálného světa může být nekonzistentní s tím světem, jestliže předpovídá A a přitom v reálném světě platí nonA.
Jak by ale mohl být konzistentní nebo nekonzistentní reálný svět [sám se sebou]?! Svět prostě je takový, jaký je. Nic netvrdí. Žádné A a nonA v něm neexistuje. Kritérium konzistence pro něj nemá smysl stejně jako nemá smysl chuť pro zvuk. Svět prostě jenom JE.
Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem.
Co je na tom k nepochopení? Zatímco naše modely těchto složek se vzájemně dostávají do rozporu, složky samé v realitě nikoli.
Jinak v reálném makrosvětě na nás core dumpy vyskakují, je na nich postavena současná elektronika, která právě využívá takového core dumpu - tunelového jevu :-)))
Ale jako "core dump" se to právě jeví jen z hlediska klasické fyziky, tedy jednoho z našich modelů reality. Pro kvantovku už to problém není, tím méně lze tvrdit, že je to nějaký fault reality, protože Všehomír udělal něco špatně a má tu nějaký leak, jakýsi zapomenutý pointer. Ne, je to v pořádku. Na tunelovém jevu není vůbec nic zvláštního nebo "chybného", prostě je, úplně normálně a přirozeně, jako když planety obíhají kolem Slunce nebo jablko padající na zem, a navíc je naprosto konzistentní s "elektromagnetismem", "obecnou relativitou", "termodynamikou" atd. (ty uvozovky mají zdůraznit konzistenci s jevy, jež ty teorie zkoumají, nikoli nezbytně s těmi teoriemi samotnými).
-
alfa a omega Ivana Noveho je ze velmi rad aplikuje poznatky z presne ohranicene domeny na lidstvo, svet ci Vesmir jako takovy .. ano je to lakave, prinasi to neotrely pohled na svet ale tim to konci, vzdy je nutno testovat proti realite (experimentem) zda ty jeho hezke analogie maji jiny vyznam nez plane placani ...
Vesmir samozrejme je zcela konzsistentni to ze na aktualnim stupni vyvoje lidstvo neni schopne vse poznat (asi i vsechny fyzikalni interakce viz problem temne energie ..) je fakt ze ktereho holt nekdo muze byt frustrovany
ono je vubec otazkou zda za treba par set let nebudou vsechny soucasne fyzikalni teorie opet nazyvany "klasickou mechanikou" s takovym tim drobnym podtextem, jako my nyni nazyvame Newtonovu eru , z jejich pohledu na nasi dobu
spis by mne zajimala otazka objektivni poznatelnosti pro zviratko jako je clovek, zda je to vubec mozne
vzdyt neumime ani otestovat zda skutecne nezijeme nahodou ve dvanactistenu (dodekahedron - jde si to do detailu predstavit ?) apod., natoz paralelni vesmiry atd ...
to same mne napada zda vyvoj pocitacu od 40.let min. stoleti byl s ohledem na tehdejsi a pozdejsi stav poznani nutne jediny mozny nebo se mohl vydat jinym smerem ...
-
Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem.
Co je na tom k nepochopení? Zatímco naše modely těchto složek se vzájemně dostávají do rozporu, složky samé v realitě nikoli.
Obrat "složky reality se nedostávají do rozporu" je stejně nepochopitelný jako "světlo této baterky je sladké".
Jak by se nějaké složky reálného světa mohly dostat do rozporu? Jak by se to projevovalo? Viděls někdy rozpor mezi hruškou a jabkem?
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
Jasně, tímto explicitně cituji M. Prýmka v tomto vlákně ;)
A doplním, když už jsme u toho, že to je funkce A^0->B, čili jak citovaný objasnil, nulární.
a nezacyklí se to?
-
Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem.
Co je na tom k nepochopení? Zatímco naše modely těchto složek se vzájemně dostávají do rozporu, složky samé v realitě nikoli.
Obrat "složky reality se nedostávají do rozporu" je stejně nepochopitelný jako "světlo této baterky je sladké".
Jak by se nějaké složky reálného světa mohly dostat do rozporu? Jak by se to projevovalo? Viděls někdy rozpor mezi hruškou a jabkem?
Krista pána, mně to nevysvětluj, to vysvětli jinému diskutérovi tady. Taky si to neumím představit a tím pádem ani slovně vystihnout.
Rozpor mezi jabkem a hruškou je asi takový, že když jsem poznal pouze jabka a vyvinul jsem krásnou teorii o nich, tak objevením hrušky se to celé zkomplikuje. Ale furt se bavíme o rozporu našich teorií, protože samotná existence jabka a hrušky vedle sebe dokazuje, že musí existovat teorie, která zahrnuje obojí vedle sebe, a to, že ji nemáme, není problémem hrušek, ale jen naším problémem.
Nebyl jsem to já, kdo tu začal rozvíjet myšlenky, že samotná realita není konzistentní a že příkladem takové nekonzistence je tunelový jev.
Tím na toto téma končím. Připadá mi to jasné a komu ne, tak problém bude na jeho přijímači. :)
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
Jasně, tímto explicitně cituji M. Prýmka v tomto vlákně ;)
A doplním, když už jsme u toho, že to je funkce A^0->B, čili jak citovaný objasnil, nulární.
a nezacyklí se to?
To je nějaký mimořádně dementní pokus o trolling?
-
Reálný svět, tedy Vesmír, samozřejmě konzistentní je, tedy všechny jeho složky navzájem.
Co je na tom k nepochopení? Zatímco naše modely těchto složek se vzájemně dostávají do rozporu, složky samé v realitě nikoli.
Obrat "složky reality se nedostávají do rozporu" je stejně nepochopitelný jako "světlo této baterky je sladké".
Jak by se nějaké složky reálného světa mohly dostat do rozporu? Jak by se to projevovalo? Viděls někdy rozpor mezi hruškou a jabkem?
Konzistence (nebo rozpor) může existovat jen vzhledem k nějakému modelu nebo teorii. Třeba to, že se v černých dírách ztrácí informace, i když si myslíme, že se nemůže nikdy nikde ztrácet, je rozpor. Buď je špatně ten zákon (ve skutečnosti hypotéza) o zachování informace, nebo se v černých dírách informace neztrácí (současná hypotéza je, že B je správně, viz Hawking). Ve fyzice máme alespoň to štěstí, že většina takových “rozporů” se projevuje jen v okrajových případech, takže místo zavrhnutí celé příslušné teorie se prostě jen poupraví.
-
Nebyl jsem to já, kdo tu začal rozvíjet myšlenky, že samotná realita není konzistentní a že příkladem takové nekonzistence je tunelový jev.
No když někdo napíše krávovinu, že zvuk kostelního zvonu je sladký, tak mu nemáš odpovídat, že je kyselý :)
Není ani kyselý, ani sladký, tyhle pojmy pro zvuk nedávají smysl. A stejně tak pojem "konzistentnosti" nedává smysl pro reálný svět.
Ale tak aspoň jsme se na tom snad nakonec shodli :)
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
Jasně, tímto explicitně cituji M. Prýmka v tomto vlákně ;)
A doplním, když už jsme u toho, že to je funkce A^0->B, čili jak citovaný objasnil, nulární.
a nezacyklí se to?
To je nějaký mimořádně dementní pokus o trolling?
pokud je číslo 42 funkce, z jaké množiny jsou její hodnoty?
-
pokud je číslo 42 funkce, z jaké množiny jsou její hodnoty?
Mám-li třídu:
class C {
fn foo(Int): Int
fn boo(Float): Float
fn doo(Int, Float): [String]
fn noop(): Int
}
z jaké množiny je hodnota noop ?
A nebo takovej ten starej vtip, co je ekvivalení 1 + 1.
Pokud je číslo 42 nulární funkce, tak její hodnota je 42, a je z množiny nulárních funkcí reprezentující přirozená čísla.
-
z jaké množiny je hodnota noop ?
Z mnoziny vsech procedur. Nebo chces-li presneji, z mnoziny vsech procedur typu (C) -> Int.
-
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
funkce jsou objekty jako třeba čísla
Čísla jsou nulární funkce ;)
Konstanta je funkce, ale ne naopak, jak psal kit
můžete uvést citaci?
Čeho? Znalosti elementárních matematických definic očekávám u každého programátora.
tohohle:
Konstanta je funkce
Jasně, tímto explicitně cituji M. Prýmka v tomto vlákně ;)
A doplním, když už jsme u toho, že to je funkce A^0->B, čili jak citovaný objasnil, nulární.
a nezacyklí se to?
To je nějaký mimořádně dementní pokus o trolling?
pokud je číslo 42 funkce, z jaké množiny jsou její hodnoty?
V kontextu programování: Zvolme si nějaký jazyk, například Haskell. Číslo 42 jakožto nulární funkce je morfismem z terminálního objektu (označme T) do objektu Int. No a protože kategorie typů je kartézsky uzavřená a mohutnost Hom(T, Int) je 1, existuje přirozená ekvivalence mezi ní a oním číslem. Tolik formální vyčerpávající odpověď, jinak jde samozřejmě o množinu čísel.
-
ono je vubec otazkou zda za treba par set let nebudou vsechny soucasne fyzikalni teorie opet nazyvany "klasickou mechanikou" s takovym tim drobnym podtextem, jako my nyni nazyvame Newtonovu eru , z jejich pohledu na nasi dobu
IMO se bude nazývat "kvantovou mechanikou", protože jméno "klasická mechanika" bude obsazené úplně tím samým jako teď. Klasická mechanika funguje pořád stejně dobře i po objevu té kvantové. Tou kvantovou totiž řešíme hlavně nové problémy. Stejně tak se po objevu další revoluční fyzikální teorie bude dál používat i kvantová mechanika. Prostě proto, že pro všechno na co ji dnes používáme bude fungovat stále stejně dobře.
-
jde samozřejmě o množinu čísel.
a ty čísla jsou konstanty?
-
jde samozřejmě o množinu čísel.
a ty čísla jsou konstanty?
Vysvětlení je v příspěvku výše.
-
a ty čísla jsou konstanty?
Konstanty jsou nulární funkce, čísla jsou konstanty, tedy to jsou nulární funkce. Co je na tom k nepochopení?
Respektive teda tohle samozřejmě není dogma. Je to jeden z možných způsobů, jak se na věci dívat. Pokud by někdo chtěl mít systém takový, že konstanty jsou žampiony a čísla jsou berušky, tak klidně může. Akorát to asi nebude úplně praktické, bude se s tím blbě pracovat a než člověk napíše nějaký článek, utratí spoustu peněz za LSD.
-
a ty čísla jsou konstanty?
Konstanty jsou nulární funkce, čísla jsou konstanty, tedy to jsou nulární funkce. Co je na tom k nepochopení?
nepasuje mi to na obvyklou definici funkce, zaptal jsem se na zdroj, Kit vybízí k trolování, co je na tom k nepochopení?
-
z jaké množiny je hodnota noop ?
Z mnoziny vsech procedur. Nebo chces-li presneji, z mnoziny vsech procedur typu (C) -> Int.
To není přesné. Možná to není ani správně.
-
a ty čísla jsou konstanty?
Konstanty jsou nulární funkce, čísla jsou konstanty, tedy to jsou nulární funkce. Co je na tom k nepochopení?
nepasuje mi to na obvyklou definici funkce, zaptal jsem se na zdroj, Kit vybízí k trolování, co je na tom k nepochopení?
Hodně dělá rozdíl mezi funkcemi z FP a funkcemi se sideefectem.
Zdroj neposkytnu, ale k úplně stejnému závěru jsem došel studiem Haskellem.
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
Mimochodem dost podobně se to dělá u Javy. Vezmeš hodnotu, zakážeš její modifikaci pomocí final static a prohlásíš to za konstantu. (Ale to už je odbočka.)
-
a ty čísla jsou konstanty?
Konstanty jsou nulární funkce, čísla jsou konstanty, tedy to jsou nulární funkce. Co je na tom k nepochopení?
nepasuje mi to na obvyklou definici funkce, zaptal jsem se na zdroj, Kit vybízí k trolování, co je na tom k nepochopení?
Hodně dělá rozdíl mezi funkcemi z FP a funkcemi se sideefectem.
Zdroj neposkytnu, ale k úplně stejnému závěru jsem došel studiem Haskellem.
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
Mimochodem dost podobně se to dělá u Javy. Vezmeš hodnotu, zakážeš její modifikaci pomocí final static a prohlásíš to za konstantu. (Ale to už je odbočka.)
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
-
Hodně dělá rozdíl mezi funkcemi z FP a funkcemi se sideefectem.
Žádné funkce by neměly mít sideeffect. Je to jen zlozvyk z jazyka C.
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice), nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
-
nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Není. Haskell (AFAIK) nemá nulární fce. Dokonce nemá žádné jiné než unární ;)
-
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice)
Proč by musela? K čemu by to bylo dobré?
nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Já uvažuji takto:
Mějme nějaký element: a. Když dám tento element a do nějaké rutiny, tak si ten element ta rutina zpracuje. Nezajímá mě, zda je to 42, nebo funkce 42().
Pak mám jiný element fn x, což je element, kterej abych mohl použít, tak musím parametrizovat nějakým elementem. Buď ho do nějaké rutiny předám jako neparametrizovaný s tím, že si ho bude parametrizovat ona, nebo ho parametrizuju a teprve výsledek toho předám té rutině.
Pointa je, a v Haskellu je to hodně vidět: že funkce není nic specielního. Je to jen určitý typ elementu. A když zavolám funkci, tak ona nevrací hodnotu. Jen tím voláním vytvořím parametrizovaný element.
A Haskell pro tohle všechno má pěkné výrazy. Ale schválně jsem to opsal, aby to nemátlo a vyniklo.
Dokonce jsem uvažoval tak, že stejně jako můžeš prohlásit, že 42 je nulární funkce, tak můžeš klidně otočit, a říct, že žádná funkce, ale (fn 5) je jen parametrizovaná hodnota.
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice), nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Je to hodně teoretický pohled. Vychází to z referenční transparentnosti (či jak se referential transparency překládá). Ref. tran. říká, že můžeš libovolně zaměňovat výrazy s jejich hodnotou.
Když máš nějakou funkci A->B->C->D, tak jí můžeš postupně předávat jednotlivé parametry až dojdeme od funkce s jedním parametrem k funkci s 0 parametry. Vlastní vyhodnocení funkce se může dít buď až nakonec, nebo v průběhu, kdy se vyhodnocují části pro které už je parametrů dost. A když už je jedno, kdy se to vyhodnocuje, tak můžeme udělat ještě krůček dál a to vyhodnocení zanedbat jako nepodstatný detail úplně. Stejně nevíme, jestli to je v paměti stále jako nevyhodnocený výraz, nebo už je to vyhodnocené.
-
To není přesné. Možná to není ani správně.
Dekuji, ze jsi to podporil argumenty.
Hodně dělá rozdíl mezi funkcemi z FP a funkcemi se sideefectem.
Pouzivat vyraz funkce v takove diskuzi je zavadejici, protoze funkce ve smyslu, prog. jazyku (procedura) nemusi skoncit, mohou mit vedlejsi efekt, atd., coz je v rozporu s ciste matematickym pristupem. Pak se v tom zacnes motat, jak se ti zrovna dari.
-
Pak se v tom zacnes motat, jak se ti zrovna dari.
Nenamahej se. Jsem vytrénovanej od Kita.
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice), nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Čistě symbolicky: množina všech n-árních funkcí z A do B je B**A**n, tedy všech nulárních B**A**0, jenže A**0 je {0}, takže dostanu B**1, což je B, takže ty množiny se podle ZFC rovnají. Pohled z algebry je v Matematických strukturách od Pultra. P.S. Co vezmu jako A je jedno, protože všechny term. objekty jsou isomorfní.
-
Čistě symbolicky: množina všech n-árních funkcí z A do B je B**A**n, tedy všech nulárních B**A**0, jenže A**0 je {0}, takže dostanu B**1, což je B, takže ty množiny se podle ZFC rovnají. Pohled z algebry je v Matematických strukturách od Pultra. P.S. Co vezmu jako A je jedno, protože všechny term. objekty jsou isomorfní.
Sice je to dobře, ale bojím se, že ho to ještě víc zmate. Chybí tam ten intuitivní pohled, že se dá na funkci koukat jako na tabulku výsledků a až pak to napsat symbolicky.
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice), nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Čistě symbolicky: množina všech n-árních funkcí z A do B je B**A**n, tedy všech nulárních B**A**0, jenže A**0 je {0}, takže dostanu B**1, což je B, takže ty množiny se podle ZFC rovnají. Pohled z algebry je v Matematických strukturách od Pultra. P.S. Co vezmu jako A je jedno, protože všechny term. objekty jsou isomorfní.
tak jsem nakoukl do toho Pultra a asi jsem zjistil kde pramení tento zmatek, funkce /= operace
-
Pokud máš nulární funkci, která je referenčně transparentní, tak se to chová přesně tak, jak jsme zvyklí u konstant.
vedlejší účinky vůbec neuvažuju, za pět, nebo kolik, let s haskellem jsem k ničemu takovému nedošel, trochu rozlišuju syntaktické prvky haskellu a matematické definice a javu bych sem raději ani netahal
V tom případě nevím, co by si rád slyšel.
myslím si, že funkce by měla vypadat třeba jako f :: () -> Int (z definice), nemyslím si, že třeba g :: Int je funkce, ptám se po nějakém teoretickém vysvětlení, proč je můj dojem chybný
Čistě symbolicky: množina všech n-árních funkcí z A do B je B**A**n, tedy všech nulárních B**A**0, jenže A**0 je {0}, takže dostanu B**1, což je B, takže ty množiny se podle ZFC rovnají. Pohled z algebry je v Matematických strukturách od Pultra. P.S. Co vezmu jako A je jedno, protože všechny term. objekty jsou isomorfní.
tak jsem nakoukl do toho Pultra a asi jsem zjistil kde pramení tento zmatek, funkce /= operace
Operace je endofunkce.
-
Operace je endofunkce.
https://en.wiktionary.org/wiki/endofunction ? to zní jako A -> A
-
Operace je endofunkce.
https://en.wiktionary.org/wiki/endofunction ? to zní jako A -> A
Na doméně nesejde, pro jakékoliv A je A**0 term. objekt. Je dobré si to nakreslit - šipky z {0} do B.
-
Hodně dělá rozdíl mezi funkcemi z FP a funkcemi se sideefectem.
Žádné funkce by neměly mít sideeffect. Je to jen zlozvyk z jazyka C.
:o