Vyplatí se učit Angular?

[rejpal]

elektron framework a napr. M$ Visual Studio Code (a x dalsich) na Slovensko jeste nedorazily ?

[Reklama]

[jpu]

hej, bezne vsetci vyvojari pouzivaju Visual Studio Code. Na normalne VS sa to nechyta. Kazdy, kto chce robi s Visual Studiom, tak si radsej stiahne Community ediciu, ktora je zadarmo a nebude si tahat VS Code .
A snad nechces povedat, ze VS Code je LOB aplikacia

[jpu]

co sa tyka vyuzitia MS technologie, tak WPF sa pouziva pri LOB aplikaciach. Apropo, naco potrebujem multiplatformovost, ked cely den budem sediet za pc s windowsom??? Stale ti nedochadza, ze naco mam brat technologie tretich stran, ked mozem pouzit nativnu technologiu?

[kimec]

A pro toho cloveka, co nevidi, jak to souvisi s tematem: dotaz byl na Angular, aktualni Angular je TypeScript-first a argument, ze "pro vsechny frameworky/knihovny stejne existuji typove soubory, takze neni treba resit, zda to podporuje primo TypeScript" je spatny. Sice je pravdivy, typove soubory existuji pro skoro vse, ale casto byvaji plne any (tzn. v podstate vypnuti typove kontroly), neuplne nebo i spatne. Takze pouzivat takovou knihovnu/framework je velmi nepohodlne a casto skoncim s tim, ze si budto upravim/vytvorim typove soubory sam, nebo si napisu spravne typovane wrappery.

Hovadina. Jeden priklad za vsetky: reaktivne formulare. Ak je nieco TypeScript-first, tak v prvom rade to musi mat poriadne otypovane verejne API. Ak TypeScript riesi iba typy a nejaky projekt o sebe tvrdi, ze je TypeScript-first, ale vo svojom verejnom API pouziva any, tak to potom nie je TypeScript-first.
Citajte so mnou definiciu typu asynchronneho validatora AsyncValidatorFn z Angularu 2.0.1:

Kód: [Vybrat]

/**
 * @stable
 */
export interface AsyncValidatorFn {
    (c: AbstractControl): any;
}
Vidite tam to @stable? Ja ano. Vidite tam navratovy typ any? Ja ano. Je to verejne API? Je. Tak podme na API dokumentaciu AsyncValidatorFn pre verziu Angular 2. Vidite tam vobec nejaky navratovy typ? Ja nie.

Aka to skoda, ze uz davno v tom case mohol byt navratovy typ iba Promise alebo Observable. A ako sa to dalo zistit? No jednoducho, pozreli ste si zdrojaky. Ako mne a mojmu IDEcku pomohol Anuglar2 TypeScript-first pristup v tomto pripade? Absolutne nijako.

Ale ano, mate pravdu, o zopaaaar verziiiii (a mesiacov) dalej sme dostali konecne typ, ktory sice implementacia vyzadovala od zaciatku, ale TypeScript-first Angular2 to nepovazoval za podstatne...

A moralne ponaucenie? Ak je nieco v TypeScripte napisane, neznamena to, ze to ma poriadne zadefinovane typy vo svojom verejnom API. Aky je potm rozdiel medzi typovymi deklaraciami generovanymi z TypeScriptu voci retrofitovanym API pre kniznice, ktore v TypeScripte napisane neboli? Absolutne ziadny - odflaknut sa da oboje, breakovat sa bude oboje.

O tom, ze pri transpilacii sa typy zahodia a ze vyznam TypeScriptu je dokumentacny (a IDEcku napomahajuci) sa dufam bavit nemusime.

[kimec]

Bavime sa po a) o SPA, po b) o javacriptovych frontendovych frameworkoch... ako sme sa dostali k Haskellu, preboha? Mohli ste rovno napisat, ze pri volani Haskellu z C++ typove deklaracie nie vzdy sedia a ze mnohe typy vasej kniznice sa v C++ nedaju ani vyjadrit. Ci to nebude tym, ze kazdy iny jazyk ma problem s Haskellom? Dovolim si tvrdit, Typescriptovy typovy system je dost sofistikovany voci ziadnemu a odost lepsi ako typovy system nominalne typovanych jazykov.

