Přejít k navigační liště

Zdroják » JavaScript » Kaffeine: další povzbuzení pro javascriptaře

Kaffeine: další povzbuzení pro javascriptaře

Články JavaScript, Různé

Káva je, a to i v naší anketě, jednou z nejpopulárnějších povzbuzovacích metod mezi programátory (populárnější je jen „spánek“). Snad i proto se v nejrůznějších podobách objevuje v názvech knihoven a programovacích jazyků. Ani dnešní nástroj není výjimka. Je opravdu povzbuzením pro JavaScriptaře?

Pro některé čtenáře byla syntax CoffeeScriptu možná až příliš radikální. Všechno to odsazování, a hlavně chybějící složené závorky, no fuj… Pokud hledáte nějaký vylepšený JavaScript, který by nebořil vaše zažité představy o tom, co musí mít programovací jazyk, zkuste Kaffeine.

Mírný pokrok v mezích zákona

Kaffeine (zdrojové kódy na GitHubu) nemění zvyklosti z JavaScriptu. Pokud napíšete čistý JS a proženete ho kompilerem Kaffeinu, nestane se s ním nic. Kaffeine pouze rozšiřuje některé možnosti, přináší nové konstrukce, a hlavně: Mezery nenesou žádný syntaktický ani sémantický význam.

Opět jde o nástroj, určený a připravený pro Node.js. Usnadňuje tedy především práci s moduly, a některým programátorům usnadní i psaní asynchronního kódu. Především pak přináší míň psaní.

Řetězce přes víc řádků

Zapsat víceřádkový řetězec v Kaffeine je snadné – příklad vše objasní:

html = "
<head>
<title>Stránka</title>
<body>
<h1>Stránka</h1>
</body>
<html>
"

Po překladu bude výsledek

var html;
html = "n
<head>n
<title>Stránka</title>n
<body>n
<h1>Stránka</h1>n
</body>n
<html>n
"

Jak vidíte, překladač zachoval konce řádků. Pokud se chceme takovému chování vyhnout, můžeme prostě každý řádek ukončit zpětným lomítkem.

Výrazy v řetězcích

Jako v Coffeescriptu nebo Ruby: zápis #{výraz} v řetězci zkracuje konstrukci  ..." + výraz + "...

Implicitní kdeco…

Ve snaze ušetřit programátorům zbytečné psaní nabízí Kaffeine spoustu možností: vynechat středníky, závorky, klíčové slovo var. Překladač se postará o správnou deklaraci, např. v následujícím případu:

x = 0
{
x = 1
y = 2
}

Překladač uzavře blok do funkce. Existující proměnné ponechá jako globální, ale ty, které se v bloku vyskytnou poprvé, nadeklaruje jako lokální:

var x;
x = 0
function() {
  var y;
  x = 1
  return y = 2
}

Kaffeine doplní i závorky k volání funkce (tedy pokud jsou předány parametry) a správně vnoří:

//funkce1 funkce2 parametr
funkce1(funkce2(parametr))
//funkce parametr1, parametr2
funkce(parametr1, parametr2)

Stejně tak lze vynechat závorky u podmínek (while, if) či u konstrukce for:

for i in A
if name == "john", return false
while i>0 { cosi... }

Implicitní return dovoluje vynechat slovo return, pokud chcete vrátit poslední vyhodnocený výraz. Implicitní function zase dovoluje vynechat slovo function:

// x = (a) {a*2}
// bude přeloženo jako:
var x;
x = function(a) {return a*2}

Bang! Bang!

Některým programátorům dělá problém vnímat, že některé JavaScriptové konstrukce jsou asynchronní, a že vykonávání programu nebude pokračovat dalším příkazem až PO dokončení asynchronní operace (AJAX), ale hned, že tedy pokračování svých geniálních algoritmů musí umístit do callback obsluhy, která se spustí po dokončení operace.

Kaffeine nabízí právě pro takové programátory vykřičníkovou konstrukci Bang!, která zbytek kódu za voláním asynchronní funkce uzavře do anonymní funkce a předá ji jako callback:

vysledek = $.get!('/ajax.php')
if vysledek != 'OK', alert(vysledek)

