"Coffeescript - a Javascript jelene és jövője?"

Programozás

Azt hiszem mindannyian írtunk már egy jó adag javascript kódot és ismerjük a nyelv/platform előnyeit és hátrányait. Számomra a legnagyobb hátránya az, hogy nem nagyon lehet benne “szép”, “elegáns” kódot írni, mert sok modern paradigma nem vagy csak nehezen megvalósítható vele. Ez persze szubjektív mérce, de úgy érzem igenis létezik egy általános “szépérzék” programozói körben, aminek nagyon sok köze van a hatékonysághoz is.

Ennek a problémának az orvosolására jött létre a Coffeescript nyelv, mely direktben javascriptre fordítható (akár on the fly böngészőben, akár előre, parancssori segédprogram segítéségével). A Coffeescript projekt saját szavai szerint: “A Coffeescript azért jött létre, hogy felszínre hozza a Javascript jó oldalát, minél egyszerűbb módon”. Lássuk hát, hogyan próbálja elérni ezt a célt és hogy sikerül-e ez neki.

A cikk itt olvasható.

( Hevi v | 2012. 04. 15., v – 12:46 )

Na ezt nem bírom a webes technológiákban. Kiforratlan, fragmentált, ezer féle layerrel, ami próbálja elfedni az egész koncepciótlanságát.

Persze, mindenki kitalál sokmindent, mert a meglevő az szar.
Persze, ezután mindenki kitalál újat, mert a meglevők vagy "szarok", vagy a "meglevő szarokat helyettesítő csodaeszköz" publikus alfái, amik persze megint "szarok", mert még kiforratlanok.
Persze, ezután loop előre.

Így lett nekünk a vbscript, az ecmascript, a javascript ötszáz verziója, a 18ezer js engine, a php, az openlaszlo, a flash, a java applet, a silverlight, a flex, az adobe air, a gwt, a yui, a ruby on rails, a tcl/perl/python/bash-ban irt cgi-k, ...

Ne csodálkozz, hogy létrejött egy n+1 -edik próbálkozás.

Ez a "termeszetes evolucio", amikor nem egy konkret szerv/stb kontrolallja, hogy itt pedig csak az lesz, es kesz. Hasonloan az emberi nyelvekhez, ott is hany nyelv van, azokon belul is nyelvjarasok stb, aztan lehet szivni, hogy az ember megtanuljon egy mas nyelvet, egyiket a masikra kell forditani stb. Raadasul egy adott nyelv tobbe-kevesbe nem logikus, megtanulasa sok energiat es idot igenyel. Van szeeeeep, logikus, stb mesterseges nyelv (eszperanto pl), valahogy megse latom, hogy mindenki elkezd csak eszperantot beszelni, es igy megoldjuk a fragmentacio problemajat :) Akkor viszont nem ertem, hogy miert varjuk el, miszerint az elet mas teruleten ne legyen fragmentacio. Eleve benne van a "hit" meg stb: van aki szerint ez jo, van aki szerint az. Ezen valtoztatni ugy lehetne, ha "bezarnad" az egesz webet, es egy szem diktatorikus hatalom megmondana mi legyen. Enelkul viszont demokracia van, parhuzamosan tobb dolog is szuletik, el majd meghal, es meglatjuk mi lesz belole ...

Persze, azokat is fejlesztik, revizionaljak. De alapvetoen, mikor elkezdenek epiteni egyet, akkor egy elfogadott terv szerint haladnak es nem szokas egy adott epitkezesen belul evoluciosdit jatszani.

Az egybol mukodott reszt meg nem tudom ertelmezni. Egy ilyet nem szokas mindenfele teszteles (es hibasan szallitott alkatresz eseten annak javitasa/csereje utan) csak ugy beroffenteni, hogy aztan vagy core dump lesz vagy sem. Ott nincs olyan, hogy majd a kovetkezo verzioban javitjak, elsore kell jonak lennie.

----------------
Lvl86 Troll - Think Wishfully™

Egyébként ezért rossz példa az atomerőmű, kösz, hogy rávilágítottál, hiba esetén más a következmény mértéke. Két külön szint. A javascript egy ember agyszüleménye, aki elkezdte csinálni, gondolom, hogy a web kicsit interaktívabb legyen, ne csak statikus HTML, aztán felkapták és lassan már minden javascriptben (is) készül (PC + rakat retro gép emuláció, 3D könyvtár). Az atomerőmű meg atomerőműnek épül, nem házi kandallónak, aztán atomerőmű lesz. Mindettől persze a kupleráj kupleráj marad. :-)