Řeknu ti to jednodušeji: máš existující JS knihovnu, která z nějaké fce vrací pole [1,'ahoj'].

Plain JS je tak volný, že se rozumným typovým systémem dá dost těžko postihnout všechny možné finty. Čili je lepší mít zbrusu novou knihovnu, která je celou dobu psaná tak, aby do TypeScriptu sedla, než zcela volně napsanou Plain JS knihovnu, která sem tam do TypeScriptu nesedne.

P.S. Co je na typovém systému TypeScriptu sofistikovaného!?

Hej, hej, preto ani v TypeScript-first Angular4 neexistuje metodika ake access modifiery pouzivat na komponentoch, ku ktorym pristupuju templaty. Ved na konci dna sa z toho aj tak kompiluje JavaScript, ktory ziadne access modifiery nema. Aha ono to potom nefunguje dobre s AOT kompilaciou, ked ludia pouzivaju restriktivne access modifiery. A to si dovolili na komponentoch, ktore sa kazdy snazi izolovat!? (ze by access modifiery boli integralnou sucastou TypeScript-u?).

Nuz, snad sa raz do tej dokumentacie dostane, ze komponenty sa sice pisu v TypeScripte, ale vlastne nemozete pouzivat plnohodnotny TypeScript, lebo veci prestanu fungovat...

Tomuto hovorim TypeScript-first Angular ^tm.

Nenapisal som, ze na typovom systeme TypeScriptu je nieco sofistikovane, napisal som, ze oproti ziadnemu typovemu systemu (JS, ES), je ten TypeScriptovy, dost sofistikovany... a tym som myslel, ze to mohlo dopadnut horsie.

[Reklama]

[kimec]

Jn, a dopadne to jako typy pro pajpu v Ramde. Vse je zcela jasne na prvni pohled z typu :

Kód: [Vybrat]

        pipe<V0, T1>(fn0: (x0: V0) => T1): (x0: V0) => T1;
        pipe<V0, V1, T1>(fn0: (x0: V0, x1: V1) => T1): (x0: V0, x1: V1) => T1;
        pipe<V0, V1, V2, T1>(fn0: (x0: V0, x1: V1, x2: V2) => T1): (x0: V0, x1: V1, x2: V2) => T1;

        pipe<V0, T1, T2>(fn0: (x0: V0) => T1, fn1: (x: T1) => T2): (x0: V0) => T2;
        pipe<V0, V1, T1, T2>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2): (x0: V0, x1: V1) => T2;
        pipe<V0, V1, V2, T1, T2>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2): (x0: V0, x1: V1, x2: V2) => T2;

        pipe<V0, T1, T2, T3>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x: V0) => T3;
        pipe<V0, V1, T1, T2, T3>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x0: V0, x1: V1) => T3;
        pipe<V0, V1, V2, T1, T2, T3>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3): (x0: V0, x1: V1, x2: V2) => T3;

        pipe<V0, T1, T2, T3, T4>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x: V0) => T4;
        pipe<V0, V1, T1, T2, T3, T4>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x0: V0, x1: V1) => T4;
        pipe<V0, V1, V2, T1, T2, T3, T4>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4): (x0: V0, x1: V1, x2: V2) => T4;

        pipe<V0, T1, T2, T3, T4, T5>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x: V0) => T5;
        pipe<V0, V1, T1, T2, T3, T4, T5>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x0: V0, x1: V1) => T5;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5): (x0: V0, x1: V1, x2: V2) => T5;

        pipe<V0, T1, T2, T3, T4, T5, T6>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x: V0) => T6;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x0: V0, x1: V1) => T6;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6): (x0: V0, x1: V1, x2: V2) => T6;

        pipe<V0, T1, T2, T3, T4, T5, T6, T7>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn: (x: T6) => T7): (x: V0) => T7;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6, T7>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7): (x0: V0, x1: V1) => T7;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6, T7>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7): (x0: V0, x1: V1, x2: V2) => T7;

        pipe<V0, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x: V0) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T6) => T7, fn: (x: T7) => T8): (x: V0) => T8;
        pipe<V0, V1, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x0: V0, x1: V1) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T5) => T6, fn7: (x: T7) => T8): (x0: V0, x1: V1) => T8;
        pipe<V0, V1, V2, T1, T2, T3, T4, T5, T6, T7, T8>(fn0: (x0: V0, x1: V1, x2: V2) => T1, fn1: (x: T1) => T2, fn2: (x: T2) => T3, fn3: (x: T3) => T4, fn4: (x: T4) => T5, fn5: (x: T5) => T6, fn6: (x: T5) => T6, fn7: (x: T7) => T8): (x0: V0, x1: V1, x2: V2) => T8;

A abych nezapomnel, tak od urcite hranice (tusim 5 nebo 6?) pretizeni to zacina solidne zpomalovat preklad cele aplikace.

+ jak jsem psal vyse, TypeScript (co vim) neumi vyjadrit ani zakladni funktor (genericky parametr nemuze vystupovat jako typ, ktery sam je parametrizovany; napr.), coz je pro funkcionalni programovani celkem dulezite (pokud tedy chcete nejake ty abstrakce a ne vse definovat nadesetkrat).

Ja to chapem tak, ze TypeScript sa snazi prepasovat aspon naznak klasickej enkapsulacie a "tradicneho" OOP z jazykov ako su C++, C# a Java do JavaScriptu. Robi tak preto, aby ludia s C++, C# a Java pozadim neboli uplne strateni v prototypovom nestabilnom svete s nazvom JavaScript. Tiez to robi preto, aby vam vedelo IDEcko pomahat. Na premostenie tychto dvoch svetov bol zvoleny typovy system, ktory dokaze "napodobnit tu Javu", ale zaroven si ako tak rozumie s JavaScriptom...

...a obe vase vytky boli v tom, ze TypeScript neumoznuje plnohodnotne funkcionalne programovanie?! Clovece, nezmylili ste si nahodou jazyk?

Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?

[noef]

Ja nerikam, ze Angular ma dokonale typovani (par any nutne neznamena, ze je neco spatne, pokud ale any pouziva kazda druha nebo kazda definice [videl jsem takove "typove" soubory], tak je to nepouzitelne a TypeScript se ani nemusi pouzivat, protoze nepouzivame zadne typy).

Muj argument byl spise opacny - pokud to neni TypeScript-first, tak mam jistotu, ze typy tam jsou spise na okrasu, bude jich cast chybet uplne, nebudou sedet k aktualni verzi knihovny, pripadne k verzi knihovny, kterou chci pouzit (nebo uz to snad podporuje verzovani, ten typings nastroj?) atd.

Ja to chapem tak, ze TypeScript sa snazi prepasovat aspon naznak klasickej enkapsulacie a "tradicneho" OOP z jazykov ako su C++, C# a Java do JavaScriptu.

To uz dela JavaScript sam, ES2015 ma tridy, na to neni potreba TypeScript.

Robi tak preto, aby ludia s C++, C# a Java pozadim neboli uplne strateni v prototypovom nestabilnom svete s nazvom JavaScript.

Nevim, i dost "plnohodnotnych" (ve vyznamu znaji a umeji pouzivat prototypovou dedicnost) JavaScript vyvojaru nema prototypy rado. Ale jiste, je mozne, ze je nemaji rado proto, ze k JS prechazeli z klasickeho OOP.

Tiez to robi preto, aby vam vedelo IDEcko pomahat.

Ano, to je jeden z hlavnich duvodu, proc mam radsi TypeScript nez divoky JavaScript.

Na premostenie tychto dvoch svetov bol zvoleny typovy system, ktory dokaze "napodobnit tu Javu", ale zaroven si ako tak rozumie s JavaScriptom...

To je trosku problem, protoze rozumnet si s dynamickym JavaScriptem, kde kazda knihovna muze pouzivat specialni logiku - svuj typovy system, nevim jestli je dosazitelne. Osobne me spis pripada, ze Angular se snazi napodobit Javu (predepisuje celkem jasne strukturu, cileny na velke projekty), TypeScript samotny mi Javu nebo jeji pristup zase tolik nepripomina (ale urcite napomaha v enterprise svete, o tom zadna). Podobne mi Flow take nepripomina Javu, mit typy != je to Java.

...a obe vase vytky boli v tom, ze TypeScript neumoznuje plnohodnotne funkcionalne programovanie?! Clovece, nezmylili ste si nahodou jazyk?

Nespletl jste si vlakno? JavaScript JE funckionalni jazyk . A stejne tak knihovny v nem pouzivaji typovy system zalozeny na Haskellu - viz Ramda nebo Sanctuary. Sanctuary dokonce provadi i typovou kontrolu (volitelne v runtime).

TypeScript se snazi svym typovym systemem umoznit bezpecne pouzivani JavaScriptovych knihoven a zaroven Sanctuary je JS knihovna (ktera ale kvuli slabemu typovemu systemu TypeScriptu nemuze byt spravne natypovana) => TypeScript je problematicky pri pouzivani JS knihoven. Chcete to napsat jeste nejak jinak, nebo to staci takto?

Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?

Co vim, tak to nebylo moc slavne. Si to s sebou tahalo runtime Haskellu a moc podporovane to nebylo. To uz spise PureScript nebo mozna Elm (ale ten je pry hodne ochuzeny). Ale zadny z nich se jaksi bezne u nas nepouziva, takze pokud se tim chcete zivit v CR, tak TypeScript nebo mozna Scala jsou asi nejblize funkcionalnimu svetu.

[jpu]

Aky prinos maju pre dotycneho tie vase prispevky kde si rozoberate haskell? To urcite zaujima tazatela. Mozne len na rootu.

[andy]

Ved Haskell sa da corsskompilovat aj do JavaScriptu, ci?

Da - akorat k tomu je dost velký runtime. Jinak to teda překvapivě funguje, ale mám pocit, že jediné rozumné řešení je používat "reflex"... což není špatné, akorát, že je to hodně work-in-progress... Asi bych to nedoporučil (a nějak mi nesednul ani purescript, bohužel moc už nevím, co je lepší varianta...).

[noef]

Aky prinos maju pre dotycneho tie vase prispevky kde si rozoberate haskell? To urcite zaujima tazatela. Mozne len na rootu.

Rozebira se TypeScript, ktery s Angularem velmi uzce souvisi. Pokud si OP zvoli Angular a tim i TypeScript (ostatni verze [Dart a JS] na tom byly s dokumentaci a popularitou podstatne hure, nevim jak je to nyni), tak je dobre vedet, na co se v pripade TypeScriptu pripravit. Rozhodne to neni krasny svet statickeho typovani jako zname z Javy, C#, Scally nebo Haskellu.

Typovy system Haskellu (asi spise podmnozina) v JavaScriptove knihovne mel pouze ilustrovat znacna omezeni pri pouzivani JavaScriptovych knihoven v TypeScriptu. Zaver je, ze pokud se rozhodnete pouzivat TypeScript, tak cokoliv, co nebylo psane pro TypeScript, bude velmi obtizne pouzitelne bez obezlicek nebo vynechani typu a tim se ztraci vyhoda TypeScriptu.

Uz chapete, jak to souvisi s tematem?

[Mirek Prýmek]

Uz chapete, jak to souvisi s tematem?

Ono to s tématem souvisí i tak, že TypeScript byl na JS naroubovaný ex post a byl vymyšlený tak, aby pokryl (aspoň) většinu patternů, které se v praktickém JS skutečně používají. Čili když s ním chce někdo dělat, neměl by očekávat stejný komfort a čistotu jako u jazyků, kde byly typy od začátku a používané patterny se musely přizpůsobit jim, ne naopak. Proto srovnání s Haskellem nebo Elmem určitě má smysl, aby člověk věděl, co očekávat.

+ jak jsem psal vyse, TypeScript (co vim) neumi vyjadrit ani zakladni funktor

A to bych mu ani zas tak moc nevyčítal. Dovedu si představit (čistě laicky, nikdy jsem nic takového nepsal, ani tomu jinak zvlášť nerozumím), že higher-kinded types implementaci typového systému (a zvlášť inference) hodně zesložití a v kombinaci s jinými silnými featurami (třeba polymorfismus) se ztratí determinismus a celý to začne být chaos, který za ty higher-kinded types nestojí. Já osobně moc nemám rád, když mi občas překladač řekne, že neví, a musím ho ručně nakopnout. Většinou jsou ty hlášky totiž dost komplikované a člověk si musí zbytečně lámat hlavu nad tím, kam vlastně to nakopnutí dopsat... Nehledě na to, že to je velký prostor pro těžko debugovatelné chyby překladače.

[noef]

Ono to s tématem souvisí i tak, že TypeScript byl na JS naroubovaný ex post a byl vymyšlený tak, aby pokryl (aspoň) většinu patternů, které se v praktickém JS skutečně používají. Čili když s ním chce někdo dělat, neměl by očekávat stejný komfort a čistotu jako u jazyků, kde byly typy od začátku a používané patterny se musely přizpůsobit jim, ne naopak. Proto srovnání s Haskellem nebo Elmem určitě má smysl, aby člověk věděl, co očekávat.

Ano, dekuji, tak jsem to presne myslel.


Myslim, ze na tech higher-kinded types delaji. Ale dovedu si predstavit, ze je to beh na dlouhou trat (uz ted podporuji zajimave veci jako union a intersection typy, n-tice pres pole, typ this u funkce, pretezovani, enumy [zajimave v kontrastu k JS]).

Inference celkove je bohuzel v TypeScriptu slaba . Jak jsem psal, treba generika u curried funkce (ihned volane) neodvodi a musi se otrocky vypisovat vsechny typove parametry. Videl jsem navrhy, jak to resit, pres nejaky "auto" typ a prekladaci podsunout jen ty typove parametry, ktere odvodit nevzladne. Neni to idealni, ale porad lepsi nez nynejsi stav. Mozna i defaultni typove parametry by tomu mohly pomoci, nevim.

TypeScriptu se musi nechat, ze jeho typovy system se rozsiruje s kazdou verzi a vyvoj je IMO rychly (oproti nejake Scale je TypeScript blesk; pravda, ve Scale se prepisuje cely prekladac a prekopova i jazyk, mozna nejsem fer).

[kimec]

Nespletl jste si vlakno? JavaScript JE funckionalni jazyk .

Iste, iste a preto ma prvotriednu podporu vynimiek a try/catch konstrukt pre imperativne riesenie side effectov... Noze este prilozte ako vyzera JavaScriptovy try/catch v Haskelli - nech si rozsirim obzor. Navyse si zelam, aby control flow pokracoval hned na riadku po odchyteni vynimky v tele presne tej istej funkcie, v ktorej vynimka nastala bez toho, aby ju runtime vobec opustil. Ved JavaScript JE funkcionalny jazyk, to predsa musi ist aj v Haskelli.

To uz dela JavaScript sam, ES2015 ma tridy, na to neni potreba TypeScript.

A kde ma triedy ES5?

Viete, ze aj Džava ma pvotriedne funkcie a monady? Je to podla vas funkcionalny jazyk?

Sanctuary je JS knihovna (ktera ale kvuli slabemu typovemu systemu TypeScriptu nemuze byt spravne natypovana) => TypeScript je problematicky pri pouzivani JS knihoven. Chcete to napsat jeste nejak jinak, nebo to staci takto?

Nie, nie, uz som pochopil. Vam vadi, ze vasa oblubena kniznica, inspirovana typovym systemom Haskellu a naimplementovana v JavaScripte, nie je otypovatelna TypeScriptom, ktory je inspirovany typovym systemom nominalne typovanych imperativnych jazykov ako C++ a Java, a ktory aby rozumne spolupracoval s JavaScriptom pouziva strukturalne subtypovanie a type erasure pri kompilacii. Vystihol som to presne?
Viete, tak nejak mam pocit, ze mozno keby ste zobrali kniznicu napisanu v JavaScripte, ktora sa inspirovala typovym systemom Javy, nebudete mat vobec problem ju ex post otypovat cez TypeScript. Nemyslite si to tiez? Ci toto nebude to, co tu nazyvate TypeScript-first....

Myslim, ze vas matie to Type v nazve TypeScriptu. Ale viete, firmy si vyberaju rozne nazvy produktov. Mozno by vam ulahodil HaskellTypedTypeScript, ktory ale zatial neexistuje.

[Mirek Prýmek]

Viete, ze aj Džava ma pvotriedne funkcie a monady? Je to podla vas funkcionalny jazyk?

Promatkuprirodu jenom prosim nezacinejte flame ohledne definice pojmu "funkcionalni jazyk" 

[jpu]

Noef:
Nie, neviem ako to suvisi s tematom. Tazatel sa zaujima, ci sa oplati ucit Angular. Ano/nie a preco. A nie to, co tu rozoberate vy