Kniha Objektové programování od Čady

[Tomáš Roll]

Tak jste mohli použít nerelační databázi, pokud jste chtěli efektivně ukládat nerelační data.

To je přece buřt, do čeho to strkám. Důležité je, aby to bylo abstraktně odděleno jako vrstva, pak tam můžu použít pro ukládání třeba pozitronový mozek androida.

Pokud jde o výkon, buřt to nebude.

[Reklama]

[Kit]

To je právě ten problém. Pod záminkou přenositelnosti mezi databázemi jsou všechny degradovány na nějaký společný základ - ať to stojí, co to stojí.

Ale to je základní vlastnost toho prostředí, webu obecně, je polygenní. Na vině je HTML a CSS. Při vývoji webu se začalo od konce a to byla chyba. Kdyby klient byl jen automat ovládaný ze serveru a zprostředkovávající interakce s uživateli, celé prostředí by bylo efektivnější. Mělo se začít javascriptem, nebo ještě lépe lispem na straně klienta. Dnes bychom měli sémantický web, protože klient by sám generoval strojově interpretovatelné informace pro roboty vyhledávačů. Bohužel web vznikl v CERNU, tedy v prostředí orientovaném uživatelsky, ne programátorsky.

V prostředí IoT to bude jinak, tam prezentační vrstva bude chybět, což povede k větší efektivitě a novým paradigmatům kolektivního zpracování informace.

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

[gll]

Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.

...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka

Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.

[Mirek Prýmek]

Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

[Bufik]

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

Jo protoze uzivatele maji sajnu jaky rozdil je mezi lispem visual basicem a javascriptem ze ?  Lisp se nedostal vubec nikde, je to akademicky konstrukt na vyuku jistych funkcionalnich aspektu programovani. V praxi je pro masy nepouzitelny a skoncilo by to tak jako tak transpilaci do jazyku nizsi generace. Tedy jedno prakticke nasazeni lispu znam - Emacs, a podle toho to i vypada :-)

[Reklama]

[gll]

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

[Ivan Nový]

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

Jo protoze uzivatele maji sajnu jaky rozdil je mezi lispem visual basicem a javascriptem ze ?  Lisp se nedostal vubec nikde, je to akademicky konstrukt na vyuku jistych funkcionalnich aspektu programovani. V praxi je pro masy nepouzitelny a skoncilo by to tak jako tak transpilaci do jazyku nizsi generace. Tedy jedno prakticke nasazeni lispu znam - Emacs, a podle toho to i vypada :-)

No HTML je "podmnožina" lispu, jen závorku nahradilo tagem a implenentaci omezilo pouze na deklarativní aspekt.

[gll]

Uživatelé nerozhodovali.

[Ivan Nový]

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

Klient by měl být konstruován tak, že k němu není přímý přístup přes nějaký jazyk, ale jen přes objektový, nebo funkcionální interface. Server by místo povelů pro renderovací jádro v HTML, CSS a javascriptu generoval lispovské seznamy, přímo interpretované lispovým jádrem prohlížeče. Důraz má být kladen na strojovou analýzu, nikoliv na čtení pro lidi. Lisp použitý jako deklarace je čitelnější než kompozit HTML, CSS a javascriptu. Ostatně proto se přechází na JSON, všude, kde to jde.

[Ivan Nový]

Uživatelé nerozhodovali.

Rozhodoval uživatelský přístup autorů webu. Tedy aby bylo snadné psát a renderovat hypertextový obsah.

[gll]

Uživatelé nerozhodovali.

Rozhodoval uživatelský přístup autorů webu. Tedy aby bylo snadné psát a renderovat hypertextový obsah.

O javascriptu už uživatelé nerozhodovali.

[Tomáš Roll]

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

Javascript je krutá pomsta. Nevím koho, nevím komu, ale opravdu krutá. Nebo něčí odporný žert. Používat ho na skriptování nějakých animací na webu, dejme tomu, ale aplikační jazyk? Proboha. Už jen to doporučované formátování, dávat bracket na stejný řádek jako function nebo if, to je zjevně něčí zlý úmysl.

[zboj]

Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

To se dá ale ošetřit, taková db4o měla svého času konfigurovatelná omezení (není to ORM, ale čistě objektová databáze, což je zde ovšem irelevantní). Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.

[Kit]

Právě Lisp by mohl s přehledem nahradit jak serverovou část, tak i HTML, CSS s Javascriptem dohromady. Jenže uživatelé to chtěli jinak a implementace Lispu se do webových prohlížečů ani nedostala.

Javascript je čitelnější než Lisp. JSON, CSS a HTML jsou čitelnější než s-expressions. Lisp měl smysl v sedmdesátých letech, kdy jiné jazyky neumožňovaly zápis složitějších struktur a interaktivní použití. Javascript to umožňuje a IMHO lépe.

O čitelnosti Javascript vs. Lisp se dá dlouze diskutovat, je to značně subjektivní. Lisp má úspornější zápis a proto se zřejmě většině lidí čte hůře.

[Mirek Prýmek]

Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.

Určitě. Ale ORM framework mu v tom mocně sekunduje a pěkně za ručičku vede do pekla Čím jednodušší na použití, tím horší.