mboost-dp1
GWT
http://tech.dayzipping.com/using-gwt-to-build-a-la...
og til windcapes yndlings aversion mod GWT:
http://supplychaintechnology.wordpress.com/2010/06...
og til windcapes yndlings aversion mod GWT:
http://supplychaintechnology.wordpress.com/2010/06...
Jeg undre mig stadigvæk over hvad Google ser i værktøjet.
Forresten
Man skal altså væbne sig med tålmodighed (og kaffe), samt helst have færdigdesignet sine sider før man begiver sig i kast med GWT.
For Ruby/Python/PHP/ASP.NET udviklere bliver GWT hurtigt en meget fustrende oplevelse.
Forresten
Note that Google has created a development mode so that you don't have to compile your project until you deploy.Det er et plugin til Firefox og Google Chrome (kom først til Chrome senere). I Firefox låser pluginet så hele browseren ned mens ens side loader i hotswap-mode.
Man skal altså væbne sig med tålmodighed (og kaffe), samt helst have færdigdesignet sine sider før man begiver sig i kast med GWT.
For Ruby/Python/PHP/ASP.NET udviklere bliver GWT hurtigt en meget fustrende oplevelse.
Mange værktøjer bruges. Vi bruger også nogle elendige SAP værktøjer på arbejde, som slet ikke ville give mening at bruge i dag.arne_v (3) skrev:Det er jo ikke kun Google - det bruges faktisk.
Men GWT giver bare ikke mening. Der er ingen fordele i forhold til andre mvc/mvp-frameworks i andre sprog. Kun ulemper.
Windcape (4) skrev:Mange værktøjer bruges. Vi bruger også nogle elendige SAP værktøjer på arbejde, som slet ikke ville give mening at bruge i dag.
Men GWT giver bare ikke mening.
Der er der jo så nogen som er uenige.
Både med hensyn til GWT og SAP.
Windcape (4) skrev:Der er ingen fordele i forhold til andre mvc/mvp-frameworks i andre sprog. Kun ulemper.
Det kan evt. skyldes at GWT ikke et et MVC/MVP framework!
Windcape (2) skrev:For Ruby/Python/PHP/ASP.NET udviklere bliver GWT hurtigt en meget fustrende oplevelse.
Nu har jeg ikke selv arbejdet med GWT, men efter hvad jeg kan læse mig til så er den primære målgruppe Java-udviklere, hvorfor der er forståeligt at det bliver frustrerende for udviklere der mangler kendskab dertil..
OT: GWT lyder spændende. Jeg burde afprøve det en af dagene, så jeg kan se hvad det kan bruges til.
Det har samme formål! At skabe hjemmesider med nem AJAX integration.arne_v (5) skrev:Det kan evt. skyldes at GWT ikke et et MVC/MVP framework!
Problemet er bare at det kræver mere kode, mere debugging, og mere hovedpine, end hvis man lavede det i hvilket somhelst andet sprog/framework.
Jeg har arbejdet med Java siden 2004. Cirka 3½ år længere tid end C#.tazimn (6) skrev:hvorfor der er forståeligt at det bliver frustrerende for udviklere der mangler kendskab dertil..
Det er fusterende fordi det er så elendigt at arbejde med. Det er langsomt og meningsløst. Du skriver 10 gange så meget boilerplate kode, frem for hvis du skrev det i rent JavaScript.
GWT har kun ét formål, og det er at undgå at man skal omskole sine Java programmører til at lære JavaScript.
#8
GWT er et frontend framework. Så det eneste du kan genbruge er koden som i forvejen er modulær.
Men GWT er så uendeligt langt bagud udviklingsmæssigt. Det et forsøg på at lave noget ala. ASP.NET 1.1.
Hvilket passer meget godt. Java lever stadigvæk i 2003! Og noget tyder på at det, og dets brugere, ikke har lyst til at gå videre.
GWT er et frontend framework. Så det eneste du kan genbruge er koden som i forvejen er modulær.
Men GWT er så uendeligt langt bagud udviklingsmæssigt. Det et forsøg på at lave noget ala. ASP.NET 1.1.
Hvilket passer meget godt. Java lever stadigvæk i 2003! Og noget tyder på at det, og dets brugere, ikke har lyst til at gå videre.
Windcape (7) skrev:Det har samme formål! At skabe hjemmesider med nem AJAX integration.
Det er så ikke formålet med MVC/MVP.
Hvilket burde være åbenlyst udfra den kendsgerning at MVC er ældre end AJAX (også selvom vi antager MVC i web kontekst).
Windcape (7) skrev:GWT har kun ét formål, og det er at undgå at man skal omskole sine Java programmører til at lære JavaScript.
Det er jo ikke korrekt.
GWT betyder også:
- mere type sikker udvikling (Java er mere type sikkert end JavaScript)
- indkapsling af det browser specifikke ved at dette håndteres i den genererede JavaScript
- bedre debugging muligheder
tazimn (8) skrev:Skal det forstås på den måde at det ikke er muligt at tage eksisterende kode og bruge GWT på? Men at de skal skrives påny?
Først skal du lige gøre dig klart hvordan GWT fungerer.
Du skriver en app i Java med brug af GWT library, GWT compileren oversætter dette til JavaScript (med håndtering af forskelle mellem IE, FF etc.), brugeren kører denne JavaScript client side.
Du kan ikke genbruge din eksisterende JavaScript kode.
Du kan genbruge diverse Java kode du måtte have udviklet gennem årene.
Windcape (9) skrev:Men GWT er så uendeligt langt bagud udviklingsmæssigt. Det et forsøg på at lave noget ala. ASP.NET 1.1.
ASP.NET 1.1 web forms er et komponent baseret ren server side framework.
GWT er et client side strongly typed AJAX framework.
To meget forskellige ting.
Hvilket understreges af at du kan lave en web app som bruger ASP.NET 1.1 web forms server side og GWT client side.
Du kan faktisk også gøre det med nyere ASP.NET web forms og ASP.NET MVC, men da nyere ASP.NET kommer med noget AJAX ville det være et mystisk valg.
Hvilket er hamrende ligegyldigt til frontend udvikling alligevel. GWT gør det mere besværligt end det burde være.arne_v (10) skrev:- mere type sikker udvikling (Java er mere type sikkert end JavaScript)
Man har jo alligevel strong-typing på serversiden, så man kan sagtens undgå dem client-side.
Det gør det også hvis du bruger JQuery eller Prototype. Frameworks der har eksisteret lang tid før GWT!arne_v (10) skrev:- indkapsling af det browser specifikke ved at dette håndteres i den genererede JavaScript
Desværre bare ikke sandt. Debugging mulighederne gennem Eclipse er smertefuldt. Og client-side debugging som f.eks. Firebug, virker slet ikke.arne_v (10) skrev:- bedre debugging muligheder
En alm. løsning hvor man selv skrev alt JavaScript, og så kunne bruge Firebug fuldt ud, giver meget bedre debugging muligheder.
Nej!arne_v (12) skrev:Hvilket understreges af at du kan lave en web app som bruger ASP.NET 1.1 web forms server side og GWT client side.
Hele ideen med GWT er at du automatisk integerer server og clientside.
At bruge GWT som "frontend" oven på et eksisterende servicelag, er direkte idioti.
Windcape (13) skrev:Hvilket er hamrende ligegyldigt til frontend udvikling alligevel.
Det er der jo så delte meninger om. Folk bruger både Java og C# til dette formål.
Windcape (13) skrev:Man har jo alligevel strong-typing på serversiden, så man kan sagtens undgå dem client-side.
Fejl i den JavaScript der kører client side bliver ikke fanget compile type fordi server side koden bliver compilet i et static strong typed sprog.
Windcape (13) skrev:Det gør det også hvis du bruger JQuery eller Prototype. Frameworks der har eksisteret lang tid før GWT!
GWT er ikke den eneste løsning på browser kompabilitets problemet.
Men derfor er det jo stadigvæk en af de ting som GWT leverer.
Windcape (13) skrev:Desværre bare ikke sandt. Debugging mulighederne gennem Eclipse er smertefuldt.
Det er igen en af de ting som folk faktisk bruger.
Windcape (13) skrev:En alm. løsning hvor man selv skrev alt JavaScript, og så kunne bruge Firebug fuldt ud, giver meget bedre debugging muligheder.
Igen er GWT ikke de eneste løsning, men det er stadigvæk noget som GWT tilbyder.
Windcape (14) skrev:Hele ideen med GWT er at du automatisk integerer server og clientside.
Nej.
Ideen er GWT er at skrive Java og generere JavaScript.
Windcape (14) skrev:At bruge GWT som "frontend" oven på et eksisterende servicelag, er direkte idioti.
Nej.
Det hedder god software arkitektur.
Det er ikke godt at have 2 tiers (client side AJAX "app" og server side services) så tæt koblet.
Du definerer de services der skal udstilles, så implementerer du dem server side og laver client kode som kalder dem.
Så kan:
AJAX "app"-------services
nemt udvides til:
AJAX "app"-----------|
smartphone app-----|-----services
anden server---------|
(f.eks. et REST API hvor det er muligt at angive om man vil have data som JSON eller XML)
#16
Grunden til det er idioti, er fordi at du kunne gøre det med ren JavaScript, på cirka. 2000% mindre kode.
Med din argumentation for GWT, kunne man jo ligeså godt bruge COBOL til at skrive Java i!
Men lad da GWT endeligt blive brugt at fjolser som er for dumme til at lære JavaScript.
Grunden til det er idioti, er fordi at du kunne gøre det med ren JavaScript, på cirka. 2000% mindre kode.
Med din argumentation for GWT, kunne man jo ligeså godt bruge COBOL til at skrive Java i!
Men lad da GWT endeligt blive brugt at fjolser som er for dumme til at lære JavaScript.
Windcape (17) skrev:#16
Grunden til det er idioti, er fordi at du kunne gøre det med ren JavaScript, på cirka. 2000% mindre kode.
Med din argumentation for GWT, kunne man jo ligeså godt bruge COBOL til at skrive Java i!
Men lad da GWT endeligt blive brugt at fjolser som er for dumme til at lære JavaScript.
Er dit største problem med GWT ikke nærmere at det ikker kommer fra Microsoft? Du lader til at have en aversion mod alt der ikke kommer der fra. Og som ikke lugter en smule af .net
#18
Nej, problemet med GWT er at det er idioti. Jeg har nævnt andre sprog som ville give ligeså fleksible og mindre boilerplate orientede løsninger.
RoR er et pragteksempel på noget som udfører GWTs funktionalitet med en fraktion af kodemængden, og uden 10minutters kompilationspauser.
Jeg har jo faktisk arbejdet med GWT. I samarbejde med Systematic udviklede vi et system i GWT (bla. for at prøve GWT som teknologi af), der integerer med en af deres eksisterende løsninger til kommunikation i forsvaret.
Og .NETs "framework" til AJAX, AJAX.NET er noget lort. Selv Microsoft har indset at det ikke var populært, så de begyndte at shippe JQuery med ASP.NET MVC.
Jeg synes også AJAX.NET er noget lort. Men modsat GWT skulle jeg ikke vente minutter på at kompilere, og jeg skulle heller ikke bruge et ustabilt browser-plugin for at kunne lave hotswap af kode.
Nej, problemet med GWT er at det er idioti. Jeg har nævnt andre sprog som ville give ligeså fleksible og mindre boilerplate orientede løsninger.
RoR er et pragteksempel på noget som udfører GWTs funktionalitet med en fraktion af kodemængden, og uden 10minutters kompilationspauser.
Jeg har jo faktisk arbejdet med GWT. I samarbejde med Systematic udviklede vi et system i GWT (bla. for at prøve GWT som teknologi af), der integerer med en af deres eksisterende løsninger til kommunikation i forsvaret.
Og .NETs "framework" til AJAX, AJAX.NET er noget lort. Selv Microsoft har indset at det ikke var populært, så de begyndte at shippe JQuery med ASP.NET MVC.
Jeg synes også AJAX.NET er noget lort. Men modsat GWT skulle jeg ikke vente minutter på at kompilere, og jeg skulle heller ikke bruge et ustabilt browser-plugin for at kunne lave hotswap af kode.
Windcape (17) skrev:Grunden til det er idioti, er fordi at du kunne gøre det med ren JavaScript, på cirka. 2000% mindre kode.
Hvis vi lige ignorerer den lille finesse at 2000% mindre kode ikke er muligt fordi kode mængde ikke kan være negative.
Så er det nok et af de steder, hvor forskellen i tilgang til tingene viser sig.
GWT drejer sig ikke om mindre kode men om mere robust kode som er nemmere at vedligeholde.
Hvis man skal skrive 25 web pages til det lokale serie 11 fodbold hold, så er projektet ikke større end at det at skrive koden udgør en stor del af projektets tid, og hvis der er en JavaScript fejl så skidt pyt.
Google's GWT projekter er af en anden vægt klasse. De er meget store, så det er en meget lille del af tiden som faktisk bruges på at indtaste kode. Og fordi der er millioner af brugere, så skal det helst virke 99.99%.
Windcape (17) skrev:Med din argumentation for GWT, kunne man jo ligeså godt bruge COBOL til at skrive Java i!
????
Fordi at man foretrækker et static typed strong typed OO sprog over et dynamic typed weak types OO sprog så skulle man foretrække et foretrækker et static typed strong typed proceduralt sprog over et foretrækker et static typed strong typed OO sprog?
Det er der ingen samenhæng i.
Windcape (17) skrev:Men lad da GWT endeligt blive brugt at fjolser som er for dumme til at lære JavaScript.
Det står dig jo frit for at tro at store firmaer som f.eks. Google, Northrop Grumman, Raytheon, Dell vælger at bruge GWT fordi deres ansatte ikke kan lære JavaScript.
Men helt ærligt synes jeg ikke at det virker troværdigt.
(og hvis man tilføjer dem som bruger GWT via Vaadin så er der endnu flere f.eks. Nordea)
Ja, Eclipse er det eneste IDE man kan bruge GWT hotswap i.Hubert (20) skrev:Jeg vil gætte på at du har været nødt til at bruge eclipse? Det er næppe noget der passer ind i din .net fikserede verden. :)
Og at Eclipse er et elendigt IDE er en helt anden diskussion. Men GWT mere platformsuafhænging end .NET. Faktisk var det indtil starten af 2009, kun muligt at udvikle GWT med Eclipse og Firefox!
I 2009 blev det så muligt at også bruge Google Chrome.
Jeg er uenig i påstanden om at Java er nemmere at vedligeholde end JavaScript.arne_v (21) skrev:GWT drejer sig ikke om mindre kode men om mere robust kode som er nemmere at vedligeholde.
Så synes jeg ikke du har forstået brugen af GWT. GWT og RoR er næsten identiske. Eller AJAX.NET for den sags skyld.arne_v (22) skrev:Jeg synes virkeligt ikke det giver meget mening at samnenligne GWT med et server side framework.
Omdrejningspunktet for både Ruby on Rails og GWT er at du har scaffolding til UI konstruktion, og en direkte integration mellem serverside-services som kaldes via. AJAX, og UI delen.
Fordelen er at du så slipper for at skrive en masse kode for at kalde diverse serverside services med AJAX, og derefter skulle deserializere det retunede data (f.eks. XML eller JSON), og tilpasse UI delen herefter.
F.eks. laver du en knap, som så kalder en data-model, og henter en række informationer ud, og derefter opdatere en liste med det givne data.
GWT og Rails har præcist samme tilgang til måden at gøre det på. Hvor f.eks. ASP.NET MVC benytter en mere service-orienteret tilgang ved at expose data fra controller metoder som f.eks. JSON, og så bruger man JQuery til at hente, og opdateren UI delen.
Men GWT er modsat fra RoR, ikke "rapid".
Windcape (25) skrev:
Omdrejningspunktet for både Ruby on Rails og GWT er at du har scaffolding til UI konstruktion,
Det er en af de vigtige dele af RoR.
Men så vidt jeg ved er det slet ikke en del af GWT.
Der findes tools som kan lave scaffolding med GWT frontend - MyEclipse for Spring er en kendt mulighed.
Windcape (24) skrev:Faktisk var det indtil starten af 2009, kun muligt at udvikle GWT med Eclipse og Firefox!
Hvor får du de mærkelige ideer fra?
Du har hele tiden kunne udvikle GWT apps i enhver IDE eller editor (inkl. Notepad) som du måtte ønske.
GWT kommer med alle de nødvendige tools to command line build eller integration i en IDE/editor som tillader dette.
Dette er og var dokumenteret i den medfølgende dokumentation.
#28
Det var så direkte en løgn.
Tilbage i "the good 'ol GWT days", omkring version 1.0-1.6, har du ret i at man brugte deres "Hosted Mode"-browser, som var baseret på firefox.
Så meget er vi enige i.
Men man kunne sagtens bruge en anden editor (IntelliJ, Netbeans eller andet) og eksekvere hosted mode browseren i debug mode, for at step-debugge igennem koden.
At du skal bruge 10 minutter på at debugge / rette en GWT UI brugergrænseflade fortæller mere om din uvidenhed om teknologien, end GWT's mangler.
Hvis vi så skal tale lidt om sløve browser plugins, så har du ret i at det ikke er den fulde, native javascript eksekveringshastighed man oplever, når man eksekverer sin GWT app i hosted mode. Det har nok noget at gøre med at processen om at cross-kompilere Java til JavaScript er en meget tung opgave. Min Quad Core Xeon Workstation, med 12 GB RAM, kan maxe CPU utilization ud på alle cores, når man cross-kompiler, så det forklarer nok noget om hvorfor hosted-mode eksekvering ikke føles "snappy".
Hvis du virkeligt synes det er tungt at lave GWT udvikling, vil jeg anbefale dg at kigge på Spring Roo, så bliver det vist ikke lettere at udvikle web 2.0 apps.
Det var så direkte en løgn.
Tilbage i "the good 'ol GWT days", omkring version 1.0-1.6, har du ret i at man brugte deres "Hosted Mode"-browser, som var baseret på firefox.
Så meget er vi enige i.
Men man kunne sagtens bruge en anden editor (IntelliJ, Netbeans eller andet) og eksekvere hosted mode browseren i debug mode, for at step-debugge igennem koden.
At du skal bruge 10 minutter på at debugge / rette en GWT UI brugergrænseflade fortæller mere om din uvidenhed om teknologien, end GWT's mangler.
Hvis vi så skal tale lidt om sløve browser plugins, så har du ret i at det ikke er den fulde, native javascript eksekveringshastighed man oplever, når man eksekverer sin GWT app i hosted mode. Det har nok noget at gøre med at processen om at cross-kompilere Java til JavaScript er en meget tung opgave. Min Quad Core Xeon Workstation, med 12 GB RAM, kan maxe CPU utilization ud på alle cores, når man cross-kompiler, så det forklarer nok noget om hvorfor hosted-mode eksekvering ikke føles "snappy".
Hvis du virkeligt synes det er tungt at lave GWT udvikling, vil jeg anbefale dg at kigge på Spring Roo, så bliver det vist ikke lettere at udvikle web 2.0 apps.
Nej. Pointen var netop at det nemt tager 10 minutter at kompilere en GWT applikation.Corholio (29) skrev:At du skal bruge 10 minutter på at debugge / rette en GWT UI brugergrænseflade fortæller mere om din uvidenhed om teknologien, end GWT's mangler.
Så hvis du ikke kan køre hotswap af kode i "Hosted Mode", så er du nød til at vente.
Og som du selv sagde, så var Firefox eneste mulighed indtil Google Chrome kom. Og Chrome låste ikke hele browseren ned under loading, modsat Firefox.
Ja. Og jeg undre mig over at Java udviklere ikke finder det et problem. De er måske vant til at alting er langsomt og sløvt, så de kan hente ekstra kaffe?Corholio (29) skrev:Hvis vi så skal tale lidt om sløve browser plugins, så har du ret i at det ikke er den fulde, native javascript eksekveringshastighed man oplever, når man eksekverer sin GWT app i hosted mode.
Alt er nemmere end hvilketsomhelst Java baserede web-framework.Corholio (29) skrev:Hvis du virkeligt synes det er tungt at lave GWT udvikling, vil jeg anbefale dg at kigge på Spring Roo, så bliver det vist ikke lettere at udvikle web 2.0 apps.
Hele tankegangen bag Java's webframeworks synes at være 5-10 år bagud i forhold til resten af scenen.
Windcape (31) skrev:Nej. Pointen var netop at det nemt tager 10 minutter at kompilere en GWT applikation.
Så er det heldigt at man har Hosted mode, så man ikke skal kompilere hele koden hver gang man laver en mindre ændring.
Windcape (31) skrev:Og som du selv sagde, så var Firefox eneste
mulighed indtil Google Chrome kom. Og Chrome låste ikke hele browseren ned under loading, modsat Firefox.
Hvorfor nævner du ikke at Hosted mode også kører i Internet Explorer?
Windcape (31) skrev:Ja. Og jeg undre mig over at Java udviklere ikke finder det et problem. De er måske vant til at alting er langsomt og sløvt, så de kan hente ekstra kaffe?
Nu ved jeg ikke med dig, men jeg kan ikke nå at hente kaffe på 3 sekunder, jeg ved ikke hvad der burde tage flere minutter i udviklingsprocessen (altså lige pånær compile eller deploy).
Windcape (31) skrev:Alt er nemmere end hvilketsomhelst Java baserede web-framework.
Ja, din mor, f.eks! - Okay, latterlig humoristisk udtalelse... men den er lige så relevant som din troll-like udtalelse.
Windcape (31) skrev:Hele tankegangen bag Java's webframeworks synes at være 5-10 år bagud i forhold til resten af scenen.
Tjah... eftersom der ikke er kommet nye funktioner til Java i de sidste hvad 5-6 år, så kan det vel meget godt passe at det ikke kan lave samme tricks som moderne sprog (og tilhørende frameworks). Det gør nu hverken frameworks eller sproget dårligere eller mindre produktivt.
Så du har ingen erfaring med andet end Java?Corholio (32) skrev:Det gør nu hverken frameworks eller sproget dårligere eller mindre produktivt.
Det kan slet ikke lade sig gøre at være produktiv i Java når det handler om webudvikling. Folk der tror det er desillusioneret, og mangler erfaring med andre sprog og frameworks.
Corholio (32) skrev:
Tjah... eftersom der ikke er kommet nye funktioner til Java i de sidste hvad 5-6 år, så kan det vel meget godt passe at det ikke kan lave samme tricks som moderne sprog (og tilhørende frameworks).
Java SE har holdt en lang pause.
6 - released December 2006
7 - forventet sommer 2011
Men Java EE hvorunder web udvikling hører har ikke haft samme pause:
5 - released May 2006
6 - released December 2009
7 - forventet vinter 2012/2013
Plus alt der som sker udenfor JCP regi:
* GWT
* Wicket
* Sling
etc.
#33
Jo, har erfaring med PHP, ASP (classic), Grails (Groovy), Python og en smule Ruby.
Er begyndt at udvikle i ASP.net (okay, er stadigvæk i begyndelse af indlæringskurven), og jeg ser ikke at det er nært så fantastisk, som du gør det til. Udviklingsmiljøet er så skræmmende handicappet og ikke de 7000 kroner værd som man skal betale for det. Konfigurering af Webserver og database er uintuitivt og reddes kun af det faktum at Powershell kan benyttes (så man ikke får en museskade, den første uge).
Men jeg glæder mig da til at jegbliver lige så snæversynet ser lyset, som du har.
Jo, har erfaring med PHP, ASP (classic), Grails (Groovy), Python og en smule Ruby.
Er begyndt at udvikle i ASP.net (okay, er stadigvæk i begyndelse af indlæringskurven), og jeg ser ikke at det er nært så fantastisk, som du gør det til. Udviklingsmiljøet er så skræmmende handicappet og ikke de 7000 kroner værd som man skal betale for det. Konfigurering af Webserver og database er uintuitivt og reddes kun af det faktum at Powershell kan benyttes (så man ikke får en museskade, den første uge).
Men jeg glæder mig da til at jeg
#36
Husk at produktivitet ikke er lig med funktionalitet per linie kode, det handler også om maintainability.
Sjovt.... for jeg skal ikke købe et 3rd party plugin for at få acceptabel refactoring support.
*host* R# og Visual Studio *host*
Husk at produktivitet ikke er lig med funktionalitet per linie kode, det handler også om maintainability.
Windcape (36) skrev:Og hvis det er noget der er handicappet, så er det Eclipse.
Sjovt.... for jeg skal ikke købe et 3rd party plugin for at få acceptabel refactoring support.
*host* R# og Visual Studio *host*
#37
Jeg giver ikke noget for påstanden om at store Java applikationer med 10 gange mere kode end tilsvarende i f.eks. Ruby, er mere maintainable.
Men okay, Java udviklerne var også dem som mente at lambda expressions og closures var det modsatte af maintainable clean code.
Så konklusionen må jo være at Java udviklere er dumme, og derfor har svært ved at se fordelen i andre sprog?
Jeg giver ikke noget for påstanden om at store Java applikationer med 10 gange mere kode end tilsvarende i f.eks. Ruby, er mere maintainable.
Men okay, Java udviklerne var også dem som mente at lambda expressions og closures var det modsatte af maintainable clean code.
Så konklusionen må jo være at Java udviklere er dumme, og derfor har svært ved at se fordelen i andre sprog?
#38
Det siger jeg heller ikke noget om, jeg prøver at lave en pointe om at statiske typestærke sprog er lettere at vedligeholde end dynamiske reflektive sprog som ruby. Dog har dynamiske sprog den styrke at de tillader at lave applikationer meget hurtigt, på bekostning af maintainibility.
Sjovt, for lamda expressions er jo faktisk en del af det feature-set der kommer i Java 8... så jeg er ikke helt sikker på hvilke Java udviklere du hentyder til? (der er ALTID nogle personer der kæmper imod forandringer)
Godtaget... såfremt jeg må antage at prik-NET udviklere er arrogante, bedrevidende studerende, der har svært ved at acceptere andre producenter, af softwareudviklingsværktøjer, end dem fra Redmond-området.
Windcape (38) skrev:Jeg giver ikke noget for påstanden om at store Java applikationer med 10 gange mere kode end tilsvarende i f.eks. Ruby, er mere maintainable.
Det siger jeg heller ikke noget om, jeg prøver at lave en pointe om at statiske typestærke sprog er lettere at vedligeholde end dynamiske reflektive sprog som ruby. Dog har dynamiske sprog den styrke at de tillader at lave applikationer meget hurtigt, på bekostning af maintainibility.
Windcape (38) skrev:Men okay, Java udviklerne var også dem som mente at lambda expressions og closures var det modsatte af maintainable clean code.
Sjovt, for lamda expressions er jo faktisk en del af det feature-set der kommer i Java 8... så jeg er ikke helt sikker på hvilke Java udviklere du hentyder til? (der er ALTID nogle personer der kæmper imod forandringer)
Windcape (38) skrev:Så konklusionen må jo være at Java udviklere er dumme, og derfor har svært ved at se fordelen i andre sprog?
Godtaget... såfremt jeg må antage at prik-NET udviklere er arrogante, bedrevidende studerende, der har svært ved at acceptere andre producenter, af softwareudviklingsværktøjer, end dem fra Redmond-området.
Windcape (38) skrev:Men okay, Java udviklerne var også dem som mente at lambda expressions og closures var det modsatte af maintainable clean code.
Det er faktisk vedtaget at de skal i Java 8.
Der har været meget diskussion om dem.
Både om hvorcidt det var en god ide og hvis ja hvordan de så skulle implementeres.
Og det er der god grund til - hvis ikke man meget nøje overvejer hvad der virkeligt giver værdi i forhold til den ekstra kompleksitet med hensyn til nye features i et sprog, så ender sproget med at være alt for bloatet.
ALGOL, PL/I og Ada døde eller blev aldrig hvad de kunne være blevet p.g.a. dette.
Python og Ruby er også strong typed. Derfor må din påstand være invalid.Corholio (39) skrev:jeg prøver at lave en pointe om at statiske typestærke sprog er lettere at vedligeholde end dynamiske reflektive sprog som ruby. Dog har dynamiske sprog den styrke at de tillader at lave applikationer meget hurtigt, på bekostning af maintainibility.
Java ender alt for hurtig i et xml-konfigurationshelvede, så jeg har derfor svært ved at se hvordan det overhovedet kan kaldes "maintainable".
Nu har C# jo helt fint bevist at lambda expressions (og expression trees), er et supergodt værktøj der gør hverdagen nemmere, og koden mere letlæselig og maintainable.arne_v (40) skrev:hvis ikke man meget nøje overvejer hvad der virkeligt giver værdi i forhold til den ekstra kompleksitet med hensyn til nye features i et sprog, så ender sproget med at være alt for bloatet.
Men så igen, Java nægter jo at få inspiration fra andre sprog. Og da slet ikke C#. Microsoft jo onde!!!
Windcape (42) skrev:Python og Ruby er også strong typed. Derfor må din påstand være invalid.
Da Python og Ruby ikke er static strong typed, så er hans påstand helt valid.
Windcape (42) skrev:Java ender alt for hurtig i et xml-konfigurationshelvede, så jeg har derfor svært ved at se hvordan det overhovedet kan kaldes "maintainable".
Det er faktisk meget nemmere at tilrette 1 XML fil end at skal ind of tilrette annotations (attributter i .NET terminologi) i X klasser.
Windcape (42) skrev:Nu har C# jo helt fint bevist at lambda expressions (og expression trees), er et supergodt værktøj der gør hverdagen nemmere, og koden mere letlæselig og maintainable.
Nu er det lidt tidligt at udtale sig om effekten på maintainability, men det ser ganske fornuftigt ud.
Og derfor vil man da også gerne have det i Java.
Windcape (42) skrev:Men så igen, Java nægter jo at få inspiration fra andre sprog. Og da slet ikke C#.
Java 5,6,7,8 er da blevet en del inspireret af .NET og C#.
Windcape (36) skrev:#35
Hvis du har erfaring med overstående og stadigvæk finder dig selv produktiv i Java, så tvivler jeg på dine evner i python og ruby.
Og hvis det er noget der er handicappet, så er det Eclipse.
Det afhænger vel af hvilket behov man har? Hvis jeg skal kunne skrive noget kode på alle mine maskiner og jeg synes det kunne være rart at bruge det samme IDE er VS ikke en mulighed. Eclipse er.
Allerede her er det VS der er handikappet og ikke Eclipse.
Set lidt fra side linjen af så virker det mest som om at du ikke bryder dig om Eclipse fordi det ikke kommer fra MS. At det ikke understøtter .net kan du ikke just bruge som undskyldning mere selvom der ikke er support for den nyeste .net så er der muligheder...
arne_v (46) skrev:#45
Nant virker fremragende.
Emonic plugin til Eclipse virker men ihvertfald seneste officielle release 0.4 er lidt tynd i funktionalitet.
Og det skulle understøtte nyeste version af .NET - artiklen fra IBM er nok fra før 4.0 blev releaset.
Ja artiklen er meget gammel. Den her helt tilbage fra 22/4 08 så der er uden tvivl sket meget siden da.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund