Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: Steve Jobs 23. 02. 2018, 20:40:39
-
Mám 7 let zkušenost v Javě/Kotlinu, 3 v Ruby a bokem si dělám kraviny v .NET core. To mě začalo dost bavit, tak jsem jsem se přihlásil na senior .NET core vývojáře. .NET core je celkem ještě žhavá novinka, ale na pohovoru jsem dostával otázky typu "vyjmenujte všechny přetížené varianty metody x". Říkám tohle nepotřebuju snad znát. "Vy se hlásíte na seniorní pozici, toto musíte vědět."
No comment. Narazil jsem na autistu.
Další pokus mi týpek po telefonu řekl, že nemám roky v původním .NET, takže by připadala jen pozice juniora. Zas říkám, že kurva mám 7 let v javě a jde jen o syntaxi a knihovny. Programovat umím a přece si nebudu hlavu zasírat věcma, který má umět kompilátor a IDE. Ne smůla.
Asi to nebudu zkoušet potřetí, ale tohle je teda silně teploušský.
-
co te tak nalakalo na .NET, ze chces opustit javu nebo jeste vice, ze chces opustit kotlin???
-
To je jednoduchy. Java je starej nevzhlednej jazyk plnej balastu a hruzy jmenem EJB, kterou stale jeste casto lze potkat.
.NET core si netahne zadny hruzny dedictvi a C# je sexy jazyk. Knihovny jsou proste .NET a nic jinyho. Zadny ze nejakej Java uchyl nataha do projektu mix sracek a pak nad tim musej vsichni trpet.
Kotlin je dobrej, ale skoro nikdo ho nepouziva.
-
Spatne vybiras nebo ti vyhovuje status quo.
btw. kdyz se nazyvas Steve Jobs, tak predpokladam, ze pachnes a jsi arogantni.
Ale to je na tobe, mozna, ze potrebujes znalosti jake po tobe chteli. Mozna pisou zakladni knihovny a potom je dobry znat vsechny pretizene varianty metody x. Holt normici nemaji na vsechno.
Kdyz menis technologie tak se priprav na to, ze zacnes jako junior nez se naucis technologii. (Toto plati v mensi mire pokud chces byt {JS Framework} vyvojar)
-
Spatne vybiras nebo ti vyhovuje status quo.
btw. kdyz se nazyvas Steve Jobs, tak predpokladam, ze pachnes a jsi arogantni.
Ale to je na tobe, mozna, ze potrebujes znalosti jake po tobe chteli. Mozna pisou zakladni knihovny a potom je dobry znat vsechny pretizene varianty metody x. Holt normici nemaji na vsechno.
Kdyz menis technologie tak se priprav na to, ze zacnes jako junior nez se naucis technologii. (Toto plati v mensi mire pokud chces byt {JS Framework} vyvojar)
Ti trochu jebe v hlave ne? Si predstav, ze bys sel na Java pohovor, typek by nahodne vylosoval knihovnu, pak by vylosoval komponentu, pak by vylosoval classu z ni a zeptal se te na parametry konkretni metody. Rozebehni se a poradne hlavou do zdi. Pokud to nepomohlo, tak zopakovat.
-
jako C-ckar chci zase zkusit vice svet Javy, spis teda ten Kotlin.
mi se prave Java a to kolem ni rozmanitejsi a lepsi nez C# .NET, neni to tak?
-
jako C-ckar chci zase zkusit vice svet Javy, spis teda ten Kotlin.
mi se prave Java a to kolem ni rozmanitejsi a lepsi nez C# .NET, neni to tak?
Rozmanitejsi do chvile, nez si tim zacnes skutecne vydelavat. Pak z ty rozmanitosti zacnes chlastat, to ti garantuju. Neni nic lepsiho nez prijit na projekt a zjistit, ze polovina knihoven jsou nejaky sileny sracky a ze Spring, kterej je defacto uz dlouhou dobu standardem, nevedou a maji plesnivy EJBcka nebo shit typu Struts. Java a jeji ekosystem je neco tak neskutecne silenyho... Nikdy neni mozny rict si "umim Javu". To radsi pujdu na .NET a vzdy budu vedet, co cekat, vzdy budu efektivni day 1. Po tech letech mi ver, ze 7 let Javy mi sebralo tak 20 let zivotni energie.
-
Ujistuji te, ze .net projekt je mozne uplne stejne zprasit jako projekt v jave. .net core muze pouzivat knihovny starsiho .netu (nebudeme se poustet do detailu, ze) a pokud vam jde o to vyhnout se mixu sracek jako EJB, tak az potkate prvni napohled navoneny .net core a uvnitr spatrite smradlavou webforms slozenou z custom controls, tak pochopite, ze java si s .net nemaji co vycitat.
To jsem se tuhle zacal vice venovat javascriptu, es8 syntaxi a po nekolika set tisicich radcich muzu rict, ze moderni javascript mam radeji nez c#.
-
to jako jde, udělat webforms aplikace na net.core?
-
To jsem se tuhle zacal vice venovat javascriptu, es8 syntaxi a po nekolika set tisicich radcich muzu rict, ze moderni javascript mam radeji nez c#.
Ja som tiež začal fušovať do JavaScriptu a zarazilo ma, že doteraz nemá poriadne funkcie na formátovanie
textu; niečo, čo Python, C#, Java majú veľmi dávno. JavaScript má len interpoláciu, čo je veľmi málo. Aj to tam používa z nepochopiteľných dôvodov backtick znaky. Ešte donedávna si museli programátori vytvárať svoje vlastné funkcie na formátovanie reťazcov.
https://stackoverflow.com/questions/610406/javascript-equivalent-to-printf-string-format
Keď som si to pozeral, tak ma chytala triaška.
-
to jako jde, udělat webforms aplikace na net.core?
To je na dlouho. Normalne to nejde, ale kdyz se chce...
Ja som tiež začal fušovať do JavaScriptu a zarazilo ma, že doteraz nemá poriadne funkcie na formátovanie
textu;
No ted uz ma ty template literals. Driv se proste scitaly stringy. Pokud ale hledate dotnetovy stringbuilder, tak to tam neni.
-
To jsem se tuhle zacal vice venovat javascriptu, es8 syntaxi a po nekolika set tisicich radcich muzu rict, ze moderni javascript mam radeji nez c#.
Ja som tiež začal fušovať do JavaScriptu a zarazilo ma, že doteraz nemá poriadne funkcie na formátovanie
textu; niečo, čo Python, C#, Java majú veľmi dávno. JavaScript má len interpoláciu, čo je veľmi málo. Aj to tam používa z nepochopiteľných dôvodov backtick znaky. Ešte donedávna si museli programátori vytvárať svoje vlastné funkcie na formátovanie reťazcov.
https://stackoverflow.com/questions/610406/javascript-equivalent-to-printf-string-format
Keď som si to pozeral, tak ma chytala triaška.
Chybí možná jen lepší podpora formátování čísel. Zarovnávání pomocí mezer na webu nedává smysl. Musíte použít styly.
-
včera se tu za mě vydával javaman. Od teď budu diskutovat jen přihlášený.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
-
Javascript ani modernejsi varianty se mi nechce studovat.
Ted se zajimam o go a kotlin.
Java je nafoukla mrtvola, c++ je nafoukly hnus, ktery kolem char* array vytvoril cely samostatny sileny vesmir.mozna ze pro dalsi generace uz bude c++30 neco jako python a haskell, ale ted je to bordel v mezicase.
-
Javascript ani modernejsi varianty se mi nechce studovat.
Ted se zajimam o go a kotlin.
Java je nafoukla mrtvola, c++ je nafoukly hnus, ktery kolem char* array vytvoril cely samostatny sileny vesmir.mozna ze pro dalsi generace uz bude c++30 neco jako python a haskell, ale ted je to bordel v mezicase.
Go je docela sympatické - staticky typované, rychlé, s rozumnou a efektivní správou paměti a bohatou standardní knihovnou. Nejvíc mě na něm ovšem zaujala kroskompilace.
-
Mám 7 let zkušenost v Javě/Kotlinu, 3 v Ruby a bokem si dělám kraviny v .NET core. To mě začalo dost bavit, tak jsem jsem se přihlásil na senior .NET core vývojáře. .NET core je celkem ještě žhavá novinka, ale na pohovoru jsem dostával otázky typu "vyjmenujte všechny přetížené varianty metody x". Říkám tohle nepotřebuju snad znát. "Vy se hlásíte na seniorní pozici, toto musíte vědět."
No comment. Narazil jsem na autistu.
Další pokus mi týpek po telefonu řekl, že nemám roky v původním .NET, takže by připadala jen pozice juniora. Zas říkám, že kurva mám 7 let v javě a jde jen o syntaxi a knihovny. Programovat umím a přece si nebudu hlavu zasírat věcma, který má umět kompilátor a IDE. Ne smůla.
Asi to nebudu zkoušet potřetí, ale tohle je teda silně teploušský.
Hele nenech se odradit.. Spousta lidi ma takove dementni predsudky. Vidim to i u nas v praci, dkyz delame pohovory. Obvykle na ne chodi lide z vice oddeleni a spousta z nich resi presne takove detaily co popisujes.. to mne hlava nebere. Ale vlastne jsem za to rad, protoze jsem k nam kvuli hlouposti ostatnich nabral uz nekolik skvelych lidi, kteri maji akorat zkusenosti o trochu posunute vedle.
-
jako C-ckar chci zase zkusit vice svet Javy, spis teda ten Kotlin.
mi se prave Java a to kolem ni rozmanitejsi a lepsi nez C# .NET, neni to tak?
Jakou dlouholety c++kar jsem v poslednich letech se z velke casti zivil javou. Je na ni poznat koule na noze snad jeste vic, nez v c++. C# je opravdu o generaci novejsi jazyk, je to poznat
-
Mi se v go libi navrat k jednoduchym vecem: for, if.
Ma nejakou vyhodu abstrakce iterator v c++ proti klasicke smycce?
Go umi odvodit typy, to je fajn. Ale ma smysl rikat necemu kontejner kdyz to je stejne strom, nebo list, nebo hash.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
-
Mi se v go libi navrat k jednoduchym vecem: for, if.
Ma nejakou vyhodu abstrakce iterator v c++ proti klasicke smycce?
Go umi odvodit typy, to je fajn. Ale ma smysl rikat necemu kontejner kdyz to je stejne strom, nebo list, nebo hash.
Go má taky něco jako iterátor, ale vestavěný. V C++ se vše řešilo v knihovnách, proto vznikly iterátory jako samostatné třídy (až později se rozšířila syntax o "for" pro kolekce využívající iterátory implicitně). Výhodou Go je, že vzniklo nedávno, takže tvůrci už věděli, co jak implementovat co nejjednodušeji. Java to mimochodem měla stejně, nebo i ObjC, kolekce se procházely přes různé "enumerátory", což byly samostatné třídy s metodami "element" a "next".
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
Nauč se počítat, javamane, aspoň jako amazonští indiáni - 1, 2, mnoho...
-
Po cca 15ti letech v Jave jsem pred nejakou chvili zacal delat iOS a swift.
Uz jsem ji mel taky plny zuby, plny zuby server side molochu,
mody kazdy dva roky "in" jinej framework,
plny zuby webu a html a js ....
V praci mi tu zmenu umoznili.
Jsem celkem spokojen.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
Nauč se počítat, javamane, aspoň jako amazonští indiáni - 1, 2, mnoho...
Nerozumíš tomu a nejsem javaman, paranoiku. V .NETu taky pužiješ WCF, na frontend ASP.NET, k databázi Entity Framework. A javascript v asp.netu je taky v nakémskik frameworku.
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
Nauč se počítat, javamane, aspoň jako amazonští indiáni - 1, 2, mnoho...
Nerozumíš tomu a nejsem javaman, paranoiku.
Přinejmenším píšeš stejně debilní příspěvky ;)
-
Taky jsem chtěl přejít na .NET, ale říkám si, že oproti standardu: Spring Boot + Hibernate/MyBatis + Tomcat + Angular.js + Linux bych si stejně tolik nepolepšíl. .NET Core na Linuxu navíc stejně pořádně nejede, byl tu o tom topic.
Čím víc frameworků, tím víc drsoň :)
nerozumíš tomu.
Jen blb si myslí, že čím víc frameworků, tím lepší kód.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
Nauč se počítat, javamane, aspoň jako amazonští indiáni - 1, 2, mnoho...
Nerozumíš tomu a nejsem javaman, paranoiku.
Přinejmenším píšeš stejně debilní příspěvky ;)
No hlavně že tvoje příspěvky jsou světové, budeš mě tu poučovat, že mnou vypsaný stack obsahuje nějaký nadbytečný framework.
+ Maven + Apache utilitky, na to bych zapomněl 8) a k tomu hezky Idea a JRebel a máš to skoro stejně dobré jako .NET. S Linuxem i lepší. Hlavně nesmí být v týmu senior blbec, co tam bude cpát nesmysly. Je to o lidech.
-
Protože ono ten .NET ti pro webový vývoj v podstatě poskytne jedinou lepší věc než java a to je ASP. Jenže...komponentově orientovaným frontendům podle mě brzo odzvoní a bude se stejně dělat v JS. Angular už je v podstatě standard. Je to taková novodobá náhrada za tenké a tlusté klienty jako se dělaly kdysi ve Swingu, jen je univerzálnější protože je doopravdy multiplatformní. A rozumní javisti, a je jich většina, taky nemají rádi, když se používají nestandardní knihovny. Je třeba si vybrat dobrou firmu a dobrý projekt, je jasné že v žumpě budou junioři bastlit s ledačím.
-
A ideálně jít na švarc, abyses nemusel nikoho doprošovat, jestli ti koupí jrebel.
-
Protože ono ten .NET ti pro webový vývoj v podstatě poskytne jedinou lepší věc než java a to je ASP.
Hmm, tak Java má hneď tri komponentové knižnice, JSF, GWT a Vaadin, pričom Vaadin je geniálny.
Po cca 15ti letech v Jave jsem pred nejakou chvili zacal delat iOS a swift.
Uz jsem ji mel taky plny zuby, plny zuby server side molochu,
mody kazdy dva roky "in" jinej framework,
plny zuby webu a html a js
Takéto pocity majú určite mnohí vývojári webu. Je to však o tom, že vytvárať webové aplikácie je náročný proces. Čo sa týka Javy, tak tam sa to ustálilo, vedie Spring, nasledovaný Java EE, svoju niche majú GWT, Grails, Vaadin, alebo Play.
Momentálne sa blázni na frontende, ale zdá sa, že tam sa etablujú tiež dve, tri projetky (Angular, React, Vue) a bude pokoj.
A jen blb považuje výše vyjmenovaný v podstatě standardní stack za "víc frameworků".
Technicky sa aj Hibernate a Angular nazývajú frameworkmi, ale ako bolo správne poukázané, sú súčaťou jedného stacku.Úplne rovnako to majú ako .NET Core, ROR, Symphony atď. Rozdiel je v tom, že .NET, ROR, Laravel sú tzv. opinionated stacky, teda sú zvolené východzie ORM, template systémy, MVC moduly atď, kým v Jave obvykle frameworky nie sú opinonated, teda užívateľ nemá prednastavené moduly, a zvolí si ich sám.
Ted se zajimam o go a kotlin. Java je nafoukla mrtvola,
Java je jedným z najúspečnejčích projektov v histórii. Je to geniálny programovací jazyk a ekosystém.
V mnohých oblastiach definoval štandardy a postupy.
Všetci do nohy kopírovali Javu, či už .NET alebo PHP. Samozrejme, že aj oni prispeli vylepšeniami.
Porovnávať Javu teraz s modernými jazykmi, je ako porovnávať ženu s troma deckami so štíhlou 25 ročnou
slečnou. Avšak Java má svojho skvelého nástupcu vo forme Kotlinu. Nie je to nový programovací jazyk, je
to skôr evolúcia Javy. Hovoriť o Jave, že je to mŕtvola je úplné ignorovanie reality. Popularita Javy je teraz
na špicy, top platové podmienky, najviac pracovných ponúk (aspoň na Slovensku) neustály vývoj dopredu,
množstvo nových publikovaných kníh, milióny programátorov po svete. Java dominuje na Androide, ktorý
dominuje prenosným zariadeniam a na veľkých projektoch na backende. Neviem ako je to pri malých zariadeniach
a IOT, ale predpokladám, že sa tam tiež dobre drží...
-
Java dominuje na Androide, ktorý
dominuje prenosným zariadeniam a na veľkých projektoch na backende. Neviem ako je to pri malých zariadeniach
a IOT, ale predpokladám, že sa tam tiež dobre drží...
V IoT vůbec.
-
No ted uz ma ty template literals. Driv se proste scitaly stringy. Pokud ale hledate dotnetovy stringbuilder, tak to tam neni.
Mal som na mysli niečo takéto:
Console.WriteLine("{0:D} {1,8:X}", 502, 546);
print('There are {0} oranges and {1} apples in the basket'.format(12, 23))
Je to veľmi pohodlné. Samozrejme, aj StringBuilder by bodol.
Chybí možná jen lepší podpora formátování čísel. Zarovnávání pomocí mezer na webu nedává smysl. Musíte použít styly.
Nuž ale JavaScript sa etabloval aj mimo webu, Node.js, Qt Quick, práca so súbormi, databázy, robia sa v tom celé webové frameworky ako Express.js alebo Sails.js. Viem, že mnohým sa nepáči, že sa JavaScript trepe na backend; tiež som otváral oči. Nuž ale keď už teda má jazyk byť univerzálny, tak by mal mať aj poriadne formátovanie.
Ináč musím povedať, že sa JavaScript veľmi zlepšil. V minulosti to bola bieda. Ešte však bude treba kopec roboty, jazyk by mal mať poriadnu základnú knižnicu. Node.js sa chváli, že majú najviac balíčkov zo všetkých repozitárov, otázka je, akej sú kvality. Za 10 - 15 rokov, kým sa to všetko odladí, resp. ak sa to odladí a dotiahne, bude JavaScript veľmi zaujímavou voľbou.
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
-
Java dominuje na Androide, ktorý
dominuje prenosným zariadeniam a na veľkých projektoch na backende. Neviem ako je to pri malých zariadeniach
a IOT, ale predpokladám, že sa tam tiež dobre drží...
V IoT vůbec.
Podla toho, co povazujete za IoT. Osobne som v jave programoval pre zariadenie s obmedzenymi zdrojmi, obmedzenym napajanim a slabym vykonom. Bolo to par rokov dozadu, ale predpokladam, ze tu platformu este nezrusili.
-
Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Zajímavá otázka. Když píšeš “haskel” s jedním L, tak žádnou lopatu potřebovat nebudeš ;)
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Ne. Ale opačně bych si to klidně představit dovedl.
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Ne. Ale opačně bych si to klidně představit dovedl.
To akoze sa mam ucit lleksah? Taky jazyk nepoznam :(
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Ne. Ale opačně bych si to klidně představit dovedl.
To akoze sa mam ucit lleksah? Taky jazyk nepoznam :(
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Ne. Ale opačně bych si to klidně představit dovedl.
To akoze sa mam ucit lleksah? Taky jazyk nepoznam :(
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
Nemohol by, aj keby chcel. Lebo by nemal skusenosti s javou, ale s exotickym jazykom, ktory pouziva 1 promile programatorov. Cize by mu to bolo celkom nanic. Kdezto haskellistov je tak malo, ze by ma aj s hello world vzali celkom urcite.
-
Console.WriteLine("{0:D} {1,8:X}", 502, 546);
print('There are {0} oranges and {1} apples in the basket'.format(12, 23))
Je to veľmi pohodlné. Samozrejme, aj StringBuilder by bodol.
Tak tomu rozumim. A nemuzu rict, ze by mi to taky nevadilo, ale da se s tim zit. Taky chapu proc tam to formatovani neni. Ale je to vicemene historie. Dnes uz js obsahuje internationalization api a casem bude jiste i string.format.
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
Nemohol by, aj keby chcel. Lebo by nemal skusenosti s javou, ale s exotickym jazykom, ktory pouziva 1 promile programatorov. Cize by mu to bolo celkom nanic. Kdezto haskellistov je tak malo, ze by ma aj s hello world vzali celkom urcite.
Akorát, že ono je to něco v tom stylu, jestli bys technického designera formule 1 byl ochoten zaměstnat jako senior technika ve škodováckém servisu.... ono designerů formule 1 je tak málo, že by je vzali i se schopností postavit elektrický modýlek celkem určitě...
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
Nemohol by, aj keby chcel. Lebo by nemal skusenosti s javou, ale s exotickym jazykom, ktory pouziva 1 promile programatorov. Cize by mu to bolo celkom nanic. Kdezto haskellistov je tak malo, ze by ma aj s hello world vzali celkom urcite.
Akorát, že ono je to něco v tom stylu, jestli bys technického designera formule 1 byl ochoten zaměstnat jako senior technika ve škodováckém servisu.... ono designerů formule 1 je tak málo, že by je vzali i se schopností postavit elektrický modýlek celkem určitě...
No lebo skodovka nevyraba auta pro pepy ale formule 1. Skor ako formula 1 by sa hodilo prirovnanie k medzihviezdnemu vozitku, ktore jazdi v rozpravkach. Formula 1 je predsa len inzinierstvo.
-
Ja mam za sebou prax 8 rokov java developera, plus cca 3 roky javy na skole. Praca sa mi pozdava, aj uz v tom viem slusne robit, aj sa mi to oplati.
Ale tu je otazka:
Prijmu ma za senior Haskell developera? Lebo 11 rokov pocuvam, ze java je nahovno, ale ja chcem byt in :( Ked napisem, ze som haskel senior, kolkych zamestnavatelov budem musiet od seba lopatou odhanat?
Ne. Ale opačně bych si to klidně představit dovedl.
To akoze sa mam ucit lleksah? Taky jazyk nepoznam :(
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Ale mohl, pokud je někdo intelektuálně schopen naučit se velmi dobře Haskell nebo nějaký podobný funkcionální jazyk (Idris třeba) se vší to šílenou vysoce abstraktní matematikou, co za ním stojí, je pro něj přízemní Java něco jako malá násobilka pro absolventa matfyzu.
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
Nemohol by, aj keby chcel. Lebo by nemal skusenosti s javou, ale s exotickym jazykom, ktory pouziva 1 promile programatorov. Cize by mu to bolo celkom nanic. Kdezto haskellistov je tak malo, ze by ma aj s hello world vzali celkom urcite.
Akorát, že ono je to něco v tom stylu, jestli bys technického designera formule 1 byl ochoten zaměstnat jako senior technika ve škodováckém servisu.... ono designerů formule 1 je tak málo, že by je vzali i se schopností postavit elektrický modýlek celkem určitě...
Hehe, tak tohle si někde uložím. Dobřes ho setřel, trolla.
-
Ale mohl, pokud je někdo intelektuálně schopen naučit se velmi dobře Haskell nebo nějaký podobný funkcionální jazyk (Idris třeba) se vší to šílenou vysoce abstraktní matematikou, co za ním stojí, je pro něj přízemní Java něco jako malá násobilka pro absolventa matfyzu.
Akorát, že ono je to něco v tom stylu, jestli bys technického designera formule 1 byl ochoten zaměstnat jako senior technika ve škodováckém servisu.... ono designerů formule 1 je tak málo, že by je vzali i se schopností postavit elektrický modýlek celkem určitě...
Ale kluci, hádam si nemyslíte, že senior Java developer je preto senior developer, lebo výborne pozná Javu.
Senior Java developer musí mať obrovské kvantum znalostí. Ten, kto výborne pozná jazyk Java, vie len veľmi málo.
Ešte je potrebné vedieť rozsiahlu základnú knižnicu, dôležité podporné externé knižnice
(napr. prácu s HTML, JSON, XML, CSV, PDF, IO (Input Output ZOO je chuťovka), requestami, atď), potom sú tu databázy (relačné, dokumentové), nadstavby nad databázami (Hibernate, MyBatis), servlety, webové knižnice, security, messaging, batch processing, scheduling, testing, logging, transakcie... Len základy Springu zaberú niekoľko mesačné intenzívne štúdium.
Musí vedieť, ako to všetko dať dohromady, teda mať znalosti integrácie. Určite musí mať prehľad aj o frontende, a vyznať sa v tom zmätku, ktorý tam momentálne panuje.
Ďalej musí vedieť ovládať viacero nástrojov, JIRA, IDE, GIT, Jenkins, Maven... V neposlednom rade musí senior Java vývojár poznať históriu Javy, kontext (napríklad vedieť, že FileReader netreba používať a prečo, prípadne prečo v servlete nemusíte uzatvárať ServletOutputStream), vyznať sa v (to je špecialita Javy) rôznych alternatívnych frameworkoch (vedeli by ste povedať, kedy by bolo vhodné použiť Vaadin, JSF, RestEasy, alebo Play, prípadne JavaLite? :))
Senior Java developer musí mať soft skills na vedenie mladších kolegov, diplomatické schopnosti na komunikáciu s manažmentov a zákazníkmi. Takže späť k Haskell programátorovi, ktorý je perfektný vo vysokej, abstraktnej matematike. Senior Java developerom by sa mohol stať, čoby nie. Po mnohých rokoch štúdia, driny, odriekania a praxe, pekne od piky.
-
Ale kluci, hádam si nemyslíte, že senior Java developer je preto senior developer, lebo výborne pozná Javu.
Senior Java developer musí mať obrovské kvantum znalostí. Ten, kto výborne pozná jazyk Java, vie len veľmi málo.
Ešte je potrebné vedieť rozsiahlu základnú knižnicu, dôležité podporné externé knižnice
(napr. prácu s HTML, JSON, XML, CSV, PDF, IO (Input Output ZOO je chuťovka), requestami, atď), potom sú tu databázy (relačné, dokumentové), nadstavby nad databázami (Hibernate, MyBatis), servlety, webové knižnice, security, messaging, batch processing, scheduling, testing, logging, transakcie... Len základy Springu zaberú niekoľko mesačné intenzívne štúdium.
Musí vedieť, ako to všetko dať dohromady, teda mať znalosti integrácie. Určite musí mať prehľad aj o frontende, a vyznať sa v tom zmätku, ktorý tam momentálne panuje.
Ďalej musí vedieť ovládať viacero nástrojov, JIRA, IDE, GIT, Jenkins, Maven... V neposlednom rade musí senior Java vývojár poznať históriu Javy, kontext (napríklad vedieť, že FileReader netreba používať a prečo, prípadne prečo v servlete nemusíte uzatvárať ServletOutputStream), vyznať sa v (to je špecialita Javy) rôznych alternatívnych frameworkoch (vedeli by ste povedať, kedy by bolo vhodné použiť Vaadin, JSF, RestEasy, alebo Play, prípadne JavaLite? :))
Senior Java developer musí mať soft skills na vedenie mladších kolegov, diplomatické schopnosti na komunikáciu s manažmentov a zákazníkmi. Takže späť k Haskell programátorovi, ktorý je perfektný vo vysokej, abstraktnej matematike. Senior Java developerom by sa mohol stať, čoby nie. Po mnohých rokoch štúdia, driny, odriekania a praxe, pekne od piky.
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
-
Ale kluci, hádam si nemyslíte, že senior Java developer je preto senior developer, lebo výborne pozná Javu.
Senior Java developer musí mať obrovské kvantum znalostí. Ten, kto výborne pozná jazyk Java, vie len veľmi málo.
Ešte je potrebné vedieť rozsiahlu základnú knižnicu, dôležité podporné externé knižnice
(napr. prácu s HTML, JSON, XML, CSV, PDF, IO (Input Output ZOO je chuťovka), requestami, atď), potom sú tu databázy (relačné, dokumentové), nadstavby nad databázami (Hibernate, MyBatis), servlety, webové knižnice, security, messaging, batch processing, scheduling, testing, logging, transakcie... Len základy Springu zaberú niekoľko mesačné intenzívne štúdium.
Musí vedieť, ako to všetko dať dohromady, teda mať znalosti integrácie. Určite musí mať prehľad aj o frontende, a vyznať sa v tom zmätku, ktorý tam momentálne panuje.
Ďalej musí vedieť ovládať viacero nástrojov, JIRA, IDE, GIT, Jenkins, Maven... V neposlednom rade musí senior Java vývojár poznať históriu Javy, kontext (napríklad vedieť, že FileReader netreba používať a prečo, prípadne prečo v servlete nemusíte uzatvárať ServletOutputStream), vyznať sa v (to je špecialita Javy) rôznych alternatívnych frameworkoch (vedeli by ste povedať, kedy by bolo vhodné použiť Vaadin, JSF, RestEasy, alebo Play, prípadne JavaLite? :))
Senior Java developer musí mať soft skills na vedenie mladších kolegov, diplomatické schopnosti na komunikáciu s manažmentov a zákazníkmi. Takže späť k Haskell programátorovi, ktorý je perfektný vo vysokej, abstraktnej matematike. Senior Java developerom by sa mohol stať, čoby nie. Po mnohých rokoch štúdia, driny, odriekania a praxe, pekne od piky.
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Nie, senior je taky, co vie Haskell a v jave robil hovno. :) Respektive aj by nahovno kodil v jave, ale nechce to.
-
http://leksah.org/ (http://leksah.org/)...? nicméně bylo to míněno tak, že ta analogie je špatně, protože Java a C# jsou velmi podobné jazyky, zatímco haskell je zcela jiný level.
No, ale celkom hlupa, lebo haskellista by java seniora robit nemohol.
Proč ne? On by asi spíš nechtěl, než nemohl....
Nemohol by, aj keby chcel. Lebo by nemal skusenosti s javou, ale s exotickym jazykom, ktory pouziva 1 promile programatorov. Cize by mu to bolo celkom nanic. Kdezto haskellistov je tak malo, ze by ma aj s hello world vzali celkom urcite.
Akorát, že ono je to něco v tom stylu, jestli bys technického designera formule 1 byl ochoten zaměstnat jako senior technika ve škodováckém servisu.... ono designerů formule 1 je tak málo, že by je vzali i se schopností postavit elektrický modýlek celkem určitě...
Hehe, tak tohle si někde uložím. Dobřes ho setřel, trolla.
Zotrel leda tak seba.
-
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Nie, senior je taky, co vie Haskell a v jave robil hovno. :) Respektive aj by nahovno kodil v jave, ale nechce to.
Jasně, chápu, Haskell je pro tebe příliš složitý, takže nedokážeš pochopit, jak by se někdo, kdo nestrávil půl života s java frameworky, v tom rozumně rychle dokázal zorientovat...
-
musí [...] vyznať sa v tom zmätku, ktorý tam momentálne panuje.
To nepochybně :)
-
Ale kluci, hádam si nemyslíte, že senior Java developer je preto senior developer, lebo výborne pozná Javu.
Tak jasně, musí znát tři řitě frameworků, aby napsal hello world. Proto je možná lepší používat jazyky, ve kterých se člověk bez frameworků obejde (a teď nemyslím jen Haskell).
Jinak to s tou matikou ve FP jsem myslel (napůl) ironicky, ta je podmínkou postačující, ovšem nikoliv nutnou.
P.S. O Haskellu se nemá smysl moc bavit, jak psal "balík", je to okrajová záležitost pro fajnšmekry a joby pro "juniory" prakticky nejsou (a "seniorů" je jak šafránu).
-
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Seniórneho programátora môžme definovať rôzne; podľa mňa je to kľúčový programátor na projekte. Myslím si, že ten, kto sa rýchlo zorientuje v nejakej technológii, nemôže byť hneď seniorom. Vysvetlím na analógii.
Povedané starým slovníkom, nemecký Reichswehr/Wehrmacht si vychovával vlastné kádre. Vytipovaných vojakov z dobrých rodín zobral do svojich škôl, kde ich zaškolili. Potom šli na prax na rôzne pozície v armáde. Išli do vojen, na misie, inokedy šli učiť do vojenských škôl, alebo velili posádke. Proste vojak, mohol byť akýkoľvek excelentný delostrelec, veliteľ menšej skupiny, organizátor, musel si prejsť rôznymi postami, aby mohol dosiahnuť na najvyššie pozície v armáde. Priemerný vek vojakov, povýšených na generálov mohol byť okolo 50 rokov, resp. 50 plus. To znamená, 30 rokov aktívnej služby. Pretože generál musí mať rozsiahle znalosti zo všetkých oblastí vojenstva.
Tak je to aj so Java seniormi (to senior tam nie je náhodou). Nestačí byť inteligentný, ovládať nejakú technológiu. Musíte mať rozsiahle vedomosti a dlhoročnú prax. Tak je to všade, resp. by to tak malo byť.
-
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Seniórneho programátora môžme definovať rôzne; podľa mňa je to kľúčový programátor na projekte. Myslím si, že ten, kto sa rýchlo zorientuje v nejakej technológii, nemôže byť hneď seniorom. Vysvetlím na analógii.
Povedané starým slovníkom, nemecký Reichswehr/Wehrmacht si vychovával vlastné kádre. Vytipovaných vojakov z dobrých rodín zobral do svojich škôl, kde ich zaškolili. Potom šli na prax na rôzne pozície v armáde. Išli do vojen, na misie, inokedy šli učiť do vojenských škôl, alebo velili posádke. Proste vojak, mohol byť akýkoľvek excelentný delostrelec, veliteľ menšej skupiny, organizátor, musel si prejsť rôznymi postami, aby mohol dosiahnuť na najvyššie pozície v armáde. Priemerný vek vojakov, povýšených na generálov mohol byť okolo 50 rokov, resp. 50 plus. To znamená, 30 rokov aktívnej služby. Pretože generál musí mať rozsiahle znalosti zo všetkých oblastí vojenstva.
Tak je to aj so Java seniormi (to senior tam nie je náhodou). Nestačí byť inteligentný, ovládať nejakú technológiu. Musíte mať rozsiahle vedomosti a dlhoročnú prax. Tak je to všade, resp. by to tak malo byť.
Ano, toto platí (aspoň by mělo) všeobecně. To jen "balík" psal, že může být haskellím seniorem hned (načež napsal "haskel" chybně) :)
-
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Seniórneho programátora môžme definovať rôzne; podľa mňa je to kľúčový programátor na projekte. Myslím si, že ten, kto sa rýchlo zorientuje v nejakej technológii, nemôže byť hneď seniorom. Vysvetlím na analógii.
Povedané starým slovníkom, nemecký Reichswehr/Wehrmacht si vychovával vlastné kádre. Vytipovaných vojakov z dobrých rodín zobral do svojich škôl, kde ich zaškolili. Potom šli na prax na rôzne pozície v armáde. Išli do vojen, na misie, inokedy šli učiť do vojenských škôl, alebo velili posádke. Proste vojak, mohol byť akýkoľvek excelentný delostrelec, veliteľ menšej skupiny, organizátor, musel si prejsť rôznymi postami, aby mohol dosiahnuť na najvyššie pozície v armáde. Priemerný vek vojakov, povýšených na generálov mohol byť okolo 50 rokov, resp. 50 plus. To znamená, 30 rokov aktívnej služby. Pretože generál musí mať rozsiahle znalosti zo všetkých oblastí vojenstva.
Tak je to aj so Java seniormi (to senior tam nie je náhodou). Nestačí byť inteligentný, ovládať nejakú technológiu. Musíte mať rozsiahle vedomosti a dlhoročnú prax. Tak je to všade, resp. by to tak malo byť.
Ano, toto platí (aspoň by mělo) všeobecně. To jen "balík" psal, že může být haskellím seniorem hned (načež napsal "haskel" chybně) :)
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
-
A není tohle spíš popis "Java guru"? Nebo snad programátor, který je schopen vzít jakoukoliv technologii a během krátké doby v tom produktivně pracovat, není Senior?
Seniórneho programátora môžme definovať rôzne; podľa mňa je to kľúčový programátor na projekte. Myslím si, že ten, kto sa rýchlo zorientuje v nejakej technológii, nemôže byť hneď seniorom. Vysvetlím na analógii.
Tak chápu, že asi ne "příští týden", na druhou stranu nerozumím tomu, proč by ten člověk nemohl být přijat primárně na seniorní pozici s tím, že s od něj očekává, že se v přiměřeně krátké době zorientuje.
Povedané starým slovníkom, nemecký Reichswehr/Wehrmacht si vychovával vlastné kádre. Vytipovaných vojakov z dobrých rodín zobral do svojich škôl, kde ich zaškolili. Potom šli na prax na rôzne pozície v armáde. Išli do vojen, na misie, inokedy šli učiť do vojenských škôl, alebo velili posádke. Proste vojak, mohol byť akýkoľvek excelentný delostrelec, veliteľ menšej skupiny, organizátor, musel si prejsť rôznymi postami, aby mohol dosiahnuť na najvyššie pozície v armáde. Priemerný vek vojakov, povýšených na generálov mohol byť okolo 50 rokov, resp. 50 plus. To znamená, 30 rokov aktívnej služby. Pretože generál musí mať rozsiahle znalosti zo všetkých oblastí vojenstva.
Tak je to aj so Java seniormi (to senior tam nie je náhodou). Nestačí byť inteligentný, ovládať nejakú technológiu. Musíte mať rozsiahle vedomosti a dlhoročnú prax. Tak je to všade, resp. by to tak malo byť.
Ne. Když to vezmu na ten příklad s formulí, tak člověka, který třeba technicky navrhoval a servisoval formule 1 asi nebude problém přijmout jako "senior" technika pro škodovky.
Ano, asi nebude ty opravy dělat hned "příští týden", ale tvrdit, že musí mít "rozsáhlé vědomosti" (která má mnohem rozsáhlejší, než ti, kteří mají tu dlouho praxi) a že musí mít dlouholetou praxi v servisování škodovek je prostě nesmysl.
Jinak to, že někdo dělá něco 7 let v nějakém jazyce samozřejmě nutně nevypovídá o tom, jak to zvládá, ale otázka zněla, zda lze jít C# -> Java, a vzhledem k podobnosti těch jazyků úplně principálně nevidím důvod, proč ne. A myslím, že OP by asi nenamítal proti nabídce typu "očekáváme, že do 2 měsíců budete schopen samostatně programovat a navrhovat".
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
Mnoho nových změn jak v Javě, tak v C# je silně ovlivněno zkušenostmi z Haskellu (mimochodem, je to částečně produktem Microsoft Research). Je to zhruba na té úrovni, jako když ten servisman z F1 přijde do toho servisu škodovek a oni tam zrovna zaváděj nejnovější cool technologii (se kterou nikdo neumí), se kterou on na té F1 pracuje poslední 3 roky.
-
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
Mnoho nových změn jak v Javě, tak v C# je silně ovlivněno zkušenostmi z Haskellu (mimochodem, je to částečně produktem Microsoft Research). Je to zhruba na té úrovni, jako když ten servisman z F1 přijde do toho servisu škodovek a oni tam zrovna zaváděj nejnovější cool technologii (se kterou nikdo neumí), se kterou on na té F1 pracuje poslední 3 roky.
No lebo formula 1 nie je standardny pasovy produkt, ktory musi prejst roznymi bezpecnostnymi kriteriami, musi byt sposobile na cestnu premavku a v skutocnosti je to uplne iny druh vozu, a nie cestne auto.
-
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
Mnoho nových změn jak v Javě, tak v C# je silně ovlivněno zkušenostmi z Haskellu (mimochodem, je to částečně produktem Microsoft Research). Je to zhruba na té úrovni, jako když ten servisman z F1 přijde do toho servisu škodovek a oni tam zrovna zaváděj nejnovější cool technologii (se kterou nikdo neumí), se kterou on na té F1 pracuje poslední 3 roky.
No lebo formula 1 nie je standardny pasovy produkt, ktory musi prejst roznymi bezpecnostnymi kriteriami, musi byt sposobile na cestnu premavku a v skutocnosti je to uplne iny druh vozu, a nie cestne auto.
Ahh... jasně... trochu mi to připomíná takové ty absurdity, kdy lidi, kteří jsou experti ve svém oboru vlastně nesmí učit ten obor někde na základce - a ten důvod není, že by byli neschopní učitelé, ale že nemají ten správný papír a neprošli si tou správnou školou....
-
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
Mnoho nových změn jak v Javě, tak v C# je silně ovlivněno zkušenostmi z Haskellu (mimochodem, je to částečně produktem Microsoft Research). Je to zhruba na té úrovni, jako když ten servisman z F1 přijde do toho servisu škodovek a oni tam zrovna zaváděj nejnovější cool technologii (se kterou nikdo neumí), se kterou on na té F1 pracuje poslední 3 roky.
No lebo formula 1 nie je standardny pasovy produkt, ktory musi prejst roznymi bezpecnostnymi kriteriami, musi byt sposobile na cestnu premavku a v skutocnosti je to uplne iny druh vozu, a nie cestne auto.
Ahh... jasně... trochu mi to připomíná takové ty absurdity, kdy lidi, kteří jsou experti ve svém oboru vlastně nesmí učit ten obor někde na základce - a ten důvod není, že by byli neschopní učitelé, ale že nemají ten správný papír a neprošli si tou správnou školou....
V zlych analogiach ste senior :) V skutocnosti vyuka konstrukcie formuly 1 by na zakladnej skole bola asi nie moc prinosna. Leda tak specialny kruzok pre deti s pokrocilou fyzikou, znalostami strojarstva a roznymi inymi obormi, co su na to potrebne. Ale co to ma spolocne s javou a haskellom, to neviem.
-
Robil som si zadek z originalneho postu, kde sa pytajuci stve, ze ho nepustia v .Net na seniora. Ja ani neviem, co to haskell je. Ovladam leda tak zle lisp. Proste nikto nemoze byt senior v niecom, co nerobil :) Prirovnania s formulou 1 a skodovkou su ale usmevne.
Mnoho nových změn jak v Javě, tak v C# je silně ovlivněno zkušenostmi z Haskellu (mimochodem, je to částečně produktem Microsoft Research). Je to zhruba na té úrovni, jako když ten servisman z F1 přijde do toho servisu škodovek a oni tam zrovna zaváděj nejnovější cool technologii (se kterou nikdo neumí), se kterou on na té F1 pracuje poslední 3 roky.
No lebo formula 1 nie je standardny pasovy produkt, ktory musi prejst roznymi bezpecnostnymi kriteriami, musi byt sposobile na cestnu premavku a v skutocnosti je to uplne iny druh vozu, a nie cestne auto.
Ahh... jasně... trochu mi to připomíná takové ty absurdity, kdy lidi, kteří jsou experti ve svém oboru vlastně nesmí učit ten obor někde na základce - a ten důvod není, že by byli neschopní učitelé, ale že nemají ten správný papír a neprošli si tou správnou školou....
V zlych analogiach ste senior :) V skutocnosti vyuka konstrukcie formuly 1 by na zakladnej skole bola asi nie moc prinosna. Leda tak specialny kruzok pre deti s pokrocilou fyzikou, znalostami strojarstva a roznymi inymi obormi, co su na to potrebne. Ale co to ma spolocne s javou a haskellom, to neviem.
Kde píšu něco o formuli 1 na základní škole...??? Jde o to, že se snažíte tvrdit, že člověk, který je odborně o několik levelů výše než to, co by měl dělat, podle vás vlastně není odborně navýši, protože nedělal zrovna to, co se po něm bude chtít. Člověk, který na té formuli 1 implementoval a navrhoval ty zařízení, která se pak následně dostala do těch normálních aut asi fakt nebude mít problém ty normální auta servisovat. Protože je odborně někde úplně jinde, byť tyhle konkrétní technologie třeba nikdy neviděl.
Stejně tak člověk, který má velké zkušenosti s Haskellem (pravda, to, že v tom X let programoval to nutně neimplikuje) asi nebude mít fakt problém s nějakou Javou nebo C#. V Javě se bavíme o tom, jestli ten člověk umí pracovat s knihovnou na parsování JSONu, XML, CSV. Haskellista si pravděpodobně nějakou takovou knihovnu za těch X let napsal několikrát.
Samozřejmě, lidi jsou různí, a rozhodně ta implikace není "každý haskellista je geniální", ale ta idea "aby člověk mohl být senior programátor v jazyce X, tak s tím musí mít hodně let praxe" je nesmysl.
-
Kde píšu něco o formuli 1 na základní škole...??? Jde o to, že se snažíte tvrdit, že člověk, který je odborně o několik levelů výše než to, co by měl dělat, podle vás vlastně není odborně navýši, protože nedělal zrovna to, co se po něm bude chtít. Člověk, který na té formuli 1 implementoval a navrhoval ty zařízení, která se pak následně dostala do těch normálních aut asi fakt nebude mít problém ty normální auta servisovat. Protože je odborně někde úplně jinde, byť tyhle konkrétní technologie třeba nikdy neviděl.
Stejně tak člověk, který má velké zkušenosti s Haskellem (pravda, to, že v tom X let programoval to nutně neimplikuje) asi nebude mít fakt problém s nějakou Javou nebo C#. V Javě se bavíme o tom, jestli ten člověk umí pracovat s knihovnou na parsování JSONu, XML, CSV. Haskellista si pravděpodobně nějakou takovou knihovnu za těch X let napsal několikrát.
Samozřejmě, lidi jsou různí, a rozhodně ta implikace není "každý haskellista je geniální", ale ta idea "aby člověk mohl být senior programátor v jazyce X, tak s tím musí mít hodně let praxe" je nesmysl.
Haskellista moze byt celkom slusnym juniorom v jave. No pisat v nej efektivny a prehladny kod nebude. Skratka su to ine jazyky.
-
Tohle by se líbilo Mirkovi ;D Stačí trochu matematiky a hned umíte všechno na světě. Umíš Haskell? Tak Javu dáš v pohodě, protože ji vlastně celou umíš. Nebo chceš dělat ředitele? Není problém, protože ta naučená abstrakce tě naučila všechno.
-
Tohle by se líbilo Mirkovi ;D Stačí trochu matematiky a hned umíte všechno na světě. Umíš Haskell? Tak Javu dáš v pohodě, protože ji vlastně celou umíš. Nebo chceš dělat ředitele? Není problém, protože ta naučená abstrakce tě naučila všechno.
Na tomhle pohorel sheldon, ani auto nenastartoval.
-
Tohle by se líbilo Mirkovi ;D Stačí trochu matematiky a hned umíte všechno na světě. Umíš Haskell? Tak Javu dáš v pohodě, protože ji vlastně celou umíš. Nebo chceš dělat ředitele? Není problém, protože ta naučená abstrakce tě naučila všechno.
Haskell neimplikuje matiku, ani naopak. Abstraktní myšlení je univerzální skill nejen pro technické obory, stejně tak ho využije filosof nebo třeba kognitivní psycholog.
-
No pisat v nej efektivny a prehladny kod nebude.
jestli to nebude víc javou než haskellistou :)
-
No pisat v nej efektivny a prehladny kod nebude.
jestli to nebude víc javou než haskellistou :)
Bude to viac javou, lebo java nie je haskell. To da rozum.
-
No pisat v nej efektivny a prehladny kod nebude.
jestli to nebude víc javou než haskellistou :)
Bude to viac javou, lebo java nie je haskell. To da rozum.
Efektivní kód v Javě? V jakém paralelním vesmíru?
-
Haskellista moze byt celkom slusnym juniorom v jave. No pisat v nej efektivny a prehladny kod nebude. Skratka su to ine jazyky.
Ty umíš Haskell? Jenom bych rád věděl, proč si tím jsi tak jist?
-
Tak jasně, musí znát tři řitě frameworků, aby napsal hello world. Proto je možná lepší používat jazyky, ve kterých se člověk bez frameworků obejde (a teď nemyslím jen Haskell).
Jinak to s tou matikou ve FP jsem myslel (napůl) ironicky, ta je podmínkou postačující, ovšem nikoliv nutnou.
P.S. O Haskellu se nemá smysl moc bavit, jak psal "balík", je to okrajová záležitost pro fajnšmekry a joby pro "juniory" prakticky nejsou (a "seniorů" je jak šafránu).
Ono sa to možno nezdá, ale frameworky uľahčujú tvorbu aplikácií. Človek by ozaj nechcel sám naprogramovať ORM vrstvu, security vrstvu, či vlastné testovacie knižnice. Tie frameworky sú potrebné preto, lebo tie aplikácie sú veľmi zložité. Bez nich by sa to nedalo.
Pre zaujímavosť Hello World vo Spring Boot a Groovy (prototyping pre Javu):
class MyApp {
@RequestMapping("/")
String home() {
"This is Spring Boot application"
}
}
$ spring run hello.groovy
$ curl localhost:8080
This is Spring Boot application
Tak chápu, že asi ne "příští týden", na druhou stranu nerozumím tomu, proč by ten člověk nemohl být přijat primárně na seniorní pozici s tím, že s od něj očekává, že se v přiměřeně krátké době zorientuje.
Vynikajúci C++ programátor hier, Haskell výpočtový programátor, ani skvelý C programátor jadra Linuxu nemôžu byť prijatí na seniórnu pozíciu Java aplikačného programátora. Platí to naopak medzi všetkými oblasťami. Tie nároky sú príliš veľké. Skúsený PHP programátor by na tom bol nepomerne lepšie, ale aj jeho by čakalo kopec driny.
Stejně tak člověk, který má velké zkušenosti s Haskellem (pravda, to, že v tom X let programoval to nutně neimplikuje) asi nebude mít fakt problém s nějakou Javou nebo C#. V Javě se bavíme o tom, jestli ten člověk umí pracovat s knihovnou na parsování JSONu, XML, CSV. Haskellista si pravděpodobně nějakou takovou knihovnu za těch X let napsal několikrát.
S jazykom C# alebo Java nie, ale s programovaním moderných, komplexných aplikácií v Jave áno. JSON, XML, CSV sú len kvapkou z toho rozsiahleho mora znalostí, ktoré aplikačný Java developer musí mať. Napriek tomu, že práca trebárs s XML nie je primárne nejako ťažká, potrebuje tam programátor dosť veľa znalostí. Ono totiž v Jave máme JAXP a JAXB API na prácu s XML, JAXP sa delí potom na ďalšie sekcie API: SAX, StaX, JDOM. Každú z API treba použiť v inej situácii.
Ďalej je tam API na validáciu XML dokumentov, ich transformáciu (XLST), a vyhľadávanie XPath. Niečo obdobné je aj pre JSON. Ďalej treba tieto vedomosti uplatniť pri frameworkoch na tvorbu Restových alebo SOAP web aplikácií.
A to prosím hovoríme o jednom malom zrnku. PHPčkár sa bude chytať, ostatní zrejme nie.
Aplikační programátori rozhodne nemajú tiež čas vyvývať svoje vlastné XML parsery. To, čo potrebujú vedieť je dosť na jeden život človeka.
-
Tak jasně, musí znát tři řitě frameworků, aby napsal hello world. Proto je možná lepší používat jazyky, ve kterých se člověk bez frameworků obejde (a teď nemyslím jen Haskell).
Jinak to s tou matikou ve FP jsem myslel (napůl) ironicky, ta je podmínkou postačující, ovšem nikoliv nutnou.
P.S. O Haskellu se nemá smysl moc bavit, jak psal "balík", je to okrajová záležitost pro fajnšmekry a joby pro "juniory" prakticky nejsou (a "seniorů" je jak šafránu).
Ono sa to možno nezdá, ale frameworky uľahčujú tvorbu aplikácií. Človek by ozaj nechcel sám naprogramovať ORM vrstvu, security vrstvu, či vlastné testovacie knižnice. Tie frameworky sú potrebné preto, lebo tie aplikácie sú veľmi zložité. Bez nich by sa to nedalo.
Pre zaujímavosť Hello World vo Spring Boot a Groovy (prototyping pre Javu):
class MyApp {
@RequestMapping("/")
String home() {
"This is Spring Boot application"
}
}
$ spring run hello.groovy
$ curl localhost:8080
This is Spring Boot application
Tak chápu, že asi ne "příští týden", na druhou stranu nerozumím tomu, proč by ten člověk nemohl být přijat primárně na seniorní pozici s tím, že s od něj očekává, že se v přiměřeně krátké době zorientuje.
Vynikajúci C++ programátor hier, Haskell výpočtový programátor, ani skvelý C programátor jadra Linuxu nemôžu byť prijatí na seniórnu pozíciu Java aplikačného programátora. Platí to naopak medzi všetkými oblasťami. Tie nároky sú príliš veľké. Skúsený PHP programátor by na tom bol nepomerne lepšie, ale aj jeho by čakalo kopec driny.
Stejně tak člověk, který má velké zkušenosti s Haskellem (pravda, to, že v tom X let programoval to nutně neimplikuje) asi nebude mít fakt problém s nějakou Javou nebo C#. V Javě se bavíme o tom, jestli ten člověk umí pracovat s knihovnou na parsování JSONu, XML, CSV. Haskellista si pravděpodobně nějakou takovou knihovnu za těch X let napsal několikrát.
S jazykom C# alebo Java nie, ale s programovaním moderných, komplexných aplikácií v Jave áno. JSON, XML, CSV sú len kvapkou z toho rozsiahleho mora znalostí, ktoré aplikačný Java developer musí mať. Napriek tomu, že práca trebárs s XML nie je primárne nejako ťažká, potrebuje tam programátor dosť veľa znalostí. Ono totiž v Jave máme JAXP a JAXB API na prácu s XML, JAXP sa delí potom na ďalšie sekcie API: SAX, StaX, JDOM. Každú z API treba použiť v inej situácii.
Ďalej je tam API na validáciu XML dokumentov, ich transformáciu (XLST), a vyhľadávanie XPath. Niečo obdobné je aj pre JSON. Ďalej treba tieto vedomosti uplatniť pri frameworkoch na tvorbu Restových alebo SOAP web aplikácií.
A to prosím hovoríme o jednom malom zrnku. PHPčkár sa bude chytať, ostatní zrejme nie.
Aplikační programátori rozhodne nemajú tiež čas vyvývať svoje vlastné XML parsery. To, čo potrebujú vedieť je dosť na jeden život človeka.
V Javě ano, ale mnohem lepší je přístup à la Go, kde vše potřebné má standardní knihovna.
-
Tak jasně, musí znát tři řitě frameworků, aby napsal hello world. Proto je možná lepší používat jazyky, ve kterých se člověk bez frameworků obejde (a teď nemyslím jen Haskell).
Ono sa to možno nezdá, ale frameworky uľahčujú tvorbu aplikácií. Človek by ozaj nechcel sám naprogramovať ORM vrstvu, security vrstvu, či vlastné testovacie knižnice. Tie frameworky sú potrebné preto, lebo tie aplikácie sú veľmi zložité. Bez nich by sa to nedalo.
Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).
type ServerApi = Get '[PlainText] Text
home = return "This is servant application!"
app = serve (Proxy @ServerApi) home
main = run 8081 app
(tohle je jenom demonstrace toho, že i bez frameworku, jenom s knihovnou, lze dosáhnout identického výsledku, nic víc tím říct nechci)
Vynikajúci C++ programátor hier, Haskell výpočtový programátor, ani skvelý C programátor jadra Linuxu nemôžu byť prijatí na seniórnu pozíciu Java aplikačného programátora. Platí to naopak medzi všetkými oblasťami. Tie nároky sú príliš veľké. Skúsený PHP programátor by na tom bol nepomerne lepšie, ale aj jeho by čakalo kopec driny.
Tak až do PHP by se to dalo brát vážně, ale tím jsi to fakt zabil....
Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.
S jazykom C# alebo Java nie, ale s programovaním moderných, komplexných aplikácií v Jave áno. JSON, XML, CSV sú len kvapkou z toho rozsiahleho mora znalostí, ktoré aplikačný Java developer musí mať. Napriek tomu, že práca trebárs s XML nie je primárne nejako ťažká, potrebuje tam programátor dosť veľa znalostí. Ono totiž v Jave máme JAXP a JAXB API na prácu s XML, JAXP sa delí potom na ďalšie sekcie API: SAX, StaX, JDOM. Každú z API treba použiť v inej situácii.
Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".
Aplikační programátori rozhodne nemajú tiež čas vyvývať svoje vlastné XML parsery. To, čo potrebujú vedieť je dosť na jeden život človeka.
No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Ale, abych to zopakoval, tohle není o Haskellu - jde o to, že to, že znám API nějakých 20 knihoven ze mě přece nedělá seniora a z druhé strany, to, že to API neznám neznamená, že se to za měsíc nemůžu naučit.
-
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Lol, lol, lol.
-
No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...
-
No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...
Ved je elegantny, do komentarov som dal poniky v ascii art. Vy budete nejaky hlupejsi.
-
No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...
Ved je elegantny, do komentarov som dal poniky v ascii art. Vy budete nejaky hlupejsi.
To je dost možné, mám třeba problém pochopit, jak jste z mého "je problém napsat elegantní parser" vyvodil, že to nejde.... asi mám moc nízké IQ, pravda....
-
No vždyť jo, to je přesně ten úplně jiný level. V haskellu schopnost napsat si funkční parser patří mezi naprosté základy (jedna z příruček pro začátečníky má téma "napiště si interpret Scheme za 48 hodin"). Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít. Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Vzhledem k neschpnosti poochopit psaný text ten parser asi moc elegantně napsaný nebude...
Ved je elegantny, do komentarov som dal poniky v ascii art. Vy budete nejaky hlupejsi.
To je dost možné, mám třeba problém pochopit, jak jste z mého "je problém napsat elegantní parser" vyvodil, že to nejde.... asi mám moc nízké IQ, pravda....
Ved ja viem, haskellisti kodia v cylindroch, to som si vas len tak doberal ...
-
Ano andy, v jave nepiseme parsery, lebo to nevieme a je to chyba javy. Idem vratit plat, parser na nestandardnu vec co som prave napisal sa napisat neda.
Knihovnu umí použít každý.
-
Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).
Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.
„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.
Tak až do PHP by se to dalo brát vážně, ale tím jsi to fakt zabil....
PHP za tie roky vyzrelo. Veľa sa inšpirovali Javou. Tí, čo sa dívajú zvrchu na PHP zrejme moderné PHP vôbec nepoznajú. Taký PHP Laravel framework je veľmi šikovný a elegantný.
Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.
Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell + matematika.
Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".
Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.
Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.
To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)
Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).
-
Knihovnu umí použít každý.
Poprosím všetkých tých, čo si toto myslia, aby doplnili nasledujúci program tak, aby
tam boli dva buttony v ľavom dolnom rohu, s medzerou medzi nimi a okrajmi.
:)
package com.zetcode
import javax.swing.*
class TooltipEx(title: String) : JFrame() {
init {
createUI(title)
}
private fun createUI(title: String) {
val closeButton = JButton("Button").apply({
toolTipText = "JButton component"
})
createLayout(closeButton)
setTitle(title)
defaultCloseOperation = JFrame.EXIT_ON_CLOSE
setLocationRelativeTo(null)
}
private fun createLayout(vararg arg: JComponent) {
val gl = GroupLayout(contentPane)
contentPane.layout = gl
(contentPane as JPanel).toolTipText = "This is JPanel"
gl.autoCreateContainerGaps = true
gl.setHorizontalGroup(gl.createSequentialGroup()
.addComponent(arg[0])
.addGap(200)
);
gl.setVerticalGroup(gl.createSequentialGroup()
.addComponent(arg[0])
.addGap(120)
);
pack();
}
}
private fun createAndShowGUI() {
val frame = TooltipEx("Tooltip example")
frame.isVisible = true
}
fun main(args: Array<String>) {
SwingUtilities.invokeLater(::createAndShowGUI)
}
Je to v jazyku Kotlin. Práve teraz si skúšam, ako spraviť Swing aplikáciu v Kotline.
(https://i.imgur.com/bEGATAc.png)
-
Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).
Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.
„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.
Tak až do PHP by se to dalo brát vážně, ale tím jsi to fakt zabil....
PHP za tie roky vyzrelo. Veľa sa inšpirovali Javou. Tí, čo sa dívajú zvrchu na PHP zrejme moderné PHP vôbec nepoznajú. Taký PHP Laravel framework je veľmi šikovný a elegantný.
Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.
Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell + matematika.
Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".
Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.
Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.
To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)
Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).
Ty časy jsou trochu přehnané. Vývojář nebo architekt je junior nebo senior bez ohledu na jazyk, jde o zkušenosti z vývoje a návrhu celkově. Vůbec to nesouvisí s Haskellem nebo Javou. Akorát Haskell je mnohem abstraktnější, takže přechod na Javu je hračka, kdežto naopak obnáší učení se novému paradigmatu.
-
Myslím, že autor tím myslel to, že je trošku rozdíl mezi "frameworkem" a "knihovnou" s tím, že je preferována "knihovna" před "frameworkem". Tohle je samozřejmě na filosofickou debatu, ale třeba konkrétně proti tvému příkladu anotace @RequestMapping tak nějak spadla z nebe, není to pořádně součást kódu, je tam nějak "navíc". Tohle je příklad tohotéž s použitím knihovny (která je teda hodně advanced).
Nespadla z neba, Spring si pozrie zdroják a potrebné závislosti si stiahne a použije. Groovy sa používa na prototyping, preto sa to takto uľahčuje. To je samozrejme niečo, čo C++, C, Haskell programátor nevie, lebo nepozná špecifiká vývoja v Jave. Je Spring Boot magic, vec ktorá veľmi zjednodušuje programátovori prácu, ale na druhej strane pridáva na štúdiu pre začiatočníkov.
No...já chápu, že je trochu problém diskutovat o filosofii jazyků, když ta druhé strana jaksi nezná to druhé...ale zkusím to. Rozdíl mezi knihovnou a frameworkem je v tom, kdo koho volá a co po něm chce. U knihovny principiálně můj kód volá knihovnu a říká jí, co má dělat. Framework naopak volá můj kód a "očekává", že na nějakých místech se třeba objeví nějaké nápady, co má ten framework dělat. Což je příklad toho @RequestMapping, kdy člověk prostě musí "vědět", že to tam ten framework očekává a nějak se podle toho zařídí. Když se to tam zapomene, tak akorát ten program nefunguje jak má, a když to člověk píše, tak se to blbě hledá, protože to tak nějak není v kódové cestě.
„Problém” v Jave nie je v tom, že na vytvorenie aplikácie potrebujeme množstvo knižníc. Každý projekt má sadu nástrojov, tzv. full stack, ktorú použije na tvorbu aplikácie. Tak je to v Jave, C#, PHP, alebo Ruby. Problém sa vníma v tom, že Java má veľa alternatív, konkurenčných knižníc, modulov, frameworkov. Problém je sa potom rozhodnúť, ktorú použiť.
No, což je situace zhruba ve všech jazycích....
Pleteš si znalosti (webových) technologií se znalostí jazyka a jeho ekosystému. Haskell má velmi dobrou podporu pro webové technologie, tak fakt netuším, proč by na tom PHPčkář měl být líp.
Upozorňoval so, že Haskell senior developer nemôže robiť Java senior developera, pretože ich doména je iná. V Jave sa riešia veľké webové projetky, Android a v Haskelli iné veci. Implicitne sa tu v diskusii myslelo Haskell + matematika.
Ne, to se vůbec implicitně nemyslelo, to někdo zmínil v tom (a ještě chybném) smyslu, že haskellový typový systém je hodně teoretický a abstraktní, a pokud ho zvládneš, tak ve srovnání s ním je všechno ostatní hračka. Ne, že v tom píšeš matematiku. Třeba konkrétně ten servant (knihovna na REST api) je krásná ukázka hodně advanced typového systému. A ano, v Haskellu se taky řeší webové projekty, dokonce bych řekl, že je to dneska asi nejčastější užití haskellu.
Nedávno jsem dělal v haskellu několik větších projektů, přičemž každý používá asi tak 50 různých knihoven z dost velkého rozsahu (parsing, security, různé web protokoly atd.). To, na co se ty tváříš, že je potřeba mít strašně velké znalosti, je asi tak na té úrovni "přečtu si API a použiju to".
Nuž ja som intenzívne študoval Swing (desktop UI) vyše roka a pol. Len JTextPane a JEditorPane komponenty by ti zabrali niekoľko mesiacov štúdia. Ak si myslíš, že sa „porozhliadneš” a začneš Swing používať, tak sa veľmi mýliš. Nenakódiš bez dlhodobého štúdia nič poriadne. O Springu ani nehovorím.
Takže podle tebe není senior java programátor ten, který neumí JTextPane a JEditorPane?
Schopnost použít nějakou knihovnu se tak nějak považuje za samozřejmost... zatímco v oblasti Javy se za senioritu považuje schopnost ty knihovny použít.
To berieš odkiaľ? Máš proti Jave a PHP poriadne predsudky. To, čo potrebuje senior Java programátor som písal podrobnejšie vyššie. (Rozsiahle znalosti knižníc, frameworkov, integrácie, návrhu aplikácií, réžie, soft skills a roky praxe.)
Odkud to beru? Od tebe. Jako kontrast proti tomu, že kdybych já někde třeba chtěl dělat senior haskell programátora, tak se mě na znalost nějakých knihoven ptají akorát za účelem zjištění, na jaké úrovni jsem schopen programovat (pokud někdo programuje 7 let v haskellu a neumí aspoň základně použít lensy, tak to poněkud vzbuzuje pochybnost, co vlastně umí).
Napsat si parser, to prostě jen v nejvyšší nouzi a moc lidí to elegantně nezvládne... (což je z velké části chyba Javy, ne nutně těch lidí).
Neviem či si to uvedomuješ, ale Java je ekosystém. Nie je to jeden programovací jazyk. V ekosystéme Javy máme funkcionálne jazyky Scalu a Clojure. Takže ak si potrebuješ spraviť parser a chceš to s funkcionálnym jazykom, tak si zoberieš jeden z týchto jazykov. A výslekok môžeš použiť trebárs spätne v Jave (jazyku).
Jasně, takže hádej kdo bude mít menší problém napsat něco ve Scale? Javista nebo haskellista? A když se bavíme o tom, kdo to je senior programátor, tak to je asi docela relevantní otázka, že?
-
Knihovnu umí použít každý.
Poprosím všetkých tých, čo si toto myslia, aby doplnili nasledujúci program tak, aby
tam boli dva buttony v ľavom dolnom rohu, s medzerou medzi nimi a okrajmi.
Buď to půjde nějakým fíglem s TRAILING alignmentem, nebo možná (dost pravděpodobně) taky ne a bude potřeba použít jiný layout, třeba BorderLayout.
Ty fakt máš pocit, že tohle je problém? (v životě jsem swing neviděl)
-
No...já chápu, že je trochu problém diskutovat o filosofii jazyků, když ta druhé strana jaksi nezná to druhé...ale zkusím to. Rozdíl mezi knihovnou a frameworkem je v tom, kdo koho volá a co po něm chce. U knihovny principiálně můj kód volá knihovnu a říká jí, co má dělat. Framework naopak volá můj kód a "očekává", že na nějakých místech se třeba objeví nějaké nápady, co má ten framework dělat. Což je příklad toho @RequestMapping, kdy člověk prostě musí "vědět", že to tam ten framework očekává a nějak se podle toho zařídí. Když se to tam zapomene, tak akorát ten program nefunguje jak má, a když to člověk píše, tak se to blbě hledá, protože to tak nějak není v kódové cestě.
To je uhol pohľadu, resp. ako si zadefinujeme pojmy. Pretože z môjho uhla pohľadu, je framework jednoducho súbor knižníc. Napríklad Spring Boot projekt si vytvorím tak, že zadefinujem potrebné závislosti a Maven mi stiahne potrebné knižnice (u nás JAR súbory). Framework obsahuje množstvo kódu, ktorý sa v projektoch opakuje. Kto koho volá; na to v Jave máme pojem dependency injection, ale primárne nerozlišujeme podľa toho pojmy framework a knižnica. Možno to tak máte zadefinované v Haskelli.
Takže podle tebe není senior java programátor ten, který neumí JTextPane a JEditorPane?
To som nepovedal. Bolo to na ilustráciu toho, že predstava, že si zoberieš knižnicu, pozrieš si API a začneš ju
používať je nereálna. Swing bol len príklad zložitejšej knižnice. Bez dlhodobého štúdia princípov UI a Swingu to nespraví začiatočník správne. Ako spravíš Tetris hru vo Swingu? Veď je to jednoduché, zvolíš si správne triedy zavoláš tie správne metódy...
Jasně, takže hádej kdo bude mít menší problém napsat něco ve Scale? Javista nebo haskellista? A když se bavíme o tom, kdo to je senior programátor, tak to je asi docela relevantní otázka, že?
Mal by to byť Haskellista. Ale odbáčaš od témy. Pointa toho, čo som povedal je, že mne sa zdá, že ty zužuješ (neviem prečo) všetko na Javu ako jazyk. Pritom Java je ekosystém s viacerými programovacími jazykmi. Tvrdíš niečo o Javistoch, hovoríš, že Java je taká a taká, pritom Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
-
Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka
-
Buď to půjde nějakým fíglem s TRAILING alignmentem, nebo možná (dost pravděpodobně) taky ne a bude potřeba použít jiný layout, třeba BorderLayout.
Ty fakt máš pocit, že tohle je problém? (v životě jsem swing neviděl)
Na to si potrebuješ naštudovať GroupLayout manager, čo sú to sequenčné a paralelné grupy a musíš praxou zistiť, ako to všetko v praxi uplatniť. (Naučiť sa pravidlá šachu vs hrať úspešne šach.) Je to triviálny príklad, ale bez dlhšieho štúdia nespravíš dobrý layout. A to som výrazne pomohol tým, že som tam dal GroupLayout, pretože korektný layout vo Swingu sa dá spraviť len s ním alebo s MigLayout manažérom. Toto všetko som zistil až po mnohých mesiacoch štúdia. Napríklad, ak by sa na to niekto spýtal na stackoverflow, veľmi často dostane nesprávnu odpoveď. Ktorá síce funguje, ale nie je portabilná.
Toto nehovorím preto, že by som sa chválil. Ja som dosť starý a zrelý na to, aby som sa potreboval nad niekým vyvyšovať. Ja som Javista ty si iba PHPčkár, ja som backend programátor, ty iba frontenďák apod. Je to na ilustráciu.
private fun createLayout(vararg arg: JComponent) {
val gl = GroupLayout(contentPane)
gl.autoCreateGaps = true
gl.autoCreateContainerGaps = true
contentPane.layout = gl
gl.autoCreateContainerGaps = true
gl.setHorizontalGroup(gl.createSequentialGroup()
.addGap(5, 250, Int.MAX_VALUE)
.addPreferredGap(RELATED,
GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
.addComponent(arg[0])
.addComponent(arg[1])
)
gl.setVerticalGroup(gl.createSequentialGroup()
.addGap(5, 250, Int.MAX_VALUE)
.addPreferredGap(RELATED,
GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
.addGroup(gl.createParallelGroup()
.addComponent(arg[0])
.addComponent(arg[1]))
)
gl.linkSize(SwingConstants.HORIZONTAL, arg[0], arg[1]);
pack()
}
Pre zaujímavosť, buttony do pravého dolného rohu sa dajú nakódiť takto.
Ak by som chcel zvoliť niečo zložitejšie, tak by som navrhol spraviť nasledovný layout:
(https://i.imgur.com/lypkvVo.png)
To je board pre monopoly. Vnútorný priestor sa mení, vonkajšie tvary sú fixné. Dosť som sa s tým potrápil.
-
Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka
Zatiaľ dominuje Java, ale Javisti bežne využívajú aj iné jazyky. Ale podľa mojej mienky to tam smeruje.
Všetko sa dramaticky mení, aj také veci, ktoré boli uhľovými kameňmi vývoja, sa zrazu menia. Trebárs
Servlety, jedna z najdôležitejších sfér v Jave. A prišiel Play framework, ktorý je postavený mimo servlety
a tiež si zvolil Scalu ako dominantný jazyk.
Je veľmi pravdepodobné, že Kotlin za pár rokov nahradí Javu a z Javy v podstate zostane názov pre tento
rozsiahly ekosystém.
-
Cetl jsem jen prvnich par prispevku, pak uz je to urcite OT jak je tady normalni a ano neni normalni se ptat na takove hovadiny na pohovoru. Mel jsi je poslat do rite a cestou ven jit na jejich HR a rict jim jaky hovada tam delaji pohovory.
-
Buď to půjde nějakým fíglem s TRAILING alignmentem, nebo možná (dost pravděpodobně) taky ne a bude potřeba použít jiný layout, třeba BorderLayout.
Ty fakt máš pocit, že tohle je problém? (v životě jsem swing neviděl)
Na to si potrebuješ naštudovať GroupLayout manager, čo sú to sequenčné a paralelné grupy a musíš praxou zistiť, ako to všetko v praxi uplatniť. (Naučiť sa pravidlá šachu vs hrať úspešne šach.) Je to triviálny príklad, ale bez dlhšieho štúdia nespravíš dobrý layout. A to som výrazne pomohol tým, že som tam dal GroupLayout, pretože korektný layout vo Swingu sa dá spraviť len s ním alebo s MigLayout manažérom. Toto všetko som zistil až po mnohých mesiacoch štúdia. Napríklad, ak by sa na to niekto spýtal na stackoverflow, veľmi často dostane nesprávnu odpoveď. Ktorá síce funguje, ale nie je portabilná.
Toto nehovorím preto, že by som sa chválil. Ja som dosť starý a zrelý na to, aby som sa potreboval nad niekým vyvyšovať. Ja som Javista ty si iba PHPčkár, ja som backend programátor, ty iba frontenďák apod. Je to na ilustráciu.
private fun createLayout(vararg arg: JComponent) {
val gl = GroupLayout(contentPane)
gl.autoCreateGaps = true
gl.autoCreateContainerGaps = true
contentPane.layout = gl
gl.autoCreateContainerGaps = true
gl.setHorizontalGroup(gl.createSequentialGroup()
.addGap(5, 250, Int.MAX_VALUE)
.addPreferredGap(RELATED,
GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
.addComponent(arg[0])
.addComponent(arg[1])
)
gl.setVerticalGroup(gl.createSequentialGroup()
.addGap(5, 250, Int.MAX_VALUE)
.addPreferredGap(RELATED,
GroupLayout.DEFAULT_SIZE, Int.MAX_VALUE)
.addGroup(gl.createParallelGroup()
.addComponent(arg[0])
.addComponent(arg[1]))
)
gl.linkSize(SwingConstants.HORIZONTAL, arg[0], arg[1]);
pack()
}
Pre zaujímavosť, buttony do pravého dolného rohu sa dajú nakódiť takto.
Ak by som chcel zvoliť niečo zložitejšie, tak by som navrhol spraviť nasledovný layout:
(https://i.imgur.com/lypkvVo.png)
To je board pre monopoly. Vnútorný priestor sa mení, vonkajšie tvary sú fixné. Dosť som sa s tým potrápil.
To je v Javě nejjednodušší řešení? Před +-30 lety to bývalo v Nextstepu od dva řády jednodušší.
-
To je board pre monopoly. Vnútorný priestor sa mení, vonkajšie tvary sú fixné. Dosť som sa s tým potrápil.
Kdybyste použil webové technologie, tak by si tu hru možná někdo i zahrál. Ale nemohl byste machrovat, že znáte exotickou knihovnu.
-
To je v Javě nejjednodušší řešení? Před +-30 lety to bývalo v Nextstepu od dva řády jednodušší.
No ide to aj jednoduchšie, pomocou MigLayout manažéra:
private void initUI() {
setLayout(new MigLayout("", "[grow][]", "[grow][]"));
JButton okButton = new JButton("OK");
JButton closeButton = new JButton("Close");
add(okButton, "cell 0 1, right, sgx");
add(closeButton, "cell 1 1, sgx");
setTitle("Buttons");
setSize(280, 180);
setLocationRelativeTo(null);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
Je to externá knižnica. Korektný layout sa dá spraviť len pomocou týchto dvoch.
Otázne je, či ten NextStep spraví UI, ktoré je portabilné, t.j. UI bude rovnako dobre vyzerať na rôznych rozlíšeniach obrazoviek. Toto je kameň úrazu väčšiny layout manažérov GUI knižníc, vrátate Qt, GTK, Winforms, wxWidgets, či WPF.
-
To je v Javě nejjednodušší řešení? Před +-30 lety to bývalo v Nextstepu od dva řády jednodušší.
No ide to aj jednoduchšie, pomocou MigLayout manažéra:
private void initUI() {
setLayout(new MigLayout("", "[grow][]", "[grow][]"));
JButton okButton = new JButton("OK");
JButton closeButton = new JButton("Close");
add(okButton, "cell 0 1, right, sgx");
add(closeButton, "cell 1 1, sgx");
setTitle("Buttons");
setSize(280, 180);
setLocationRelativeTo(null);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
Je to externá knižnica. Korektný layout sa dá spraviť len pomocou týchto dvoch.
Otázne je, či ten NextStep spraví UI, ktoré je portabilné, t.j. UI bude rovnako dobre vyzerať na rôznych rozlíšeniach obrazoviek. Toto je kameň úrazu väčšiny layout manažérov GUI knižníc, vrátate Qt, GTK, Winforms, wxWidgets, či WPF.
Nextstep byl pravděpodobně prvním GUI prostředím s naprosto obecnými layouty, které šly navíc naklikat bez napsání řádky kódu. Java se ostatně v oblasti (nejen) GUI inspirovala právě Nextstepem díky tomu, že Sun koupil společnost vyvíjející pro Nextstep (tuším že se jmenovala nějak jako Lighthouse), jejíž vývojáři přenesli na tehdejší dobu velmi moderní myšlenky a postupy právě do (základní knihovny) Javy.
-
Zatiaľ dominuje Java, ale Javisti bežne využívajú aj iné jazyky.
To je hodně odvážné tvrzení. Já znám několik Java programátorů a to jsou mnohem větší konzervy než já, programující v C. Ti jsou tak tvrdě zaseklí na Javě (jazyku), že sotva ví o existencí jiných jazyků pro JVM, maximálně zaregistrovali Kotlin, jen protože kolem něj byl dost humbuk, když se stal ofiko jazykem pro droida.
-
Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka
Zatiaľ dominuje Java, ale Javisti bežne využívajú aj iné jazyky. Ale podľa mojej mienky to tam smeruje.
Všetko sa dramaticky mení, aj také veci, ktoré boli uhľovými kameňmi vývoja, sa zrazu menia. Trebárs
Servlety, jedna z najdôležitejších sfér v Jave. A prišiel Play framework, ktorý je postavený mimo servlety
a tiež si zvolil Scalu ako dominantný jazyk.
Je veľmi pravdepodobné, že Kotlin za pár rokov nahradí Javu a z Javy v podstate zostane názov pre tento
rozsiahly ekosystém.
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
-
Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
tj. java programátor je programátor, který programuje pro JVM? to by byla hodně bizarní myšlenka
Zatiaľ dominuje Java, ale Javisti bežne využívajú aj iné jazyky. Ale podľa mojej mienky to tam smeruje.
Všetko sa dramaticky mení, aj také veci, ktoré boli uhľovými kameňmi vývoja, sa zrazu menia. Trebárs
Servlety, jedna z najdôležitejších sfér v Jave. A prišiel Play framework, ktorý je postavený mimo servlety
a tiež si zvolil Scalu ako dominantný jazyk.
Je veľmi pravdepodobné, že Kotlin za pár rokov nahradí Javu a z Javy v podstate zostane názov pre tento
rozsiahly ekosystém.
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Když už si umíš napsat v Javě úplně všechno, napiš si spell checker ;) Pochybuju, že v práci vyješ :P
-
To je uhol pohľadu, resp. ako si zadefinujeme pojmy. Pretože z môjho uhla pohľadu, je framework jednoducho súbor knižníc. Napríklad Spring Boot projekt si vytvorím tak, že zadefinujem potrebné závislosti a Maven mi stiahne potrebné knižnice (u nás JAR súbory). Framework obsahuje množstvo kódu, ktorý sa v projektoch opakuje. Kto koho volá; na to v Jave máme pojem dependency injection, ale primárne nerozlišujeme podľa toho pojmy framework a knižnica. Možno to tak máte zadefinované v Haskelli.
No, já jsem reagoval na to, jak někdo někdo prohlásil, že preferuje knihovny proti frameworkům. Samozřejmě, je to otázka, jak se to nadefinuje, ale když někdo něco takového prohlásí, tak tím typicky myslí to, že se se vyrobí kód toho typu, co jsem ukázal (používá knihovny) vs. to, že napíšu "new project" a vyrobí se mi projekt o 20 souborech s předdefinovaným kódem, který následně modifikuju. Někdo (ty?) na to reagoval ve smyslu, že používat knihovny dává smysl (to samozřejmě ano), ale princip konfliktu "library vs. framework" je to, co jsem psal.
Spring je v podstatě snaha dostat se z typického frameworku zpátky na úroveň knihovny, ale třeba ty anotace mají pořád nádech frameworku.
To som nepovedal. Bolo to na ilustráciu toho, že predstava, že si zoberieš knižnicu, pozrieš si API a začneš ju
používať je nereálna. Swing bol len príklad zložitejšej knižnice. Bez dlhodobého štúdia princípov UI a Swingu to nespraví začiatočník správne. Ako spravíš Tetris hru vo Swingu? Veď je to jednoduché, zvolíš si správne triedy zavoláš tie správne metódy...
Jo, přesně tak. V čem je problém? Principy UI jsou všude stejné, liší se jenom implementace. Upřímně řečeno, poměrně dost knihoven, které používám (a dokonce i napíšu) poté promptně zapomenu. A když se vrátím k rozdílu mezi frameworkem a knihovnou, tak největší průšvih jsou právě věci typu anotace (v Haskellu je na podobně blbé úrovni makrojazyk), protože ty makra člověk musí "znát", zatímco to ostatní se dá odvodit.
Mal by to byť Haskellista. Ale odbáčaš od témy. Pointa toho, čo som povedal je, že mne sa zdá, že ty zužuješ (neviem prečo) všetko na Javu ako jazyk. Pritom Java je ekosystém s viacerými programovacími jazykmi. Tvrdíš niečo o Javistoch, hovoríš, že Java je taká a taká, pritom Java programátori môžu využívať viaceré jazyky: Java, Kotlin, Scala, Groovy, či Clojure.
Celá tahle diskuze začal tím, že OP se divil, že nemůže být brán jako C# senior programátor, když má velké zkušenosti z Javy. Na což tady někdo odpověděl, že by mohl klidně být senior programátorem v haskellu - přičemž na to jsem reagoval, že tímto směrem ne, ale opačně klidně. Dále jsme se dostali k tomu, že na to, aby někdo mohl být považován za seniora potřebuje poměrně hodně zkušeností, z nichž jen malá část je vázána na konkrétní jazyk a řešený problém.
A to "opačně klidně" je postavené na tom, že Haskell je prostě z hlediska možností jazyka někde úplně jinde než Java (i když v posledních verzích do Javy některé věci konečně začínají implementovat). Dobrý programátor je schopen programovat v jakémkoliv jazyce, akorát ten Haskell fakt zabere docela dlouho. A nikoliv proto, že by to byla spousta triviálních věcí (jako v Javě), ale protože to je fakt složité. (rozdíl ve stylu "naučit se telefonní seznam" vs. "dokázat fermatovu větu" (teda to je zase úplně jiný level, ale jen pro ilustraci)).
Na to si potrebuješ naštudovať GroupLayout manager, čo sú to sequenčné a paralelné grupy a musíš praxou zistiť, ako to všetko v praxi uplatniť. (Naučiť sa pravidlá šachu vs hrať úspešne šach.) Je to triviálny príklad, ale bez dlhšieho štúdia nespravíš dobrý layout. A to som výrazne pomohol tým, že som tam dal GroupLayout, pretože korektný layout vo Swingu sa dá spraviť len s ním alebo s MigLayout manažérom. Toto všetko som zistil až po mnohých mesiacoch štúdia. Napríklad, ak by sa na to niekto spýtal na stackoverflow, veľmi často dostane nesprávnu odpoveď. Ktorá síce funguje, ale nie je portabilná.
Já tě vůbec nechápu. Dal jsi otázku týkající se 2 knoflíků dole. Odpověděl jsem, že bych použil BorderLayout, knoflíky dát do toho PAGE_END. Zadání splněno.
To hraní s GroupLayoutem je normální řešní problému. Děláš z toho strašnou vědu. Taky znám spoustu temných zákoutí všeho možného SW, ale to prostě není podstatou toho být senior programátor. To je naopak být schopen rychle najít efektivní řešení a když na takovéhle problémy narazíš, tak je prostě vyřešit.
-
....
Vy ste ako duro mokry, ked spovedal Zicha a Laufera. Ibaze ten mokry si robil zadek :) https://www.youtube.com/watch?v=km4cF_dGAZg
-
Haskell fakt zabere docela dlouho. A nikoliv proto, že by to byla spousta triviálních věcí (jako v Javě), ale protože to je fakt složité. (rozdíl ve stylu "naučit se telefonní seznam" vs. "dokázat fermatovu větu"
Doufám, že tu nepadne ono neblahé M-slovo, nebezpečně to jím tu začíná zavánět... ???
-
fakt složité
přeháníte
-
fakt složité
přeháníte
"Složité" je relativní pojem, ale pomůže analogie. Java vs. Haskell je něco jako Pythagorova věta vs. integrace per partes.
-
fakt složité
přeháníte
"Složité" je relativní pojem, ale pomůže analogie. Java vs. Haskell je něco jako Pythagorova věta vs. integrace per partes.
Pricom integracia per partes je len tiez pouzitie vzorceka pre cvicene opice, tak isto ako pythagorova veta.
-
fakt složité
přeháníte
"Složité" je relativní pojem, ale pomůže analogie. Java vs. Haskell je něco jako Pythagorova věta vs. integrace per partes.
Pricom integracia per partes je len tiez pouzitie vzorceka pre cvicene opice, tak isto ako pythagorova veta.
Chtěl bych tě vidět, jak si odvodíš Pythagorovu větu. Většina lidí to nedá. U per partes to je ještě o několik řádů složitější. Ale chápu, že cvičená opice, která "vyvýja" (abych citoval nejpovolanějšího, tedy tebe ;)) v tom asi rozdíl nevidí.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
-
fakt složité
přeháníte
"Složité" je relativní pojem, ale pomůže analogie. Java vs. Haskell je něco jako Pythagorova věta vs. integrace per partes.
Pricom integracia per partes je len tiez pouzitie vzorceka pre cvicene opice, tak isto ako pythagorova veta.
Chtěl bych tě vidět, jak si odvodíš Pythagorovu větu. Většina lidí to nedá. U per partes to je ještě o několik řádů složitější. Ale chápu, že cvičená opice, která "vyvýja" (abych citoval nejpovolanějšího, tedy tebe ;)) v tom asi rozdíl nevidí.
Rec nebola o odvodeni, ale mozem otvorit zosit zo strednej strednej, alebo vysokej skoly. Tam taketo blbosti od nas vyzadovali. Mne zatial staci to vediet pouzivat. Vy si urcite ten haskell kodite v kazdom projekte.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
Ono s tymi scalami a kotlinmi je problem, ze to nikto nechce a pouzivaju to tak najviac startupy. Scalu by sme s kolegom pouzivali v jednom projekte, ale manazeri nam to neodsuhlasili, lebo by na to nezohnali ludi.
-
Mne zatial staci to vediet pouzivat.
Aha, čili přístup lopaty.
Vy si urcite ten haskell kodite v kazdom projekte.
Ani ne, ale FP používám.
-
Mne zatial staci to vediet pouzivat.
Aha, čili přístup lopaty.
Vy si urcite ten haskell kodite v kazdom projekte.
Ani ne, ale FP používám.
Ale ako mozete verit haskellu, ktory ste si sam nenaprogramovali a nedokazali jeho korektnost? Ved to je hereza, co ked vas niekedy zradi? Ved ste lopata.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
O Scale se tam píše? Nepíše. Když už Wikipedie, tak anglická. Mají tam seznam "esoterických" jazyků. Ale výt se dá v jakémkoliv jazyce ;)
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
O Scale se tam píše? Nepíše. Když už Wikipedie, tak anglická. Mají tam seznam "esoterických" jazyků. Ale výt se dá v jakémkoliv jazyce ;)
Co mate furt s tym vytim, dostali ste vlka?
-
Mne zatial staci to vediet pouzivat.
Aha, čili přístup lopaty.
Vy si urcite ten haskell kodite v kazdom projekte.
Ani ne, ale FP používám.
Ale ako mozete verit haskellu, ktory ste si sam nenaprogramovali
Co to je za blábol? Postrádá návaznost na linii diskuse, kterou tímto končím, protože s trollem ztrácet čas nebudu.
-
Mne zatial staci to vediet pouzivat.
Aha, čili přístup lopaty.
Vy si urcite ten haskell kodite v kazdom projekte.
Ani ne, ale FP používám.
Ale ako mozete verit haskellu, ktory ste si sam nenaprogramovali
Co to je za blábol? Postrádá návaznost na linii diskuse, kterou tímto končím, protože s trollem ztrácet čas nebudu.
Dakujem.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
O Scale se tam píše? Nepíše. Když už Wikipedie, tak anglická. Mají tam seznam "esoterických" jazyků. Ale výt se dá v jakémkoliv jazyce ;)
Co mate furt s tym vytim?
Protože píšeš v souvislosti s Javou "vyvýja", což evokuje vytí.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
O Scale se tam píše? Nepíše. Když už Wikipedie, tak anglická. Mají tam seznam "esoterických" jazyků. Ale výt se dá v jakémkoliv jazyce ;)
Co mate furt s tym vytim?
Protože píšeš v souvislosti s Javou "vyvýja", což evokuje vytí.
Tomu sa hovori preklep a stava sa to kazdemu.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala).
Všechno, čemu nerozumíš nebo nemáš intelektuálně na to se naučit, je "esoterické"? Chápeš vůbec, co to slovo znamená? Asi ne...
Tu je wikipedia:
https://sk.wikipedia.org/wiki/Ezoterizmus
O Scale se tam píše? Nepíše. Když už Wikipedie, tak anglická. Mají tam seznam "esoterických" jazyků. Ale výt se dá v jakémkoliv jazyce ;)
Co mate furt s tym vytim?
Protože píšeš v souvislosti s Javou "vyvýja", což evokuje vytí.
Tomu sa hovori preklep a stava sa to kazdemu.
Ano, stává. Ale tohle překlep? Jak blízko je na klávesnici i a y? Když chci napsat "expert", a vyleze z toho "lopata", je to šest překlepů? ;D
-
Ano, stává. Ale tohle překlep? Jak blízko je na klávesnici i a y? Když chci napsat "expert", a vyleze z toho "lopata", je to šest překlepů? ;D
Vycikat a spat, sup sup ...
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Neviem, či je Scala na ústupe. Občas vidím pracovné ponuky na Scalu s veľmi zaujímavým ohodnotením.
Čo sa týka Kotlinu, odporúčam si ho naštudovať. To nie je nový jazyk, ale v podstate evolúcia Javy.
Kotlin má obrovské množstvo drobných aj väčších zlepšení, ktoré v konečnom dôsledku neskutočne zlepšia
prácu programátora Javy. Je to vo svojej podstate Java; stále tam máš tie svoje známe triedy, trebárs
StringBuilder, či FileInputStream, akurát je tam kopec zlepšení. Je to perfektne premyslené, vidno, že nad
návrhom jazyka dlho premýšlali. Spomeniem námatkovo zabudované funkcionálne metódy do polí,
typová inferencia pri definovaní premenných (chystá sa to aj v JDK 10), šikovné metódy pre stringy
(napr padding), možnosť definovania funkciií mimo tried (!!!!!!), funkcia sa definuje pomocou slova fun a
nie function ako v JavaScripte, multi-line stringy (Java pain in the ass), možnosť rýchlej tvorby kolekcií
(Java pain in the ass), na výpis na konzolu nepotrebuješ System.out.println, ale println a hromada ďalších.
Čím viac ho študujem, tým viach nachádzam skvelých vecí...
Ja vidím budúcnosť Kotlinu dobre, podpora od JetBrains, Googlu, Pivotal (tvorca Springu). Veľmi rýchlo získal
popularitu na Androide, dnes vraj 20% nových projektov sa tvorí v Kotline. Možnosť tvorby DSL v Kotline
je geniálna, a ak by Kotlin nahradil JavaScript na frontende, tak to máme večné lovištia na zemi...
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Čo sa týka Kotlinu, odporúčam si ho naštudovať.
Monády to má?
-
Nextstep byl pravděpodobně prvním GUI prostředím s naprosto obecnými layouty, které šly navíc naklikat bez napsání řádky kódu. Java se ostatně v oblasti (nejen) GUI inspirovala právě Nextstepem díky tomu, že Sun koupil společnost vyvíjející pro Nextstep (tuším že se jmenovala nějak jako Lighthouse), jejíž vývojáři přenesli na tehdejší dobu velmi moderní myšlenky a postupy právě do (základní knihovny) Javy.
Nekúpil NextStep Steve Jobs? Pôvodné layout manažéry boli síce flexibilné, ale mali zásadnú chybu: rozostupy medzi komponentami boli natvrdo definované v pixeloch. Takto sa výzor aplikácie rozbije pri rôznych veľkostiach monitorov.
Medzeri musia byť nadefinované v relatívnych mierkach, napr. milimetroch, tzv. logických pixeloch, alebo odvodené od veľkosti fontu. A to správne robia len dva manažéry: GroupLayout (ktorý pretlačili do Javy programátori z NetBeans) a MigLayout. (Práca jedného švédskeho programátora. Je zaujímavé, že tú istú chybu spravili aj pri JavaFX, znova tie zabudované manažéry natvrdo definujú veľkosť medzier v pixeloch.
Monády to má?
Ako externý modul.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Neviem, či je Scala na ústupe. Občas vidím pracovné ponuky na Scalu s veľmi zaujímavým ohodnotením.
Čo sa týka Kotlinu, odporúčam si ho naštudovať. To nie je nový jazyk, ale v podstate evolúcia Javy.
Kotlin má obrovské množstvo drobných aj väčších zlepšení, ktoré v konečnom dôsledku neskutočne zlepšia
prácu programátora Javy. Je to vo svojej podstate Java; stále tam máš tie svoje známe triedy, trebárs
StringBuilder, či FileInputStream, akurát je tam kopec zlepšení. Je to perfektne premyslené, vidno, že nad
návrhom jazyka dlho premýšlali. Spomeniem námatkovo zabudované funkcionálne metódy do polí,
typová inferencia pri definovaní premenných (chystá sa to aj v JDK 10), šikovné metódy pre stringy
(napr padding), možnosť definovania funkciií mimo tried (!!!!!!), funkcia sa definuje pomocou slova fun a
nie function ako v JavaScripte, multi-line stringy (Java pain in the ass), možnosť rýchlej tvorby kolekcií
(Java pain in the ass), na výpis na konzolu nepotrebuješ System.out.println, ale println a hromada ďalších.
Čím viac ho študujem, tým viach nachádzam skvelých vecí...
Ja vidím budúcnosť Kotlinu dobre, podpora od JetBrains, Googlu, Pivotal (tvorca Springu). Veľmi rýchlo získal
popularitu na Androide, dnes vraj 20% nových projektov sa tvorí v Kotline. Možnosť tvorby DSL v Kotline
je geniálna, a ak by Kotlin nahradil JavaScript na frontende, tak to máme večné lovištia na zemi...
Njn, tak Dart, TypeScript, node.js, a nevim jaké ještě přístupy, aby se nemuselo psát v netypovaném blbém jazyku (rozumněj JS), neuspěly (resp. uspěly, někde, bohužel), a teď by to měl být Kotlin? Ano, možná ano, protože hlavně umožní nepsat ty netypované sr.nce v JS a navíc vygenerovat i java bytecode, ale nevím jestli se chci vzdát psaní čisté javy, jen proto, že existuje JS ... fakt ho nemám rád :D
-
Nextstep byl pravděpodobně prvním GUI prostředím s naprosto obecnými layouty, které šly navíc naklikat bez napsání řádky kódu. Java se ostatně v oblasti (nejen) GUI inspirovala právě Nextstepem díky tomu, že Sun koupil společnost vyvíjející pro Nextstep (tuším že se jmenovala nějak jako Lighthouse), jejíž vývojáři přenesli na tehdejší dobu velmi moderní myšlenky a postupy právě do (základní knihovny) Javy.
Nekúpil NextStep Steve Jobs?
Jobs ho prodal Applu.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Čo sa týka Kotlinu, odporúčam si ho naštudovať.
Monády to má?
Ne, i když přes ty generika to "nějak" jde naimplementovat (je to trošku lepší než přímo v javě, ale ne o moc). Nicméně chystají se implementovat typeclassy, což bych řekl, že velmi výrazně zvýší použitelnost. Kybychom se časem dočkali i nějakého operátoru pro "bind" a "return", tak by to bylo fakt fajn.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Čo sa týka Kotlinu, odporúčam si ho naštudovať.
Monády to má?
Ne, i když přes ty generika to "nějak" jde naimplementovat (je to trošku lepší než přímo v javě, ale ne o moc). Nicméně chystají se implementovat typeclassy, což bych řekl, že velmi výrazně zvýší použitelnost. Kybychom se časem dočkali i nějakého operátoru pro "bind" a "return", tak by to bylo fakt fajn.
Typeclassy jen pro restrikci funktorů nebo plnohodnotné HKT?
-
Celá tahle diskuze začal tím, že OP se divil, že nemůže být brán jako C# senior programátor, když má velké zkušenosti z Javy. Na což tady někdo odpověděl, že by mohl klidně být senior programátorem v haskellu - přičemž na to jsem reagoval, že tímto směrem ne, ale opačně klidně. Dále jsme se dostali k tomu, že na to, aby někdo mohl být považován za seniora potřebuje poměrně hodně zkušeností, z nichž jen malá část je vázána na konkrétní jazyk a řešený problém.
Tá narážka na Haskell mala byť irónia, ktorú som tiež takto nepochopil. Ale OP spravil chybu podľa mňa, že očakával hneď seniórnu pozíciu, resp. plat. Mal ukázať, že sa vie na začiatok uskromniť a po roku že dokáže byť prínosom ako senior. Takže človek by mal na začiatok nastúpiť s menšími očakávaniami a dokázať po čase, že na to má byť seniórnym programátorom. A podľa môjho názoru to môže trvať dosť dlho, kým sa adaptuje. Najkratšia cesta je asi medzi C#/NET a Java/Spring. Avšak predsa je tam veľa väčších i menších rozdielov, múch, špecifík, ktoré treba zvládnuť.
Já tě vůbec nechápu. Dal jsi otázku týkající se 2 knoflíků dole. Odpověděl jsem, že bych použil BorderLayout, knoflíky dát do toho PAGE_END. Zadání splněno.
To hraní s GroupLayoutem je normální řešní problému. Děláš z toho strašnou vědu. Taky znám spoustu temných zákoutí všeho možného SW, ale to prostě není podstatou toho být senior programátor. To je naopak být schopen rychle najít efektivní řešení a když na takovéhle problémy narazíš, tak je prostě vyřešit.
Príklad z BorderLayout bude fungovať, ale nebude 100% korektný. UI sa rozbije sa pri rôznych rozlíšeniach. BorderLayout totiž nastavuje medzery medzi kompentami v pixeloch, čo je neportabilné. Tá veda okolo toho nie je samoúčelná, to realita je komplexná. A práve tu su tie finesy, ktoré prídu až rokmi skúseností.
Alebo načítanie textu v Jave, nájdeme si triedu, FileReader, super, akurát že táto trieda má menší nedostatok, že natvrdo berie typ kódovania z JVM, čo je chyba. Preto túto triedu netreba používať, ale ísť inou cestou. Pokiaľ všetky tieto úskalia nemá Haskell/C# programátor vychytané, ako môže byť seniorom v Java projekte a viesť mladších programátorov, opravovať ich, hovoriť im, ako to korektne a správne majú naprogramovať?
Uzavieranie databázových connections v Jave je taká Švejkova Budějovická anabaze. Všetky tutoriály na čele s tými v Oracle, Microsoft a MySQL, plus Stackoverflow odpoveďami to ukazujú zle, resp veľmi zle. Jak sa z toho nejavista má vysomáriť?
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Čo sa týka Kotlinu, odporúčam si ho naštudovať.
Monády to má?
Ne, i když přes ty generika to "nějak" jde naimplementovat (je to trošku lepší než přímo v javě, ale ne o moc). Nicméně chystají se implementovat typeclassy, což bych řekl, že velmi výrazně zvýší použitelnost. Kybychom se časem dočkali i nějakého operátoru pro "bind" a "return", tak by to bylo fakt fajn.
Typeclassy jen pro restrikci funktorů nebo plnohodnotné HKT?
Vypadá, to že HKT. https://github.com/Kotlin/KEEP/pull/87 (https://github.com/Kotlin/KEEP/pull/87) Aspoň z té diskuze to tak vypadá.
-
To je super, ze chvalite ezotericky jazyk, ktory uz je na ustupe (scala). Lebo aj tak sa vyvyja uplne inak. Vacsinou v browseri react a na serveri microservices pomocou spring boot. Spring boot ide do kopy aj s kotlinom, takze si aj startupisti na 2 roky uziju, nez kotlin zakape, a nahradi ho dalsie frikulinstvo.
Čo sa týka Kotlinu, odporúčam si ho naštudovať.
Monády to má?
Ne, i když přes ty generika to "nějak" jde naimplementovat (je to trošku lepší než přímo v javě, ale ne o moc). Nicméně chystají se implementovat typeclassy, což bych řekl, že velmi výrazně zvýší použitelnost. Kybychom se časem dočkali i nějakého operátoru pro "bind" a "return", tak by to bylo fakt fajn.
Typeclassy jen pro restrikci funktorů nebo plnohodnotné HKT?
Vypadá, to že HKT. https://github.com/Kotlin/KEEP/pull/87 (https://github.com/Kotlin/KEEP/pull/87) Aspoň z té diskuze to tak vypadá.
To vypadá slibně. Skoro jako ve Swiftu.
-
Tá narážka na Haskell mala byť irónia, ktorú som tiež takto nepochopil. Ale OP spravil chybu podľa mňa, že očakával hneď seniórnu pozíciu, resp. plat. Mal ukázať, že sa vie na začiatok uskromniť a po roku že dokáže byť prínosom ako senior. Takže človek by mal na začiatok nastúpiť s menšími očakávaniami a dokázať po čase, že na to má byť seniórnym programátorom.
S tím celkem souhlasím - něco ve stylu "vzhledem ke zkušenostem na to mám, tuhle technologii neznám, ale rychle se ji naučím, za 2 měsíce uvidíme" by mi taky přišlo docela normální.
Príklad z BorderLayout bude fungovať, ale nebude 100% korektný. UI sa rozbije sa pri rôznych rozlíšeniach. BorderLayout totiž nastavuje medzery medzi kompentami v pixeloch, čo je neportabilné. Tá veda okolo toho nie je samoúčelná, to realita je komplexná. A práve tu su tie finesy, ktoré prídu až rokmi skúseností.
Alebo načítanie textu v Jave, nájdeme si triedu, FileReader, super, akurát že táto trieda má menší nedostatok, že natvrdo berie typ kódovania z JVM, čo je chyba.
S tímhle přístupem ale žádného senior programátora neseženeš, protože každý projekt používá specifické komponenty, které mají podobné záludnosti. Takže tohle je spíš otázka, kde říct "tohle se dá snadno naučit". Konec konců, pokud někdo v různých jazycích četl ze souboru, tak otázka "v jakém kódování se to načte" by ho třeba i mohla napadnout. A pokud je to serverová část, tak se samozřejmě dá požadavek, že JVM poběží s nastaveným default kódováním na UTF-8. A pokud dělal v nějaké moderní aplikaci nějaké UI, tak otázka "jak se specifikují pixel-independent velikosti" je taky poměrně normální.
Preto túto triedu netreba používať, ale ísť inou cestou. Pokiaľ všetky tieto úskalia nemá Haskell/C# programátor vychytané, ako môže byť seniorom v Java projekte a viesť mladších programátorov, opravovať ich, hovoriť im, ako to korektne a správne majú naprogramovať?
Jednoduše. Koupí si nějakou knížku ve stylu "advanced java programming", "spring" apod., za 14 dní se přes těch 1200 stránek prožvejká a může začít. Pokud je senior v daném oboru, jen používá jiný jazyk/knihovny, tak to pro něj bude jednoduché čtení, kde je akorát si potřeba všímat nějakých specifik. A ti junioři toho neumí mnohem víc, než zrovna jazyk a framework.
-
Preto túto triedu netreba používať, ale ísť inou cestou. Pokiaľ všetky tieto úskalia nemá Haskell/C# programátor vychytané, ako môže byť seniorom v Java projekte a viesť mladších programátorov, opravovať ich, hovoriť im, ako to korektne a správne majú naprogramovať?
Jednoduše. Koupí si nějakou knížku ve stylu "advanced java programming", "spring" apod., za 14 dní se přes těch 1200 stránek prožvejká a může začít. Pokud je senior v daném oboru, jen používá jiný jazyk/knihovny, tak to pro něj bude jednoduché čtení, kde je akorát si potřeba všímat nějakých specifik. A ti junioři toho neumí mnohem víc, než zrovna jazyk a framework.
Kupim si haskell za 7 dni. V googli uz si chystaju benefity, ako ma budu hyckat. Ovladam scheme, tak to bude dost easy.
(Pre lepsie chapavych, je to zasa ironia)
-
Jednoduše. Koupí si nějakou knížku ve stylu "advanced java programming", "spring" apod., za 14 dní se přes těch 1200 stránek prožvejká a může začít. Pokud je senior v daném oboru, jen používá jiný jazyk/knihovny, tak to pro něj bude jednoduché čtení, kde je akorát si potřeba všímat nějakých specifik. A ti junioři toho neumí mnohem víc, než zrovna jazyk a framework.
Zhrnul by som potrebnú literatúru. Prvú knihu, ktorú by som odporučil a ktorá sa medzičasom stala klasikou je Effective Java 400 strán. Obsahuje presne takého tipy pre správne programovanie. Základné API, Java: The Complete Reference, 1300 strán. Pre dobrý úvod do Springu máme dve Biblie, referenčnú príručku a tutoriál, Pro Spring 5 a Spring 5 recipes, obe po 800 strán. Hibernate tips 250 strán. Java EE tutoriál pre základné pojmy a prehľad tvorby enterprise aplikácií v Jave, 1200 strán.
Spolu to máme 400 + 1300 + 800 + 800 + 250 + 1200 = 4750
K tomu online tutoriály Spring Guides, RestEasy alebo Jersey tutoriál pre REST, Maven alebo Gradle guide. V neposlednom rade by sa bolo potrebné pozhovárať s viacerými skúsenými Javistami, pretože veľa vecí existuje len v hlavách skúsených programátorov, ako kolektívne vedomie a nedá sa to dohľadať.
-
Zhrnul by som potrebnú literatúru. Prvú knihu, ktorú by som odporučil a ktorá sa medzičasom stala klasikou je Effective Java 400 strán. Obsahuje presne takého tipy pre správne programovanie. Základné API, Java: The Complete Reference, 1300 strán. Pre dobrý úvod do Springu máme dve Biblie, referenčnú príručku a tutoriál, Pro Spring 5 a Spring 5 recipes, obe po 800 strán. Hibernate tips 250 strán. Java EE tutoriál pre základné pojmy a prehľad tvorby enterprise aplikácií v Jave, 1200 strán.
Spolu to máme 400 + 1300 + 800 + 800 + 250 + 1200 = 4750
K tomu online tutoriály Spring Guides, RestEasy alebo Jersey tutoriál pre REST, Maven alebo Gradle guide. V neposlednom rade by sa bolo potrebné pozhovárať s viacerými skúsenými Javistami, pretože veľa vecí existuje len v hlavách skúsených programátorov, ako kolektívne vedomie a nedá sa to dohľadať.
Dobře, tak 3 týdny. Uvědom si, že celá Java jsou známé koncepty jenom v jiné syntaxi, takže effective java je prostě easy. Z referenčních příruček je primárně potřeba si přečíst věci relevantní k tomu, co budu dělat, a to dost orientačně. Hibernate je prostě "další ORM v řadě".
Pro balkiho: přechod Haskell -> Java je v tom stylu, že dáš houslistovi violu. Samozřejmě se vždycky najde spousta lidí, který začnou vykládat, jak potřebuješ roky praxe, znalost repertoáru (knihoven...), tu správnou violovu techniku a tón.. Ve skutečnosti se na to dobrý houslista za měsíc naučí. Přechod Java -> Haskell je jako když klarinetistovi řekneš, aby zahrál na housle. Možná za 5 let. (haskell je v tomhle jednodušší....)
-
Jednoduše. Koupí si nějakou knížku ve stylu "advanced java programming", "spring" apod., za 14 dní se přes těch 1200 stránek prožvejká a může začít. Pokud je senior v daném oboru, jen používá jiný jazyk/knihovny, tak to pro něj bude jednoduché čtení, kde je akorát si potřeba všímat nějakých specifik. A ti junioři toho neumí mnohem víc, než zrovna jazyk a framework.
Zhrnul by som potrebnú literatúru. Prvú knihu, ktorú by som odporučil a ktorá sa medzičasom stala klasikou je Effective Java 400 strán. Obsahuje presne takého tipy pre správne programovanie. Základné API, Java: The Complete Reference, 1300 strán. Pre dobrý úvod do Springu máme dve Biblie, referenčnú príručku a tutoriál, Pro Spring 5 a Spring 5 recipes, obe po 800 strán. Hibernate tips 250 strán. Java EE tutoriál pre základné pojmy a prehľad tvorby enterprise aplikácií v Jave, 1200 strán.
Spolu to máme 400 + 1300 + 800 + 800 + 250 + 1200 = 4750
K tomu online tutoriály Spring Guides, RestEasy alebo Jersey tutoriál pre REST, Maven alebo Gradle guide. V neposlednom rade by sa bolo potrebné pozhovárať s viacerými skúsenými Javistami, pretože veľa vecí existuje len v hlavách skúsených programátorov, ako kolektívne vedomie a nedá sa to dohľadať.
Čím víc přehánění, tím víc cool?
-
Čím víc přehánění, tím víc cool?
Nie, to vôbec nie je preháňanie. Náročnosť Javy a v podstate každého veľkého enterprise projektu tkvie v rozsiahlosti znalostí potrebných pre dokončenie projektu. Javista (obvykle, niektoré projekty sú určite tiež také) nerieši nejaké zložité logické problémy, či brutálne algoritmy - musí vedieť veľmi veľa. Pretože tá realita je náročná a komplexná. A to som nespomenul frontend (o ktorom musí mať senior minimálne prehľad, aby vedel zhodnotiť či použiť React, Vue, či Angular, alebo niečo iné), bezpečnosť, otázky continuous delivery, či messagingu a ďalších.
Čo si myslíte, koľko znalostí musí mať stavebný inžinier alebo advokát/prokurátor? Keď mi ukazovali technicky tie hrubé knihy, ktorými sa museli prelúskať, tak ma chytila závrať. Taký advokát musí prejsť desiatkami tisíc strán zložitých právnych dokumentov, analýz, paragrafov...
Prelúskať tých necelých 5000 strán pre pokročilejšieho kódera z iného jazyka, stacku nie je oproti tomu podľa mňa až tak veľa.
-
Čím víc přehánění, tím víc cool?
Prelúskať tých necelých 5000 strán pre pokročilejšieho kódera z iného jazyka, stacku nie je oproti tomu podľa mňa až tak veľa.
No právě, dá se to poměrně rychle, pokud už člověk má přehled v oboru a zkušenosti z něčeho podobného. Nakonec se tu všichni shodneme :) (kromě "balíka", to je ztracený případ pro Chocholouška)
-
Čím víc přehánění, tím víc cool?
Prelúskať tých necelých 5000 strán pre pokročilejšieho kódera z iného jazyka, stacku nie je oproti tomu podľa mňa až tak veľa.
No právě, dá se to poměrně rychle, pokud už člověk má přehled v oboru a zkušenosti z něčeho podobného. Nakonec se tu všichni shodneme :) (kromě "balíka", to je ztracený případ pro Chocholouška)
To je tak, na roote "bla bla", ale realita je uplne ina. Povedzme, ze by taky clovek nejakym zazrakom presiel cez pohovor na Java seniora.(Co by nepresiel) Dostal by do ruky projekt "Na pracuj" + nejakych juniorov, ktorych by mal pod palcom a len by tapal.
-
Čím víc přehánění, tím víc cool?
Prelúskať tých necelých 5000 strán pre pokročilejšieho kódera z iného jazyka, stacku nie je oproti tomu podľa mňa až tak veľa.
No právě, dá se to poměrně rychle, pokud už člověk má přehled v oboru a zkušenosti z něčeho podobného. Nakonec se tu všichni shodneme :) (kromě "balíka", to je ztracený případ pro Chocholouška)
To je tak, na roote "bla bla", ale realita je uplne ina. Povedzme, ze by taky clovek nejakym zazrakom presiel cez pohovor na Java seniora.(Co by nepresiel) Dostal by do ruky projekt "Na pracuj" + nejakych juniorov, ktorych by mal pod palcom a len by tapal.
jdi otravovat jinam, čobolotrollo ;)
-
Čím víc přehánění, tím víc cool?
Prelúskať tých necelých 5000 strán pre pokročilejšieho kódera z iného jazyka, stacku nie je oproti tomu podľa mňa až tak veľa.
No právě, dá se to poměrně rychle, pokud už člověk má přehled v oboru a zkušenosti z něčeho podobného. Nakonec se tu všichni shodneme :) (kromě "balíka", to je ztracený případ pro Chocholouška)
To je tak, na roote "bla bla", ale realita je uplne ina. Povedzme, ze by taky clovek nejakym zazrakom presiel cez pohovor na Java seniora.(Co by nepresiel) Dostal by do ruky projekt "Na pracuj" + nejakych juniorov, ktorych by mal pod palcom a len by tapal.
jdi otravovat jinam, čobolotrollo ;)
Ospravedlnujem sa, ze vam kazim silacke reci realitou.
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
Na jazyce jako takovém není super nic, ale když ho prosazuje Google...
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
- nějakou syntaktickou podporu "bind" pro Option typ
- sealed classes (což by se mělo snad dát použít jako sum type)
- je to schopné (nějak) kompilovat do JS
- typový systém s type inference a type erasure (do čehož možná dodělají ty typeclassy, takže pak už by to mohlo být použitelné)
Taky mi prozatím nepřijde, že by to přinášelo tolik, aby mělo smysl to použít místo Javy. Ale zatím jsem v tom taky nic nenapsal..
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
- sealed classes (což by se mělo snad dát použít jako sum type)
Jak?
-
A to som nespomenul frontend (o ktorom musí mať senior minimálne prehľad, aby vedel zhodnotiť či použiť React, Vue, či Angular, alebo niečo iné), bezpečnosť, otázky continuous delivery, či messagingu a ďalších.
Heh, to by mě zajímalo, jak někdo zhodnotí, zda použít React, Vue, Angular nebo něco jiného... (teda kromě toho, že tohle jsou JS technologie, ne Java). Odhadci ceny prý používají 2 metody - okenní a palcovou. Tady to bude asi tak totéž...
Nedávno tady někdo psal do threadu, co má sakra použít, aby to za 3 roky nebylo v žumpě a když v tom je ten projekt napsaný, aby se to nemuselo za 5 let znova přepisovat. Nedostal odpověď (taky by mě zajímala). Byla už tahle iterace frameworků konečná, nebo to za 5 let bude úplně někde jinde? Taky mám svoji sbírku projektů.... 10 let staré - jQuery, 5 let staré - AngularJS... bojím se začít další. Je dost možné, že přijde WebAssembly a celý slavný JS s velkou slávou (a radostí) hodíme se všema těma frameworkama do koše.
To skoro vypadá, že ten senior by měl znát úplně všechno .... zpaměti... a ještě k tomu umět věštit budoucnost...Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
- sealed classes (což by se mělo snad dát použít jako sum type)
Jak?
https://kotlinlang.org/docs/reference/sealed-classes.html (https://kotlinlang.org/docs/reference/sealed-classes.html)
-
A to som nespomenul frontend (o ktorom musí mať senior minimálne prehľad, aby vedel zhodnotiť či použiť React, Vue, či Angular, alebo niečo iné), bezpečnosť, otázky continuous delivery, či messagingu a ďalších.
To skoro vypadá, že ten senior by měl znát úplně všechno .... zpaměti... a ještě k tomu umět věštit budoucnost...
A mít 30 let praxe.
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
Nuž treba to začať študovať hlbšie a začať si v tom programovať príklady; nestačí sa len dívať na dokumentáciu. Skúsený Javista začne po chvíli vidieť výhody Kotlinu. Čím viac ho študujem, tým viac vidím tie desiatky a stovky drobných zlepšení, ktoré v konečnom synergickom efekte nesmierne zlepšujú tvorbu kódu.
package com.zetcode;
import java.util.ArrayList;
import java.util.List;
public class JavaEx {
public static void main(String[] args) {
List<String> words = new ArrayList<>();
words.add("pen");
words.add("dog");
words.add("pencil");
words.forEach(word -> System.out.println(word));
}
}
Zoberme si jednoduchý príklad v Jave a obdobný v Kotline.
package com.zetcode
fun main(args: Array<String>) {
val words = listOf("pen", "pencil", "dog")
words.forEach { word -> println(word) }
}
Kotlin umožňuje používanie funkcií, v Jave máme len metódy, t.j. nemusíme pri definovaní funkcie vždy vytvoriť triedu.
V príklade vidíme, že nepoužívame bodkočiarku (ala Python) na ukončenie príkazu. Máme literálový zápis na tvorbu
menších zoznamov, čo bolo jedným z najväčších pain in the ass Javy pre mňa. Pre výpis na konzolu používame println oproti zdĺhavému System.out.println.
Typová inferencia pri premennej words. (Chystá sa pre Javu 10.) Kotlin nemá ten debilný statický kontext, ktorý len prinášal viac problémov ako osohu. Kotlin má citlivo zvolená názvoslovie, mne sa proste najviac páči kľúčové slovo fun, oproti function (príliš dlhé), fn, def a pod. To isté pri val, oveľa viac mi to sedí ako const (JavaScript).
package com.zetcode;
public class JavaEx {
public static void main(String[] args) {
System.out.println(max(4, 5));
}
public static int max(int x, int y) {
if (x > y) {
return x;
} else {
return y;
}
}
}
package com.zetcode
fun main(args: Array<String>) {
println(max(30, 40))
}
fun max(x: Int, y: Int) : Int = if (x > y) x else y
if je v Kotline výraz, čo nám umožňuje použiť ho ako priradenie na pravej strane. Je to jedným z tých bezpočet malých zlepšení. Kotlin ďalej odbremení programátora od rozdielu medzi primitívnymi a objektovými dátovými typmi.
Viacriadkové reťazce, napríklad pri veršoch.
package com.zetcode;
public class JavaEx {
public static void main(String[] args) {
String sonnet = "Not marble, nor the gilded monuments\n" +
"Of princes, shall outlive this powerful rhyme;\n" +
"But you shall shine more bright in these contents\n" +
"Than unswept stone, besmear'd with sluttish time.\n" +
"When wasteful war shall statues overturn,\n" +
"And broils root out the work of masonry,\n" +
"Nor Mars his sword nor war's quick fire shall burn\n" +
"The living record of your memory.\n" +
"'Gainst death and all-oblivious enmity\n" +
"Shall you pace forth; your praise shall still find room\n" +
"Even in the eyes of all posterity\n" +
"That wear this world out to the ending doom.\n" +
"So, till the judgment that yourself arise,\n" +
"You live in this, and dwell in lovers' eyes.\n";
System.out.println(sonnet);
}
}
V Jave musíme zdĺhavo sčítať reťazce, použiť znak nového riadku. Nevyzerá to bohvie ako.
package com.zetcode
fun main(args: Array<String>) {
val sonnet = """
Not marble, nor the gilded monuments
Of princes, shall outlive this powerful rhyme;
But you shall shine more bright in these contents
Than unswept stone, besmear'd with sluttish time.
When wasteful war shall statues overturn,
And broils root out the work of masonry,
Nor Mars his sword nor war's quick fire shall burn
The living record of your memory.
'Gainst death and all-oblivious enmity
Shall you pace forth; your praise shall still find room
Even in the eyes of all posterity
That wear this world out to the ending doom.
So, till the judgment that yourself arise,
You live in this, and dwell in lovers' eyes.
"""
println(sonnet.trimIndent())
}
Kotlin to zjednodušuje výrazne, navyše elegantne jednou metódou odstráni vytvorené odsadenie. Podobne to má Python, ale oproti Kotlinu v Pythone musíme použiť navyše importovať funkciu z modulu.
Takto by som mohol pokračovať dlho. Tie zlepšenie nemajú konca, neustále narážam na nové a nové skvelé veci. Ako hovorím, seasoned Java programátor si veľmi rýchlo uvedomí, ako ohromne zlepší Kotlin prácu Java programátora.
Samostatnou kapitolou sú Kotlin DSL, ktoré takéto zlepšenia umožnia pre knižnice a výrazne zlepšia prácu s SQL, UI, súbormi atď.
No a ak by sa podarilo nahradiť JavaScript Kotlinom...
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
package com.zetcode
fun main(args: Array<String>) {
println(max(30, 40))
}
fun max(x: Int, y: Int) : Int = if (x > y) x else y
a kdyby to mělo fungovat pro jakýkoliv typ s definovanou operací "větší než"?
-
a kdyby to mělo fungovat pro jakýkoliv typ s definovanou operací "větší než"?
https://stackoverflow.com/questions/6452313/how-to-implement-a-generic-maxcomparable-a-comparable-b-function-in-java
Pokud v Kotlinu zavedou typeclassy, tak se to možná zjednoduší. Nebo taky ne. Otázka, jaký typ by vlastně mělo mít "max (A, B)", kde jedno je potomkem druhého, není zrovna triviální.
Nuž treba to začať študovať hlbšie a začať si v tom programovať príklady; nestačí sa len dívať na dokumentáciu. Skúsený Javista začne po chvíli vidieť výhody Kotlinu. Čím viac ho študujem, tým viac vidím tie desiatky a stovky drobných zlepšení, ktoré v konečnom synergickom efekte nesmierne zlepšujú tvorbu kódu.
Ano, implementují tam jakž takž věci, které jsou v FP světě běžné a zkušený Javista zjišťuje, že to má smysl.. bohužel narvat FP na Javu je někdy trochu problém (obávám se, že neschopnost tail-call optimalizace se začne s více FP dost projevovat), takže je to občas trochu přes ruku. Takže třeba výroba builderu sice vyžaduje tohle (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-dsl-marker/index.html), ale aspoň nějak to jde...
-
Ano, implementují tam jakž takž věci, které jsou v FP světě běžné a zkušený Javista zjišťuje, že to má smysl.. bohužel narvat FP na Javu je někdy trochu problém (obávám se, že neschopnost tail-call optimalizace se začne s více FP dost projevovat), takže je to občas trochu přes ruku.
Nie je všetko len o funkcionálnom programovaní, x vecí sa týka syntaxe, OOP a iných.
Ak niekomu nevyhovuje úroveň FP v Kotline, nech si zvolí Scalu alebo Clojure. Máme viacero programovacích paradigiem, ale žiadny z nich nie je ten najlepší. Ja by som teda nechcel teda vytvárať Swing aplikáciu v Clojure, hoci to ide.
-
Diky Jano7 za shrnuti, je to jak jsem si myslel, Kotlin je par syntaktickych cukriku, jinak to k nicemu neni.
Tvuj prvni priklad bych v Jave napsal:
String[] str = {"pen","dog","pencil"};
List<String> strL = Arrays.asList(str);
strL.forEach(word -> System.out.println(word));
A hned to vypada lip, co? A ten prevod na List delam jenom proto, aby sla pozit lambda, jinak se da samozrejme pracovat primo se String[]
Druhy priklad, nevim co je tak spatneho na staticke metode, proste budu mit tridu Functions a v ni sadu statickych metod pouzivanych jako funkce.
V realu bych ja osobne zkratka nechal Springem via @Autowired injektovat bean v defaultnim singleton scope, kde bude bezna nestaticka metoda
public int max(int x, int y) {
return x > y ? x : y;
}
Posledni prikad je uz uplny nesmysl, basne nemaji v kodu co delat, ty se nacitaji z resources.
A pokud precejen neco takoveho potrebuju, pres CTRL C+V vlozim do Eclipse, ktery to automaticky zformatuje do potrebneho traru vcetne potrebnych escape sekvenci.
-
Pravda, muj examplik s porovnavanim cisel neni genericky, nekdo vys na toto pouzkazal, oprava:
public <T extends Comparable<T>> T max(T x, T y) {
return x.compareTo(y)>0 ? x : y;
}
-
Co je na kotlinu tak super? Koukl jsem se jim na stránku a nevidím jediný důvod proč se to učit.
Nuž treba to začať študovať hlbšie a začať si v tom programovať príklady; nestačí sa len dívať na dokumentáciu. Skúsený Javista začne po chvíli vidieť výhody Kotlinu. Čím viac ho študujem, tým viac vidím tie desiatky a stovky drobných zlepšení, ktoré v konečnom synergickom efekte nesmierne zlepšujú tvorbu kódu.
package com.zetcode;
import java.util.ArrayList;
import java.util.List;
public class JavaEx {
public static void main(String[] args) {
List<String> words = new ArrayList<>();
words.add("pen");
words.add("dog");
words.add("pencil");
words.forEach(word -> System.out.println(word));
}
}
Zoberme si jednoduchý príklad v Jave a obdobný v Kotline.
package com.zetcode
fun main(args: Array<String>) {
val words = listOf("pen", "pencil", "dog")
words.forEach { word -> println(word) }
}
.....
Hele, ja nejsem Java guru, ani ji moc zrovna v lasce nemam, ale tohle nejsou dobre priklady:
Arrays.asList("pen", "pencil", "dog").forEach(System.out::println);
BinaryOperator<Integer> max = (x, y) -> x > y ? x : y;
System.out.println(max.apply(4, 5));
Jinak ano, stringy jsou fakt pain v Jave, to fakt nechapu proc se s tim neco neudelalo zatim.
-
Sakra, pozde, trochu jsem se opakoval. Sry, @Jano7 nicemene vidis sam z ruznych zdroju, ze se to da napsat i jinak.
Jo to kdyby Kotlin rozsiril pouziti generik, coz by znamenalo, ze by nejspis bylo potreba poladit trochu type erasure - z druhe strany si nemusi tahnout kouli na noze... tak to by bylo jiny.
-
To v žiadnom prípade nebolo zhrnutie, len maličká ukážka. Tých zlepšení sú stovky, možno tisíce. Aj keby šlo len o syntactic sugar, tak zefektívnenie je obrovské.
A hned to vypada lip, co? A ten prevod na List delam jenom proto, aby sla pozit lambda, jinak se da samozrejme pracovat primo se String[]
Mne to nikdy lepšie nepripadalo, vždy mi to klalo oči.
Berme, že potrebujeme mať zoznam, teda dynamicky meniť jeho veľkosť. Nikdy ti neprišlo divné použiť Arrays triedu na tvorbu zoznamu? To už radšej použijem Guavu. To keď vidí trebárs Python, Ruby programátor, tak sa musí udivene pýtať: ty na tvorbu zoznamu vytvoríš (úplne inú kolekciu) pole a potom zavoláš statickú metódu Arrays, aby si to previedol na zoznam?
nums = [1, 2, 3, 4, 5]
Tak sa to robí v Ruby/Pythone ...
Druhy priklad, nevim co je tak spatneho na staticke metode, proste budu mit tridu Functions a v ni sadu statickych metod pouzivanych jako funkce.
Je omnoho elegantnejšie mať možnosť definovať funckcie, ako používať statické metódy. Niet divu, že Java sa neujala medzi matematikmi.
...vlozim do Eclipse..
Nemyslíš vážne. :o Používaš Eclipse?
package com.zetcode
class Car(var name: String, var price: Int) {
override fun toString(): String {
return "Car(name='$name', price=$price)"
}
}
fun main(args: Array<String>) {
val cars = listOf(Car("Mercedes", 23400), Car("Toyota", 28900))
cars.forEach { car -> println(cars) }
}
Ďalšie elegancia, ďalšie skrátenie kódu. Ak nepoužijeme class bez modifikátora, máme automaticky public. Výrazná úspora pri gettroch a settroch. Ďalšia zjednodušenie toString metódy. Netreba použiť new pri tvorbe objektu.
package com.zetcode
fun main(args: Array<String>) {
println(alphabet());
}
fun alphabet() = StringBuilder().apply {
for (letter in 'a'..'z') {
append("$letter ")
}
}.toString()
Funkcia apply umožní takto čarovať. Máme range operátor. Ďalej zabudovaný string interpolation nám umožní práve v takýchto maličkostiach zjednodušiť kód: potrebujem medzeru medzi písmanami. Príklad sa ešte ďalej dá zjednodušiť pomocou zabudovanej buildString standardnej Kotlin funkcie.
-
Hele, ja nejsem Java guru, ani ji moc zrovna v lasce nemam, ale tohle nejsou dobre priklady:
Arrays.asList("pen", "pencil", "dog").forEach(System.out::println);
Ako som už spomínal vyššie, toto neberiem. Vytvárať zoznam pomocou poľa nie je kóšer.
Ale akurát mi napadlo, že od Javy 9 sa to dá spraviť elegantnejšie:
package com.zetcode;
import java.util.List;
public class JavaEx {
public static void main(String[] args) {
List<String> words = List.of("pen", "pencil", "dog");
// od JDK 10
//var words = List.of("pen", "pencil", "dog");
words.forEach(word -> System.out.println(word));
}
}
OK, takže oproti Jave 9 má Kotlin v tomto prípade len menšie zlepšenia, ale má.
BinaryOperator<Integer> max = (x, y) -> x > y ? x : y;
System.out.println(max.apply(4, 5));
OK, aj to je možnosť. Kotlin verzia je však kratšia a podľa mňa elegantnejšia.
-
Stream.of("pen", "pencil", "dog").forEach(System.out::println)
-
takhle se mi zatím prezentované jazyky jeví strašně ukecané a neelegantní
-
Stream.of("pen", "pencil", "dog").forEach(System.out::println)
Tu nešlo o výpis troch stringov na konzolu, ale o chýbajúci literálový, alebo podobný skrátený zápis inicializácie menšieho zoznamu.
Niečo na štýl Pythonovho
words = ["pen", "pencil", "dog"]
Vyriešila to až Java 9 s týmto:
List<String> words = List.of("pen", "pencil", "dog");
-
Hele, ja nejsem Java guru, ani ji moc zrovna v lasce nemam, ale tohle nejsou dobre priklady:
Arrays.asList("pen", "pencil", "dog").forEach(System.out::println);
Ako som už spomínal vyššie, toto neberiem. Vytvárať zoznam pomocou poľa nie je kóšer.
Co si myslis, ze je na pozadi toho ArrayListu, nebo listu, ktery vytvaris? Tvuj argument je zcela lichy. Nedelas nic jineho, nez cos psal ty. Jenomze to napises jinym zpusobem.
BinaryOperator<Integer> max = (x, y) -> x > y ? x : y;
System.out.println(max.apply(4, 5));
OK, aj to je možnosť. Kotlin verzia je však kratšia a podľa mňa elegantnejšia.
Jak kratsia? Jako myslis to, ze pisu System.out.prinln misto println? Nebo to ze pisu max.apply(...) misto max(...) ? Mas tam navic else, takze to je nastejno. :) Ano uznavam, ze tohle je v jave divny a vubec ty lambdy jsou takove divne oproti c++, ale na Java svet to funguje dobre.
-
Obvykle právě seznam k ničemu nepotřebuješ. Pro mě Kotlin také moc výhod nemá.
Ale jak píšeš, Java 9 má další vychytávky a dnes je 9 už standard, za dveřmi je 10 s dalším menším nášupem. Není důvod se domnívat, že cokoli nad JVM bude lepší než Java. Kompletně jiný jazyk a ekosystém ale možná ano.
-
Stream.of("pen", "pencil", "dog").forEach(System.out::println)
Tu nešlo o výpis troch stringov na konzolu, ale o chýbajúci literálový, alebo podobný skrátený zápis inicializácie menšieho zoznamu.
Niečo na štýl Pythonovho
words = ["pen", "pencil", "dog"]
Vyriešila to až Java 9 s týmto:
List<String> words = List.of("pen", "pencil", "dog");
Funkcionální konstrukty v Javě vypadají blbě a ukecaně, ale stejně se moc nepoužívají, tak to je asi jedno. Když FP nad JVM, tak Scalu.
-
Ano, obvykle pouzivam Eclipse. Tedy presneji Spring Tool Suite.
A osobne Eclipse hatery nechapu, dnes se IDE pouziva jako editor a spoustec pro Maven a GIT client, je vicemene jedno co se pouzije.
Jinak co se tyce examplu s cenami aut tak:
package pkg;
public class Car {
private String name;
private int price;
/**
* @param name
* @param price
*/
public Car(String name, int price) {
super();
this.name = name;
this.price = price;
}
@Override
public String toString() {
return "Car [name=" + name + ", price=" + price + "]";
}
public String getName() {
return name;
}
public int getPrice() {
return price;
}
}
Z vyse uvedeneho datoveho beanu jsem napsal pouze ty dva radky s name a price. Zbytek vygeneroval Eclipse:
- Nejprve Create new Class
- Pak ty moje 2 radky s atributy
- Generate constructor using fields
- Generate getters and setters
- Generate toString()
Atributy jsou samozrejme private s gettery, to je zaklad slusneho code stylu, do getteru si muzu dat pripadne debug hook, nebo jej udelat synchronized, pokud bude potreba. Samozrejme by slo mit atributy public, nedoporucuju. Atribut bez pristupoveho modifikatoru je v Jave tzv. package-private - tedy maji k nemu pristup classy ze stejne package.
Boilerplate vubec nijak nevadi, kazdy vi k cemu slouzi datovy bean, vsechny sedi v bean specific package a jedine zajimave jsou ty dva radky s definici atributu.
Zavolani v kodu:
Arrays.asList(new Car("Mercedes", 23400), new Car("Toyota", 28900)).forEach(System.out::println);
-
Přesně jak jsem čekal, škrtám kotlin ze seznamu jazyků na prohlédnutí.