Akkor most olvass utana, hogy a 3 Mile Island hogy olvadt le. Emberi mulasztas volt, aha (igazabol UI bug volt, ami miatt az emberek nem vettek eszre hogy nyitva a szelep).

A 3 Mile Island atomeromunek epult, tekintve hogy un. atomeromu volt.

A javascript tobb ember agyszulemenye nyilvan, eredetileg egy ember kezdte (Brendan Eich), de o erosen epitett a Scheme-re es a Self-re, elobbi erosen epitett a LISP-re. Aztan persze voltak ficsorrequestek (pl. hogy ne LISP-szeru legyen a syntax, hanem java szeru, ettol lett javascript), meg nyilvan elobb utobb masok is beleszoltak (tobbek kozt az MS), mostanaban pedig eleg sok modositas van benne ami effektiv Crockfordtol jott.

Az meg, hogy miert minden ebben keszul, nyilvan azert, mert bongeszo van a te gepeden is, meg az enyemen is, es bar tortenetesen mindkettonk gepen van joesellyel java is, azt egy remalom elinditani, meg kulon minek mig a bongeszot amugy is hasznaljuk, kodot deployolni meg egy linkre kattintassal lehet, mersekelten biztonsagosan. De ez mar nem a bohockodas szintje..

Amit feljebb írtam, sosem volt szó arról, hogy atomerőműben nincs hiba, így esetedben sem értem hogyan kerül ide.

Továbbra is tartom, a javascript és az atomerőmű fejlődése más. De rendben, legyen, javascript szar, java szar, akkor mi a jó? Mert eddig mindenki szidta, alternatívát viszont nem látok.

"Továbbra is tartom, a javascript és az atomerőmű fejlődése más."

Látom, nem sikerült megérteni a lényeget. Egy atomerőmű nem fejlődik a létrehozása során, hanem megtervezik és azt építik meg. De a hangsúly nem az atomerőművön van, ha eddig még nem esett volna le.

Szoftvereknél meg jelenleg a nagyipari barkácsolás folyik.

----------------
Lvl86 Troll - Think Wishfully™

:)

(Mondjuk ott azért egy jó adag emberi ostobaság - szabályzatok figyelmen kívül hagyása, operátorok nem megfelelő tájékoztatása, stb - is szükséges volt a katasztrófához.

És a teljesség kedvéért tegyük hozzá: vannak azért lehetőségek az utólagos apróbb tuningra, Pakson is húztak úgy 60-60 MW-nyit a blokkokon, persze, ez még messze van a totális átépítéstől és véletlenül sem tért el az eredeti céltól.)

----------------
Lvl86 Troll - Think Wishfully™

Mivan? Most az, hogy a webtechnologiak joresze kiserleti fazisban van... Ettol ez meg mernoki tudomany, bocsanat, es annak a resze.

A panelekbe meg azbesztet epitettek, holott nem egeszseges. Akkor most az epiteszek kozul akik panelt epitettek, azok nem mernokok, vagy amikor panelt epitunk az nem mernokseg?

Kontarok mindig vannak. Minden mernoki teruletet meg lehet kozeliteni kontar modon. Szakteruletet kipecezni, hogy na az ott nem mernokseg, ezt igy most hirtelen

Az egészben talán az a visszás, hogy ha a JSre nem mint nyelvre hanem mint platformra tekintünk, akkor talán nincs is jó szájízzel elfogadható megoldás:

- ha JS fölé csak egy kis, többé kevésbé átlátszó réteget rakunk - mint ez - akkor felmerül a kérdés, hogy mennyire éri meg az erőfeszítés

- ha viszont teljesen elfedjük, akkor meg minek a JS: mindenki érzi, hogy ekkor egy általánosabb és gépközelibb virtuális gép lenne a szebb alap technológiailag (JVM, CLI) - ehhez képest az ilyesmi gányolásnak hat - csak hát ilyen meg nincs szabványosan alapból a böngészőkben... (Nem PONT a JVMre vagy a CLIre gondolok csak arra, hogy itt a JS nyelv tul. képpen egy felesleges réteg amit ki kéne/lehetne hagyni)

szerk.:
Az 1.es ponthoz egy példa:

