Co si myslíte o OOP?

[Kit]

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.

V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.

[Reklama]

[Kit]

Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

[Kiwi]

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.

V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.

Proč?

[BaldSlattery]

Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.

A důvod?

[Kadet]

Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2

[Reklama]

[Kit]

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.

V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.

Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?

[Kit]

Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.

A důvod?

Důvod je ten, že nemám důvod pro statické typování. Ničemu to neprospěje a jen to hází klacky pod nohy.

[Kiwi]

Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2

Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora.  Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.

V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.

Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?

Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Koncept webu, tak jak to vymysleli v CERNu, je IMHO jeden z největších omylů IT za posledních 30 let. A další ukázka toho, jak se může i naprosto nemožná technologie masově rozšířit.

[Kit]

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?

Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.

[BaldSlattery]

Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.

http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2

Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora.  Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."

Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.

V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.

Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.

Proč?

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?

Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Koncept webu, tak jak to vymysleli v CERNu, je IMHO jeden z největších omylů IT za posledních 30 let. A další ukázka toho, jak se může i naprosto nemožná technologie masově rozšířit.

  Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.

[Kiwi]

Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?

Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?

Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.

Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.

Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.

A jednak je nevhodná celková koncepce, kdy statický web složitými kličkami dynamizuji. Komprimace je sice hezká, ale neřeší podstatu problému.

Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.

Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory na to, jak by podle něj mohl vypadat web. Proč jsem schválně autora neuvedl, je snad zřejmé - většina lidí ani nemá svůj názor, jen kýve či kroutí podle toho, kdo daný názor vysloví. A to dnes bohužel platí i v politice a umění.

[BoneFlute]

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

Tak já bych se s dovolením od této blbosti odpíchl, a zeptal se vás na názor.

V čem je dynamické typování, či případně netypování, užitečné? Za mě jsem dospěl k závěru, že jsou to dvě situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Kromě těchto dvou scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.

Co myslíte vy?

[anonym]

Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

U slozitych IS je rozhodny faktor poradek v cem to jen jde, muze to byt klidne tezkopadne a casoe narocnejsi na implementaci, ale jak by v tom byl bordel jako u webdevelopmentu, tak by se ti to vratilo nasobne na tezsi udrzbe. Narocnost SW vyvoje roste exponencialni se slozitosti domeny, kterou ma resit, ne linearne.

[Kiwi]

Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.

Tak já bych se s dovolením od této blbosti odpíchl, a zeptal se vás na názor.

V čem je dynamické typování, či případně netypování, užitečné? Za mě jsem dospěl k závěru, že jsou to dvě situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.

Kromě těchto dvou scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.

Co myslíte vy?

V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě. Zatímco ve strukturovaných jazycích typu Pascal obvykle předpokládám určitý typ dat na určitém místě a situace, kdy tomu tak není, jsou spíše výjimečné, v objektovém přístupu je tomu přesně naopak. Pokud toto není aspoň v nějaké omezené formě umožněno (jako v C++ či v Javě), tak se vůbec nedá mluvit o objektovém programování.

Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.

[Kit]

Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.

Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.

A jednak je nevhodná celková koncepce, kdy statický web složitými kličkami dynamizuji. Komprimace je sice hezká, ale neřeší podstatu problému.

Vzal jsem používané bajtkódy. Samozřejmě je možné vymyslet jednodušší a kratší bajtkód, viz tvůj binární kód pro mikrořadiče. Jenže když do něj doplníš vlastnosti, které jsou dnes po něm požadovány, tak z něj zase vznikne moloch. Přenášený zdroják spíš vnímám jako serializovaný derivační strom. Když ho má číst člověk, tak je dobré ho mít upravený i graficky, ale pokud ho má číst jen stroj, tak je to vcelku jedno.

Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?