Překlad:

$.get('/ajax.php', function(vysledek) {
  if(vysledek != 'OK') alert(vysledek)
})

Názory na vhodnost podobné konstrukce se mohou lišit, pravdou zůstává, že v mnohých případech pomůže snazšímu pochopení i zápisu kódu, obzvlášť při vnořených asynchronních operacích.

@This

Obdobně jako v CoffeeScriptu je i v Kaffeine zavináč zkratkou pro this, a stejně jako v CfS si i v Kaffeine udržuje kontext.

Funkce

Kromě výše uvedených zjednodušení, jako je implicitní return a implicitní function, nabízí Kaffeine i další zjednodušení pro funkce. Jedním z nich jsou anonymní (nepojmenované) argumenty:

dvojnasobek = {# * 2}
mocnina = {# * #}
soucin = {# * #1}

# zastupuje parametr funkce. #1 pak druhý parametr, #2 třetí apod. Výsledný kód bude:

dvojnasobek = function() {return arguments[0] * 2}
mocnina = function() {return arguments[0] * arguments[0]}
soucin = function() {return arguments[0] * arguments[1]}

Pipe

Z *nixů vám bude jistě známý způsob řetězení volání pomocí znaku | (pipe). Kaffeine nabízí něco podobného:

hodnota = vstup | funkce parametr
vysledek = a1, a2 | funkce 1 par1 | funkce 2 par1, par 2 | funkce 3 parametr
var hodnota, vysledek;
hodnota = __.funkce.call(this, vstup, parametr)
vysledek = __.funkce.call(this, a1, a2, 1(__.funkce.call(this, par1, 2(par1, par(__.funkce.call(this, 2, 3(parametr)))))))

Výchozí hodnoty parametrů

Příjemný syntaktický cukr nabízí Kaffeine v podobě defaultních hodnot parametrů funkce, jako v jiných jazycích:

//f = (a=20, b, c=10) {a+b+c}
f = function(a, b, c) {
  a = a == null ? 20 : a, c = c == null ? 10 : c;return a+b+c}

Operátory

Kaffeine nabízí i nové operátory přiřazení: ||=.=

//location.href .= replace("?old", "?new")
location.href = location.href.replace("?old", "?new")
//name .= toUpperCase()
name = name.toUpperCase()
//opts ||= {}
opts = opts || {}

Třetí nový operátor je operátor rozšíření: ←

options = options <- { size: "small", num: 10}

Překlad je o něco složitější, definuje funkci extends(), a výsledkem je sloučení (mixin) dvou objektů:

var options;
options = __extend(options, { size: "small", num: 10})
function __extend(a,b) {
  var c = {}, i;
  a = a || {};
  for(i in a) c[i] = a[i];
  for(i in b) c[i] = b[i];
  return c;
}

Závěr

Pro použití Kaffeine platí víceméně totéž co pro CoffeeScript: Používejte to, pokud chcete a pokud vám to pomůže. Překladač je napsaný v JavaScriptu, takže bude fungovat v prohlížeči i v Node.js.

Komentáře

Subscribe
Upozornit na
guest
40 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
oj

asi zůstanu u čistého JavaScriptu :-)

blizzboz

js je super jazyk akurát sa v ňom nedá (rozumne) programovať, keby mali programátori na strane klienta inú voľbu tak by JS upadol do zabudnutia, ale pretože tu máme len JS s ktorým nikto neni spokojný, tak vznikajú nadstavby jazyka ktoré sa ho snažia zľudštiť. nanešťastie žiadna z týchto nadstavieb do JS, neprináša nič čo mi v JS chýbalo… asi vytvorím vlastnú nadstavbu. škodaže sa neštandardizoval ECMA Script 4.0 ktorý obsahoval aj Namespaces a Triedy, Properties, Typy, Vnorené triedy, viditeľnosť, proste všetko na čo sme zvyknutý z dospelých programovacích jazykov.

bauglir

Samo, že jde o Váš názor, ale nabídnu svůj :)
1/ Namespaces nejsou potřeba, jdou dokonale simulovat objekty
2/ Třídy? jde o zvyk, dědičnost v JS je, dostačující
3/ Properties? Jakože vlastnosti objektů? Ty jsou v ECMAScriptu (readonly, writeonly, setters, getters…)
4/ Typy? Cožpak je ECMAScript netypový?
5/ Vnořené třídy? co tím máte na mysli?
6/ viditelnost? viditelnost čeho? viditelnost properties? Jde simulovat, ale špatně… ta mi tam taky trošku chybí :)

