mboost-dp1
Sun
Super godt at Sun endelig får gjort noget ved denne kæmpe mangel. 10 år for sent er bedre end aldrig. En simpel og ligetil løsning som den i C# ville være at foretrække. Sådan set burde de bare tilføje den udvidelse til Java sproget som Microsoft blev sagsøgt for at lave for 10 år siden.
Jeg håber at de kan nå at få syntax for properties med i forslaget også, så vi endelig kan slippe af med 'getters' og 'setters'.
I øvrigt er den korrekte term sådan set 'lambda funktioner' og ikke 'closures'. Closures har Java allerede i form a anonyme klasser.
Jeg håber at de kan nå at få syntax for properties med i forslaget også, så vi endelig kan slippe af med 'getters' og 'setters'.
I øvrigt er den korrekte term sådan set 'lambda funktioner' og ikke 'closures'. Closures har Java allerede i form a anonyme klasser.
LordMike (3) skrev:Hvad er en 'Closure'?...
If you don't know it, you don't need it, you don't need to know it :-)
mathiass (2) skrev:Super godt at Sun endelig får gjort noget ved denne kæmpe mangel. 10 år for sent er bedre end aldrig. En simpel og ligetil løsning som den i C# ville være at foretrække. Sådan set burde de bare tilføje den udvidelse til Java sproget som Microsoft blev sagsøgt for at lave for 10 år siden.
Jeg er desværre bange for at Sun ikke kan stoppe mens legen er god. Jeg krydser fingre for en SIMPEL løsning. Men når man kender Dr. Reinhold og hand kompaner, så kan det nemt gå helt i skoven med simpliciteten..
#3: Der menes en form for anonym funktion som kan defineres direkte hvor den skal bruges (på samme måde som man kan definere en klasse anonymt i Java). Der er en god forklaring her: http://gafter.blogspot.com/2006/08/closures-for-ja...
#4 Argumentet (fra Sun) for ikke at have closures var at det let kunne blive for kompliceret. Det er jeg personligt lidt uforstående overfor da det på ingen måde er mere kompliceret end anonyme klasser, og det er som sådan både konceptuelt og sytaktisk renere. Af den grund tror jeg bestemt at de vil gå efter en simpel løsning uden infererede funktionstyper, subtyping og lignende.
#6: Jeg giver dig helt ret.
Det er irriterende når Sun udelukker smarte ting fra Java med det argument at det bliver for kompliceret for udvikleren eller at sproget bliver for stort. C# lever p.t. højt på smarte sprog-features, som mange savner i Java. Tænk hvor C# ville have været hvis Java sproget var ligeså godt eller måske ligefrem bedre.
Det er irriterende når Sun udelukker smarte ting fra Java med det argument at det bliver for kompliceret for udvikleren eller at sproget bliver for stort. C# lever p.t. højt på smarte sprog-features, som mange savner i Java. Tænk hvor C# ville have været hvis Java sproget var ligeså godt eller måske ligefrem bedre.
C# ER Java. Microsofts Java, som de begyndte på i slutningen af 90erne.><))°r (7) skrev:Tænk hvor C# ville have været hvis Java sproget var ligeså godt eller måske ligefrem bedre.
SUN sagsøgte Microsoft for at forbedre sproget.
Så nej, tænk på hvor fedt Java havde været i dag, hvis Microsoft havde fået lov at hjælpe!
Simpelt er et ukendt koncept i Java :-)jappe123 (4) skrev:Jeg er desværre bange for at Sun ikke kan stoppe mens legen er god. Jeg krydser fingre for en SIMPEL løsning. Men når man kender Dr. Reinhold og hand kompaner, så kan det nemt gå helt i skoven med simpliciteten..
Og det må ikke lige C#, fordi at SUNs udviklere hader Microsoft som pesten, og derfor vil forrige closures bare for at få det til at se anderledes ud.
#8: Så stor forskel er der ikke på performance mellem C#/.NET og Java. Jeg er træt af den "myte". Jeg koder i begge sprog, og oplever ikke at Java er så meget langsommere end C#/.NET.
Her er kan man se nogle performance forskelle:
http://reverseblade.blogspot.com/2009/02/c-versus-...
I øvrigt er Windows ikke det eneste system Java kan køre på, så performance på Windows er ikke altafgørende for sproget.
I mit indlæg #7 tænkte jeg mere på hvor attraktivt Java som sprog er i forhold til C#. Udviklere koster jo typisk mere end hardware, så hvis sproget er godt kan udviklerne spare tid og dermed penge. Her står C# stærkt i forhold til Java på Windows, men også på systemer som understøtter Mono.
Her er kan man se nogle performance forskelle:
http://reverseblade.blogspot.com/2009/02/c-versus-...
I øvrigt er Windows ikke det eneste system Java kan køre på, så performance på Windows er ikke altafgørende for sproget.
I mit indlæg #7 tænkte jeg mere på hvor attraktivt Java som sprog er i forhold til C#. Udviklere koster jo typisk mere end hardware, så hvis sproget er godt kan udviklerne spare tid og dermed penge. Her står C# stærkt i forhold til Java på Windows, men også på systemer som understøtter Mono.
JVM er langsom i forhold til .NETs CLR, og derfor er JVM ret elendig til at køre andre sprog som f.eks. Scala, i forhold til IronPython/IronRuby i .NET, og med forbedringer i C# 4.0 (forventet omkring Marts 2010), så er JVM er altså LANGT bagud.><))°r (10) skrev:#8: Så stor forskel er der ikke på performance mellem C#/.NET og Java. Jeg er træt af den "myte". Jeg koder i begge sprog, og oplever ikke at Java er så meget langsommere end C#/.NET.
Derudover er Java's UI frameworks, som f.eks. Swing, sindsyg langsomme.
Nahilas (8) skrev:Så længe Javas VM er så forfærdeligt langsom som den er, ville C# sgu nok have samme del af Windows markedet som det har nu...
JVM som sådan er ikke langsom. Det er noget sludder.
#11: Du blander ting sammen her. CLR indeholder nogle indbyggede ting som gør dynamic dispatching (som i IronPython og IronRuby) hurtigere. Det har hele tiden været en del af den kommende JVM at dette skulle forbedres. Microsoft var bare hurtigere til at få det på markedet end Sun er. Sun har været meget sløve omkring udviklingen af Java de senere år.
Derudover er Java's UI frameworks, som f.eks. Swing, sindsyg langsomme.Ikke hvis man ved hvad man laver. Problemet er at det er for svært at lave det ordentligt. Umiddelbart vil jeg mene at GUI er fuldstændig ligemeget, da det ikke er det folk bruger Java til, men Swing bliver kraftigt forbedret i den nye Java 7.
I øvrigt er Windows ikke det eneste system Java kan køre på, så performance på Windows er ikke altafgørende for sproget.Windows er bestemt heller ikke det eneste system C# kan køre på.
Hvis man sammenligner med C#, så er GUI rimelig relevant.mathiass (12) skrev:Umiddelbart vil jeg mene at GUI er fuldstændig ligemeget, da det ikke er det folk bruger Java til, men Swing bliver kraftigt forbedret i den nye Java 7.
WPF, Silverlight, WinForms osv.
Så jo, jeg synes at man kan tillade sig at kritisere Swing hastighed. Og jeg er heller ikke tilfreds med SWT.
Hvis man sammenligner med C#, så er GUI rimelig relevant.Sure, min pointe er bare at ingen laver GUI i Java. Java bruges mest til server software.
Så jo, jeg synes at man kan tillade sig at kritisere Swing hastighed. Og jeg er heller ikke tilfreds med SWT.Den eneste grund til at 'Swing er langsomt' er at grafikken tegnes af den samme tråd som du laver dine beregninger i med mindre programmøren selv laver om på det. Man kan sagtens få det til at performe godt, men API'et burde gøre det muligt at gøre det på en nemmere måde.
mathiass (12) skrev:#11: Du blander ting sammen her. CLR indeholder nogle indbyggede ting som gør dynamic dispatching (som i IronPython og IronRuby) hurtigere. Det har hele tiden været en del af den kommende JVM at dette skulle forbedres. Microsoft var bare hurtigere til at få det på markedet end Sun er. Sun har været meget sløve omkring udviklingen af Java de senere år.
Ikke CLR'en som sådan, men med .NET 4 kommer der den såkaldte DLR som er en dynamisk "runtime" der kører på CLR, og implementerer en masse af de ting som p.t. får JavaScript til at køre så hurtigt på WebKit-browsere (polymorf inline cache, context threading etc.). Det er her hastighedsforbedringen kommer ind. Kunsten er så at gøre DLR'en abstrakt nok til at kunne modelere så mange sprog (Python, Ruby) som muligt, så simpelt som muligt. Jeg skal ikke kunne sige om det er lykkedes, men det virker rimelig fornuftigt.
#15 Min pointe var bare at det ikke har noget at gøre med hvorvidt JVM som sådan er hurtig eller langsom. Du tænker i øvrigt på Chrome's V8 JavaScript fortolker. WebKit er et rendering engine, som bruges både i Safari og Chrome, men de to browsere bruger forskellige fortolkere til JavaScript. Så vidt jeg ved bruger Safari ikke de teknikker du nævner.
#16 Jeg tænker på V8 og SFX (eller Nitro), som er de to store JS engines til WebKit. Ved at skrive WebKit regnede jeg med at omtale dem under et, da de jo begge performer i de stores liga :-).
..og jo, SFX bruger også disse teknikker. Jeg vidste faktisk kun at SFX gør (og ikke noget om hvad V8 gør), men jeg regnede med at det galdt for dem begge.
...desuden sagde jeg WebKit-browsere, ikke WebKit ;-)
..og jo, SFX bruger også disse teknikker. Jeg vidste faktisk kun at SFX gør (og ikke noget om hvad V8 gør), men jeg regnede med at det galdt for dem begge.
...desuden sagde jeg WebKit-browsere, ikke WebKit ;-)
Det er der nu en del der gør, bl.a. undertegnede. Min erfaring er at det generelt fungerer fint, hvis man tænker sig om. De typiske performanceproblemer skyldes netværks-latency, som handler om arkitektur og er ens uanset hvilket sprog GUI'et er udviklet i. Swing kan være lidt sløvt, men så kan man fx bruge SWT, som bruger native widgets samtidig med at det virker på tværs af de mest udbredte OS'er.mathiass (14) skrev:Sure, min pointe er bare at ingen laver GUI i Java.
Closures lyder dejligt. Var lidt mystisk over at jeg ikke kunne gøre det her i et projekt jeg har gang i.
Det er generelt lidt mystisk at arbejde med Java når man er C++ mand. Syntaksen er absolut genkendelig og anvendelig, men det der går mig mest på er manglen på pointers/referencer. I C++ vil man jo så gerne smide en pointer eller reference videre til andre funktioner, så man er helt sikker på at der ikke laves en kopi, og man kan selvfølgelig ændre det objekt man videregiver til funktionen. Det kan man så ikke i Java. Må indrømme jeg ikke helt forstår hvorfor. Det er jo hverken pointer eller referencer, når det bliver et nyt objekt hvis man ændrer i det, men det skulle, så vidt jeg forstår, stadig være en reference hvis man ikke ændrer i det? Gid de dog blot havde const, det ville gøre min forvirring så meget mindre :| Kan ikke lide at sproget gør sådanne ting automastisk; det er hukommelse og objekters integritet vi snakker om her. Men jo, jeg er jo blot en C++ mand fanget i et sprog der stadig er en jungle. (Deres dokumentation er dog i top! Det kan C++ ikke prale af, der må man bruge diverse trejdeparts dokumentationer)
Det er et okay sprog at lave skoleting i, og jeg forstår at mange virksomheder bruger det. Men jeg kan altså ikke lade være med at syntes at C++ er mest lækkert. Jeg mangler kontrol. Og det med at det hele kører over JVM, appellerer altså ikke til mig. Jeg vil så gerne blot kompilerer det, og kører det uden at tænke på hvad andre computere har installeret. Selvom jeg undgår DLL helvedet. (Jeg syntes ikke det er et helvede - bare være opmærksom på hvad man bruger, og husk at lægge det ved siden af, hvor svært er det?)
Nå, stuck in Java, indtil thesis går jeg ud fra :) (Jo mindre dem jeg kommer til at lave thesis med elsker det :S)
Det er generelt lidt mystisk at arbejde med Java når man er C++ mand. Syntaksen er absolut genkendelig og anvendelig, men det der går mig mest på er manglen på pointers/referencer. I C++ vil man jo så gerne smide en pointer eller reference videre til andre funktioner, så man er helt sikker på at der ikke laves en kopi, og man kan selvfølgelig ændre det objekt man videregiver til funktionen. Det kan man så ikke i Java. Må indrømme jeg ikke helt forstår hvorfor. Det er jo hverken pointer eller referencer, når det bliver et nyt objekt hvis man ændrer i det, men det skulle, så vidt jeg forstår, stadig være en reference hvis man ikke ændrer i det? Gid de dog blot havde const, det ville gøre min forvirring så meget mindre :| Kan ikke lide at sproget gør sådanne ting automastisk; det er hukommelse og objekters integritet vi snakker om her. Men jo, jeg er jo blot en C++ mand fanget i et sprog der stadig er en jungle. (Deres dokumentation er dog i top! Det kan C++ ikke prale af, der må man bruge diverse trejdeparts dokumentationer)
Det er et okay sprog at lave skoleting i, og jeg forstår at mange virksomheder bruger det. Men jeg kan altså ikke lade være med at syntes at C++ er mest lækkert. Jeg mangler kontrol. Og det med at det hele kører over JVM, appellerer altså ikke til mig. Jeg vil så gerne blot kompilerer det, og kører det uden at tænke på hvad andre computere har installeret. Selvom jeg undgår DLL helvedet. (Jeg syntes ikke det er et helvede - bare være opmærksom på hvad man bruger, og husk at lægge det ved siden af, hvor svært er det?)
Nå, stuck in Java, indtil thesis går jeg ud fra :) (Jo mindre dem jeg kommer til at lave thesis med elsker det :S)
ipwn (20) skrev:I C++ vil man jo så gerne smide en pointer eller reference videre til andre funktioner, så man er helt sikker på at der ikke laves en kopi, og man kan selvfølgelig ændre det objekt man videregiver til funktionen. Det kan man så ikke i Java.
Du kan ikke sende en simpel data type over som referance.
Objekter sendes altid over som referance. Der bliver kun lavet en kopi af "pointeren". Og du kan godt ændre i objektet (hvis klassen har metoder til det).
ipwn (20) skrev:Gid de dog blot havde const, det ville gøre min forvirring så meget mindre
Java's final dækker nogle få af de ting som C++ const gør, men du har f.eks. ikke mulighed for const objekter og const metoder.
#20
Hehe, jeg morer mig altså lidt over dit indlæg. Jeg undrer mig lige så meget over hvor underlig C++ er, når jeg roder med det.
Funktionaliteten er der skam. Der skal bare 3 linjers kode til, i stedet for én.
Der bliver aldrig lavet en kopi af et objekt, uden nogen har kodet hvordan man kopierer objektet.
Men enhver reference bliver kopieret, når man bruger den som argument til en metode.
Java er hverken pass-by-value eller pass-by-reference. Det et referencen der er pass-by-value. (Men primitiver er pass-by-copy.)
Jeg forstår ikke hvad du prøver at sige her. Et objekt bliver ikke til et nyt objekt, bare fordi man ændrer lidt i det. Referencen bliver heller ikke ændret.
Jeg ved meget lidt om C, så tilgiv mig hvis jeg lyder dum nu. Men kan final ikke give dig hvad du mangler? Jeg ved ikke lige hvad const gør. Jeg gætter bare ud fra navnet, og burde holde min kæft her. ;-)
Automatikken betyder at du (næsten) ikke kan lave fejl. Og integriteten kan jeg ikke se noget problem med.
(Dammit, arne_v kom først. Jeg fortsætter altså.)
Jamen ... jamen ... det er jo Java's fordel. Hmm.
Hehe, jeg morer mig altså lidt over dit indlæg. Jeg undrer mig lige så meget over hvor underlig C++ er, når jeg roder med det.
ipwn (20) skrev:Closures lyder dejligt. Var lidt mystisk over at jeg ikke kunne gøre det her i et projekt jeg har gang i.
Funktionaliteten er der skam. Der skal bare 3 linjers kode til, i stedet for én.
ipwn (20) skrev:så man er helt sikker på at der ikke laves en kopi
Der bliver aldrig lavet en kopi af et objekt, uden nogen har kodet hvordan man kopierer objektet.
Men enhver reference bliver kopieret, når man bruger den som argument til en metode.
Java er hverken pass-by-value eller pass-by-reference. Det et referencen der er pass-by-value. (Men primitiver er pass-by-copy.)
ipwn (20) skrev:når det bliver et nyt objekt hvis man ændrer i det
Jeg forstår ikke hvad du prøver at sige her. Et objekt bliver ikke til et nyt objekt, bare fordi man ændrer lidt i det. Referencen bliver heller ikke ændret.
ipwn (20) skrev:Gid de dog blot havde const, det ville gøre min forvirring så meget mindre :|
Jeg ved meget lidt om C, så tilgiv mig hvis jeg lyder dum nu. Men kan final ikke give dig hvad du mangler? Jeg ved ikke lige hvad const gør. Jeg gætter bare ud fra navnet, og burde holde min kæft her. ;-)
ipwn (20) skrev:Kan ikke lide at sproget gør sådanne ting automastisk; det er hukommelse og objekters integritet vi snakker om her.
Automatikken betyder at du (næsten) ikke kan lave fejl. Og integriteten kan jeg ikke se noget problem med.
(Dammit, arne_v kom først. Jeg fortsætter altså.)
ipwn (20) skrev:Jeg vil så gerne blot kompilerer det, og kører det uden at tænke på hvad andre computere har installeret.
Jamen ... jamen ... det er jo Java's fordel. Hmm.
#22 Haha :) Ja, jeg kan se at vi så er lige forvirret :)
Syntaks der stort set ligner hinanden, men en helt anden verden :S
Jeg må indrømme jeg stadigvæk, på trods af dit indlæg, ikke kan forstå hvordan det bliver passet igennem en funktion.
Du kan hjælpe mig meget her;
Indeholder den container så hest eller hvad indeholder den? S: (Håber den indeholder hest, ellers så går det da helt amok hvor meget hukommelse mit program bruger - kopierer hele danmarks vejsystem i så fald)
const i C/C++ er ganske simpelt. Det betyder blot at objektet ikke må ændres, og hvis man derfor sender et objekt til en funktion kan man garanterer at det ikke er en kopi, det kan kun være objektet selv. Så kan man bruge dets data, uden at være i tvivl om at man bruger ekstra hukommelse :) (Hvis man sender en pointer/reference)
Jaja, jeg ved godt det er lidt mystisk hvad jeg skrev om kompilering. Det er helt klart fordi jeg er for noob til Java. Kan ikke få lortet til at starte udenfor Eclipse :S Har aldrig oplevet det i C++. Især fordi at man slet ikke kan kører en konsol udenfor sit IDE.
Angående fejl, syntes jeg ikke at jeg laver flere end jeg gør i C++? Der er de sædvanlige med at jeg prøver at tilgå et element i en container der ikke findes, eller at jeg prøver at kalde en metode på et objekt der er sat til null :)
Syntaks der stort set ligner hinanden, men en helt anden verden :S
Jeg må indrømme jeg stadigvæk, på trods af dit indlæg, ikke kan forstå hvordan det bliver passet igennem en funktion.
Du kan hjælpe mig meget her;
public void Somefunc(Someclass h) { somecontainer[x] = h; }
Someclass hest = new Someclass();
Somefunc(hest);
Indeholder den container så hest eller hvad indeholder den? S: (Håber den indeholder hest, ellers så går det da helt amok hvor meget hukommelse mit program bruger - kopierer hele danmarks vejsystem i så fald)
const i C/C++ er ganske simpelt. Det betyder blot at objektet ikke må ændres, og hvis man derfor sender et objekt til en funktion kan man garanterer at det ikke er en kopi, det kan kun være objektet selv. Så kan man bruge dets data, uden at være i tvivl om at man bruger ekstra hukommelse :) (Hvis man sender en pointer/reference)
Jaja, jeg ved godt det er lidt mystisk hvad jeg skrev om kompilering. Det er helt klart fordi jeg er for noob til Java. Kan ikke få lortet til at starte udenfor Eclipse :S Har aldrig oplevet det i C++. Især fordi at man slet ikke kan kører en konsol udenfor sit IDE.
Angående fejl, syntes jeg ikke at jeg laver flere end jeg gør i C++? Der er de sædvanlige med at jeg prøver at tilgå et element i en container der ikke findes, eller at jeg prøver at kalde en metode på et objekt der er sat til null :)
#24 Ah tusind tak :)
Det var også det jeg havde håbet. Men hvorfor kan jeg så ikke ændre i den klasse i Java, og bagefter se ændringerne? Det havde jeg nemlig lidt bøvl med.
I C var det jo nærmest normen, at man gav en reference til et objekt til en funktion der så lavede nogle ændringer, og derefter var de så stadigvæk i kraft? Forsøgte jeg mig nemlig med i Java, men objektet var fuldstændigt uberørt efter funktionskaldet.
Det var også det jeg havde håbet. Men hvorfor kan jeg så ikke ændre i den klasse i Java, og bagefter se ændringerne? Det havde jeg nemlig lidt bøvl med.
I C var det jo nærmest normen, at man gav en reference til et objekt til en funktion der så lavede nogle ændringer, og derefter var de så stadigvæk i kraft? Forsøgte jeg mig nemlig med i Java, men objektet var fuldstændigt uberørt efter funktionskaldet.
#11
Benchmarks? JVM version? Vendor?
Det er sgu for fesent at du bare slynger sådan en kommentar ud, uden noget som helst til at bakke det op.
Wtf? Sidder du og sammenligner en nuværende Java JVM's ydelse til C# 4.0 der først udkommer engang til næste år? Sådan kan man da ikke argumentere?
Jython, Scala, Groovy og JRuby kører aldeles glimrende på en JVM og i Java 7 bliver integrationen endnu bedre.
Lad mig gætte din fremgangsmåde for at komme til denne konklusion: Du har ligesom, dengang du 'forsøgte' at lære JSF, bare gået igang med at skrive slamkode udfra dine egne selvfede overbesvisninger, uden at læse en halv skid om emnet først!
Vis noget swing kode du har skrevet, og følgende er sikkert sandt:
- AL kode, kører på EDT'en.
- Resource/tidskrævende beregninger har sikkert ikke sin egen tråd.
------------------------------------
Du er virkelig en religiøs slyngel. På en rigtig, professionel arbejdsplads sidder de ikke og måler pikke konstant, så jeg håber du bliver mere fornuftig når du kommer i rigtigt arbejde.
JVM er langsom i forhold til .NETs CLR
Benchmarks? JVM version? Vendor?
Det er sgu for fesent at du bare slynger sådan en kommentar ud, uden noget som helst til at bakke det op.
og derfor er JVM ret elendig til at køre andre sprog som f.eks. Scala, i forhold til IronPython/IronRuby i .NET, og med forbedringer i C# 4.0 (forventet omkring Marts 2010), så er JVM er altså LANGT bagud.
Wtf? Sidder du og sammenligner en nuværende Java JVM's ydelse til C# 4.0 der først udkommer engang til næste år? Sådan kan man da ikke argumentere?
Jython, Scala, Groovy og JRuby kører aldeles glimrende på en JVM og i Java 7 bliver integrationen endnu bedre.
Derudover er Java's UI frameworks, som f.eks. Swing, sindsyg langsomme.
Lad mig gætte din fremgangsmåde for at komme til denne konklusion: Du har ligesom, dengang du 'forsøgte' at lære JSF, bare gået igang med at skrive slamkode udfra dine egne selvfede overbesvisninger, uden at læse en halv skid om emnet først!
Vis noget swing kode du har skrevet, og følgende er sikkert sandt:
- AL kode, kører på EDT'en.
- Resource/tidskrævende beregninger har sikkert ikke sin egen tråd.
------------------------------------
Du er virkelig en religiøs slyngel. På en rigtig, professionel arbejdsplads sidder de ikke og måler pikke konstant, så jeg håber du bliver mere fornuftig når du kommer i rigtigt arbejde.
ipwn (25) skrev:Men hvorfor kan jeg så ikke ændre i den klasse i Java, og bagefter se ændringerne?
Det kan du skam også. Problemet er at undgå det.
public void Somefunc(Someclass h) {
h.setSomeThing("YY");
}
Someclass hest = new Someclass();
Somefunc(hest);
System.out.println(hest.getSomeThing());
Udskriver "YY", hvis getter og setter opfører sig som man bør forvente.
Undskyld jeg bryder ind i jeres herlige nørderi med en off-topic observation. :
Hvor er det DEJLIGT at se en tråd på Newz fuld af konstruktive, positive og ikke-spammende indlæg (som mit eget tendensere imod)
Jeg har nu læst alle 30 kommentarer og jeg fatter stadig ikke en hat af noget som helst hehe.
Hvor er det DEJLIGT at se en tråd på Newz fuld af konstruktive, positive og ikke-spammende indlæg (som mit eget tendensere imod)
Jeg har nu læst alle 30 kommentarer og jeg fatter stadig ikke en hat af noget som helst hehe.
#30
Ja, alt efter hvordan man nu designer sit system. Nogle mener at attributter "altid" skal være private, og tilgåes udefra via getter og setter (den skole hører jeg så til), andre mener at man bare laver dem public og tilgår dem direkte.
Teknisk set virker både public-ideen og private/getter/setter, men den sidste giver mere kontrol mod mere kode.
Ja, alt efter hvordan man nu designer sit system. Nogle mener at attributter "altid" skal være private, og tilgåes udefra via getter og setter (den skole hører jeg så til), andre mener at man bare laver dem public og tilgår dem direkte.
Teknisk set virker både public-ideen og private/getter/setter, men den sidste giver mere kontrol mod mere kode.
public class SomeClass {
public String something;
}
#32 Okay, syntes bare ikke der skete noget som helst da jeg prøvedet :S Så jeg lavede en ekstra funktion til formålet dengang.
Jeg må lige prøve igen her i morgen. Syntes virkelig ikke at der skete noget. Nå, det er sikkert en fejl 40 :)
Takker jer nørder der har været så tålmodige og venlige at hjælpe en C++ fyr, der tror han kan lave mirakler i Java. (Men det er tæt på! Det er stadigvæk kun en variant af et sprog, og det meste gælder stadig hehe)
Jeg må lige prøve igen her i morgen. Syntes virkelig ikke at der skete noget. Nå, det er sikkert en fejl 40 :)
Takker jer nørder der har været så tålmodige og venlige at hjælpe en C++ fyr, der tror han kan lave mirakler i Java. (Men det er tæt på! Det er stadigvæk kun en variant af et sprog, og det meste gælder stadig hehe)
#32
Jeg kan sagtens se formålet med getters og setters, men er imod at fylde klasserne med ligegyldige metoder.
Her er auto-implemented properties lækkert i C#:
Hvis jeg senere har brug for at gøre noget ved get/set udvider jeg det til:
Personligt går jeg ikke så meget op i det, men så er de designliderlige tilfredse.
Jeg kan sagtens se formålet med getters og setters, men er imod at fylde klasserne med ligegyldige metoder.
Her er auto-implemented properties lækkert i C#:
public string Tralala { get; set; }
Hvis jeg senere har brug for at gøre noget ved get/set udvider jeg det til:
public string Tralala
{
get { return _Tralala; }
set { if(value<10) _Tralala = value; }
}
private string _Tralala;
Personligt går jeg ikke så meget op i det, men så er de designliderlige tilfredse.
Properties er en stor fordel frem for get/set når der skal laves et property grid til f.eks. GUI design.mazing (34) skrev:Personligt går jeg ikke så meget op i det, men så er de designliderlige tilfredse.
Derudover er properties noget nemmere at arbejde med, hvis man skal arbejde med collections.
Jeg er fint bekendt med best-pratice i Swing, samt GUI threading teorier, threadpools, background jobs, med mere.squad2nd (26) skrev:Lad mig gætte din fremgangsmåde for at komme til denne konklusion: Du har ligesom, dengang du 'forsøgte' at lære JSF, bare gået igang med at skrive slamkode udfra dine egne selvfede overbesvisninger, uden at læse en halv skid om emnet først!
Swing er stadigvæk en grundlæggende langsomt framework. Og hvis SUN ikke havde været nogle fjolser, og sagsøgt Microsoft, havde de haft P/Invoke istedet for JNI, altså en ordenlig implementering af platform library invokes, og derfor kunne have lavet en GTK/QT binding istedet, med noget bedre resultatet (ihvertfald hvis de havde valgt QT).
Du misvudere grunden til at bruge et sprog. Java er godt fordi det er nemt at skrive letforståelig kode i, som nemt kan genbruges, autodokumenteres og mere.ipwn (20) skrev:Det er et okay sprog at lave skoleting i, og jeg forstår at mange virksomheder bruger det.
Prøv f.eks. at kode en server<->client client i C++. Det er noget mere besværligt, og du skal ud og arbejde med libraries, som skal linkes ind og meget andet.
Kontrol er overvuderet. I de fleste tilfælde har du ikke brug for at manuelt styre memory, eller kunne bestemme hvordan der kompileres. Derudover tillader en virtuel maskine at du kan få just-in-time debugging. Vil klart anbefale at du læser op på debugging og brug af exceptions.ipwn (20) skrev:Men jeg kan altså ikke lade være med at syntes at C++ er mest lækkert. Jeg mangler kontrol. Og det med at det hele kører over JVM, appellerer altså ikke til mig.
Frameworks som Java og .NET er ret standard i dag.ipwn (20) skrev:Jeg vil så gerne blot kompilerer det, og kører det uden at tænke på hvad andre computere har installeret.
DLL hell har ikke ekisteret siden Windows 2000.ipwn (20) skrev:Selvom jeg undgår DLL helvedet. (Jeg syntes ikke det er et helvede - bare være opmærksom på hvad man bruger, og husk at lægge det ved siden af, hvor svært er det?)
Windows XP og op har tillade meta-data med versions-styring af libraries. Desværre er der utrolig mange folk der ikke har forstået det endnu :(
Java er faktisk ret svagt på det punkt, da Java 6 ikke har versions-styring af JARs. (Der er værktøjer til det, men de er ikke standard).
#Java
Til jer som arbejde med Java, og ikke er så bekendt med C#, så har Ole Friis Østergaard fra Trifork har givet lidt input på version2:
http://www.version2.dk/artikel/13072-julegave-til-...
Jeg er ret enig med ham. Og Trifork har mig bekendt flere resourcer i Java end .NET.
Til jer som arbejde med Java, og ikke er så bekendt med C#, så har Ole Friis Østergaard fra Trifork har givet lidt input på version2:
http://www.version2.dk/artikel/13072-julegave-til-...
Jeg er ret enig med ham. Og Trifork har mig bekendt flere resourcer i Java end .NET.
Og da bare lige for at trolle:squad2nd (26) skrev:Wtf? Sidder du og sammenligner en nuværende Java JVM's ydelse til C# 4.0 der først udkommer engang til næste år? Sådan kan man da ikke argumentere?
C# 4 er allerede tilgængelig in Community Technology Preview (CTP), og er i anden beta-udgave.
Jeg kender flere som allerede benytter det til intern produktion, eller forberedelse.
Grunden til at vi skal vente til Marts er fordi at Visual Studio 2010, samt Visual Studio AddOn partners lige skal være klar til brug ;-) Ingen ny version af .NET, uden nye udviklingsværktøjer til at hjælpe.
Forhåbenlig så vil det samme ske for Java 7, men jeg er bekymret over SUNs utrolig langsomme process for at få videreudviklet sproget, samt så lidt informationer de lukker ud.
De kunne altså lære en masse fra Microsoft på dette her punkt.
#C++ const
C++
kan laves i Java som:
C++
kan laves i Java som:
Men C++
og
Kan ikke laves i Java.
Betydningen er at at man i Test metode ikke kan ændre noget i o objektet.
C++
void Test(Foobar *o)
kan laves i Java som:
void Test(Foobar o)
C++
void Test(Foobar *const o)
kan laves i Java som:
void Test(final Foobar o)
Men C++
void Test(const Foobar *o)
og
void Test(const Foobar *const o)
Kan ikke laves i Java.
Betydningen er at at man i Test metode ikke kan ændre noget i o objektet.
#42
Netop mangel på muligheder for immutability I Java og C#, er et ofte diskutteret emne.
Jeg synes ikke rigtig at det er funktionalitet man mangler. I de tilfælde hvor det er relevant, er man nok ude i den slags software hvor C/C++ i forvejen er det rigtige valg.
Eller et funktionelt sprog som Haskell, hvor det nærmest er omvendt, hvor mutability ikke er slået til som standard.
Netop mangel på muligheder for immutability I Java og C#, er et ofte diskutteret emne.
Jeg synes ikke rigtig at det er funktionalitet man mangler. I de tilfælde hvor det er relevant, er man nok ude i den slags software hvor C/C++ i forvejen er det rigtige valg.
Eller et funktionelt sprog som Haskell, hvor det nærmest er omvendt, hvor mutability ikke er slået til som standard.
Windcape (43) skrev:Jeg synes ikke rigtig at det er funktionalitet man mangler.
Det er ellers fremragende både til at dokumentere og enforce hvor noget kan ændre sig.
Windcape (43) skrev:I de tilfælde hvor det er relevant, er man nok ude i den slags software hvor C/C++ i forvejen er det rigtige valg.
Jeg betragter ikke C/C++ som det oplagte valg til robust sikker kode.
Ja, men jeg betragter stadigvæk ikke immutability som noget der altid giver mening.
f.eks.
Her representere vi en typisk bruger. Hvor vi i Java/C# kan arbejde med en instance af en bruger som et mutable objekt, så kræver funktionelle sprog (her Haskell) at vi laver et ny bruger, hvis brugeren ændre sin email.
Jeg synes ikke at fuld immutability er nødvendigt, frem for at designe sine modeller korrekt, med god brug af getters/setters til at få objekterne til at fremstå som begrænset mutable.
Muligheden for at gøre noget mutable i Haskell via. en Monad er muligt, men jeg vil mene at det kræver langt bedre sprogforståelse, og en meget bedre programmør, end at lave det tilsvarende i Java / C#.
f.eks.
data User = User {
userId :: Int,
username :: String,
email :: String
}
Her representere vi en typisk bruger. Hvor vi i Java/C# kan arbejde med en instance af en bruger som et mutable objekt, så kræver funktionelle sprog (her Haskell) at vi laver et ny bruger, hvis brugeren ændre sin email.
Jeg synes ikke at fuld immutability er nødvendigt, frem for at designe sine modeller korrekt, med god brug af getters/setters til at få objekterne til at fremstå som begrænset mutable.
Muligheden for at gøre noget mutable i Haskell via. en Monad er muligt, men jeg vil mene at det kræver langt bedre sprogforståelse, og en meget bedre programmør, end at lave det tilsvarende i Java / C#.
#45
Men netop her synes jeg jo at C++ gør det godt.
void M1(const User *u)
void M2(const User *u)
void M3(const User *u)
void M4(User *u)
...
User *u = new User();
M1(u);
M2(u);
M3(u);
M4(u);
Vi ved nu at M1, M2 og M3 ikke ændrer u - men i M4 hvor vi gerne vil ændre i u kan vi gøre det.
Stor fleksibilitet.
Men netop her synes jeg jo at C++ gør det godt.
void M1(const User *u)
void M2(const User *u)
void M3(const User *u)
void M4(User *u)
...
User *u = new User();
M1(u);
M2(u);
M3(u);
M4(u);
Vi ved nu at M1, M2 og M3 ikke ændrer u - men i M4 hvor vi gerne vil ændre i u kan vi gøre det.
Stor fleksibilitet.
Jeg er enig i at det er stor fleksibilitet, og jeg ville da heller ikke klage hvis det kom med i C# eller Java.
Jeg ser det bare ikke som noget der er utrolig vigtigt. Implementering af closures og extension methods i Java er (var?) ihvertfald højere på min ønskeliste.
Er der forresten nogen som ved om de vil implementere lambda expressions samtidig med closures, eller bare beholde en mere predicate agtig syntaks?
Jeg ser det bare ikke som noget der er utrolig vigtigt. Implementering af closures og extension methods i Java er (var?) ihvertfald højere på min ønskeliste.
Er der forresten nogen som ved om de vil implementere lambda expressions samtidig med closures, eller bare beholde en mere predicate agtig syntaks?
Windcape (47) skrev:Jeg er enig i at det er stor fleksibilitet, og jeg ville da heller ikke klage hvis det kom med i C# eller Java.
Jeg ser det bare ikke som noget der er utrolig vigtigt. Implementering af closures og extension methods i Java er (var?) ihvertfald højere på min ønskeliste.
Forskellige prioriteringer.
Jeg synes at noget der kan forhindre fejl i kode er vigtigere end noget der sparer programmøren for arbejde.
mathiass (2) skrev:Sådan set burde de bare tilføje den udvidelse til Java sproget som Microsoft blev sagsøgt for at lave for 10 år siden.
Windcape (9) skrev:SUN sagsøgte Microsoft for at forbedre sproget.
Inden I kommer for langt med at udbrede diverse myter: SUN sagsøgte MS fordi deres Java *MANGLEDE* features.
MS mente ikke at brugerne skulle have RMI og JNI.
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
- ⟨
- Nyheder
Gå til bund