Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Jakub Váňa 25. 01. 2017, 23:52:54
-
Krásný den,
byl jsem požádán, abych uřídil vývoj webové aplikace - pro jednoduchost řekněme, že to bude něco podobného Trellu, ale to je fakt zjednodušení - ne, nechceme napodobovat tento produkt, ale pro pochopení situace se dá předpokládat, že druhé Trello vyvíjíme ;-).
Ačkoli finální výběr technologie bude na vývojářích, měl bych být připraven na diskusi na téma, proč je právě zvolená technologie nejvhodnější a být relevantním oponentem.
Jalikož nejsem z webové oblasti IT pořeboval bych se nějak zorientovat v tom, co je na vývoj aplikace podobné Trellu dnes vhodná technologie.
Rád bych se poradil, kde vůbec začít - a odfiltroval uplné nesmysly. Když hledám, zjišťuju, že už teď spoustu názvů latantně znám, ale povětšinou si pod nimi neumím nic představit. Obecně se mi už teď líbí serverside javascript, tak abych nekombinoval jazyky a aby se v případě nutnosti mohli částečně zastoupit client a server side developeři.
Moc děkuju za nějaké směrování .... ;-)
-
Rubyonrails... Kamaradi se se všemi typy SQL
-
Trello běží na Node.js, Backbone.js a MongoDB, tak co třeba to? ;-)
-
Výběr je skutečně velký a i když se zdá že můžete vybrat špatně, tak je to jen iluze - ve skutečnosti totiž záleží především na tom, jaké máte lidi a co oni umí.
Pokud máte vývojáře co jsou v něčem zkušení, vyberte to.
Pokud máte vývojáře a jsou natěšeni se něco učit, můžete to zvolit - ale bacha, je to riziko které ne všichni zvládnou ukočírovat.
Pokud vývojáře nemáte a teprve je chcete hledat podle zvolené technologie... tak máte docela velký problém a v podstatě nemůžete vybrat dobře.
-
Dalsi manazer, co hovno vie ale berie tazke prachy... :(
Ach jo...
-
Výběr je skutečně velký a i když se zdá že můžete vybrat špatně, tak je to jen iluze - ve skutečnosti totiž záleží především na tom, jaké máte lidi a co oni umí.
Pokud máte vývojáře co jsou v něčem zkušení, vyberte to.
Pokud máte vývojáře a jsou natěšeni se něco učit, můžete to zvolit - ale bacha, je to riziko které ne všichni zvládnou ukočírovat.
Pokud vývojáře nemáte a teprve je chcete hledat podle zvolené technologie... tak máte docela velký problém a v podstatě nemůžete vybrat dobře.
Děkuji za pohled - jelikož chceme první verzi zadat k vývoji nějakému týmu, tak si odnáším, že než technologie, budou pro nás důležitější reference ;-) S tím jsme i trochu počítali, ale u věčí věci má člověk vždycky obavu, aby si někde nezavřel dveře - s ohledem na další rozvoj produktu. Děkuji moc.
Děkuji i ostatním.
-
Dalsi manazer, co hovno vie ale berie tazke prachy... :(
Ach jo...
Zklamu Vás i Vaši negativitu ;-) Neberu za to žádné prachy - je to projekt, do kterého investuji své úsilí a taky z něj nic být nemusí, pokud nevyjde.
Ano, rozhodl jsem se vylézt z ulity a kromě techniky se naučit taky něco z byznysu, protože když si tyhle dva světy nerozumí, tak vznikají akorát výkaly ;-)
Nejsem webař a nebojím se to přiznat, to že jsem zbouchal pár věci v PHP a Nette ze mě nedělá odborníka. Jen pro představu, co moje odbornost je, tak jsem se živil i takovými věcmi, jako ladění ovladače pro síťovku a memory management Linuxu pro embeded zařízení, ovladače na flasku, správa storage .....
Mym jazykem je spíš assembler než javascript ;-) Víte, co je assembler ? :D :D
-
Výběr je skutečně velký a i když se zdá že můžete vybrat špatně, tak je to jen iluze - ve skutečnosti totiž záleží především na tom, jaké máte lidi a co oni umí.
Pokud máte vývojáře co jsou v něčem zkušení, vyberte to.
Pokud máte vývojáře a jsou natěšeni se něco učit, můžete to zvolit - ale bacha, je to riziko které ne všichni zvládnou ukočírovat.
Pokud vývojáře nemáte a teprve je chcete hledat podle zvolené technologie... tak máte docela velký problém a v podstatě nemůžete vybrat dobře.
Děkuji za pohled - jelikož chceme první verzi zadat k vývoji nějakému týmu, tak si odnáším, že než technologie, budou pro nás důležitější reference ;-) S tím jsme i trochu počítali, ale u věčí věci má člověk vždycky obavu, aby si někde nezavřel dveře - s ohledem na další rozvoj produktu. Děkuji moc.
Děkuji i ostatním.
Doporučuju Go, je nádherné blbuvzdorné, takže i méně kvalitní tým může vyprodukovat něco funkčního.
-
Něco podobného řeším už delší dobu a taky jsem z toho zoufalý....
Mám několik projektů v python+bottle na backendu a angular na frontendu. A není to dobré.
Node.js na backendu je dneska móda, pokud jo, tak bych se díval aspoň po něčem jako je Typescript. Na frontendu...v módě jsou nějaké ty Reacty, Vue apod., asi to není úplně špatný směr. MongoDB bych asi vynechal; je potřeba se nejdřív zamyslet, jestli budete mít takový provoz, že na něj sqlko nestačí...
-
Tu je vhodný odkaz k pročtení: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.ibn17k46q. V poslední době mě zaujal PostgREST (https://github.com/begriffs/postgrest), mám pocit, že by to na některé projekty, kde na serveru nepotřebuju žádnou velkou magii mohlo stačit.
-
Doporučil bych jako framework odoo, ten už správu projektů na vázanou na vše potřebné, včetně účetnictví má, má promyšlenou strukturu a dá se dobře modifikovat.
https://www.odoo.com/documentation/10.0/howtos/website.html
https://www.odoo.com/documentation/10.0/howtos/backend.html
Hlavně vám to vyřeší problém s tím, až aplikace bude úspěšná a firma se bude rozrůstat, administrativní záležitosti už budete mít dopředu vyřešené. Je možný snadný přechod do cloudu a zpřístupnění pro externí klienty.
-
Něco podobného řeším už delší dobu a taky jsem z toho zoufalý....
Mám několik projektů v python+bottle na backendu a angular na frontendu. A není to dobré.
Node.js na backendu je dneska móda, pokud jo, tak bych se díval aspoň po něčem jako je Typescript. Na frontendu...v módě jsou nějaké ty Reacty, Vue apod., asi to není úplně špatný směr. MongoDB bych asi vynechal; je potřeba se nejdřív zamyslet, jestli budete mít takový provoz, že na něj sqlko nestačí...
Taky jsem to nedávno řešil a zjistil, že pro backend pro obchodní aplikaci není moc co vybrat - PHP jako bezestavové nepovažuju ani za ten backend, Node.js není koncepčně špatné, ale Javascript mě jako modelovací nástroj a problematickou asynchronností zklamal. Python neposoudím. Do microsoftích vendorlockinových sraček bych nešel. Modelování by měla zvládnout Java, ale jak je to s frontendem, netuším. Osobně chci vyzkoušet ještě Pharo (implementace Smalltalku), ale to nikomu doporučovat nebudu, aby tu zas někdo nedržkoval.
Kdybych vyloženě nemusel, relační databázi bych už dnes nepoužil, protože vytvoření a aktualizace modelu v ní jsou v porovnání s dokumentovou DB extrémně náročné (už se to tu řešilo) - jasně, můžete použít nějaký framework, ale pak máte opět lock-in. To je ale osobní názor.
-
Něco podobného řeším už delší dobu a taky jsem z toho zoufalý....
Mám několik projektů v python+bottle na backendu a angular na frontendu. A není to dobré.
Node.js na backendu je dneska móda, pokud jo, tak bych se díval aspoň po něčem jako je Typescript. Na frontendu...v módě jsou nějaké ty Reacty, Vue apod., asi to není úplně špatný směr. MongoDB bych asi vynechal; je potřeba se nejdřív zamyslet, jestli budete mít takový provoz, že na něj sqlko nestačí...
Kdybych vyloženě nemusel, relační databázi bych už dnes nepoužil, protože vytvoření a aktualizace modelu v ní jsou v porovnání s dokumentovou DB extrémně náročné (už se to tu řešilo) - jasně, můžete použít nějaký framework, ale pak máte opět lock-in. To je ale osobní názor.
A relace bys tam dělal jak?
-
nejaky opensource, ktery vypadal jako trello a byl nejak propojeny s gitlabem jsem asi pred 2 rokama rozchazel. takze technologie asi podobne. jak jsou daleko ted, netusim, ani si nevzpominam na jmeno, ale kdyz tak pohledam ...
-
Spring boot na Backend, react na frontend.
https://projects.spring.io/spring-boot/
https://github.com/facebook/react
-
+1
A co ty relace?
-
Doporučil bych jako framework odoo, ten už správu projektů na vázanou na vše potřebné, včetně účetnictví má, má promyšlenou strukturu a dá se dobře modifikovat.
https://www.odoo.com/documentation/10.0/howtos/website.html
https://www.odoo.com/documentation/10.0/howtos/backend.html
Hlavně vám to vyřeší problém s tím, až aplikace bude úspěšná a firma se bude rozrůstat, administrativní záležitosti už budete mít dopředu vyřešené. Je možný snadný přechod do cloudu a zpřístupnění pro externí klienty.
+1
také bych nedělal podobnou věc od nuly. Můžete se místo znovuvynalézání kola soustředit na featury specifické pro vaší firmu.
-
Spring boot na Backend, react na frontend.
https://projects.spring.io/spring-boot/
https://github.com/facebook/react
Vue
-
prototyp udělej v čemkoliv na co máš vývojáře a co dokážeš spáchat rychle, django, symfony klidně na backend, react, knockout na frontend, nebo to napíš v Adě či erlangu. Automaticky počítej s tím, že to prostě přepíšeš, ale už budeš vědět a až si ověříš koncept.
Největší chyba, kterou teď můžeš udělat je to prostě na počátku přeoptimalizovat a vysnít si dokonalou aplikaci. Je nemožné na takovémhle začátku zvolit správný technologický stack, často se ani netrefí borcí co to dělají 30 let, pač dopředu není známá návštěvnost, funkcionalita nebo třeba počet vývojářů či vývojové procesy.
Rozděl rozpočet, 1/3 dej na PoC (Proof of concept; pilot), dej tomu 3 měsíce bouřlivého vývoje bez jakýhkoliv hranic a poté se zkušenostmi to vem na zelené louce a pořádně. Zároveň už budeš vědět, jestli to obchodně dává smysl. Vývojáři k tomu ještě budou nadšení, že si mohou vyzkoušet nové technologie.
-
presne tak. nejhorsi je zacit "aby to bylo technologicky cisty". technologie je naprosto nepodstatna. udelej to v cemkoliv na co vubec budes schopen sehnat lidi. za pul roku uvidis jestli mas vubec potencial na nejaky trh a co a jak.
-
Isomorfní aplikace, Scala na backendu i frontendu - https://www.scala-js.org ;)
-
Sáhni po největším mainstreamu. Dneska Node/PHP/ROR/Java, jQuery/React, ES6. Když dáš na lidi, co ti radí kdejaký obskurní jazyk, tak možná ušetříš pár řádků kódu, ale připravíš si peklo. Nenajdeš na to pořádně dokumentaci, lidi, knihovny, nástroje, atd.
Pro rady ohledně použití různých transpilerů platí úplně to samé. Po pár letech, kdy měly všechny tyhle "alternativy" boom a vzniklo jich milión, už jsou tím lidi neskonale otrávení. Dokola se učit livescript, deadscript, prenatalscript, mňaumňauskript a hovnoskript(které používá dohromady pět lidí, ti další tři zase používají zmrdskript), abys za týden zjistil, že vývoj "toho jazyka, co nahradí JavaScript" skončil, to už fakt nikoho nebaví.
Ber vždycky pokud možno ty nejzavedenější technologie a chybu neuděláš.
-
presne tak. nejhorsi je zacit "aby to bylo technologicky cisty". technologie je naprosto nepodstatna. udelej to v cemkoliv na co vubec budes schopen sehnat lidi. za pul roku uvidis jestli mas vubec potencial na nejaky trh a co a jak.
Bohužel u mých "free" projektů je výsledkem to, že mi pak mnoho let běží ten projekt na technologii, která mě moc netěší (ten python+angular+coffeescript) a motivace to přepsat moc není (protože to funguje). Bohužel si nemůžu moc stěžovat, protože v době, kdy jsem to psal, prostě ty lepší technologie nebyly nebo byly doslova v plenkách...
Jinak z hlediska maintenance osobně preferuju na backendu haskell (mimochodem, PostgREST je v něm napsaný), ale bohužel naučit se to je úplně jiný level, než nějaký framework... Příští projekt budu zkoušet Haskell na backendu a Purescript (asi zkusím s "pux" (i.e. React)) na frontendu. A za pár let zjistím, jestli to byl dobrý krok či nikoliv...
Jinak nerozumím tomu nadšení pro non-SQL databáze. SQL je super. Pokud není nějaký markantní důvod SQL nepoužít, tak prostě použít. Bohužel ORMka jsou tragická asi tak všechna ve všech jazycích. Ale to platí pro noSQL taky.
Jinak TypeScript je pokud vím normální Javascript s typovou kontrolou. Zkušenost s tím nemám, ale obecně typová kontrole je důležitá. Hodně. Speciálně kvůli tomu, až do toho budeš chtít za pár let šáhnout a budeš chtít mít nějakou jistotu, že to nerozbiješ.
-
Jinak nerozumím tomu nadšení pro non-SQL databáze. SQL je super. Pokud není nějaký markantní důvod SQL nepoužít, tak prostě použít. Bohužel ORMka jsou tragická asi tak všechna ve všech jazycích. Ale to platí pro noSQL taky.
Jak by mělo vypadat netragické ORM?
-
Jinak TypeScript je pokud vím normální Javascript s typovou kontrolou. Zkušenost s tím nemám, ale obecně typová kontrole je důležitá. Hodně. Speciálně kvůli tomu, až do toho budeš chtít za pár let šáhnout a budeš chtít mít nějakou jistotu, že to nerozbiješ.
Dělej, jak uznáš za vhodné, jenom jsem ti nabídl svůj pohled na věc po zhruba deseti letech v oboru. Do apllikace postavené na haskell/typescript bych osobně nešel. V JS se dají dělat i velké projekty, je to jenom o zkušenostech. TypeScript se samozřejmě překládá do JavaScriptu. Problém je trochu jinde, třeba na takovém TIOBE není ani v první stovce jazyků. To je tak trochu sebevražda z mojeho pohledu. Až do toho budeš chtít za pár let šáhnout, tak TypeScript možná už ani nebude existovat. Kdyby ho brutálně netlačil MS, tak není už teď. Ale jestli to má být jenom jednoduchá nástěnka typu trello, tak je to vlastně víceméně jedno.
-
a motivace to přepsat moc není (protože to funguje).
no tak kde je problem?
preferuju na backendu haskell
pro samo-domo(nauc se sam) nebo naopak mega projekty(nemusis moc resit prachy) dobry, ale jinak si shanej vyvojare...
-
Příští projekt budu zkoušet Haskell na backendu a Purescript (asi zkusím s "pux" (i.e. React)) na frontendu. A za pár let zjistím, jestli to byl dobrý krok či nikoliv...
Skvělá odvaha a vývěr technologií, to mi imponuje ;)
Zvažoval jsi Elm? Vyřadil jsi ho na základě něčeho konkrétního? (pokud už jsem se tě na to ptal, tak sorry, jsem hlava děravá :) )
-
Obecně se mi už teď líbí serverside javascript, tak abych nekombinoval jazyky a aby se v případě nutnosti mohli částečně zastoupit client a server side developeři.
Četl jsem o praktickém provozu Node.js dost škaredé věci... A představa, že bych adminoval JS na backendu je moje nejhorší noční můra. No... možná až po adminování web serveru na Windows ;)
Se stackem radit nebudu, na to situaci málo sleduju, jenom moje 2 halíře: možná by mohlo pro inspiraci pomoct kouknout na https://stackshare.io/stacks (nebrat smrtelně vážně, jenom tak kouknout, co se v praxi vyskytuje ve světě...)
...
+100!
Jestli je něco určitě potřeba o webařině vědět, tak to, že "nejnovější trendy" budou zaručeně za dva roky úplně jiné, takže je úplně jedno, jaká technologie se dneska vybere. Za dva roky bude beztak out jak slipy do zvonů ;)
-
Obecně se mi už teď líbí serverside javascript, tak abych nekombinoval jazyky a aby se v případě nutnosti mohli částečně zastoupit client a server side developeři.
Četl jsem o praktickém provozu Node.js dost škaredé věci... A představa, že bych adminoval JS na backendu je moje nejhorší noční můra. No... možná až po adminování web serveru na Windows ;)
Se stackem radit nebudu, na to situaci málo sleduju, jenom moje 2 halíře: možná by mohlo pro inspiraci pomoct kouknout na https://stackshare.io/stacks (nebrat smrtelně vážně, jenom tak kouknout, co se v praxi vyskytuje ve světě...)
Snadná administrace je naopak jednou z výhod node.js. Je to jen jeden proces. Když chcete, aby se po pádu restartoval, spustíte ho pomocí forever. To je vše.
-
Podivej se na velke projekty, co pouzivaji za technologie. Nema cenu nasazovat neco exotickeho kdyz jsou tu osvedcene veci, ktere zvladnou bez problemu i velky traffic. Takze na backend Ruby on Rails, Django, pripadne neco ze sveta PHP nebo Javy a na front end (pokud potrebujes neco jako SPA, coz je dnes moda ale podle me se bez toho da bez problemu obejit) Angular nebo React. Urcite stoji za to uvazovat i o nejakem CSS frameworku, nejznamejsi je asi Bootstrap.
-
Snadná administrace je naopak jednou z výhod node.js. Je to jen jeden proces. Když chcete, aby se po pádu restartoval, spustíte ho pomocí forever. To je vše.
No já jsem spíš myslel takové věci jako ladění výkonu, nasazení v clusteru, debug apod. Tím, že něco nastavím a spustím celá ta legrace teprve začíná ;)
-
Jak by mělo vypadat netragické ORM?
Nevím. V Haskellu existují bindingy na SQL, které se docela přibližují tomu, co by se mi líbilo, ale stejně to pořád není úplně ono (buď to nemá dost funkcionality, nebo je kolem to ho strašného boilerplate, a navíc to není úplně intuitivní).
a motivace to přepsat moc není (protože to funguje).
no tak kde je problem?
Když chci přidat další funkcionalitu, tak se bojím a nechce se mi :( Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.
Zvažoval jsi Elm? Vyřadil jsi ho na základě něčeho konkrétního? (pokud už jsem se tě na to ptal, tak sorry, jsem hlava děravá :) )
Pux by měl být elm-like binding na react. Elm konkrétně jsem nezkoušel, ale co jsem četl, tak je to dobré intro do FP...a tím to tak končí. Nemá to TypeClassy, což mi osobně připadá jako docela problém.
Četl jsem o praktickém provozu Node.js dost škaredé věci...
Bylo by něco konkrétního? Kolega na to chce právě přepisovat něco rozsáhlejšího, tak by mě to zajímalo...
Podivej se na velke projekty, co pouzivaji za technologie.
Jenže velké projekty mají typicky slušné financování, takže to ti lidé pak napíšou třeba v té Javě se spoustou mezivrstev, kvantem modelů apod. To IMO není zrovna cesta pro malé projekty... PHP, Django, Ruby mě osobně připadají strašně nepohodlné...
SPA a REST připadají jako hodně velký krok vpřed a mám pocit, že se konečně ty webové aplikace dají nějak rozumně uchopit...
-
Pux by měl být elm-like binding na react.
Pokud to správně chápu na první pohled, tak se tím myslí asi spíš Elm 0.16. To bylo fakt FRP, hodně jako React. Od 0.17 Elm prošel dost zásadní změnou, která není úplně jasná, když v tom neděláš (úplně bez urážky, to určitě chápeš), ale v 17ce se fakt píše líp. Viz http://elm-lang.org/blog/farewell-to-frp Přijde mi, jakoby Elm pokukoval po užší spolupráci s Elixirem/Phoenixem, což by bylo megacool ;)
Elm konkrétně jsem nezkoušel, ale co jsem četl, tak je to dobré intro do FP...a tím to tak končí. Nemá to TypeClassy, což mi osobně připadá jako docela problém.
Jako haskellistu by tě to mohlo štvát, to určitě. Ale je to myslím vědomej krok - nejspíš proto, aby se jazyk nekomplikoval, a mně osobně to zas tak moc neva - v té konkrétní doméně webovýho programování se bez nich dá obejít a tam, kde to fakt nejde (např. obecná fce toString) má runtime "výjimky" - on může dělat a dělá věci, který bys v jazyce neudělal ;)
Kdyby typeclassy měl, mohl bys dělat větší abstrakce a měl bys míň boilerplate, ale otázka je, jestli to stojí za to ;) Neumím to vysvětlit, musel bys to vyzkoušet sám (docela doporučuju). Pro haskellistu to asi bude trochu opruz z těch omezení, ale na druhou stranu, podle mě má Elm větší šanci získat větší publikum, právě proto, jak moc se Evan soustředí na jednoduchost, přístupnost a user friendliness.
Četl jsem o praktickém provozu Node.js dost škaredé věci...
Bylo by něco konkrétního? Kolega na to chce právě přepisovat něco rozsáhlejšího, tak by mě to zajímalo...
Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval :)
Nechci o Node nic tvrdit, zkušenosti nemám, ale k čemukoli z JS světa bych byl extra podezřívavej a před nasazením si to teda pořádně proklepl... Jako Python a Ruby jsou sice taky nic moc světy, ale aspoň mají nějakou historii a spousty instalací, že jo, tak se člověk asi tak nespálí...
-
Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval :)
Jo, tak jsem to kupodivu našel (level: Google master! ;) ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
-
Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval :)
Jo, tak jsem to kupodivu našel (level: Google master! ;) ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
Node.js je sračka, ale ta základní myšlenka je dobrá - NIO a jedno vlákno, co víc si přát. Akorát teda mnohem lepší je analogická implementace v C (libevent), C++ (má lambdy), případně s využitím GCD (má lambdy jen při překladu clangem a bez kqueue je pomalé, ale jinak nejlepší) nebo rovnou v Go, které je v tomto ohledu asi nejlepší.
BTW jak se řeší NIO v FP?
-
Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval :)
Jo, tak jsem to kupodivu našel (level: Google master! ;) ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
Tomu člověku vadí, že existuje mnoho knihoven a frameworků, které ho nikdo nenutí používat. To je daň za popularitu. Porovnává node.js s blokujícími framweorky jako Flask a Django. Problémy s callbacky a asynchronním handlováním chyb, na které si stěžuje, v těchto frameworcích logicky neexistují. V neblokujícím IO je na tom python hůř. V pythonu existuje několik navzájem nekompatibilních event loopů. S každým z nich musíte používat jen s ním kompatibilní knihovny. V node.js je neblokující vše.
-
Node.js je sračka
Všude píší, že je to sračka, a lidi to přesto používají. Takový SW nemůže být špatný.
-
BTW jak se řeší NIO v FP?
Runtime GHC (Haskell) má green thready, takže to typicky spustíš s N OS threadama, kde N~počet corů a mezi tím ti tak nějak migrují green thready, takže sice píšeš "blocking", ale ve skutečnosti to je všechno non-blocking. Kupodivu v FFI je možnost volat i long-blocking operace, má to trochu vyšší režii, ale funguje to docela v pohodě.
Purescript pro změnu má Aff monad, který elegantně abstrahuje javascript-callback-hell, takže se píše normálně sekvenčně. Něco ve stylu teď nových asynchronních funkcí (?), ale řekl bych, že lepší...
Kdyby typeclassy měl, mohl bys dělat větší abstrakce a měl bys míň boilerplate, ale otázka je, jestli to stojí za to ;) Neumím to vysvětlit, musel bys to vyzkoušet sám (docela doporučuju). Pro haskellistu to asi bude trochu opruz z těch omezení
Já si to bez typeclass nějak fakt neumim představit...v haskellu to používám docela hodně. Jako on purescript taky neni nějaká extra výhra, chvíli jsem se v tom snažil a moc mě to nepřesvědčilo (Generika na houby, ani tím pořádně nejde napsat JSON serializaci, ten Record system v konečném důsledku moc nepřináší (v novém purescriptu je to prý přes nějaký generický newtype lepší) a extensible effects jsou sice hezké, ale nevím pořádně na co...
podle mě má Elm větší šanci získat větší publikum, právě proto, jak moc se Evan soustředí na jednoduchost, přístupnost a user friendliness.
To bez pochyby ano, a je to jen dobře, ale asi to publikum nebude úplně od haskellistů :)
-
node a sračka ? :D a kde ste na to přišli ?
Rychlí jako ďábel (proti PHP, ruby a pythonu), asynchronní ...
Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení, v clusteru to je pak ještě jiná.
Ruby a podobný joky ... to radí jen šílenec, ruby už skončilo.
Teď je doba JS a Javy.
A Haskell ? Jednu dobu sem byl velkej fanda FP ... ale bohužel, v praxi je dost nahovno, kdo nevyzkoušel na něčem trošku složitějším než school level srandě, nepochopí ...
Nebylo by to tak strašný kdyby existoval pořádný systém na handling side efektů a ne ty komedie co sou dneska... žejo io monado, zdravim tebe.
-
A Haskell ? Jednu dobu sem byl velkej fanda FP ... ale bohužel, v praxi je dost nahovno, kdo nevyzkoušel na něčem trošku složitějším než school level srandě, nepochopí ...
Nebylo by to tak strašný kdyby existoval pořádný systém na handling side efektů a ne ty komedie co sou dneska... žejo io monado, zdravim tebe.
Hele já chápu, že tam jsou omezení - když má člověk blbý use case s GC, tak prostě fakt někdy řešení neexistuje, stejně tak, pokud by člověk šel na krev s výkonností - ale mám v tom napsaný jeden projektík, který vůbec není school-level a psát to v čemkoliv jiném, tak to potřebuje asi výrazně víc lidí a času. Co máš konkrétně na mysli?
Jinak komedie side-efektů ve srovnání s Java/JS má znamenat co? Purescript tohle umí a přišlo mi, že to, co to přinese, za přidanou komplexitu nějak moc nestojí...
-
BTW jak se řeší NIO v FP?
Runtime GHC (Haskell) má green thready, takže to typicky spustíš s N OS threadama, kde N~počet corů a mezi tím ti tak nějak migrují green thready, takže sice píšeš "blocking", ale ve skutečnosti to je všechno non-blocking.
Erlang to má stejně.
Já si to bez typeclass nějak fakt neumim představit...v haskellu to používám docela hodně.
Hele, já to neumím přesně vyargumentovat, nejsem haskellista, takže do té praxe dost nevidím. Ale tak laicky bych řekl, že tam hrají roli dvě věci:
1. problémová doména - co si budeme povídat, weby nejsou žádná raketová věda, máš nějaké datové struktury a chceš je nějak zobrazit, máš nějaké události a chceš je poslat na backend a zpátky. To je celý. 3D raytracing tam psát nebudeš. Pokud nemáš možnost dělat nějaké wifikundační abstrakce, tak je prostě dělat nebudeš a nezblázníš se z toho. Sem tam to znamená, že musíš nějaký kód vzít a zkopírovat jinam a při refaktoringu máš víc práce než kdybys měl k dispozici lepší abstrakci. Ale tak co no, i tak je to lepší než se střelit do nohy nebo programovat v JS ;)
2. Nevím, jestli Haskell má něco podobného, ale v Elmu sem tam nějakou abstrakci zastanou "neúplné recordy" (teď nevím, jak se to oficiálně jmenuje) - prostě řekneš, že typ je {a|s : String, t: Int} - tj. record, který má položky s a t plus možná něco navíc, co tě v té fci nezajímá (to je to "a").
Taky mám pocit, že ten typový systém je i v nějakých detailech trochu volnější než u Haskellu, ale konkrétní příklad teď fakt nedám. Myslím, že jde třeba udělat fce typu "a -> b" (a ani b nijak nespecifikuju) a překladač se s tím nějak popere. To myslím v Haskellu nejde, ne? Teď si fakt nejsem jistej a nechce se mi to už takhle v noci zkoušet a zkoumat. Spíš si to fakt zkus, ty to posoudíš líp než já, já to beru jenom fakt pragmaticky jako menší zlo než JS a nijak moc se nad tím nezamýšlím, dokud to dělá to, co od toho potřebuju :)
ani tím pořádně nejde napsat JSON serializaci
Elm má (de)serializaci JSONu moc pěknou: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode a http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Encode
-
Když chci přidat další funkcionalitu, tak se bojím a nechce se mi :( Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.
ses si jisty, ze problem je v pouzite technologii? Neni to spis tvuj vlastni mrdník a absence kvalitnich testu od jednotkovych po integracni?
-
Když chci přidat další funkcionalitu, tak se bojím a nechce se mi :( Přesunulo se to trošku do kategorie "zombie", ač to lidi používaj a rozvoj by nebyl špatný.
ses si jisty, ze problem je v pouzite technologii? Neni to spis tvuj vlastni mrdník a absence kvalitnich testu od jednotkovych po integracni?
Testů tam moc nemám, ale obávám se, že bych se bál úplně stejně, i kdyby tam ty testy byly (a nemám tým lidí, aby mi je udržoval). Popravdě testovat mi připadá rozumné algoritmy/parsing, ale věci typu "vezmi data, pošli je někam", tam toho moc na testování není. Shodou okolností v tom projektíku je napsaný parsing nějakého "kalendáře", kolem kterého je tuna testů (protože bez toho by to vůbec napsat nešlo) a do toho se mi šahat nechce už vůbec.... (lex/bison parsing je fakt lahůdka obzvláště na jazyk, který nebyl designován s tím, aby byl takhle parsovatelný...resp. u kterého se o designu nedá moc mluvit)
Spousta věcí, která se běžně řeší testama, je v těchhle jazycích tak nějak zadarmo.... takže když provedeš refaktoring, tak nemusíš přepisovat tunu testů. Z druhé strany, ty angular aplikace mají tendenci tak nějak špagetovatět. Kdybych tam měl různou spoustu testů, tak si sice můžu být rozumně jistý, že nic nerozbiju, ale něco tam změnit pořád není zrovna jednoduché; btw, tohle evidentně není jen moje zkušenost, když Angular2 je zpětně nekompatibilní změna jedničky.
-
Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.
Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.
-
Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.
Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.
Primární problém je v použité technologii. Když jedna technologie vyžaduje 4x víc práce na to, aby to bylo nějak udržovatelné než druhá, tak je problém v té první technologii. A vybírat si jazyk/framework na základě rychlosti vývoje, udržovatelnosti apod. není politika.
-
Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.
Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.
Pokud máš něco napsané v něčem, do čeho se ti nechce sahat, tak to nemusí být v technologii, ale určitě je to ve vztahu tebe a té technologie ;)
Opačný extrém toho, co píšeš, je, že můžeš skončit s programem napsaným v Cobolu pro S/360 :)
-
Všude píší, že je to sračka, a lidi to přesto používají.
Teorie vs praxe. Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.
-
Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.
Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.
Primární problém je v použité technologii. Když jedna technologie vyžaduje 4x víc práce na to, aby to bylo nějak udržovatelné než druhá, tak je problém v té první technologii. A vybírat si jazyk/framework na základě rychlosti vývoje, udržovatelnosti apod. není politika.
+1
Radši přeučím PHP člověka na něco pořádného, pokud on za to stojí.
-
Testů tam moc nemám, ale obávám se, že bych se bál úplně stejně, i kdyby tam ty testy byly (a nemám tým lidí, aby mi je udržoval). Popravdě testovat mi připadá rozumné algoritmy/parsing, ale věci typu "vezmi data, pošli je někam", tam toho moc na testování není.
Právě že ano. Zrovna u podobných aplikací je třeba mít na všechno replikovatelné testy na testovacích datech.
-
A Haskell ? Jednu dobu sem byl velkej fanda FP ... ale bohužel, v praxi je dost nahovno, kdo nevyzkoušel na něčem trošku složitějším než school level srandě, nepochopí ...
Nebylo by to tak strašný kdyby existoval pořádný systém na handling side efektů a ne ty komedie co sou dneska... žejo io monado, zdravim tebe.
Hele já chápu, že tam jsou omezení - když má člověk blbý use case s GC, tak prostě fakt někdy řešení neexistuje, stejně tak, pokud by člověk šel na krev s výkonností - ale mám v tom napsaný jeden projektík, který vůbec není school-level a psát to v čemkoliv jiném, tak to potřebuje asi výrazně víc lidí a času. Co máš konkrétně na mysli?
Jinak komedie side-efektů ve srovnání s Java/JS má znamenat co? Purescript tohle umí a přišlo mi, že to, co to přinese, za přidanou komplexitu nějak moc nestojí...
Komedii side efektu myslim komedii se side efektama v dnešních "pure" fp nádherách. O js sem nemluvil, to je oop ...
Nejlíp je na tom elm, ale to je zas dost dosranej jazyk když ho porovnám s haskellem. Možná už je na tom líp, nevím a ani mne to moc netankuje.
Svět bude na fp připraven ve chvíli kdy se stroje nebudou programovat ale učit ... Asi takhle to řeknu. Takže, pozdě.
-
Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.
Jistě.
Doporučuju Go, je nádherné blbuvzdorné, takže i méně kvalitní tým může vyprodukovat něco funkčního.
Se stackem radit nebudu, na to situaci málo sleduju
-
Nerikam, ze Angular je nejaka hitparada. Jen tvrdim, ze primarni problem neni v pouzite technologii/jazyce/frameworku.
Pokud budu mit tym Angular veteranu tak asi nejspis nebudu novy projekt politicky tlacit na React/Ember/Elm/whatever jen protoze "to je lepsi". Stejne tak kdyz budu mit tym zkusenych PHPkaru na frameworku XY tak nebudu z politickeho duvodu tlacit Haskell jen protoze je podle nekoho sexy a in.
Primární problém je v použité technologii. Když jedna technologie vyžaduje 4x víc práce na to, aby to bylo nějak udržovatelné než druhá, tak je problém v té první technologii. A vybírat si jazyk/framework na základě rychlosti vývoje, udržovatelnosti apod. není politika.
takže co byste doporučil pro aplikaci v haskellu, která potřebuje rozumné webové rozhraní a ústředním prvkem jejího rozhraní je treeview s lazy-loaded větvema (nyní fancytree)?
-
Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.
Jistě.
Doporučuju Go, je nádherné blbuvzdorné, takže i méně kvalitní tým může vyprodukovat něco funkčního.
Se stackem radit nebudu, na to situaci málo sleduju
Argument s méně kvalitním týmem zrovna od člověka jako zboj nezní moc přesvědčivě. Podle jeho předchozích příspěvků hádám, že spolupracuje s nadprůměrně vzdělanými a schopnými lidmi.
Go protlačuje Google. Node.js se rozšířilo i navzdory špatnému PR. Já to beru jako důkaz kvality i když na aplikaci, kterou chce tazatel dělat, bych použil něco jiného.
-
Testů tam moc nemám, ale obávám se, že bych se bál úplně stejně, i kdyby tam ty testy byly (a nemám tým lidí, aby mi je udržoval). Popravdě testovat mi připadá rozumné algoritmy/parsing, ale věci typu "vezmi data, pošli je někam", tam toho moc na testování není.
Právě že ano. Zrovna u podobných aplikací je třeba mít na všechno replikovatelné testy na testovacích datech.
Jasně, všichni máme neomezený čas a rozpočet, obzvlášť, když děláš projektík zadarmo pro nějakou komunitu. Testovat věci ve stylu "funkce vrátí obsah tabulky" je fakt na pytel - ale samozřejmě v node nebo pythonu to má smysl, protože se ti snadno může stát, že třeba nějaký atribut zapomeneš vrátit. Když máš v těch typovaných jazycích typ endpointu "Action", tak prostě tohle testovat víceméně nemá smysl, protože to prostě vždycky vrátí celou Action se všemi atributy. Ne, že by se někdy nějaký kix v tomhle stát nemohl, ale ta cost-benefit analýza pak najednou vychází jinak. Navíc když to chvíli nebude fungovat, tak se svět nezboří (byť to používá tak různě docela dost lidí...)... a ty testy fakt udržovatelnosti toho kódu moc nepomůžou - kdysi jsem si dal práci a napsal testy k jednomu pythoním projektu (ne-webovému) - vzhledem k omezenému přístupu na cílovou platformu to pomohlo odchytat při vývoji spoustu chyb. Ale pro další údržbu už jsem ty testy ignoroval, protože to prostě nemělo smysl....
Komedii side efektu myslim komedii se side efektama v dnešních "pure" fp nádherách. O js sem nemluvil, to je oop
Mně to připadá, jak kdybys kritizoval FP nádhery, že ty použitelné nemaj dependent-types. No nemají. Java/JS taky ne. A co? Řízení side-efektů funguje na IO/pure granularitě, a nebo si pak můžeš zvolit nějaký přístup, který tu granularitu zlepšuje; záleží na tom, co od toho chceš. Některé věci se dají řešit celkem v pohodě, jiné moc ne. Pořád nechápu praktický dopad na psaní webového backendu pro aplikaci velikosti trello v kontextu alternativy typu node.
takže co byste doporučil pro aplikaci v haskellu, která potřebuje rozumné webové rozhraní a ústředním prvkem jejího rozhraní je treeview s lazy-loaded větvema (nyní fancytree)?
Asi nerozumím otázce... jako že máte aplikaci v haskellu a teď k ní budete dělat rozhraní?
-
takže co byste doporučil pro aplikaci v haskellu, která potřebuje rozumné webové rozhraní a ústředním prvkem jejího rozhraní je treeview s lazy-loaded větvema (nyní fancytree)?
Asi nerozumím otázce... jako že máte aplikaci v haskellu a teď k ní budete dělat rozhraní?
spíš předělávat, nějaké rozhraní mám, ale ubohé, udělat to znovu a "správně" by bylo velmi feasible
-
Testů tam moc nemám, ale obávám se, že bych se bál úplně stejně, i kdyby tam ty testy byly (a nemám tým lidí, aby mi je udržoval). Popravdě testovat mi připadá rozumné algoritmy/parsing, ale věci typu "vezmi data, pošli je někam", tam toho moc na testování není.
Právě že ano. Zrovna u podobných aplikací je třeba mít na všechno replikovatelné testy na testovacích datech.
Jasně, všichni máme neomezený čas a rozpočet, obzvlášť, když děláš projektík zadarmo pro nějakou komunitu. Testovat věci ve stylu "funkce vrátí obsah tabulky" je fakt na pytel - ale samozřejmě v node nebo pythonu to má smysl, protože se ti snadno může stát, že třeba nějaký atribut zapomeneš vrátit. Když máš v těch typovaných jazycích typ endpointu "Action", tak prostě tohle testovat víceméně nemá smysl, protože to prostě vždycky vrátí celou Action se všemi atributy. Ne, že by se někdy nějaký kix v tomhle stát nemohl, ale ta cost-benefit analýza pak najednou vychází jinak. Navíc když to chvíli nebude fungovat, tak se svět nezboří (byť to používá tak různě docela dost lidí...)... a ty testy fakt udržovatelnosti toho kódu moc nepomůžou - kdysi jsem si dal práci a napsal testy k jednomu pythoním projektu (ne-webovému) - vzhledem k omezenému přístupu na cílovou platformu to pomohlo odchytat při vývoji spoustu chyb. Ale pro další údržbu už jsem ty testy ignoroval, protože to prostě nemělo smysl....
ORM objekty jsou typované. Špatná data do nich nacpete jen dost těžko. Zrovna u DB aplikací dokáží testy podstatně urychlit vývoj. S databází, která se vám mění pod rukama se vyvíjí špatně. Je třeba, aby testy byly replikovatelné. Kontrolovat správnost výsledků po každém spuštění jen očima také moc dobře nejde. Určetě to chce praxi. Naučit se efektivní TDD chvíli trvá. IMHO naučit se dělat weby v haskellu trvá déle.
-
Řízení side-efektů funguje na IO/pure granularitě, a nebo si pak můžeš zvolit nějaký přístup, který tu granularitu zlepšuje
já bych teda Free monádu a "interpretter pattern" zmínil explicitně, a samozřejmě http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf
-
Svět bude na fp připraven ve chvíli kdy se stroje nebudou programovat ale učit ... Asi takhle to řeknu. Takže, pozdě.
Bravo. To je ono. Pak budou vznikat turingovsky neúplné jazyky, jako výsledek procesu učení. Prostor možných jazykových konstrukcí takto vzniklého jazyka bude řídký, snadněji uchopitelný pro evoluční algoritmy.
-
Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení
To umí cokoliv, co používá kqueue nebo epoll.
-
Všude píší, že je to sračka, a lidi to přesto používají.
Teorie vs praxe. Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.
Neco něco kvalitního, co se používá.
-
Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení
To umí cokoliv, co používá kqueue nebo epoll.
To ano, ale jen v Javascriptu je tento model defaultní a používají ho všechny knihovny.
-
Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení
To umí cokoliv, co používá kqueue nebo epoll.
To ano, ale jen v Javascriptu je tento model defaultní a používají ho všechny knihovny.
co ghc?
-
ORM objekty jsou typované. Špatná data do nich nacpete jen dost těžko. Zrovna u DB aplikací dokáží testy podstatně urychlit vývoj. S databází, která se vám mění pod rukama se vyvíjí špatně. Je třeba, aby testy byly replikovatelné. Kontrolovat správnost výsledků po každém spuštění jen očima také moc dobře nejde. Určetě to chce praxi. Naučit se efektivní TDD chvíli trvá. IMHO naučit se dělat weby v haskellu trvá déle.
Tak konkrétní příklad - mám tu (v pythonu) třídu - nějaký "objekt" (obsahuje nějaké časovéinfo, jméno, nějaký geopolygon). Jaké má vlastně atributy? No...abych prošel __init__ metodu a hledal. Co se stane, když ten atribut bude chybět? Bůhví. Jaké jsou možné typy těch atributů? Tohle jsou všechno věci, které bych vlastně měl testovat.
A teď nějaký typovaný jazyk (jakýkoliv, to vůbec nemusí být haskell) - podívám se na deklaraci a vidím. Je jasné, co to má za atributy, jaký mají typ. Když něco smažu a rekompiluju to, tak mi překladač poslušně nahlásí, kde to všude používám. Když něco neinicializuju, tak mě překladač varuje. Takže testovat, jestli má objekt určité atributy je sice hezké, ale pravděpodobnost, že v tomhle dojde k nějaké chybě se blíží nule, takže to vlastně testovat smysl nemá.
TDD používám - třeba u parsingu. Nebo třeba u serializací (QuickCheck je na tohle docela geniální věc). Ale u těch DB přístupů, které v drtivé většině jsou typu "zapiš něco do databáze", resp. "přečti něco z databáze" mi to připadá dost zbytečné.
Ono naučit se Haskell není zrovna lehké... ale TDD v node.js apod. je řešení problému hrubou silou. Naštěstí se třeba Java, ale myslím i C++ hodně FP inspiruje, takže spousta důležitých věcí už to umí...
co ghc?
http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf (http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf)
-
ORM objekty jsou typované. Špatná data do nich nacpete jen dost těžko. Zrovna u DB aplikací dokáží testy podstatně urychlit vývoj. S databází, která se vám mění pod rukama se vyvíjí špatně. Je třeba, aby testy byly replikovatelné. Kontrolovat správnost výsledků po každém spuštění jen očima také moc dobře nejde. Určetě to chce praxi. Naučit se efektivní TDD chvíli trvá. IMHO naučit se dělat weby v haskellu trvá déle.
Tak konkrétní příklad - mám tu (v pythonu) třídu - nějaký "objekt" (obsahuje nějaké časovéinfo, jméno, nějaký geopolygon). Jaké má vlastně atributy? No...abych prošel __init__ metodu a hledal. Co se stane, když ten atribut bude chybět? Bůhví. Jaké jsou možné typy těch atributů? Tohle jsou všechno věci, které bych vlastně měl testovat.
Invarianty objektů můžete kontrolovat v __setattr__. Atributy ORM modelů se nespecifikují v __init__. Používal jste SqlAlchemy nebo Django? Můžete provádět mnohem složitější validace než by vám umožnil typový systém.
-
A teď nějaký typovaný jazyk (jakýkoliv, to vůbec nemusí být haskell) - podívám se na deklaraci a vidím. Je jasné, co to má za atributy, jaký mají typ. Když něco smažu a rekompiluju to, tak mi překladač poslušně nahlásí, kde to všude používám. Když něco neinicializuju, tak mě překladač varuje. Takže testovat, jestli má objekt určité atributy je sice hezké, ale pravděpodobnost, že v tomhle dojde k nějaké chybě se blíží nule, takže to vlastně testovat smysl nemá.
Dokážete pomocí typové kontroly validovat nějaký dlouhý formulář, kde jsou validace jednotlivých položek na sebe navázány? Jak překladač kontroluje, že jste při ukládání do databáze nepřehodil názvy položek? Jak překladač zjistí, že jste neudělal chybu v regulárním výrazu?
-
Invarianty objektů můžete kontrolovat v __setattr__. Atributy ORM modelů se nespecifikují v __init__. Používal jste SqlAlchemy nebo Django? Můžete provádět mnohem složitější validace než by vám umožnil typový systém.
Jenže mě ani nešlo o nic složitého (navíc to nebyl ORM objekt). Jde o to, že se podívám na definici třídy a nevím vůbec nic. Init metoda je na stránku, a teď abych hledal přiřazení do "self", jaké to má vlastně atributy a pak ještě vymýšlel, jaký asi mají typ (nedejbože, že bych použil atribut různých typů....), případně ještě prolézal funkce, které ten __init__ volá, jestli se náhodou někde něco nepřiřazuje.
Konkrétně teda v Haskellu je ten objekt imutable, a pokud chci, aby byly dodrženy invarianty, tak nevyexportuju konstruktor, ale vyexportuju "inteligentní konstruktor", který je vynutí. V Javě se to řeší private atributama a konstruktorem, který to vynutí (a kvantem getterů/setterů...) v C++ také...
Dokážete pomocí typové kontroly validovat nějaký dlouhý formulář, kde jsou validace jednotlivých položek na sebe navázány?
No asi použiju ten inteligentní konstruktor viz výše...
Jak překladač kontroluje, že jste při ukládání do databáze nepřehodil názvy položek?
Já teda nechtěl, aby tohle dopadlo jako promo haskellu (ani jsem to Jakubovi nedoporučoval)...ale pokud to je přes nějaké ORM, použijí se generické funkce na přístup do databáze resp. konverzi do JSONu. Takže tam zrovna moc nic na spletení není. Ale tohle IMO funguje snad i v Javě, není to nic objevného. A když je to všechno generované automaticky, tak opět není moc důvod tyhle věci testovat....
V Haskellu je trošku anti-pattern mít funkci, která bere více parametrů stejného typu, takže se to pak řeší tím, že má každá položka separátní typ - tzn. např. typ "Jméno", "Příjmení", "Adresa". Takže se pak nestane, že se funkce, která má parametr "Příjmení", zavolá místo toho s "adresou". Takže se opět zmenšuje prostor pro chybu a snižuje "benefit" testování.
Jak překladač zjistí, že jste neudělal chybu v regulárním výrazu?
Pokud jde o regexpy - v haskellu se regexpy prakticky nepoužívají (napsat si parser je výrazně jednodušší a není to write-only jako regexpy... ať žije udržovatelnost kódu...). Nicméně je na to nějaká knihovna (https://hackage.haskell.org/package/rex-0.5.2/docs/Text-Regex-PCRE-Rex.html), která to compile-time zkompiluje (možná i zkontroluje korektní počet group)...
-
Co myslíte, má větší smysl zabejvat se Node.JS nebo ASP.NET Core? Chci svůj další projekt experimentálně postavit na jedný z těchle dvou technologií. Popularita JS ve mě budí pocit, že je to něco úžasnýho a kdo v něm dneska nedělá, neni cool. Chvíli jsem si s nim hrál, ale vůbec mě nezaujal - neustálenej ekosystém, každej fw řeší jen úplnej základ a na zbytek je potřeba hromada knihoven, absence typů - po dlouholetym programování v PHP stíhnu spíš k typovanejm jazykum, leda s využitim TypeScriptu, což je ale zase jen jeden z několika transpilerů. Další věc je asynchronní styl programování, sice mu moc nerozumim, ale neni při rozsáhlejších projektech spíš komplikací? Docela se vidim v tom, ž bych dopadl podobně - https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a#.yhw7n5k4r (https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a#.yhw7n5k4r).
C# se mi jako jazyk líbí, má podporu na Linuxu, vzniká pořádný konkurenční IDE 3. strany - JetBrainsu.. I když zase .NET Core je tu jen chvilku.
Další možností byla Java, ale přijde mi, že se třeba v i takovym Springu dělá všechno zdlouhavě a složitě. Stavět na Javě malou stránku by bylo nejspíš postavený na hlavu.
Python neberu v úvahu, to můžu zustat u PHP.
-
Node.JS (obecně Javascriptové frameworky typu Angular / React) ti umožňují přenést část aplikace do prohlížeče uživatele. To je zásadní výhoda, proto přes všechny JS nectnosti tak frčí. Takže jde v první řadě o to, jaký styl aplikace chceš dělat.
A taky jak velká ta aplikace bude. Dál píšeš "Stavět na Javě malou stránku by bylo nejspíš postavený na hlavu". Pokud opravdu chceš dělat malou stránku, tak na to je fakt to PHPko. .NET není o moc vhodnější na malé stránky než Java.
Když zmiňuješ Spring, tak ten dělá model, controller a třeba servisní vrstvu, na webovou aplikaci potřebuješ v něčem dělat views a to něco může být JSP/JSF/Tiles/...
Dál může být zajímavý Wicket, který k celé věci přistupuje dost jinak než většina ostatních frameworků (v různých jazycích). Webovou aplikaci v něm stavíš z javových komponent/tříd podobně jako kdyby to byla desktopová aplikace. A má dobrou podporu AJAXu.