Problém ECMAScriptu není v tom, že něco neumí, ale že umí věci prostě jinak :)

pas

No pod tou typovostí si podle mě vývojář přicházející třeba ze světa Javy, Flashe nebo Silverlightu představí, že mu runtime ohlídá, aby do proměnné nebylo za běhu strčeno něco jiného než tam strčeno smí být, atd. Doufám, že vývoj půjde aspoň k upozadění JS do role neviditelného assembleru, abych i při debuggování viděl kód v nějakém svém oblíbeném vyšším jazyku, atd. Už proto, aby existovala volba jazyků a konkurence mezi nimi – aby příští generace nežily v dojmu, že existuje jen JS.

bauglir

V tom případě je to vývojář, který nezná základní terminologii. Toto není typovost, ale striktní typovost. A kromě JS používám pro jinou práci jazyk, který je striktně a silně typovaný (ECMAScript není ani jedno), takže vím, jaké překvapení se může objevit.
Vyšším jazyku? Pokud chcete dělit jazyk na nízko a vysoko úrovňové, potom ECMAScript je vysokoúrovňový jazyk. Prostě jenom nemá vlastnosti, které byste si přál.
Dokud bude konkurence mezi prohlížeči, nebude ECMAScript dle mého názoru nahrazen. Maximálně vzniknou (a vznikají) obaly kolem něj (jiná syntaxe „překompilovávaná“ do ECMAScriptu). Což asi tedy pro Vás možnost. A přesto že jsem Pascalista (moc mainstream vzdálenějších jazyků od ECMAScriptu není :)), tak mě by nahrazení ECMAScriptu vysloveně nevyhovovalo a wrappery kolem nepotřebuji :)

Problém ECMAScriptu není v ECMAScriptu, ale v tom, že se programátoři neobtěžují jej naučit.

pas

Jistěže JS engine bude v browserech těžko někdy nahrazen. Ale snad se z něj stane něco jako CLR v .NETu (jako „bytecode“ je snad dostačující, nevím, zas takový teoretik nejsem…), čili vývojář nebude omezen na jediný jazyk, ve kterém musí psát. Ono by to bylo takřka „proti přírodě“, aby v takovém odvětví zavládl tak silný a trvalý konsensus. :)

pas

Jinak já momentálně programuju v ActionScriptu, jehož verze 1 byla ekvivalentní s JavaScriptem, takže ho myslím dobře znám. Verze 2 a 3 (které přišly se silným typováním a přiblížením k Javě) mi jednoduše přinesly znatelné zefektivnění práce. Takže o to opírám svůj názor.

blizzboz

1. simulovať? ale ja ich nechcem simulovať, každý poriadny jazyk obsahuje klúčové slovo namespace, prípadne package, ak musím niektoré jazykové konštrukcie simulovať inými tak to len ukazuje že ten jazyk je na dve veci.
2. Neni
3. properties podporuje až ECMAScript 5 takže sú v praxi nepoužiteľné, neviem prečo na takéto „argumenty“ vôbec reagujem
4. JS má veľmi slabú typovú kontrolu, a tým pádom vývoj aplikácií neskutočne predražuje
5. Myslím tým vnorené triedy
6. Symulovať??, proste aby bol ten kód aspoň minimálne čitateľný, tak sa musí celý jazyk ohackovať a opatchovať. To predsa neni programovanie.

>>Problém ECMAScriptu není v tom, že něco neumí, ale že umí věci prostě jinak :)

Jinak… proste na hovno…

blizzboz

Symulovať -> Simulovať

Jiří Knesl

1. existence nebo neexistence namespaces v pr.jazyce nevypovídá o ničem, jen o tom, zda tam jsou nebo ne. V JS je možnost je simulovat, ale protože se kolize nedějí, používá je jen pár velkých frameworků (jako je Dojo).

2. v JS frameworcích je dokonce vícenásobná dědičnost. Ne, že by dědičnost byla k něčemu dobrá.

3. nikdo nikomu nebrání napsat si metodu getXyz. Dokonce i private atributy a metody JS umí.

4. slabá typová kontrola naopak vývoj aplikací zlevňuje.

5. právě pomocí vnořených tříd se v JS simulují namespaces.

6. jazyk je výborně čitelný pro toho, kdo ho umí.

Javascript zjevně neumíte, snažíte se předpokládat, že musí mít množinu X vlastností, jen proto, že jsou v jazyce Y, přitom nic z toho, jako namespaces, viditelnost, dědičnost nebo nested classes nemají na kvalitu zdrojového kódu nijak velký vliv.

Jestli vám ten C#, Java nebo co používáte tak vyhovuje, dál si v něm bastlete a mezi slušné lidi se dál neštvěte, děkuji.

bauglir

Normálně bych dal palec nahoru, ale
„Ne, že by dědičnost byla k něčemu dobrá.“
Proboha co tím myslíte??? Jakože dědičnost je k ničemu???

Jinak já už to vzdal, své argumenty jsem přednesl, obhájil, vysvětlil, ale některým lidem se prostě ECMAScript nelíbí, bez ohledu na důvody na to mají právo, jejich věc :)

Jiří Knesl

Jazyky s OOP založeným na prototypování vznikly už před dlouhou dobou. Reagují na to, že čím větší systém máme, tím více chyb je způsobováno tím, že změna v rodičovské třídě rozbíjí své potomky plus potřeba, kdy je mnohdy nutné, aby „tento jeden objekt to dělal trochu jinak“ a změnou třídy se v podstatě rozšířená logika dává všem.

V jazycích s OOP existují návrhové vzory, které tyto problémy řeší (a nebo se právě znásilní dědičnost). Řešení jsou ale nepraktická, nepřehledná, zbytečné složitá vycházející z nedostatečnosti dědičnosti.

Následkem jsou jazyky typu Self, které se bez dědičnosti obejdou. Navíc vedou k delegaci místo dědičnosti, což má pozitivní vliv na testovatelnost, znovupoužitelnost a variabilitu použití kódu.

Je zajímavé, že JS byla dána do vínku vlastnost, která jej předurčuje pro běh na daleko větších codebases, než třeba Javu, C# nebo C++, jakkoliv se to zatím v praxi neděje.


Co se dědičnosti týká: ikdyž je udělaná sebelépe, jakmile se projekt dostatečně rozroste, je problematická. Nehledě na to, že jako lektor jsem prošel dost firem a správně dědičnost použivá tak jeden ze sta.

bauglir

Celý váš argument je variací na jednu větu: „Nehledě na to, že jako lektor jsem prošel dost firem a správně dědičnost použivá tak jeden ze sta.“, Faktem, že je někdo špatný návrhář není argumentem pro zamítnutí vlastnosti technologie (dědičnosti).
Diskuze delegace vs. dědičnost je rozumná, užití delegace vs. dědičnosti ukazuje na programátorovu schopnost navrhovat složitější komponenty, chápání jaká funkcionalita je je specifická a jaká nespecifická.
Ale nespecifická nemůže být delegována, její delegace by to totiž znamenala to, že by se daný objekt ptal vlastníka objektu, co je zač, aby dokázal funkcionalitu správně vyřešit. A ano, naopak, v případě, že daná funkcionalita je specifická, potom by v takovém případě její nedelegování vedlo buď k duplicitě kódu, nebo k tomu, že by objekt řešil záležitosti, které mu vlastně nepatří (resp. funkcionalitu, které je mnohem obecnější, než daný objekt).
Abych uvedl příklad:
1/ co delegovat
řekněme, že je vaším záměrem implementovat několik internetových protokolů (smtp, imap, ftp, http, websocket). V takovém případě, ponecháme funkcionalitu protokolů, formátovaní vstupů a dekódování výstupů v daných typech, ale samotnou komunikaci po serveru delegujeme jinému objektu (řekněme connection).
2/ co nedelegovat
řekněme, že vaším závěrem je vytvoření modelovacího SW, budete implementovat několik typů objektů (textovou poznámku; nějaký geometrický útvar, kterému budete moci měnit rozměry; přímou čáru; čáru se segmenty, které si bude uživatel definovat; čáru s automaticky vytvářenými segmenty, atd.). Ano, nastavení barev a fontů budete delegovat, ale i tak, předpokládám, že samotný objekt „nastavení vzhledu“ bude vlastností předka výše uvedených typů objektů, stejně tak další vlastnosti (id, text, left, top, width, height [nebudete-li mít Rect]) budou předpokládám vlastností předka, skaláry ani nelze delegovat. Stejně tak medy jako Save, Load, DoMouseDown, DoMouseMove, Paint nebudete delegovat (jejich chování je přímo vázané na daný typ). Tady se prostě hodí mít předka (toto dokonce ani bez předka prakticky udělat nejde [resp. ano, samo, že to jde, ale byl by to vyslovený nesmysl]).

Fakt, že existují programovací jazyky bez dědičnosti není argument, oni existují programovací jazyky bez OOP a přesto OOP nezavrhujete.

Navíc Self samozřejmě dědičnost má a to právě prototypovou (vypadá to, jako byste za dědičnost považoval pouze dědičnost třídní, ale dědičnost lze implementovat 2 způsoby: jako třídní a jako prototypovou).

A na konec, když už jsme u toho, Vámi popsaného problému se nezbavíte v případě prototypové dědičnosti, pokud dědíte od prototypu (živého objektu), potom ve chvíli, kdy změníte vlastnosti rodičovského objektu (v objektu, v jeho prototypu či v konstrukční funkci), tak k tomuto rozbití může dojít tak jako tak.

Jiří Knesl

Právěže to není variací na jeden argument. O tom, jak lidé používají OOP špatně jsem se zmínil jen na konci.

Co jsem napsal: OOP založené na dědičnosti má i své stinné stránky a můžete ho dělat sebelíp, časem se budete muset „snížit“ k návrhovým vzorům, které nevýhody dědičnosti řeší.

Co když ten Control (např. obdélník v modelovacím SW) bude mět mít možnost změny vzhledu a zároveň reagoval na uživatelskou akci (zvětšit, double click, right click). V tu chvíli už budete motat dohromady vzhled a chování a porušíte single responsibility principle (a je to obdoba spaghetti-kódu, který míchá HTML šablonu a aplikační logiku). Možná se neshodnem, ale v jedné třídě by nikdy neměly být metody pro View a pro Model (existují způsoby, jak to řešit čistě: mixiny, kategorie, nicméně i to má své slabé stránky).

Já netvrdím, že „dědičnost je špatná, protože existuje Self“, já tvrdím, že: „dědičnost má stinné stránky, ale existuje jazyk, které se je snaží řešit jiným přístupem“. Dědičnost by měla záporné stránky, ikdyby Self nakrásně neexistoval.

Abych to vyjasnil, vztahuji se k termínům: „class-based“ a „prototype-based“, kde druhý považuji za lepší než první. Ale máte pravdu, rozbít se dá všechno – i změnou prototypu. Chyba, která by rozbila třídu, rozbije často i ekvivaletntní obdobu v prototypu.

bauglir

