Kniha Objektové programování od Čady

Re:Kniha Objektové programování od Čady
« Odpověď #210 kdy: 01. 06. 2017, 19:49:08 »
S jistou nadsazkou muzeme rict, ze ES5 dnes vnimame jako assembler, low level vrstvu. Je jedno v cem programujes, nakonec se to kompiluje do asm/binarky. To ze se tomu u webaru rika "transpilace" je jenom buzzword.
To se ovšem velice mýlíš. Jediný důvod, proč se kde co kompiluje do JS, je ten, že se výrobci prohlížečů nejsou schopní domluvit na čemkoli jiném (téměř cokoli by bylo lepší než JS).

JS vyhrává ne proto, že "by byl vnímaný jako assembler", ale proto, že prostě není na výběr.


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #211 kdy: 01. 06. 2017, 20:59:00 »
JS vyhrává [...] proto, že prostě není na výběr.
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #212 kdy: 01. 06. 2017, 21:01:08 »
Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.

Re:Kniha Objektové programování od Čady
« Odpověď #213 kdy: 01. 06. 2017, 21:04:12 »
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější. Ale jak už tady někdo psal, člověk nemůže chtít všechno, no :)

Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.
To je zajímavý, měl bys nějaký konkrétní příklad (ne nutně kód)? Já si neuvědomuju, že bych na něco narazil (ani v Prologu, ani v Erlangu).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #214 kdy: 01. 06. 2017, 21:07:03 »
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější. Ale jak už tady někdo psal, člověk nemůže chtít všechno, no :)
Já používám Safari a zatím jsem nenarazil na web, co by roztočil větrák (a ne, nemyslím na dvanáctipalcovém MacBooku ani iPadu  :) )


Re:Kniha Objektové programování od Čady
« Odpověď #215 kdy: 01. 06. 2017, 21:10:41 »
Já používám Safari a zatím jsem nenarazil na web, co by roztočil větrák (a ne, nemyslím na dvanáctipalcovém MacBooku ani iPadu  :) )
Stačí nestabilní model v D3 - nějaká kulička se ti tam gingle o jeden pixel tam a zpátky a ČEZ má žně :)

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #216 kdy: 01. 06. 2017, 21:16:07 »
Atom je [...] stejný, pak je ekvivalentní, nebo není a pak není :) V Prologu je to ale stejně, ne?
Jo, je to stejně, a občas to je problém, proto se ptám, jestli to Erlang nemá vyřešené lépe. Zřejmě to je tedy stejně svazující jako v Prologu a člověk musí hledat workaroundy.
To je zajímavý, měl bys nějaký konkrétní příklad (ne nutně kód)? Já si neuvědomuju, že bych na něco narazil (ani v Prologu, ani v Erlangu).
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."

Re:Kniha Objektové programování od Čady
« Odpověď #217 kdy: 01. 06. 2017, 21:35:52 »
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)

JSfun

Re:Kniha Objektové programování od Čady
« Odpověď #218 kdy: 01. 06. 2017, 21:47:22 »
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější.

Jeste stale si nam nevysvetlil co je na JS nerozumnyho. Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree a prave kde jake lintery, minifikatory, transpilery a nastroje pro refactoring tezi primo z nej. Teoreticky si vyhackuj zdrojaky chrome a V8 a muzes si programovat primo v "assembleru" AST, bez meziclanku JS a DOMu kdyz ti to je trnem v oku.

Ta "nabidka" jazyku primo v prohlizeci je to POSLEDNI co chceme (pametnici znaji IE4-5 a VBScript vs JScript vs JavaScript). Roky se tu taha valka o standardy a ted kdyz je raj na dosah protoze IE i FF jsou na vymreni a staci nam podporovat chrome engine tu nekdo chce "svobodu" vyberu ? Tak jako tak by takovej jazyk musel byt navrzen od piky protoze pouzit jiny stavajici by bylo nevhodne vzhledem na specifika webariny, prace s DOM atd. Takze zase idealisticka utopie a vratme se na Zem a k optimalnim postupnym krokum k svetlym zitrkum - ES6+ a TypeScript. A ano stale jsou plne transpilovatelne do ES5 protoze je computational complete a tedy dokonaly i bez tech vasich atomu a primitiv (protoze vsechno v JS je defacto objekt).

No a s tim hucenim vetraku pri browseru, tak nevim co delas spatne ale tipuji to na kombinaci linuxu a firefoxu, zname to neoptimalni zrouty pameti a systemovych prostredku :) My s MacbookPro a Safari (a odnedavna i vytunenym Chrome) to nezname...

UF

Re:Kniha Objektové programování od Čady
« Odpověď #219 kdy: 01. 06. 2017, 22:09:23 »
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;) a nejspíš i ta nabídka jazyků pro frontend by byla zajímavější.

Jeste stale si nam nevysvetlil co je na JS nerozumnyho. Ten VM tam pod poklickou tak ci tak je, akorat mu rikame Abstract syntax tree a prave kde jake lintery, minifikatory, transpilery a nastroje pro refactoring tezi primo z nej. Teoreticky si vyhackuj zdrojaky chrome a V8 a muzes si programovat primo v "assembleru" AST ... tady sem prestal cist

dalsi zabijak

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #220 kdy: 01. 06. 2017, 22:09:36 »
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)
Tak, je to o dodatečných informacích, které nejsou a priori známy. V Prologu by to jít mělo (v nějakém rozšíření), protože nikde není řečeno, že dvě konstanty musí být vždy rozdílné. Takhle to člověk musí obcházet a vynalézat kolo (nebo zakulatit ten správný čtverec  :D ). A asi jo, často se stává, že člověk potřebuje nějakou "krávovinu", ale to plyne z podstaty řešených problémů/algoritmů.

JSfun

Re:Kniha Objektové programování od Čady
« Odpověď #221 kdy: 01. 06. 2017, 22:17:37 »
...tady sem prestal cist

dalsi zabijak

Fungujes proste prilis logicky a ne ezotericky jako javascript :-)

Svet nepostavili architekti ale zednici, webarinu neudelali vedci ale inzenyri, bitvu nevyhral general ale vojak. As good as it gets.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Kniha Objektové programování od Čady
« Odpověď #222 kdy: 01. 06. 2017, 22:22:55 »
...tady sem prestal cist

dalsi zabijak

Fungujes proste prilis logicky a ne ezotericky jako javascript :-)

Svet nepostavili architekti ale zednici
Taky podle toho vypadá...

UF

Re:Kniha Objektové programování od Čady
« Odpověď #223 kdy: 01. 06. 2017, 22:26:25 »
Jo, měl. Parsing do FOL například. Když se použije Early nebo něco takového, tak chci pro "Pepe eats pâté" dostat něco jako "eats(x,y) & Pepe(x) & pâté(y)", přičemž z lexikonu vyleze Pepe(u) a pâté(v) a během parsingu zjistím, že x=u a y=v. Pro efektivní implementaci by se hodila hashmapa nad termy, pro které můžu určit ekvivalenci. Kdyby to měl nějaký jazyk zabudované, celkem by to usnadnilo implementaci mnohých algoritmů, protože efektivní algoritmus se pro to píše blbě. Bohužel, "if you want something done right, you have to do it yourself."
Čili jestli to dobře chápu, princip je v tom, že v průběhu výpočtu zjistíš nějaké dodatečné informace, které ti nějaké atomy ztotožní. Jasný, to nejde. A imho by by to ani jít nemělo - atom by měl z principu zastupovat nějakou neměnnou entitu. Kdyby ti někdo splnil tohle, tak si zas vymyslíš nějakou jinou krávovinu, která nejde, viď, ty lišáku! ;)
Tak, je to o dodatečných informacích, které nejsou a priori známy. V Prologu by to jít mělo (v nějakém rozšíření), protože nikde není řečeno, že dvě konstanty musí být vždy rozdílné. Takhle to člověk musí obcházet a vynalézat kolo (nebo zakulatit ten správný čtverec  :D ). A asi jo, často se stává, že člověk potřebuje nějakou "krávovinu", ale to plyne z podstaty řešených problémů/algoritmů.

uz by sis mel napsat vlastni jazyk aby ses konecne zabavil a unavil - me se libila prednaska o joxe pro inspiraci - https://vimeo.com/49116180 - to sem si chtel vzdycky vyzkouset ale odsunul sem to do dalsiho zivota

Re:Kniha Objektové programování od Čady
« Odpověď #224 kdy: 01. 06. 2017, 22:26:54 »
Na tom snad není nic špatného, dokud nemusím na JS sahat ručně (ani pohrabáčem). Když to za mě generuje transpiler, tak můžu být v klidu (viz GWT).
Jo, ale kdyby byl místo JS rozumný VM, nemusel by i relativně jednoduchý web vytížit procesor tak, že začne hučet větrák ;)

Jestli to spíš není tím, že dneska weby píše kde kdo ;)

a JavaScript dobude cely svet!

A ne?

----

Jako fakt mě baví, jak tu má někdo mindrák z JS a JSONu jen proto, že v prvním případě to nezná (nebo chce být ignorant) a v druhém proto, že danou technologii chce cpát někam, kam nepatří (aneb vyčítáme Octavii, že nevyjede kopec jako Range Rover). Super.