tényleg nagyon kényelmes a
"for i in alma blabla(i)"
jellegű ciklus, nade itt az egész félkarú óriás az ilyesmit natívan támogató nyelvekhez képest, ugyanis automatikusan erre fordul:
for (_i = 0, _len = alma.length; _i < _len; _i++) {
i = alma[_i];
blabla(i);
}

Elsőre látszik, hogy önmagában eleve indexelhető struktúrának kell lennie az alma-nak (nem lehet ott pl. a saját láncolt listám), de mivel a JSben nincs operator overloading (hogy definiáljam a []-t saját adatra), egyáltalán nem is működhet saját adatstruktúrával még ha indexelhető akkor sem...
Szóval így ez csak egy korlátozottan használható szintaktikai könnyítés, nem valami lényegi szemantikailag megalapozott plusz funkció.

( szniki | 2012. 04. 15., v – 13:11 )

A Dart hasonló célokkal született, azt is fikázta mindenki, pedig kifejezetten jó és átgondolt dolgok vannak benne. Lásd itt.

Egyetértek. Én örülnék neki ha a dart már előrébb tartana, legalább ott, hogy natívan támogatja minden nagy browser aktuális verziója.

Szerintem a coffeescript-nek is akkor lesz értelme, ha nem kell compile-olni js-ben, hanem tudnak nyelvileg újat nyújtani a js-hez képest.

A Dart fejlesztők célja mindenképpen az, hogy az elterjedt böngészők aktuális verzióját támogassák, de a kérdés az, hogy mit értünk natív támogatás alatt? A dart2js fordító (többnyire) helyes JS-t generál, ami mindenhol fut, a kérdés az, hogy az adott böngésző JS engine-je tudja-e értelmezni az adott HTML5 vagy egyéb szabvány dolgait.

Szerintem a Coffeescript-nek is megvan a maga helye és használhatósága, de egyáltalán nincs ugyanabban a kategóriában, ahol a Dart van. Utóbbinak egyik fontos, de nem mindig hangsúlyozott részlete, hogy nem csak nyelvileg akar újat nyújtani a JS-hez képest, hanem a futtatókörnyezetben is (miközben megőrzi a kompatibilitást).

--
dart fórum

kulcsszo: tipusossag.

Ha jol tudom, nehanyan a V8 teamben nem hisznek abban hogy a javascriptben tovabbi lenyeges sebessegvaltozast tudjanak elerni.

Erre ket megoldasuk van, az egyik a tipushinting (javadoc kommentekkel), ami annyira jol megy a chrome + closure compiler parosnak, hogy a gmailt es a docs-ot lassan mas bongeszoben nem is erdemes megnyitni se, mert nagysagrendekkel lassabb.

A masik pedig a darts tipusossaga, tulajdonkeppen egy (opcionalisan) tipusos javascript, ami ugyan ki tudja dobni a tipusokat, lebutitva ezzel a programot, nem az a muveszet, hogy kidobjuk a tipusinformaciokat futas elott, hanem az, hogy beletegyuk.

Ebben kulonbozik a coffeescriptbol, ami nem akar VM lenni.

En szeretnek hinni a trace based compilingben. En szeretnek hinni abban, hogy a programozonak nem kell explicit megmondania hogy HashMap, eleg, ha azt mondja, hogy Map, aztan majd a JIT ra fog jonni arra, hogy mire is szanjak ezt a dolgot. Mint ahogy ezt amugy csinalja a CPython (dict-ekkel). Mint ahogy ma mar nem kell kezzel cimezni a memoriat, a C-ben ez elorelepes volt, es a nextfit-bestfit is csak egy kerdes az OpRe vizsgan, de nem gyakorlati problema az alkalmazasfejlesztok hadanak.

Eveken keresztul csinaltam kezzel statikus analizist dinamikus kodokon, aztan irtam az AST meg regexp alapu code quality toolokat hozzajuk, es amikor a Google vegre rajott a V8-cal, hogy a funkcionalis nyelvek logikajan elindulva a tipustartast lehet felhasznalni a tipus meghatarozasahoz, amikor kitalalta a "forditsuk le valahogy, aztan ha nem jo, max leforditjuk ujra" logikat, en szeretnek hinni ebben.

Aztan lehet hogy nem, visszaesunk, es jon a darts. Vagy valami nativ plugin, es akkor LLVM.

Meglatjuk.

Ha jol tudom, nehanyan a V8 teamben nem hisznek abban hogy a javascriptben tovabbi lenyeges sebessegvaltozast tudjanak elerni.

Ez így van, bár a "nem hisznek benne" részt inkább úgy mondanám, hogy "elfogytak a gyorsítást szolgáló opciók". A V8 alapítója és a Dart projekt vezetője Lars Bak, aki már nem kevés VM-et csinált, és neki elhiszem, hogy úgy tervezték meg a Dartot, hogy gyors tudjon lenni (ha jelenleg még nincs is ott sebességben, ahova várják).

En szeretnek hinni a trace based compilingben.

Ezt (részben) már most is alkalmazzák a VM-ek (pl. Java HotSpot), bár az tény, hogy nem a Map implementáció kicserélésére. Hint: ugyanaz a Lars Bak dolgozott a HotSpoton, a V8-on és most a Dart-on ;)

--
dart fórum

Ezt (részben) már most is alkalmazzák a VM-ek (pl. Java HotSpot)

Java-ban trace based compiling? Az invokedynamic-kal lehet hogy valahogy ki lehet kenyszeriteni, de amikor az megjelent, addigra a v8 mar letezett. Meg aztan ugye ott olyan VM kellene, ami fordit n db alternativ valtozatot, es ha nem eleg gyors valamelyik, kicsereli. A jvm viszont oroksegebol adodoan nagyon nehezen mozdul ebbe az iranyba, hisz erre a zaszloshajo nyelveknek - java es scala - nincs szukseguk.

Nem tudom, hogy rezolucios eljarasokkal (aka Prolog) mennyire lehet meg javitani a tipusfelismerest, egy ismerosom dolgozik ezen (egyetemen), remelem, hogy van meg olyan, amit ok mar tudnak es Larsek meg nem.

Lattam amugy Lars eloadasat a darts-rol, azt gondolom hogy a V8 egy hatalmas es korszakalkoto elorelepes a dinamikus nyelvtechnologiakban.

Azt gondolom hogy ez le fog, le kell hogy csorogjon a tobbi dinamikus nyelvre is (python, ruby).

Azt is gondolom, hogy a darts-js "vita" nem arrol szol, hogy akkor holnaptol (vagy azutan) milyen szintaxissal fogunk mi webet programozni, hanem arrol, hogy mennyire vagyunk kepesek megszabadulni az explicit tipusjelolestol.

Amikor ugyfellel kodreview-zok, harom dolgot szoktam csinalni:
- pythonositon a szintaxist (kapcsoszarojelek eltuntetese)
- eltuntetem a lathatosag jelzoket (private, public)
- eltuntetem a felesleges tipusokat

Ekkkor a kod "emberileg" ertelmezhetove valik, a laikus, de intelligens ugyfel meg tudja mondani, ez-e az az algoritmus, amit o latni szeretne (ertelemszeruen alkalmazas business logic, nem videokartya-driver)

Ez viszont egy nagyon fontos lepes. A visibility nem ugy, az igazabol default setting kerdese egy nyelvben (mert publikus (vagy oroklesnel: vedett) tagja minden osztalynak van, privat nem kotelezoen), az indentalas az szintaktika kerdese, viszont az explicit tipus az nem az, az szemantika.

Ha ezeket a nyelveket sikerul felhozni teljesitmenyben, akkor arrol beszelunk, hogy a programozo agyterhelese csokken-e, a kod atlathatosaga no-e, ezaltal a programozo teljesitmenye, hatekonysaga no-e.

Egy tipusos nyelvet irni, ami utana ki tudja dobni a tipusokat es lefordul javascriptre, nem kunszt, ma mar van LLVM bytecode -rol JS-re fordito cucc is (ez az Emscripten), es a darts-ot egy komplett megfutamodasnak erzem.

"hanem arrol, hogy mennyire vagyunk kepesek megszabadulni az explicit tipusjelolestol."

Csak nekem tűnik ordenáré nagy ökörségnek megszabadulni az explicit típusjelölésektől, hogy utána egy szoftver próbálja meg jobb-rosszabb eredménnyel (mellesleg jelen esetben futásidőben) kitalálni, hogy mit is akarhatott a fejlesztő? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A programozó oldaláról hitvita van, kinek mi jön be jobban:
- az explicit típusmegjelölés segíthet megérteni a kódot
vs
- az explicit típusmegjelölés túl hosszúvá és bonyolulttá teheti a kódot

A VM oldalról viszont kb. mindegy: akár megjelölöd, akár nem, akkor is végig kell játszania a lookup-okat, ellenőrizni a típusmegfelelést, valamint azt, hogy vajon egy származtatott osztályként felülírtad-e a metódusokat vagy sem. A típusinformáció segíti a fordítást és ezáltal néhány hiba gyors elkapását, de futási időben nem jelent lényeges előnyt. (*)

(*) Legalábbis nekünk ezt mondta Lars Bak, amikor a Java VM vs Dart VM belső működésekről kérdeztük. Ha elkészülnek vele, akkor derül ki igazán :)

--
dart fórum

Szerintem minden előny, ami még fordítási időben elvégezhető és nem kell futásidőt lassítani vele.

De ha már említed a metódus felüldefiniálást: valóban szükség van mindig virtuális metódusokra? C#-ban sem véletlenül csak az virtuális, amit te jelölsz meg annak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hat saxus, akkor meg kene kerni a C fejlesztoket, hogy hadd jelold meg te a pontos memoriatartomanyt amiben a programod fut, ne lassitsuk vele a futast, hogy az oprendszer allokal meg ilyenek...

Az en tapasztalatom amugy 2-2 es felszeres hatekonysagnovekedes, ennyivel gyorsabban "gepelik be" a dinamikus nyelvu kodokat az emberek, azonos bugrata mellett.

Meg junior fejleszto kodjaban se lattam viszont soha tipus-hibat, egyszeruen nem tevesztik el.

Ellenben egyes java kodokban meglepoen sok a wrappeles, vagy a trivialis tipuskonverzio, ez idot vesz el, ezt meg kell irni (nem mindig az IDE irja sajna).

Egeszen addig, amig a programjaink a pszichologiai sebessegkorlatokon belul futnak (100ms eszrevetlen, 200ms visszacsatolas, 1 mp feldolgozas, 1 perc hosszufeldolgozas), a vegfelhasznalonak, addig tolem assembly-ben is, COBOL-ban is, meg INTERCAL-ban is lehet irva: a lenyeg onnantol kezdve a bugrata, a fejlesztes sebessege, a kod karbantarthatosaga.

( uid_19334 | 2012. 04. 15., v – 13:37 )

===NYELVTANNÁCI ON===

Nem tudom mi okból használsz ilyen idézőjeleket, de kérlek, amennyiben nélkülözni tudod őket - ne tedd. Használj „normális” vagy "lusta" idézőjeleket, de angolszász(?)-okat ne.

===NYELVTANNÁCI OFF===

( anon7002197 | 2012. 04. 15., v – 19:59 )

Üssetek, de nekem a JS kód olvashatóbb, átláthatóbb.

Hát nyilván sok helyen úgy spórol, hogy néhol kevésbé explicit mint a JS - a honlapján van jó pár egymás melletti kódrészlet ahol ez jól látszik.

Az implicit viselkedései megértéséhez meg ismerni kell a nyelv szemantikáját, különben persze hogy nem olvasható. Ruby programozókat itt kevesebb meglepetés éri. Hosszútávon szerintem mondjuk kifizetődő a tömörség, feltéve ha nem kriptikusan - mondjuk főleg plusz operátorokkal - valósítják meg egy nyelvben.

+1. Attól, hogy elhagyunk néhány zárójelet, még önmagában nem lesz olvashatóbb a kód. Mellesleg, most is van sok nyelvben olyan nyelvi elem, amely ugyan első ránézésre plusz, gyakorlatban azonban pont az áttekinthetőséget segíti elő.

Egyékbént, kb. hasonlóra beformázva az első példában mutatott JS kódot, kiszedve a kommenteket, pontosan kettő db. }; -el lesz több sorok számában a kód, azt leszámítva centire ua. Leszámítva ilyeneket, hogy az ifes sor totál máshogy van, mint a nyelvek 99%-ában megszokott.

----------------
Lvl86 Troll - Think Wishfully™

( zsoc | 2012. 04. 16., h – 08:47 )

Világ életemben ki nem állhattam azokat a kezdeményezéseket, amelyekkel un. könnyebben lehet az adott nyelvet "kezelni". Az első ilyen siralomház a LESS CSS volt, amiben ugyan tényleg akadt érdekes megvalósítás (leginkább a változók kezelése), de a többi része kb elhanyagolható, és pusztán egy markáns tudás birtokában megoldható "natív" (már az is nevetséges, hogy ezt így le kell írni) css paraméterekkel.