Jak jsem psal výše, vzhled samozřejmě bude delegován jinému objektu, který bude vlastností, ale pokud se bavíme o view a controller a srovnáváte to s HTML vs. App logika (HTML vs. JS nebo HTML vs. serverový kód), tak musíte vzít jako fakt, že někde se ty dvě vrstvy sejít musí, nějak musíte data zobrazit, ale samozřejmě na co nejužší plose, pokud zůstanu u designeru, který jsme popisoval, potom, samotný designer (control s canvasem: CanvasControl) bude mít ponětí o nějakém typu CustomDesigne­rObject (obecném objektu tvaru), ale nebude mít naprosto tušení o tom, že to může být text, čára, obdélník, složený tvar, Jediné, co udělá, bude, že požádá daný objekt, aby se vykreslil (a tímto způsobem odstíníte view od modelu, protože danému objekty předáte prostě canvas, a může to být canvas controlu, bitmapového obrázku, tiskárny)… čili, objekt, na který bude vykreslováné nezajímá, co přesně na něj bude vykresleno a tvar nebude zajímat, na jaký typ canvasu se vykresluje. Stejně tak úkolem tvaru nebudou samotné grafické fuknce (jak nakreslit čáru, elipsu), to zase bude delegováno jinam. Ano, v tomto případě, by bylo možné implementovat mezivrstvu, jakýsi DesignerControl, který bude na jedné straně přijímat canvas, na který se má vykreslit a na druhé straně popis tvaru (např. SVG) a bude prostě umět vykreslit „nějaké“ SVG na nějaký canvas, ale i tak, pokud bych případ řešil tímto způsobem (tzn. definoval si nějaký popis obecný obrázku), ve finále cesta bude stejná: CanvasControl­.paint() vyvolá CustomDesigne­rObject.paint(). Protože totje je IMHO nejlogičtější cesta, která neodporuje single-responsibility principu (každý typ je zodpovědný za funkčnost jenom a právě sebe). Váš postup může dopadnout tak, že vám zbudou objekty pouze jako datové struktury s 1-2 funkcemi (constructor, destructor) a statické typy, kde objektu budou držet data živých objektů a statické typu budou zodpovědné za fukcionalitu (SvgConvertor, Painter, MouseProcessor, KeyProcessor, Saver, Loader, co já vím). A ano, budete to mít cool, vše delegované, dědičnost pouze ve smyslu „nemusim definovat vlastnosti“. Jenže v tomto případě vypadne jakákoliv konzistence funkcionalit, vypadne možnost dědit funkcionalitu z předka, statické typy budou muset mít přehled o interní struktuře jednotlivých objektů apod. Tak jako tak nelze dědičnost odmítnou, můžeme pouze diskutovat o tom, co je a není vhodné delegovat a co ne.
Ad Self: znovu a podruhé: Self má dědičnost :)

Je fakt, že změna rodiče (ať už třidy, nebo prototypu) může vést k rozbití funkcionality, ale to je prostě jako s jakýmkoliv programováním, záleží na programátorovi… Je na něm, jak kvalitní návrh je shopen vytvořit, je na něm, zda je schopen si pohlídat, co je shodné (a patří do předka) a co ne, co je specifické (patří do objektu) a co ne…

pas

Můžu se zeptat na podrobnosti k tomuto bodu? (stačí klidně nějaký odkaz)

„slabá typová kontrola naopak vývoj aplikací zlevňuje.“

Já se ani náhodou nechci hádat, jen mě prostě zaujalo, že to je v rozporu s mými osobními zkušenostmi, tak si chci ověřit, zda zefektivnění práce mé a mých kolegů při přechodu na silně typové jazyky nepřičítám něčemu zcestnému (a skutečný důvod je třeba banální – zlepšení přicházející s věkem :)). Díky.

Jiří Knesl

Asi záleží na tom, jak je použijete. Silné typování vede k jednomu postupu, který vede k lepší čistotě a následkem i produktivitě (k immutable proměnným, jakkoliv nejsou explicitně vyžadovány) a jinému triku brání (implicitnímu přetypování). Třeba já kombinuju obojí, v jedné proměnné udržuju vždy jen jeden typ a přetypování (ať už implicitní nebo explicitní) provádím zase do dalších proměnných, jejichž typ mi bude znám.

Co se například intellisense týká, jeden přístup to řeší typy, další anotacemi. Já ve vimu to řeším tréningem paměti. :)

To, jestli je to naprogramované správně musí stejně řešit automatizované testy a ty je nutné psát pro naprosto jakýkoliv jazyk. Tím pádem dojde i k ověření správného použití rozhraní (pomocí mock objektů), návratových hodnot atd.

Co se zkušenosti týká: ta hraje velkou roli. Rutinní operace bude vždy rychlejší, než když je nutnost objevovat, číst dokumentaci a hledat.

blizzboz

