mboost-dp1

Sun
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Word of warning: http://www.lucidimagination.com/blog/2011/07/28/do...
Java 7 is the release everybody has been waiting for, for quite a long time.Not really, no.
De fjernede jo 50% af de oprindelige features, og puttede dem i Java 8, så de faktisk kunne blive færdig i dette århundrede.
Men eller ser det fint. Nu kan de stakkels java udviklere få de features vi andre har haft i C# i 4-10 år. Jeg er sikker på at selv myplacedk vil blive glad for at kunne bruge lambda expressions :p
Besides that, nothing left to say but
Java is the new COBOL
#2 - bliver sq nødt til at rate dig "sjov", selvom en flamebait også kunne være på sin plads :P
Men altså lambda expressions? Jeg håber da for satan ikke folk har ventet længe på syntatisk sukker... jeg har ikke i hvert fald ikke ;)
4 - 10 år - det er sq bredt :O Hvilke features er det C# har som Java har manglet så meget?
Men altså lambda expressions? Jeg håber da for satan ikke folk har ventet længe på syntatisk sukker... jeg har ikke i hvert fald ikke ;)
Windcape (2) skrev:[...]
Nu kan de stakkels java udviklere få de features vi andre har haft i C# i 4-10 år.
4 - 10 år - det er sq bredt :O Hvilke features er det C# har som Java har manglet så meget?
C# har jo fået flere features, derfor tidsperioden.Darwind (4) skrev:4 - 10 år - det er sq bredt :O Hvilke features er det C# har som Java har manglet så meget?
Primært er det closures (.NET 1.0), optimal parameters (.NET 1.0, C# 3.0), og lambdas (.NET 3.5). Jeg har ikke styr på om Extension Methods (.NET 3.5) også kom med i Java 7, eller det først er Java 8.
Det er jo ikke sukker at kunne gøre:Darwind (4) skrev:Jeg håber da for satan ikke folk har ventet længe på syntatisk sukker
var adults = guests.Where(guest => guest.Age >= 18);
I andre sprog vil man beskrive det som en higher-order function.sheph (6) skrev:Så det bliver ikke oversat til en løkke der løber igennem listen af gæster? Det ligner sukker for mig. Men ganske praktisk sukker :-)
Der er jo mange, select, map, filter, osv. som alle er standard funktioner i funktionelle sprog som Haskell.
Derudover slipper du for at allokere en ekstra liste til resultatet, da Where retunere en iterator. Og du slipper for side-effects ved at have en mutable liste, som du selv fylder ud, i din kode.
Jeg er helt enig med #4 og #6.. Alle funktioner som C# har som Java ikke har er syntaktisk sukker ;-) Jeg er ikke misundelig.
Faktisk burde alle programmere med en spidset magnetiseret skruetrækker direkte på harddisken.
Ovenstående er også grunden til at jeg ikke vil have en SSD. ;-)
#Ontopic:
I mine øjne er C# klart det bedste sprog lige nu. Java er sakket bagud på både tool support og features.
Selvfølgelig er begge sprog turing komplette, og selvfølgelig kan man bruge 3. parts libraries, men ting som WPF, WCF, Entity Framework, Parallel Computing og LinQ gør bare livet lettere for en .Net programmør.
Faktisk burde alle programmere med en spidset magnetiseret skruetrækker direkte på harddisken.
Ovenstående er også grunden til at jeg ikke vil have en SSD. ;-)
#Ontopic:
I mine øjne er C# klart det bedste sprog lige nu. Java er sakket bagud på både tool support og features.
Selvfølgelig er begge sprog turing komplette, og selvfølgelig kan man bruge 3. parts libraries, men ting som WPF, WCF, Entity Framework, Parallel Computing og LinQ gør bare livet lettere for en .Net programmør.
sheph (6) skrev:Windcape (5) skrev:Det er jo ikke sukker at kunne gøre:
var adults = guests.Where(guest => guest.Age >= 18);
Så det bliver ikke oversat til en løkke der løber igennem listen af gæster? Det ligner sukker for mig. Men ganske praktisk sukker :-)
Sukker, jeg vil nok sammenligne det med crack cocaine, heroin eller lignende.
Meget svært at gå tilbage til java, når man har vænnet sig til de 3 ting som er illustreret i den ovenstående eksempel.
Hvorfor det ovenstående kode er så meget mere end blot sukker, kan man se i følgende foredrag The Busy Java Developer's Guide to Java Collections by Ted Neward
#10
Uuugh, JavaDocs. Endnu en ting ORACLE virkelig virkelig virkelig burde fikse.
ALT Java dokumentation fra java.com (be it docs or tutorials) ligner noget fra 90erne (hov vent, det ER fra 90erne). Og hele ideen med at f.eks. Eclipse skal parse (invalid) HTML for at kunne tilbyde intellisense er *scary*
De kunne godt tage sig sammen og begynde at lave noget XML dokumentation, ligesom .NET. Og så samtidig opdatere layoutet af java.com , opfriske deres tutorials, og skrive javadocs et seriøst makeover!
Uuugh, JavaDocs. Endnu en ting ORACLE virkelig virkelig virkelig burde fikse.
ALT Java dokumentation fra java.com (be it docs or tutorials) ligner noget fra 90erne (hov vent, det ER fra 90erne). Og hele ideen med at f.eks. Eclipse skal parse (invalid) HTML for at kunne tilbyde intellisense er *scary*
De kunne godt tage sig sammen og begynde at lave noget XML dokumentation, ligesom .NET. Og så samtidig opdatere layoutet af java.com , opfriske deres tutorials, og skrive javadocs et seriøst makeover!
Windcape var det ikke en genial ide at bruge 30 minutter på Java 7 inden du udtalte dig om det.
Lambda, optional parameters og extension methods er ikke med i Java 7.
Java docs har faktisk fået en større overhaling i Java 7.
Windcape (2) skrev:Men eller ser det fint. Nu kan de stakkels java udviklere få de features vi andre har haft i C# i 4-10 år. Jeg er sikker på at selv myplacedk vil blive glad for at kunne bruge lambda expressions :p
Windcape (5) skrev:Primært er det closures (.NET 1.0), optimal parameters (.NET 1.0, C# 3.0), og lambdas (.NET 3.5). Jeg har ikke styr på om Extension Methods (.NET 3.5) også kom med i Java 7, eller det først er Java 8.
Lambda, optional parameters og extension methods er ikke med i Java 7.
Windcape (11) skrev:ALT Java dokumentation fra java.com (be it docs or tutorials) ligner noget fra 90erne (hov vent, det ER fra 90erne).
Windcape (11) skrev:og skrive javadocs et seriøst makeover!
Java docs har faktisk fået en større overhaling i Java 7.
Chucara (9) skrev:Selvfølgelig er begge sprog turing komplette, og selvfølgelig kan man bruge 3. parts libraries, men ting som WPF, WCF, Entity Framework, Parallel Computing og LinQ gør bare livet lettere for en .Net programmør.
Hvad laver du i WCF, EF og TPL som du ikke kan lave i de tilsvarende Java teknologier?
Oh? Damnit! Nå, men så kan jeg gøre grin med Java et par år endnu, hurray!arne_v (12) skrev:Lambda, optional parameters og extension methods er ikke med i Java 7.
Så, men i det mindste kan java udviklerne lave switch på strings nu! Super feature!
Ah ja, hvis man explicit åbner SE7 så har det det fået et nyt style. Jeg åbnede bare konsekvent SE 6 for at checke. (Still, frames, eeew).arne_v (12) skrev:Java docs har faktisk fået en større overhaling i Java 7.
Når "Strings in switch statements" og "Underscores in numeric litarals" er 2 af 7 nye features i selve sproget, så er der virkelig ikke sket meget, det er næsten tragisk at kalde det version 7.
C# 5.0 er næsten i trykken, hvilket gør det endnu værre at Java7 ikke engang kan nå C# 3.5 til sokkeholderne.
C# 5.0 er næsten i trykken, hvilket gør det endnu værre at Java7 ikke engang kan nå C# 3.5 til sokkeholderne.
#13
Det er ikke et spørgsmål om hvorvidt man, givet uendelig tid, kan opnå det samme resultat på en anden platform, det er et spørgsmål om hvor veludviklerede værktøjerne er, da tid ofte er lig penge.
Det er ikke et spørgsmål om hvorvidt man, givet uendelig tid, kan opnå det samme resultat på en anden platform, det er et spørgsmål om hvor veludviklerede værktøjerne er, da tid ofte er lig penge.
#0
Original kilden siger "about five years".
Det faktiske interval er 11. december 2006 - 28. juli 2011 eller 4 år og 7 måneder og et antal dage.
Original kilden siger ikke noget om dette.
Og det er heller ikke korrekt.
Apache trak sig p.g.a. licens vilkårene for Java SE TCK. Og den konflikt startede før Oracle købte SUN.
Efter mere end fem år siden frigivelsen af den forrige version er Oracle nu klar med den næste store opdatering til Java SE, Java SE 7.
Original kilden siger "about five years".
Det faktiske interval er 11. december 2006 - 28. juli 2011 eller 4 år og 7 måneder og et antal dage.
Opdateringen kommer efter en turbulent periode, hvor Java gik fra at være under Suns vinger til nu at være kontrolleret af Oracle. Netop dette faktum har mødt en del kritik og fik for ekempel Apache Foundation til at trække sig fra eksklusivkomiteen (EC) i JCP-samarbejdet (Java Community Process) tilbage i december 2010.
Original kilden siger ikke noget om dette.
Og det er heller ikke korrekt.
Apache trak sig p.g.a. licens vilkårene for Java SE TCK. Og den konflikt startede før Oracle købte SUN.
silashansen (16) skrev:Det er ikke et spørgsmål om hvorvidt man, givet uendelig tid, kan opnå det samme resultat på en anden platform, det er et spørgsmål om hvor veludviklerede værktøjerne er, da tid ofte er lig penge.
Ja.
Men hvad er det indenfor de 3 emner som du mener tager længere tid i Java end i C#?
Jeg synes ikke rigtigt at der er/har været noget tilsvarende til TPL i Java.arne_v (13) skrev:Hvad laver du i WCF, EF og TPL som du ikke kan lave i de tilsvarende Java teknologier?
Fik de faktisk inkluderet Fork/Join i Java 7 ?
Derudover er biblioteker som TPL altså noget mere behageligt at bruge i sprog der har closures! F.eks. som dette her ville være svært at efterligne i Java. (At C# 5.0 async så gør det obsolete, er noget helt andet)
Alrekr (3) skrev:Yay! Det passer lige med at jeg skal lære at programmere java til næste semester.....
Nu er .net også det bedste. Så lær det i stedet. Java er lort når der er opdateringer intet af det gamle virker længere. Vi har næsten altid bøvl med java når de opdaterer så virker det ene og så virker det andet ikke og så er mange som laver deres egne jave eks ibm som ikke virker med sap. Java er noget skrammel
Windcape (19) skrev:Jeg synes ikke rigtigt at der er/har været noget tilsvarende til TPL i Java.
java.util.concurrent
Windcape (19) skrev:Fik de faktisk inkluderet Fork/Join i Java 7 ?
Ja.
Windcape (19) skrev:Derudover er biblioteker som TPL altså noget mere behageligt at bruge i sprog der har closures!
Nu kan man diskutere længe hvorvidt Java anonymous classes krav om at ydre variable skal være final for at de kan tilgåees inde fra gør at de ikke er en closure.
Men en C# lambda sparer ihvertfald en del boilerplate kode.
silashansen (15) skrev:hvilket gør det endnu værre at Java7 ikke engang kan nå C# 3.5 til sokkeholderne.
Det er svært at nå en ikke eksisterende version til sokkeholderne.
C# gik direkte fra 2.0 til 3.0 til 4.0.
Det var .NET som gik fra 2.0 til 3.5 til 4.0 (og 3.0 men den indeholdt ikke en ny C#).
arne_v (18) skrev:Ja.
Men hvad er det indenfor de 3 emner som du mener tager længere tid i Java end i C#?
Synes egentligt ikke at det er fair for java at blive sammenlignet med C#, de har jo taget hver sin retning.
Anders har stort fokus på udvikler produktivitet , imens java blev købt af Oracle, go figure :D
#23
Der er store forskelle i baggrund og filosofi.
For C# og .NET er der kun 1 firma som skal være enig.
For Java er der mange stakeholders som skal være enige. JCP SE/EE EC består lige pt af:
3 hardware firmaer firmaer (Ericsson, Fujitsu, Intel)
3 hardware+software firmaer (HP, IBM, Oracle)
4 software firmaer (Google, Redhat, SAP, VMware)
2 ikke IT firmaer (Credit Suisse, Goldman Sachs)
1 open source organisation (Eclipse)
2 Java bruger grupper (London, Brasilien)
1 enkelt person (Werner Keil)
Det er åbenlyst at MS kan træffe hurtigere beslutninger end JCP.
MS har også en lang tradition for at:
- flere features er godt
- tools er vigtige
- det skal være nemt for udviklerne
I Java verdenen er man mere blandede men traditionelt har der været synspunkter som:
- sproget skal være simpelt
- det skal være god OO
- det skal være sikkert
- det skal være portabelt
Der er store forskelle i baggrund og filosofi.
For C# og .NET er der kun 1 firma som skal være enig.
For Java er der mange stakeholders som skal være enige. JCP SE/EE EC består lige pt af:
3 hardware firmaer firmaer (Ericsson, Fujitsu, Intel)
3 hardware+software firmaer (HP, IBM, Oracle)
4 software firmaer (Google, Redhat, SAP, VMware)
2 ikke IT firmaer (Credit Suisse, Goldman Sachs)
1 open source organisation (Eclipse)
2 Java bruger grupper (London, Brasilien)
1 enkelt person (Werner Keil)
Det er åbenlyst at MS kan træffe hurtigere beslutninger end JCP.
MS har også en lang tradition for at:
- flere features er godt
- tools er vigtige
- det skal være nemt for udviklerne
I Java verdenen er man mere blandede men traditionelt har der været synspunkter som:
- sproget skal være simpelt
- det skal være god OO
- det skal være sikkert
- det skal være portabelt
@syntaktisk sukker
Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.
#12
Jeg skulle også lige til at skrive at λ-udtryk ikke er med i java 7.
#24
Det med at det skal være sikkert har irriteret mig noget. Javas sikkerhedsmodel gør at man ikke umiddelbart kan have ægte tail calls i JVMen :/
Er det muligt at lave sådan noget her i C# eller java m. lambda expressions?
Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.
#12
Jeg skulle også lige til at skrive at λ-udtryk ikke er med i java 7.
#24
Det med at det skal være sikkert har irriteret mig noget. Javas sikkerhedsmodel gør at man ikke umiddelbart kan have ægte tail calls i JVMen :/
Er det muligt at lave sådan noget her i C# eller java m. lambda expressions?
class Tarpit
public int fire(int->int fun)
return fun(0)
class Foo
private int x = 42
public blabla main(???)
Tarpit.fire(i => {
x+=random(10)
return x+1
})
println(x)
onetreehell (26) skrev:@syntaktisk sukker
Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.
Java 7 har ikke lambda.
Det er planlagt for Java 8.
onetreehell (26) skrev:Er det muligt at lave sådan noget her i C# eller java m. lambda expressions?
Ikke i Java - se ovenfor.
C#:
using System;
namespace E
{
public delegate int Fun(int v);
public class Tarpit
{
public static int Fire(Fun f)
{
return f(0);
}
}
public class Foo
{
private static int x = 42;
public static void Main(string[] args)
{
Tarpit.Fire(i => { x+=(new Random()).Next(10); return x+1; });
Console.WriteLine(x);
Console.ReadKey();
}
}
}
*tror* jeg gør det samme som din kode.
arne_v, dit C# er lidt rusten ;-)
using System;
class Tarpit
{
public static int Fire(Func<int, int> fun)
{
return fun(0);
}
}
class Program
{
private static int x = 42;
public static void Main()
{
Tarpit.Fire(i => {
x += (new Random()).Next(10);
return x + 1;
});
Console.WriteLine(x);
}
}
Hvilket Microsofts udviklere traditionelt også har været glade for. Det er jo trods alt os som bruger deres værktøjer, og features i sproget, ikke vores chefer.arne_v (24) skrev:MS har også en lang tradition for at:
- flere features er godt
- tools er vigtige
- det skal være nemt for udviklerne
Mig bekendt var Gosling også en stor fan af purity i sprog. Han synes ikke at Java skulle være et multiparadigm sprog, ligesom C# er i dag.arne_v (24) skrev:I Java verdenen er man mere blandede men traditionelt har der været synspunkter som:
- sproget skal være simpelt
- det skal være god OO
- det skal være sikkert
- det skal være portabelt
Jeg synes ikke at lambda har gjort C# mere komplekst. Det giver mere læsbar kode, og er implementeret i en form der giver mening for folk der ikke har arbejdet med det før.
Personligt synes jeg at C#s navnevalg til Enumerable<T> Extensions, er bedre end de standard navne som Haskell har defineret for alle de funktionelle sprog (map, filter, bind, etc.)
Anonymous Inner Classes.onetreehell (26) skrev:Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.
Men man kan bruge Guava (tidl. Google Collections). Jeg mener det er et must-have library for at arbejde seriøst med collections i Java.
#Java 7
Der kommer nok i'vrigt en update meget hurtigt.
Apache Lucene og Solr fandt en bug i JIT compileren.
http://lucene.apache.org/#28+July+2011+-+WARNING%3...
Der kommer nok i'vrigt en update meget hurtigt.
Apache Lucene og Solr fandt en bug i JIT compileren.
http://lucene.apache.org/#28+July+2011+-+WARNING%3...
28 July 2011 - WARNING: Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7
Oracle released Java 7 today. Unfortunately it contains hotspot compiler optimizations, which miscompile some loops. This can affect code of several Apache projects. Sometimes JVMs only crash, but in several cases, results calculated can be incorrect, leading to bugs in applications (see Hotspot bugs 7070134, 7044738, 7068051).
Apache Lucene Core and Apache Solr are two Apache projects, which are affected by these bugs, namely all versions released until today. Solr users with the default configuration will have Java crashing with SIGSEGV as soon as they start to index documents, as one affected part is the well-known Porter stemmer (see LUCENE-3335). Other loops in Lucene may be miscompiled, too, leading to index corruption (especially on Lucene trunk with pulsing codec; other loops may be affected, too - LUCENE-3346).
These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see this mail). This means you cannot use Apache Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM option to not risk index corruptions.
Please note: Also Java 6 users are affected, if they use one of those JVM options, which are not enabled by default: -XX:+OptimizeStringConcat or -XX:+AggressiveOpts.
Windcape (29) skrev:arne_v, dit C# er lidt rusten ;-)
Jeg praktiserer ikke så meget.
Men forskellen er at du har brugt Func<> mens jeg har brugt en egen delegate.
Func<> er helt klart det som matcher onetreehell's kode bedst.
Men Func<> og Action<> har aldrig været min kop te. De er simpelthen ikke typesikre nok.
Windcape (19) skrev:F.eks. som dette her ville være svært at efterligne i Java. (At C# 5.0 async så gør det obsolete, er noget helt andet)
Jeg kan ikke se helt pointen.
Eksemplet er ikke parallelt orienteret. Det bruger .NET/Windows async IO. Og to globale thread pools.
C#:
this.button1.Click += new System.EventHandler(this.Button1Click);
...
void Button1Click(object sender, EventArgs e)
{
var webRequest = WebRequest.Create("http://www.reedcopsey.com");
webRequest.GetReponseAsync().ContinueWith(t =>
{
using (var sr = new StreamReader(t.Result.GetResponseStream()))
{
string str = sr.ReadLine();;
this.textBox1.Text = string.Format("Page at {0} supports XHTML 1.0: {1}", t.Result.ResponseUri, str.Contains("XHTML 1.0"));
}
}, TaskScheduler.FromCurrentSynchronizationContext());
}
...
public static class WebRequestExtensions
{
public static Task<WebResponse> GetReponseAsync(this WebRequest request)
{
return Task.Factory.FromAsync<WebResponse>(
request.BeginGetResponse,
request.EndGetResponse,
null);
}
}
Java (1.6 !):
final ExecutorService es = Executors.newFixedThreadPool(2);
btn.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
try {
final URL url = new URL("http://www.reedcopsey.com");
es.submit(new Callable<Void>() {
public Void call() throws Exception {
BufferedReader br = new BufferedReader(new InputStreamReader(url.openConnection().getInputStream()));
final String str = br.readLine();;
EventQueue.invokeLater(new Runnable() {
public void run() {
tf.setText(String.format("Page at %0$s supports XHTML 1.0: %1$b", url, str.contains("XHTML 1.0")));
}
});
br.close();
return null;
}
});
} catch (MalformedURLException ex) {
ex.printStackTrace();
}
}
});
Der er en del forskelle, men umiddelbart fører alle veje jo til Rom.
#38
Det har altid irriteret mig meget. Det er svært at søge i dokumentationen, det kræver en browser og så er der de forbandede frames! Og så er det også træls at skrive værktøjer til for så skal man til at scrape html >.<
Det har altid irriteret mig meget. Det er svært at søge i dokumentationen, det kræver en browser og så er der de forbandede frames! Og så er det også træls at skrive værktøjer til for så skal man til at scrape html >.<
Windcape (11) skrev:Og hele ideen med at f.eks. Eclipse skal parse (invalid) HTML for at kunne tilbyde intellisense er *scary*
Windcape (11) skrev:De kunne godt tage sig sammen og begynde at lave noget XML dokumentation, ligesom .NET.
Windcape (38) skrev:The pinnacle of hippie development. Using broken HTML for what XML is made for.
onetreehell (39) skrev:Det har altid irriteret mig meget. Det er svært at søge i dokumentationen, det kræver en browser og så er der de forbandede frames! Og så er det også træls at skrive værktøjer til for så skal man til at scrape html
Formålet med JavaDoc er at lave dokumentation for mennesker.
Til det formål er HTML bedre end XML.
Hvis formålet var at lave dokumentation til IDE'er, så var XML naturligvis bedre.
Men da JavaDoc blev opfundet kunne Java IDE'er ikke vise JavaDoc og XML var slet ikke opfundet, så XML til IDE'er var ikke på radar skærmen.
De eksisterende Java IDE'er har så lært at leve med HTML.
Hvis nogen skulle have behov for JavaDoc XML, så er det ikke noget problem:
* download en af de mange XML doclet'er
* kør javadoc med jar fil(er) i -docletpath og class name i -doclet
SUN havde engang en XML doclet men den er vist gået tabt undervejs.
Men:
http://jeldoclet.sourceforge.net/
http://code.google.com/p/wo-xmldoclet/
virker fint (jeg kan naturligvis ikke garantere at udseendet af XML'en passer med et konkret behov).
arne_v (41) skrev:
Formålet med JavaDoc er at lave dokumentation for mennesker.
Til det formål er HTML bedre end XML.
Et standardiseret dokumentations xml format + xsl til "menneskevisningen" ville imo have været den sublime løsning.
Pointen er at du kan lave XSLT stylesheets i dag, hvilket gør det direkte idiotisk at autogenere HTML frem for XML.arne_v (45) skrev:Virkeligt.
Hvilket software producent foretrækker XML over HTML til brugerne?
Og *alle* browserne kan forstå XSLT stylesheets i dag, du skal ikke engang bruge serverside manipulation mere!
Windcape (47) skrev:Pointen er at du kan lave XSLT stylesheets i dag,
Windcape (47) skrev:Og *alle* browserne kan forstå XSLT stylesheets i dag, du skal ikke engang bruge serverside manipulation mere!
Ja.
Windcape (47) skrev:hvilket gør det direkte idiotisk at autogenere HTML frem for XML.
Har du overvejet om MS, Oracle, IBM etc. der alle server HTML og ikke XML+XSL bare er nogle store idioter eller om de måske har nogle grunde?
Windcape har ret Java er noget lort. Det kommer jo ikke fra Microsoft. Desuden er det totalt irellevant at Java kan køre 100% ens på Windows, Linux og Mac.
Rigtige fanboys bruger kun sprog, der er Windows only.
- Det gode ved .net er jo netop at man kan argumentere for at det kan køre på Linux, men det kan det bare ikke alligevel, når det skal føres ud i virkeligheden.
.net er noget af det smarteste Microsoft har fundet på siden internet explorer <7.
Rigtige fanboys bruger kun sprog, der er Windows only.
- Det gode ved .net er jo netop at man kan argumentere for at det kan køre på Linux, men det kan det bare ikke alligevel, når det skal føres ud i virkeligheden.
.net er noget af det smarteste Microsoft har fundet på siden internet explorer <7.
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.