A js-nek bőven elég, hogy már olyan primitív, kvázi dizájnereknek szóló keretrendszerek léteznek, hogy az egyszeri photoshop user is össze tud már valamit hányni.

A LESS-szel mi a baj? Nézd meg mondjuk azt ExtJS-t, hogy az SASS-nek (~LESS) köszönhetően mennyire egyszerű módosítani a kinézeten. És nem egyszerűen arról van szó, hogy könnyebbé tették a CSS kezelését, hanem csináltak egy eszközt arra, hogy ne kelljen felesleges kódismétléseket írnod (ami a CSS sajátja).

Meg _kell_ tanulni CSS-t írni, aztán nem lesz annyira zavaró a kódismétlés...

De azért egy kis segítség, mielőtt még a newbie-k rákapnak minden szarra, abszolút feleslegesen:
http://www.slideshare.net/stubbornella/object-oriented-css
--
http://www.runatabor.com
Born to be alive!

Ennek semmi köze a tanuláshoz, vagy az oo-css-hez. Ezekkel az _eszközökkel olyan dolgokat tudsz egyszerűen megcsinálni, amit natívan sehogy. Olvass utána! Mintha valaki azt mondaná, hogy egy fullextrás IDE az gyogyósoknak való, mert a faszagyerekek notepadben kódolnak. Butaság.

Egyszer volt egy fejfogós veszekedésem valakivel, aki erőltette, hogy az IDE-k használata micsoda hülyeség, meg erőforráspazarlás, stb :)

Egyébként mik azok amiket natívan nem lehet megcsinálni? Még nem igazán sikerült elszakadnom a "natív" css-től, de szívesen ismerkedek meg új dolgokkal :)

Meg lehet csinálni mindent természetesen, a végén a LESS is CSS-é fordul, mint ahogy a Coffeescript Javascriptté. Az egész arról szól hogy fejlesztői oldalon mi és hogyan használható.

Pár kulcsszó a LESS mellett:
- változók (pl. oldal konténer szélesség, változóként végigvezetheted, utána elég 1 helyen átírnod)
- mixin-ek
- egymásba ágyazott szabályok
- névterek
- operátorok és függvények

( Aadaam v | 2012. 04. 16., h – 12:24 )

Vicces latni, ahogy itt a sok kocajavascriptes szidja a coffeescriptet.

Nem szeretem annyira en se, varom hogy mikor tunik fel a harmony-ban vegre hogy nem kell kiirni a function operatort,

csak azt tessek figyelembe venni, hogyha nem jQuery-ben ganyolsz spagettit*, hanem teljesen napi ugymenet a tobbszaz, esetleg ezer sor JS begepelese (ha ertesz hozza, begepelsz ennyit egy nap, tesztekkel mindennel egyutt plane), akkor az idegesito baromsagok, pl. pontosvesszo, vesszo, opcionalis parameterek jo kezelese, callbackeles...

sz'al ha ez a napi munkad, akkor ertheto ha nehanyan kenyelmesebb feluletet akarnak.

* a jQuery nem framework, hanem lib; a chainelest a vilag osszes tobbi rendszereben spagetti-keszitesnek hivjak;tudom hogy kezreall, nyilvan nem veletlenul keszultek spagetti kodok a vilag tobbi nyelveben se.

hirtelen().nem().tudnam().megmondani().miert().tunik().ugyanolyan().hosszunak()...

A spagetti ugye igy nez ki: ()__________________________________________________________)

Miota helyes eljaras ortogonalis, vagy epp fuggetlen utasitasok egymas melle pakolasa?

A es B first() kapcsolatban vannak, oke

A.csinalvelevalamit().first().csinaljvelemasvalamit()

Vagy:
A.csinaljvelevalamit().aztancsinaljvelemasvalamit()

Ez miota helyes? bocsanat.

Szerinted az jobb, ha egy dologgal sokmindent szeretnél elvégezni, akkor ismételgeted az objektum nevét?

Szerinted nem kényelmesebb és áttekinthetőbb ez: 


ctx.beginPath()
   .moveTo(25,25)
   .lineTo(105,25)
   .lineTo(25,105)
   .fill();

mint ez: 


ctx.beginPath();
ctx.moveTo(25,25);
ctx.lineTo(105,25);
ctx.lineTo(25,105);
ctx.fill();