váš príspevok je jeden blábol za druhým na to ani nemá zmyslel reagovať, ale táto veta je donebavolajúca kravina: slabá typová kontrola naopak vývoj aplikací zlevňuje. asi sa programovaním neživíte nikdy ste nepracovali na vačšom projekte a tejto problematike jednoducho nerozumiete.

Michal Augustýn

No nevím, přijde mi to spíš jako ochuzení jazyka než obohacení. Jediné, co se mi líbí, je Bang! (aka async-await v C# 5).

karf

To by mě zajímalo, kdo má v rámci dlouhodobě udržitelného růstu efektivity práce (ušetřením několika závorek) čas zkoušet každý týden nový jazyk s obskurní syntaxí. Fakt nad tímhle někdo uvažuje pro seriózní práci? (Kromě toho mám radši čaj.)

imploder

+1 .

blizzboz

ten coffeScript vyzeral celkom pekne akurát mi v ňom stále chýbalo ešte pár drobností…

Josef Richter

zkus trochu otevřenější pohled na svět ;-)

Pingy

No, první když jsem viděl ten titulek jsem přemýšlel, co tu dělá přehrávač Kaffeine, ale pak až sem ho otevřel mi to došlo :D

severák

Vtipný je, že Kaffeine a Coffe script ukazujou sílu javascriptu. V něm byl naprogramován interperet loga – http://www.calormen.com/logo/, Forthu – http://www.forthfreak.net/jsforth.html a i jiné poněkud neobvzklejší jazyky.

Já teda nevim co je na javascriptu tak špatně, v určitých věcech je i o ždibec praktičtější než Java, C nebo nedej bože C s křížkem.

bauglir

Je „jiný“. A jako všechno, co je „jiné“, musí být zničeno, protože když je to „jiné“, tak to je „špatně“ ;)

pas

To se spíš říká, když je něco „nové“ (a jiné). JS je tu s námi vícéméně beze změn 15 let, tak snad je povoleno o něm vést seriozní diskusi. :) Ruku na srdce – vážně si myslíte, že kdyby Netscape v roce 1995 viděl, že za 15 let se z browseru stane operační systém, trval by na JavaScriptu? Nepoužil by náhodou prostě Javu? Proč se dnes nesáhne po JavaScriptu v nově vznikajících platformách? Proč Google dává přednost Javě pro Android, proč BlackBerry dává přednost ActionScriptu pro TabletOS? Zkrátka obhajování „výhod“ JS se mi jeví trochu umělé a neupřímné – radši by se měla energie věnovat naplnění té vize webového „assembleru“ s nadstavbami v podobě jazyků, na které jsou vývojáři zvyklí. Jsem fanouškem crossplatformních aplikací v browseru a nerad bych, aby je převálcovaly klasické nativní aplikace pro jednotlivé OS, třeba proto, že je to nakonec snazší na vývoj. Malinko to obracení trendu cítím, díky dravosti mobilních OS.

pas

Ale no tak. :) Netscape to viděl jako: BUĎ dokumenty (HTML + JS na sem tam nějaký rollover efekt) NEBO aplikace (Java aplety). Dva oddělené světy. Což byla ona podstata neprozíravosti. Operační systém se nám stal z těch dokumentů.

bauglir

Ale to samozřejmě ani náhodou :) JavaScript vznik prioritně jako nástoj pro ovládáni Java appletů. Sun tehdy tlačil na Netscape, aby podporoval Javu, Netscape to prozíravě odmítl…

blizzboz

Java Applety pochoval microsoft tým že Javu vyhodil z Windows XP a presadzoval ActiveX, ActiveX sa pochovalo samo lebo malo bezpečnostné prtoblémy.

bauglir

Myslíte si, že kdyby vývojáři C všděli, že z toho jazyka bude jenou podklad pod vtakřka všechno, že by ho napsali stejný? A myslíte si, že kdyby vývojáři C++ vyděli do budoucnosti, že by rovnou nenavrhli C#? A myslíte si, že kdyby vynálezci automobilu věděli, jakou rychlostí a jak se bude jezdit, že by do něj nenavrhli airbacky rovnou? To je teda argument? Myslíte si, že existuje člověk, který by měl následné realitě odpovídající předtavu o tom, co se stane v SW/HW průmyslu za 15 let?
Ještě jednou, nic proti wrapperům, jejich jediným důsledkem je změna syntaxe (funkcionalitu změnit nemohou). Pokud vám to vyhovuje, používejte to… A jestli nevidíte některá výhody ECMAScriptu? Dobrá, nevidíte… mě to zase může přijít jako takový folklór lidí, která se neobtěžovali pochopit jazyk (samo, nikdo Vás k tomu nenutí), ale kopat jen tak? Hm….
Mobilní OS jsou aktuálně realitou, ale mám za to, že browser jako crossplatform runtime už nic nezastaví, naopak, takové aplikace budou crossplatform i z hlediska typu HW (desktop, tablet, mobil).
To, co teď akutně chybí, je knihovna ovládacích prvků…

bauglir

Ještě dodám, samo, že by se mi líbilo, kdyby vendoři nasáčkovali do browsery C# nebo Object Pascal (nebo tedy když taž i tu overrated Javu, pokud by napsali vlastní interpret, né ten od Oraclu), ale
1/ buď by se změnila jenom syntaxe (+ přidali například třidy), což je IMHO zbytečné, a navíc jazyk je sice fajn věc, ale přidaná API jsou v realitě důležitější, a pokud jsem zvykli na WinAPI z Pascalu nebo C#, tak by to bylo, jako by mi najednou usekli ruce…
2/ nebo by portovali i API na které jsme zvyklí z desktopového programování, což by ale značně snižovalo portabilitu mezi platformami
3/ A to úplně nejdůležitější: věci se mají tak, jak se mají a nic nenasvědčuje tomu, že ECMAScript bude nahrazen (novým jazykem, ne wrapperem kolem něj). Takže nadávání na něj mi připomíná koučování fotbalu z gauče u televize… nechápu účel

bauglir

sorry za strašné hrubky… už jsem nějak moc dlouho vzhůru :)

imploder

Souhlasím. Já bych si tady radši přečetl o šikovných tricích v samotném JS (ten „správný způsob, jak v JS programovat“), experimentální nadstavby jsou zajímavá věc, ale zatím ne moc prakticky použitelná. Prostě líbily by se mi články o „asembleru webu“ ukazující, jak programovat v souladu s jeho filozofií a nesnažit se tam rvát zažité postupy z C/C++ (jak se zřejmě většina lidí snaží).

bauglir

přesně, děkuji!

imploder

Díky.

pas

Já vaše postoje, založené na nějaké praxi, chápu, a vy prosím pochopte ty moje, založené zase na jiné praxi, a hlavně prosím opakuji, že v mém případě nejde o „neobtěžování pochopit jazyk“. U mě je to přesně naopak – od JavaScriptu, poté ActionScriptu 1 (což je totéž), jehož filozofii velmi dobře znám, jsem teprve po letech přešel k AS2 a AS3, takže mám skvělou příležitost každodenně si zkoušet, „čím mohl být JavaScript“ (kdyby nebyl zavržen ECMAScript 4 – základ i pro AS3). Kromě toho Flash posloužil jako skvělá případová studie na téma, jak navrhnout jazyk, který je na jedné straně robustní pro velké aplikace, a na druhé straně nadále nepřidělává vrásky ani těm, co potřebují rychle spíchnout nějaký ten rollover efekt (to se Javě nepodařilo). Jednoduše vidím, že od té doby jsem produktivnější, dělám méně chyb, rychleji je najdu a vyřeším, atd., toť vše. Touha zdokonalovat jazyk je přece přirozená všude, proč by web měl být výjimkou – holt to tam bude muset jít cestou těch nadstaveb, to je všechno, co jsem chtěl říct, snad jsem tedy dostatečně vysvětlil, že „nekopu jen tak“.

bauglir

Rozumím, ale tady je otázka, které návrhy jazyk zdokonalí a které jej pouze změní… možnost bez obezliček definovat private a protected properties? Rozhodně zdokonalení. Nahradit prototypy třídami? Namespaces? Strikní a silné typování? Jenom změna. Ano, nejspíše změna blíže k mainstreamu, ale jenom změna, nikoliv zdokonalení jazyka.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.