Szerintem a világ legjobb ötlete a chainelhetőség, de ha nem is az, mi a baj vele?

Tisztazzuk, te itt egy muveletet vegzel tulkepp: haromszoget rajzolsz. Az utasitasaid se nem ortogonalisak, se nem fuggetlenek.

De amikor megvaltoztatod a kinezetet, majd klikkelhetove is teszed, az mar ketto.

A baj vele itt kezdodik:

jQuery.fn.extend({newWidgetType:function()....})

$('#bela').newWidgetType();

$('#tibi').dependentWidget({dependency: $('#bela')}

es amikor tibi szinkron meg szeretne kerdezni belatol, hogy o most milyen allapotban is leledzik, az API nem nyujt ra lehetoseget... Avagy miert undorito minden jquery gridwidget api-ja.

De ez csak a kezdet.

-1
A chainek szerintem is nagyon jól olvashatók, mert kimarad az objektumreferencia, vagy temporális változók által keltett zaj:
pl.

a.sort.head(5).sum

szerintem olvashatóbb mint:
b=a.sort
c=b.head(5)
d=c.sum

Ez rengeteg felesleges temporális változó. Okok persze a,b,c,d helyett beszédes név kellene de akkor is túl bőbeszédű lenne. Persze a túl hosszú lánc megint rossz, egyszerűen jó helyeken kell elvágni...

Ráadásul nagy hagyományai is vannak ennek, egészén a Smalltalk időkből. Ami kicsit visszavetette az a (leginkább Bertrand Meyer - Eiffel kitalálója - által népszerűsített) coding convention, hogy ha állapotot módosít egy metódus a visszatérési értéke legyen void.
Erre persze mindenképp kell valamilyen bejáratott jelzés, de ha az olyan ami nem akadályozza a chaininget akkor számomra szimpatikusabb. Mint pl. a. C++-ban bevezetett const metódusok, vagy a Smalltalk/Scheme/Ruby vonalnál népszerű !-es elnevezési konvenció. (a.sort! vs. a.sort)

Szerintem nem, nem temporalis valtozoknak hivjak ugyanis oket, hanem magyarazovaltozoknak.

Ezt persze kodmetrikak es kodellenorzo dolgok is alatamasztjak.

top5 = a.sort().head(5)
sum = top5.sum();

A mutator elvet amugy en is viszem, egyszeruen statisztikailag olvashatobb a kod.

A kodot ugyanis nem a compilernek irod, es nem arrol szol a verseny, ki tud minel kevesebb atmeneti lepesben kodot gyartani; azt koszoni szepen, majd kioptimalizalja a compiler.

Eleg nehez ertelmezni, refactorolni azt a kodot, amiben a koztes lepesek kimaradnak. kb. olyan, mintha assembly-t olvasnal, vagy obfuscated kodot: hiaba tudod, mi a kezdoallapot, es a vegeredmeny, ha nem erted, hogy jott ez elo, es sorrol sorra le kell kovetned a muveleteket.

A jelzes amugy az aktiv es passziv igekkel szokott tortenni.

( Pontscho | 2012. 04. 16., h – 15:10 )

Tehat ha jol ertem... valaki irt javascripttel egy compilert, ami egy kodot - akar on-the-fly - lefordit javascript-re, amit a bongeszo lefordit bytecode-ra, majd utana meg egy JIT compilert is raereszt, majd utana elkezdi futtatni, ha egyaltalan fut az adott bongeszovel az a kod es nem kell a javascriptet is romma verziozni. Alomszep, maris imadom. :)

---
pontscho / fresh!mindworkz

Rosszul érted. Az elsődleges cél nem az, hogy JavaScriptre forduljon, hanem az, hogy azonnal byte-kódként fusson, azaz semmivel nem rosszabb mint a JavaScript runtime. Itt a JavaScript nyelv kiváltásáról van szó, az átmeneti időszak támogatásával.

A Dart ehhez képest egyébként sokkal többet ad az opcionális típusokkal, mely alapkövetelmény egy komoly alkalmazáshoz. Az előadást fentebb linkeltem.

Csakhogy: Ennek a problémának az orvosolására jött létre a Coffeescript nyelv, mely direktben javascriptre fordítható (akár on the fly böngészőben, akár előre, parancssori segédprogram segítéségével).

Ez on-the-fly bongeszoben mashogy nehezen kivitelezheto jelen allapotok szerint.

---
pontscho / fresh!mindworkz