mboost-dp1
unknown
ok... Har så aldrig hørt om Ruby... Men godt nok - lad os bare få nogle flere over på .net holdet :)
Når det nu skal være, så er der da snart ikke mange sprog, som ikke findes til .net...
Når det nu skal være, så er der da snart ikke mange sprog, som ikke findes til .net...
Har så aldrig hørt om Ruby
Det er så fordi du lever i en lukket .NET verden, tag lige at lufte ud engang imellem, det er sundt.
mega nemt, En hallo world:
Det er vel ikke meget anderledes end:
#include <iostream.h>
#include <string.h>
class string
{
private:
int size;
char *ptr;
string() : size(0), ptr(new char[1]) { ptr[0] = 0; }
string(const string &s) : size(s.size)
{
ptr = new char[size + 1];
strcpy(ptr, s.ptr);
}
~string()
{
delete [] ptr;
}
friend ostream &operator <<(ostream &, const string &);
string &operator=(const char *);
};
ostream &operator<<(ostream &stream, const string &s)
{
return(stream << s.ptr);
}
string &string::operator=(const char *chrs)
{
if (this != &chrs)
{
delete [] ptr;
size = strlen(chrs);
ptr = new char[size + 1];
strcpy(ptr, chrs);
}
return(*this);
}
int main()
{
string str;
str = "Hello World";
cout << str << endl;
return(0);
}
//
Lige for at bemærke, Ruby != Rails.
#2 Ligegyldig / irrelevant?
Ligegyldig - måske - det er jo bare én brugers mening, så hvis alle andre mener noget andet så har du vel ret.
Men så irrelevant mener jeg nu ikke den er. Jeg mener jo bare at det er vigtigt at se flere muligheder til .net platformen. Jo flere programmøre til .net jo mere materiale kan man bruge/dele - og det er jo altid godt, skulle jeg mene.
Jeg selv programmerer i C#, men er da ikke bleg for at bruge en .net-komponent fra et andet sprog,(Kunne være Ruby.net, VB.net eller Fortran.net for den sags skyld), hvis den gør det arbejde jeg har brug for på en god måde (Og er veldokumenteret!).
#3 takker - så er jeg up-to-date igen :)
#4 Console.WriteLine("Hello World, ;)");
#5
Taget til efterretning :)
Ligegyldig - måske - det er jo bare én brugers mening, så hvis alle andre mener noget andet så har du vel ret.
Men så irrelevant mener jeg nu ikke den er. Jeg mener jo bare at det er vigtigt at se flere muligheder til .net platformen. Jo flere programmøre til .net jo mere materiale kan man bruge/dele - og det er jo altid godt, skulle jeg mene.
Jeg selv programmerer i C#, men er da ikke bleg for at bruge en .net-komponent fra et andet sprog,(Kunne være Ruby.net, VB.net eller Fortran.net for den sags skyld), hvis den gør det arbejde jeg har brug for på en god måde (Og er veldokumenteret!).
#3 takker - så er jeg up-to-date igen :)
#4 Console.WriteLine("Hello World, ;)");
#5
Det er så fordi du lever i en lukket .NET verden, tag lige at lufte ud engang imellem, det er sundt.
Taget til efterretning :)
Det er da rart at det blive implementeret til at bruge .NET, selvom jeg ikke lige tror at det smadre normalt ruby, så det kun bliver ruby.net.
Og hvad grund har man helttaget til at kigge uden for .NET? Vi har jo ikke brug for andet - det kan jo alt. (Og for lige at sige det, så tror jeg at de fleste PHP folk har det på præsis samme måde: Hvorfor kigge på .NET? Vi kan hvad vi vil.)
Og for ikke at sætte mig selv i bås, så har jeg kigget på: PHP,Java,Ruby, Ruby on Rails, C++, .NET og RealBasic.
Og så lige en bemærkning:
PHP.NET findes
Java.NET findes
Ruby.NET kommer jo så til at findes
C++.NET findes
Delhi.NET findes
Python.NET findes
og *.NET findes om 10 år :D
Og hvad grund har man helttaget til at kigge uden for .NET? Vi har jo ikke brug for andet - det kan jo alt. (Og for lige at sige det, så tror jeg at de fleste PHP folk har det på præsis samme måde: Hvorfor kigge på .NET? Vi kan hvad vi vil.)
Og for ikke at sætte mig selv i bås, så har jeg kigget på: PHP,Java,Ruby, Ruby on Rails, C++, .NET og RealBasic.
Og så lige en bemærkning:
PHP.NET findes
Java.NET findes
Ruby.NET kommer jo så til at findes
C++.NET findes
Delhi.NET findes
Python.NET findes
og *.NET findes om 10 år :D
#4 Hvordan kan man ud fra print "Hello World" bestemme sig for om et sprog er nemt eller ej? Det er da vel meget afhængig af opgaven!
Der er mange andre sprog som klare "Hello World" opgaven ligeså godt eller bedre. Jeg ville dog ikke udvikle det næste CRM system i det!
APL: 'Hello World'
Batch filer: echo "Hello World"
QBasic: print "Hello World"
SQL: select 'Hello World' from <some table with one row>;
Der er mange andre sprog som klare "Hello World" opgaven ligeså godt eller bedre. Jeg ville dog ikke udvikle det næste CRM system i det!
APL: 'Hello World'
Batch filer: echo "Hello World"
QBasic: print "Hello World"
SQL: select 'Hello World' from <some table with one row>;
[offtopic]
#12 inlighten me, please...
Hvad mener du med inlejret? Tror da ikke der er mange der bare pløjer SQL og HTML ind i koden på må og få, men opbyger det via objekter og strukture... Jojo - der er selvfølge SQL-kode i de klasser, som i sidste ende, skal udføre en handling, men hvorfor er det "slamkode"?
[/offtopic]
#12 inlighten me, please...
#10 Aha... hmm ok hvilket ORM/Web-framework har .NET at byde på? Det er jo ikke alle virksomheder der er intereseret i slamkode med indlejrede SQL-sætnigner, HTML osv.
Hvad mener du med inlejret? Tror da ikke der er mange der bare pløjer SQL og HTML ind i koden på må og få, men opbyger det via objekter og strukture... Jojo - der er selvfølge SQL-kode i de klasser, som i sidste ende, skal udføre en handling, men hvorfor er det "slamkode"?
[/offtopic]
#10
Så længe det ikke understøttes fuldt ud på Linux/Mac/Solaris/what-ever er det altid interessant at kikke uden for dotNET.
Desuden drive firmaet hvor jeg er ansat, et ASP center. Forskellen på om jeg kompilere med C++/Native eller C++.Net er 25% mere i CPU forbrug og 40% mere hukommelsesforbrug. Sagt på en anden måde, så kan vi have en del flere bruger pr. server ved at undgå dotNET, hvilket er lig med større indtjening.
Og hvad grund har man helttaget til at kigge uden for .NET?
Så længe det ikke understøttes fuldt ud på Linux/Mac/Solaris/what-ever er det altid interessant at kikke uden for dotNET.
Desuden drive firmaet hvor jeg er ansat, et ASP center. Forskellen på om jeg kompilere med C++/Native eller C++.Net er 25% mere i CPU forbrug og 40% mere hukommelsesforbrug. Sagt på en anden måde, så kan vi have en del flere bruger pr. server ved at undgå dotNET, hvilket er lig med større indtjening.
#15 Hibernate er til Java, NHibernate er en C# port. Ellers flot søgning du har lavet med google må jeg sige.
Faktum er at der intet framework føler med til .NET, modsat f.eks. JDev. Jo jo MS arbejder da godt nok på LINQ, hvis altså ikke dette hives ud af planerne ligesom så meget andet fra Microsoft - det kommer i alt fald ikke med i C# 3.0.
http://www.it-eye.nl/weblog/2006/06/13/it-eye-prog...
Faktum er at der intet framework føler med til .NET, modsat f.eks. JDev. Jo jo MS arbejder da godt nok på LINQ, hvis altså ikke dette hives ud af planerne ligesom så meget andet fra Microsoft - det kommer i alt fald ikke med i C# 3.0.
http://www.it-eye.nl/weblog/2006/06/13/it-eye-prog...
#17 mrmorris:
Bliver LINQ forsinket? Det melder The LINQ Project altså intet om, men jeg kan da have overset noget.
Bliver LINQ forsinket? Det melder The LINQ Project altså intet om, men jeg kan da have overset noget.
Hvis der skal laves stabil kode så er det .net som skal vælges.
Java vil altid være bagud .net, især hvis man ser på alle de teknologier som kommer her i .net 3.0 og 3.5 (bl.a. linq). Til den tid vil java være lysår bagud på desktoppen, og det samme med php på web. Opensource-communitiet omkring .net er også stigende.
Den store forskel ligger blandt andet også i visual studio, samt dokumentationen.
/duckie
Java vil altid være bagud .net, især hvis man ser på alle de teknologier som kommer her i .net 3.0 og 3.5 (bl.a. linq). Til den tid vil java være lysår bagud på desktoppen, og det samme med php på web. Opensource-communitiet omkring .net er også stigende.
Den store forskel ligger blandt andet også i visual studio, samt dokumentationen.
/duckie
#15
Så bare fordi det hedder .Net, så må man kun bruge løsninger der er leveret af Microsoft? Jeg bruger selv Wilson ORM, og det er da for dumt at sidde og pille sig i navlen, og sige at alle der bruger .Net ikke kan benytte sig af ORM, bare fordi Microsoft ikke har frigivet et produkt til det.
Og sry for mit manglende prefix. Om du kalder det Hibernate eller NHibernate er for mig underordnet, da produktet i sidste ende er det samme. Det samme gør sig gældende for mange andre produkter der er portet fra Java til .Net, og lige har fået sat et N foran navnet.
Så bare fordi det hedder .Net, så må man kun bruge løsninger der er leveret af Microsoft? Jeg bruger selv Wilson ORM, og det er da for dumt at sidde og pille sig i navlen, og sige at alle der bruger .Net ikke kan benytte sig af ORM, bare fordi Microsoft ikke har frigivet et produkt til det.
Og sry for mit manglende prefix. Om du kalder det Hibernate eller NHibernate er for mig underordnet, da produktet i sidste ende er det samme. Det samme gør sig gældende for mange andre produkter der er portet fra Java til .Net, og lige har fået sat et N foran navnet.
#18 Det er kun rygter fra blogger-verdenen (som dog ofte er mere pålidelig end noget andet) og i disse tider hvor MS trækker teknologier tilbage, må det anses som en meget stor mulighed. Det tekniske rationale er som følger.
WinFX (Indigo) bliver omdøbt til .NET Framework 3.0, som dog stadig kører på CLR 2.0. Derfor vil C# 3.0 ikke være med i næste .NET version men istedet først komme ud med Orcas familien (engang i 2007, sammen med VB 9.0) om måske omdøbt til C# 4.0 for at komme på højde med frameworket.
#20 Hvorfor adresserer du dig selv? Anyway, du har ret i at C# og .NET som sprog (syntaktisk og semantisk) har fordel af ikke at have 10 års API slæbende efter sig, men Java er (om en måneds tid) Open Source, har et community helt uden lige og så er man ikke låst fast på platform og underlige Microsoft licenser.
WinFX (Indigo) bliver omdøbt til .NET Framework 3.0, som dog stadig kører på CLR 2.0. Derfor vil C# 3.0 ikke være med i næste .NET version men istedet først komme ud med Orcas familien (engang i 2007, sammen med VB 9.0) om måske omdøbt til C# 4.0 for at komme på højde med frameworket.
#20 Hvorfor adresserer du dig selv? Anyway, du har ret i at C# og .NET som sprog (syntaktisk og semantisk) har fordel af ikke at have 10 års API slæbende efter sig, men Java er (om en måneds tid) Open Source, har et community helt uden lige og så er man ikke låst fast på platform og underlige Microsoft licenser.
#14
Og hvor mange % større er udviklingsomkostningerne så ? Og hvor mange % større er jeres software fejl ?
Chancen for bufferoverrun osv er langt størrere i C++ (og lignende) kode end i f.eks. C#.net osv.
Samt udviklingstiden er også størrere (jaja nu er der sikkert nogle C++ nørder der vil påstå det modsatte)
Og hvor mange % større er udviklingsomkostningerne så ? Og hvor mange % større er jeres software fejl ?
Chancen for bufferoverrun osv er langt størrere i C++ (og lignende) kode end i f.eks. C#.net osv.
Samt udviklingstiden er også størrere (jaja nu er der sikkert nogle C++ nørder der vil påstå det modsatte)
"men Java er (om en måneds tid) Open Source"
Og hvorfor er det en fordel? Jeg ville sige det hurtigt kan blive en ulempe..!
"har et community helt uden lige"
Har du lagt mærke til de store communities som microsoft har oprettet/opbygget? Windowsforms.net, asp.net, codeplex osv..
Foruden de selvstændige som f.eks. codeproject.com, samt de danske dotnetforum.dk, activedeveloper.dk (samt flere))
"og så er man ikke låst fast på platform"
Så længe det er den mest udbredte platform i verden den er låst til (foruden mono og lign. projekter) så er det altså bare ikke vigtigt. Jeg er personlig ligeglad. Det er en grund til det er windows only. At et er for at lave lock-in behøver vel ikke være en hemmelighed, men så længe microsoft ikke lukker de opensource-implementeringer, så kudos til dem.
"underlige Microsoft licenser."
Hvilke underlige licenser?
Og hvorfor er det en fordel? Jeg ville sige det hurtigt kan blive en ulempe..!
"har et community helt uden lige"
Har du lagt mærke til de store communities som microsoft har oprettet/opbygget? Windowsforms.net, asp.net, codeplex osv..
Foruden de selvstændige som f.eks. codeproject.com, samt de danske dotnetforum.dk, activedeveloper.dk (samt flere))
"og så er man ikke låst fast på platform"
Så længe det er den mest udbredte platform i verden den er låst til (foruden mono og lign. projekter) så er det altså bare ikke vigtigt. Jeg er personlig ligeglad. Det er en grund til det er windows only. At et er for at lave lock-in behøver vel ikke være en hemmelighed, men så længe microsoft ikke lukker de opensource-implementeringer, så kudos til dem.
"underlige Microsoft licenser."
Hvilke underlige licenser?
"Desuden drive firmaet hvor jeg er ansat, et ASP center. Forskellen på om jeg kompilere med C++/Native eller C++.Net er 25% mere i CPU forbrug og 40% mere hukommelsesforbrug. Sagt på en anden måde, så kan vi have en del flere bruger pr. server ved at undgå dotNET, hvilket er lig med større indtjening."
Den er nemt at svinge ud. Jeg påstår så til gengæld, at vi har øget vores performance med 20000% efter vi har skiftet til .net.
At der vil være performanceforskel mellem c++ og .net tror jeg gerne på, men så høje tal virker efter min mening overdrevne.
Den er nemt at svinge ud. Jeg påstår så til gengæld, at vi har øget vores performance med 20000% efter vi har skiftet til .net.
At der vil være performanceforskel mellem c++ og .net tror jeg gerne på, men så høje tal virker efter min mening overdrevne.
#14: Det lyder vildt i forhold til hvad jeg oplever med C#/.NET applikationer. Men selvom vi hypotetisk antager at tingene kører 25% langsommere ved .NET, så er det nu sjældent her jeg oplever flaskehalse i de systemer jeg udvikler til hverdag - det er oftest databaseservere der udgør flaskehalsen.
Som et eksempel har jeg pt. en driftserver skrevet i C#/.NET kørende med 10.000 opkoblede klienter og et konstant dataflow herimellem og den bruger ca. 3-5% CPU-kraft på serveren, det performer faktisk langt over min umiddelbare forventning da jeg skrev serveren.
Som et eksempel har jeg pt. en driftserver skrevet i C#/.NET kørende med 10.000 opkoblede klienter og et konstant dataflow herimellem og den bruger ca. 3-5% CPU-kraft på serveren, det performer faktisk langt over min umiddelbare forventning da jeg skrev serveren.
#10
Hvorfor overhovedet tænke på at bygge huse med andet end gasbeton? Man kan jo alt med det, og så er det skide stabilt. ;-)
Sådanne udsagn giver mig altid lidt kriller ned af nakken. .NET har klart en række vigtige fordele, men jeg betragter det stadig som andenrangssoftware i forhold til programmer "native" til operativsystemet. For de performance-krævende programmer, f.eks. ens teksteditor eller browser, kan .NET bare ikke stille noget op. Det er for sløvt og tungt.
Desuden er det at programmere PC'er jo ikke alt. Der findes uden tvivl flere microcontrollere end PC'er i denne verden, og de kan ved den gode grød ikke programmeres i .NET. Desuden er der ofte krav om realtid i sådanne systemer. Kan man overhovedet lave f.eks. et hårdt realtidssystem i .NET? I don't think so.
Og hvad grund har man helttaget til at kigge uden for .NET? Vi har jo ikke brug for andet - det kan jo alt.
Hvorfor overhovedet tænke på at bygge huse med andet end gasbeton? Man kan jo alt med det, og så er det skide stabilt. ;-)
Sådanne udsagn giver mig altid lidt kriller ned af nakken. .NET har klart en række vigtige fordele, men jeg betragter det stadig som andenrangssoftware i forhold til programmer "native" til operativsystemet. For de performance-krævende programmer, f.eks. ens teksteditor eller browser, kan .NET bare ikke stille noget op. Det er for sløvt og tungt.
Desuden er det at programmere PC'er jo ikke alt. Der findes uden tvivl flere microcontrollere end PC'er i denne verden, og de kan ved den gode grød ikke programmeres i .NET. Desuden er der ofte krav om realtid i sådanne systemer. Kan man overhovedet lave f.eks. et hårdt realtidssystem i .NET? I don't think so.
Og hvorfor er det en fordel? Jeg ville sige det hurtigt kan blive en ulempe..!
Det er en fordel, for man ikke er låst til en speciel implementation eller platform og har fuld adgang til koden. .NET er til sammenligning helt black box udvikling. Java's JSR procedure betyder at samtlige udviklere og samarbejdspartnere kan tage del i udviklingen af sproget. Hos Microsoft er det mere som et diktatur (Anders Hejlsberg). Behøver jeg påpege hvorledes de slagtede VB6 og fuldstændig efterlod det største business software community til at sejle deres egen sø?
Har du lagt mærke til de store communities som microsoft har oprettet/opbygget?
Alle dem du nævner er ejet af Microsoft bortset fra codeproject. På Sourceforge.net, hvor du finder rigtige community projekter, er Java det mest populære sprog. Til forskel fra .NET, udvikler sværvægtere som f.eks. Oracle og Apache utallige åbne Java komponenter. Seriøse .NET komponenter er typisk lukkede og hundedyre.
Så længe det er den mest udbredte platform i verden den er låst til (foruden mono og lign.)
Mono implementere kun en lille del af .NET 1.0, og er håbløs bagud så kan ikke bruges til meget andet en "Hello World" applikationer. Med Java får du derimod valgfrihed og kan vælge at køre på Mac, Windows, Linux, Sparc mf.
Hvilke underlige licenser?
Microsoft's EULA specificerer at man ikke ejer softwaren, men den kun er licenseret, hvilket tvinger forbrugeren til at acceptere div. krav og acceptere opgraderingsomkostninger med jævne mellemrum - ligesom det nu er kommet frem at Windows ringer hjem med div. oplysninger.
Produkt registrering, produkt aktivering, amputerede produkter (VC++ 2003SE har f.eks. ingen uden optimizer), udokumenterede protokoller, afvigelser fra standarderne og manglende sikkerhed er også irretationsmomumenter jeg er stødt på det sidste års tid.
#28: Til forskel fra VB6 og Java er stortset hele .NET Frameworket en ECMA og ISO standard, alle specifikationer er med andre ord åbne og det er også grunden til at projekter som Mono kan lade sig gøre og faktisk er de ved at være ret godt med - ihvertfald til server og ASP.NET applikationer.
For mere info, se:
ISO/IEC 23270 (C#)
ISO/IEC 23271 (CLI)
Ecma-334(C#)
Ecma-335(CLI)
For mere info, se:
ISO/IEC 23270 (C#)
ISO/IEC 23271 (CLI)
Ecma-334(C#)
Ecma-335(CLI)
#28 -> BlackBox-udvikling? Sikker noget fis, det fortæller en del om at du ikke har undersøgt sagerne ordentligt
"The Common Language Infrastructure (CLI) is the ECMA standard that describes the core of the .NET Framework world. The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification."
http://www.microsoft.com/downloads/details.aspx?Fa...
samt
"In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the Common Language Infrastructure (CLI) and C# specifications"
http://msdn.microsoft.com/netframework/ecma/
CLI og c# er altså en godkendt standart
" Developers interested in the internal workings of the .NET Framework can explore this implementation of the CLI to see how garbage collection works, JIT compilation and verification is handled, security protocols implemented, and the organization of frameworks and virtual object systems."
Hvori består det black-boxede??
"Behøver jeg påpege hvorledes de slagtede VB6 og fuldstændig efterlod det største business software community til at sejle deres egen sø?"
Slagtede? Læs lige her:
http://msdn.microsoft.com/vbrun/support.aspx
Som alle andre produkter har de kun en vis livstid. Det er 6 år siden det blev releaset. Først Marts 2008 er det ikke muligt at få support.
"Alle dem du nævner er ejet af Microsoft bortset fra codeproject."
Og? Det er aktive communities, med masser af medlemmer.
"På Sourceforge.net, hvor du finder rigtige community projekter, er Java det mest populære sprog."
Det tvivler jeg ikke på. Men som du siger har java også en del flere år på bagen - .net er ved at få et godt momentum, og der vil komme langt flere.
"Til forskel fra .NET, udvikler sværvægtere som f.eks. Oracle og Apache utallige åbne Java komponenter."
Det samme gør microsoft. Microsofts standart-kontroller er f.eks. bedre end java'
"Seriøse .NET komponenter er typisk lukkede og hundedyre."
Hvilket også gælder java.
"ligesom det nu er kommet frem at Windows ringer hjem med div. oplysninger."
Relevans til emnet?
"Microsoft's EULA specificerer at man ikke ejer softwaren, men den kun er licenseret, hvilket tvinger forbrugeren til at acceptere div. krav og acceptere opgraderingsomkostninger med jævne mellemrum"
og hvor i _alverden_ står det henne? Du disker op med "fakta", så lad os se nogle kilder.
Hvis jeg _læser_ EULAen for f.eks. 1.1 (den første jeg fandt) står der sjovt nok intet af det du skriver
Se http://msdn.microsoft.com/library/default.asp?url=...
"Produkt registrering, produkt aktivering,"
Og?
"VC++ 2003SE har f.eks. ingen uden optimizer)"
Og? Undskyld mig, men det er sku da også for dumt at købe en version, som tydeligvis ikke indholder en optimiser, hvis du har brug for det. Endnu mere dumt er det at pive over det bagefter.
"The Common Language Infrastructure (CLI) is the ECMA standard that describes the core of the .NET Framework world. The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification."
http://www.microsoft.com/downloads/details.aspx?Fa...
samt
"In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the Common Language Infrastructure (CLI) and C# specifications"
http://msdn.microsoft.com/netframework/ecma/
CLI og c# er altså en godkendt standart
" Developers interested in the internal workings of the .NET Framework can explore this implementation of the CLI to see how garbage collection works, JIT compilation and verification is handled, security protocols implemented, and the organization of frameworks and virtual object systems."
Hvori består det black-boxede??
"Behøver jeg påpege hvorledes de slagtede VB6 og fuldstændig efterlod det største business software community til at sejle deres egen sø?"
Slagtede? Læs lige her:
http://msdn.microsoft.com/vbrun/support.aspx
Som alle andre produkter har de kun en vis livstid. Det er 6 år siden det blev releaset. Først Marts 2008 er det ikke muligt at få support.
"Alle dem du nævner er ejet af Microsoft bortset fra codeproject."
Og? Det er aktive communities, med masser af medlemmer.
"På Sourceforge.net, hvor du finder rigtige community projekter, er Java det mest populære sprog."
Det tvivler jeg ikke på. Men som du siger har java også en del flere år på bagen - .net er ved at få et godt momentum, og der vil komme langt flere.
"Til forskel fra .NET, udvikler sværvægtere som f.eks. Oracle og Apache utallige åbne Java komponenter."
Det samme gør microsoft. Microsofts standart-kontroller er f.eks. bedre end java'
"Seriøse .NET komponenter er typisk lukkede og hundedyre."
Hvilket også gælder java.
"ligesom det nu er kommet frem at Windows ringer hjem med div. oplysninger."
Relevans til emnet?
"Microsoft's EULA specificerer at man ikke ejer softwaren, men den kun er licenseret, hvilket tvinger forbrugeren til at acceptere div. krav og acceptere opgraderingsomkostninger med jævne mellemrum"
og hvor i _alverden_ står det henne? Du disker op med "fakta", så lad os se nogle kilder.
Hvis jeg _læser_ EULAen for f.eks. 1.1 (den første jeg fandt) står der sjovt nok intet af det du skriver
Se http://msdn.microsoft.com/library/default.asp?url=...
"Produkt registrering, produkt aktivering,"
Og?
"VC++ 2003SE har f.eks. ingen uden optimizer)"
Og? Undskyld mig, men det er sku da også for dumt at købe en version, som tydeligvis ikke indholder en optimiser, hvis du har brug for det. Endnu mere dumt er det at pive over det bagefter.
#23 disky
Udviklingsomkostninger afhænger af hvor gode funktionsbiblioteker du har og om du først lige skal til at start et nyt større projekt op. Jeg har lige knap 1 mill. linier C++ kode. Tanken om at flytte til C# får mig ikke lige til at tænke på mere fritid og færre omkostninger. Vi har 280 kunder som ikke lige venter på at vi flytter koden til et andet sprog OG introducere nye børnesygdomme.
Om vi har % større softwarefejl ved jeg ikke. Det afhænger meget af hvor dygtig en programmør du er og hvor godt dit produkt er testet. Jeg har flere gange set dårlige programmører tro at bare fordi dotNET har en garbage collector, kan de svine med hukommelsen og programmere helt hen i vejret.
Ang. bufferoverrun er det igen et spørgsmål om evner. Der er to måder at implementere en streng i C++. Enten via en array eller via en streng klasse der dynamisk udvider sig når du fylder mere i. Streng typen i dotNET er ikke noget unikt. De fleste C++ programmører har kopieret deres fra deres første lærebøger i årevis. I vores kode findes det ikke meget som er defineres via en fast bufferstørrelse.
Udviklingstid afhænger igen af hvor mange funktionsbiblioteker du har. Vi har næsten ligeså mange som der er i dotNET (with thanks to sourceforge.net :-)
Hvis jeg skulle til at skrive den første linie kode i dag, så ville jeg da helt sikkert vælge C#. Det er et klart mere stilrent sprog at arbejde med.
Udviklingsomkostninger afhænger af hvor gode funktionsbiblioteker du har og om du først lige skal til at start et nyt større projekt op. Jeg har lige knap 1 mill. linier C++ kode. Tanken om at flytte til C# får mig ikke lige til at tænke på mere fritid og færre omkostninger. Vi har 280 kunder som ikke lige venter på at vi flytter koden til et andet sprog OG introducere nye børnesygdomme.
Om vi har % større softwarefejl ved jeg ikke. Det afhænger meget af hvor dygtig en programmør du er og hvor godt dit produkt er testet. Jeg har flere gange set dårlige programmører tro at bare fordi dotNET har en garbage collector, kan de svine med hukommelsen og programmere helt hen i vejret.
Ang. bufferoverrun er det igen et spørgsmål om evner. Der er to måder at implementere en streng i C++. Enten via en array eller via en streng klasse der dynamisk udvider sig når du fylder mere i. Streng typen i dotNET er ikke noget unikt. De fleste C++ programmører har kopieret deres fra deres første lærebøger i årevis. I vores kode findes det ikke meget som er defineres via en fast bufferstørrelse.
Udviklingstid afhænger igen af hvor mange funktionsbiblioteker du har. Vi har næsten ligeså mange som der er i dotNET (with thanks to sourceforge.net :-)
Hvis jeg skulle til at skrive den første linie kode i dag, så ville jeg da helt sikkert vælge C#. Det er et klart mere stilrent sprog at arbejde med.
#30 duckfighter
Jeg tror du har misforstået, hvad der menes det her blackbox-halløj. Det har ikke noget som helst at gøre med om teknologien er ECMA-standardiseret, men om teknologien udvikles i åbent eller lukket forum.
Microsoft frigiver ganske rigtigt CLI'en og C# som ECMA-standarder, så andre kan se hvordan de fungerer og har mulighed for at lave alternative implementationer. Men nye tiltag til den næste version af .NET-platformen dikteres kun et sted fra: Microsoft.
Dette er til forskel fra Sun og Java. Her sker nyudvikling igennem JCP, hvor andre personer, organisationer og firmaer har mulighed for at deltage.
Jeg tror du har misforstået, hvad der menes det her blackbox-halløj. Det har ikke noget som helst at gøre med om teknologien er ECMA-standardiseret, men om teknologien udvikles i åbent eller lukket forum.
Microsoft frigiver ganske rigtigt CLI'en og C# som ECMA-standarder, så andre kan se hvordan de fungerer og har mulighed for at lave alternative implementationer. Men nye tiltag til den næste version af .NET-platformen dikteres kun et sted fra: Microsoft.
Dette er til forskel fra Sun og Java. Her sker nyudvikling igennem JCP, hvor andre personer, organisationer og firmaer har mulighed for at deltage.
#25
Det er ikke noget som er nemt at svinge ud. Det er noget som er testet. De sidste 2 år har vi sørget for at vores kode kunne kompileres i C++.NET. Det meste er godt nok unmanaged code, men enkelt funktionsbiblioteker er testet med som managed code. Jeg er ikke naiv. Hvis fremtiden kun hedder dotNET (usandsynligt) vil jeg gerne være bare lidt forberedt.
#26
Jeg sagde ikke at programmet var 25% langsommere, jeg sagde at den brugte 25% mere CPU. Det meste er koden er ikke mere en 5-10% langsommere, men ofte mere ressourcekrævende. Andre steder er det 300% langsommere.
Vi har omkring 200 samtidige brugere på vores ASP (terminalserver). Dvs. at serveren er både server og klient. Disse kunder arbejder bl.a. med digitale røntgenbilleder der hver har en størrelse på 3-5MB (gang selv op). Her kan dotNET ikke være med ret længe. Jeg har ekstremt meget brug for at allokeret hukommelse frigives så hurtigt som overhovedet muligt og her er GC ikke en hjælp. Selv forholdsvis simple algoritmer til billedbehandling er ekstremt langsomme skrevet i dotNET. Igen - skulle jeg starte forfra havde jeg nok fundet en løsning med C#. F.eks. færre bruger pr. server :-)
Ang. dine 10.000 opkoblede klienter, så går jeg ud fra at det drejer sig om en webserver lignende løsning? Hvis det er ASP, må det være dyrt med de 10.000 licenser du betaler til M$. Og ja – det er databasen som er flaskehalsen. Ergo er det jo den (læs harddisken) som laver det meste arbejde og ikke dit program, så det er da klart du ligger på 3-5%. Dit program bruger mere tid på at vente på forbindelser og harddisk end egentligt arbejde. (skrevet med forbehold for at jeg ikke ved hvad dit program laver).
Java er da heller ikke den rene engel. Vi har et talegenkendelse produkt baseret på Sphinx. Det findes i en Java version og en C version. Vi bruger Java versionen på PC’er, men kan du gætte hvilken version der IKKE virker på en PDA?!
Det er ikke noget som er nemt at svinge ud. Det er noget som er testet. De sidste 2 år har vi sørget for at vores kode kunne kompileres i C++.NET. Det meste er godt nok unmanaged code, men enkelt funktionsbiblioteker er testet med som managed code. Jeg er ikke naiv. Hvis fremtiden kun hedder dotNET (usandsynligt) vil jeg gerne være bare lidt forberedt.
#26
Jeg sagde ikke at programmet var 25% langsommere, jeg sagde at den brugte 25% mere CPU. Det meste er koden er ikke mere en 5-10% langsommere, men ofte mere ressourcekrævende. Andre steder er det 300% langsommere.
Vi har omkring 200 samtidige brugere på vores ASP (terminalserver). Dvs. at serveren er både server og klient. Disse kunder arbejder bl.a. med digitale røntgenbilleder der hver har en størrelse på 3-5MB (gang selv op). Her kan dotNET ikke være med ret længe. Jeg har ekstremt meget brug for at allokeret hukommelse frigives så hurtigt som overhovedet muligt og her er GC ikke en hjælp. Selv forholdsvis simple algoritmer til billedbehandling er ekstremt langsomme skrevet i dotNET. Igen - skulle jeg starte forfra havde jeg nok fundet en løsning med C#. F.eks. færre bruger pr. server :-)
Ang. dine 10.000 opkoblede klienter, så går jeg ud fra at det drejer sig om en webserver lignende løsning? Hvis det er ASP, må det være dyrt med de 10.000 licenser du betaler til M$. Og ja – det er databasen som er flaskehalsen. Ergo er det jo den (læs harddisken) som laver det meste arbejde og ikke dit program, så det er da klart du ligger på 3-5%. Dit program bruger mere tid på at vente på forbindelser og harddisk end egentligt arbejde. (skrevet med forbehold for at jeg ikke ved hvad dit program laver).
Java er da heller ikke den rene engel. Vi har et talegenkendelse produkt baseret på Sphinx. Det findes i en Java version og en C version. Vi bruger Java versionen på PC’er, men kan du gætte hvilken version der IKKE virker på en PDA?!
Lidt sjovt at der er så meget traction omkring ruby for tiden.
Mht. .net vs. java så er der fordele og ulemper, her er en ikke fyldestgørende oversigt:
Java fordele:
Sproget er godt forstået, idet det er en stabil platform med en del år på bagen.
Sproget/platformen supporteres af langt flere store IT firmaer (Oracle, HP, IBM, SUN mfl.).
Platformen er for længst kommet forbi børnesygdomsstadiet.
Er det mest platformsuafhængige sprog (dvs. hvis man kigger på .net vs. java).
Java platformen udvikles åbent.
Der er frit valg af platformsleverandør samt OS leverandør på serversiden (websphere, jboss osv.).
Ulemper:
Idet java har en del år på bagen, er der "særheder" grundet legacy.
Skal du skrive platformsuafhængigt har det sine begrænsninger.
Få "små" software huse og udviklere supporterer java.
.Net fordele:
Platformen er optimeret til OS, hvilket ihvertfald i teorien burde forbedre performance ift. java.
Stortset ingen legacy og dermed er sproget meget logisk opbygget ift. idags standarder.
Rigtigt mange kan udvikle til platformen, da der er lavet compilere for stortset alle sprogtyper.
Massere af små udviklingshuse.
Ulemper:
En relativt ny platform, mange svagheder er ikke fuldt forstået/kendt endnu.
Kun en platforms og OS leverandør (nej, mono er ikke seriøst endnu, kom igen når et stort projekt kører på mono).
Microsoft vs. the world syndrom.
Generelt er begge fortolkede sprog med de ulemper det indebærer (forøget memory og cpu forbrug - i tilfældet common lisp (som vel nok er den ældste fortolkede sprog platform) regner man med gennemsnitligt 10% dårligere cpu udnyttelse). Idet det må forventes at visse dele af .NET clr vil blive preloaded med Vista boot kan man forvente at .NET vil få bedre startup tider end java programmer engang i fremtiden - som det er nu er det dog min oplevelse at sammenligneligt komplekse programmer starter hurtigere på java (ihvertfald på 2k, ved ikke om det er anderledes på XP?).
Mht. .net vs. java så er der fordele og ulemper, her er en ikke fyldestgørende oversigt:
Java fordele:
Sproget er godt forstået, idet det er en stabil platform med en del år på bagen.
Sproget/platformen supporteres af langt flere store IT firmaer (Oracle, HP, IBM, SUN mfl.).
Platformen er for længst kommet forbi børnesygdomsstadiet.
Er det mest platformsuafhængige sprog (dvs. hvis man kigger på .net vs. java).
Java platformen udvikles åbent.
Der er frit valg af platformsleverandør samt OS leverandør på serversiden (websphere, jboss osv.).
Ulemper:
Idet java har en del år på bagen, er der "særheder" grundet legacy.
Skal du skrive platformsuafhængigt har det sine begrænsninger.
Få "små" software huse og udviklere supporterer java.
.Net fordele:
Platformen er optimeret til OS, hvilket ihvertfald i teorien burde forbedre performance ift. java.
Stortset ingen legacy og dermed er sproget meget logisk opbygget ift. idags standarder.
Rigtigt mange kan udvikle til platformen, da der er lavet compilere for stortset alle sprogtyper.
Massere af små udviklingshuse.
Ulemper:
En relativt ny platform, mange svagheder er ikke fuldt forstået/kendt endnu.
Kun en platforms og OS leverandør (nej, mono er ikke seriøst endnu, kom igen når et stort projekt kører på mono).
Microsoft vs. the world syndrom.
Generelt er begge fortolkede sprog med de ulemper det indebærer (forøget memory og cpu forbrug - i tilfældet common lisp (som vel nok er den ældste fortolkede sprog platform) regner man med gennemsnitligt 10% dårligere cpu udnyttelse). Idet det må forventes at visse dele af .NET clr vil blive preloaded med Vista boot kan man forvente at .NET vil få bedre startup tider end java programmer engang i fremtiden - som det er nu er det dog min oplevelse at sammenligneligt komplekse programmer starter hurtigere på java (ihvertfald på 2k, ved ikke om det er anderledes på XP?).
#30 Kun C# og CLI er ECMA standardiseret, som blinklys nævner, simpelthen ved at MS kommer og siger "dette skal være standard".
Men det er .NET jo ikke, og det er her der er en betydelig forskel for al funktionaliteten kommer fra API'et, og det er stadig lige så lukket som det altid har været.
Men det er .NET jo ikke, og det er her der er en betydelig forskel for al funktionaliteten kommer fra API'et, og det er stadig lige så lukket som det altid har været.
Deternal:
Du har bestemt ret i de fleste af dine pointer.
Men ligefrem kalde .net for en relativ ny platform er måske lige at stramme den lidt. Så ny er den nu heller ikke længere :) Men det er selvfølgelig en definitionssag.
Angående JCP'er så er det i teorien en god ting, man det tager ufatteligt lang tid at få dem gennemført. Har selv arbejdet på en virksomhed som var med til at få 3d på j2me platformens JCP igennem, og det gik ufatteligt langsomt. Så lutter lagkage er det ikke.
Det er korrekt at .net kun findes til en platform hvor den er implementeret ordentligt, men denne ene platform er også meget udbredt, så et så stort problem som at Java ikke er native på nogen platforms synes jeg nu ikke det er.
Det med langsom .net start må skyldes du kører 2k, jeg har ingen problemmer på nogle af mine XP maskiner, men .net er jo også en del af XP hvilket nok forklarer det :)
Du har bestemt ret i de fleste af dine pointer.
Men ligefrem kalde .net for en relativ ny platform er måske lige at stramme den lidt. Så ny er den nu heller ikke længere :) Men det er selvfølgelig en definitionssag.
Angående JCP'er så er det i teorien en god ting, man det tager ufatteligt lang tid at få dem gennemført. Har selv arbejdet på en virksomhed som var med til at få 3d på j2me platformens JCP igennem, og det gik ufatteligt langsomt. Så lutter lagkage er det ikke.
Det er korrekt at .net kun findes til en platform hvor den er implementeret ordentligt, men denne ene platform er også meget udbredt, så et så stort problem som at Java ikke er native på nogen platforms synes jeg nu ikke det er.
Det med langsom .net start må skyldes du kører 2k, jeg har ingen problemmer på nogle af mine XP maskiner, men .net er jo også en del af XP hvilket nok forklarer det :)
#37: Du har ret, det er et definitionsspørgsmål, lidt ligesom nogle snakker om *nix som noget nyt på serversiden - selvom NT da efterhånden har nogle år på bagen er det vel stadig *nix der er det "gamle" serversystem og NT der er nyt.
Mht. .NET er min pointe blot at når man stiller .NET og Java overfor hinanden må Java alt andet lige ses som en mere stabil og kendt platform med de fordele det bringer, og .NET som noget mere nyt, men knap så stabilt og kendt (relativt set - har nu ikke erfaring for at .NET app's ligefrem crasher). En af de absolutte fordele for .NET er i den sammenhæng, som jeg nævner, at .NET så er mere logisk opbygget da der ikke er så meget legacy der skal tages hensyn til. Præcis som NT platformen er mere logisk end 9x platformen af præcis samme årsag.
Personligt anser jeg den manglende mulighed for at vælge .NET app server og serverplatform leverandør som det største problem med .NET, omend jeg nok ville vente til 2008 før jeg ville turde binde an på at binde infrastruktur til .NET platformen - noget jeg ikke ville have noget problem med at gøre med Java platformen - præcist fordi .NET stadigvæk er lidt for nyt i den sammenhæng. Men til webapp's er det da fint nok, og det er også min oplevelse at det i den sammenhæng har nogle styrker og er Java overlegent.
Spørgsmålet er så om ikke næste udgave af J2EE springer foran .NET igen.
Når det så er sagt har jeg aldrig rigtigt forstået hvorfor MS har været så forhippede på at udvikle .NET fremfor at gå ind i Java processen - basalt set løser de jo samme problem, og der er jo, modsat MS påstand om andet, intet til hinder for at udvide java ift. standarden, så længe man overholder minimumskravene (og det var det, som var problemet med MS java, at de havde fjernet dele af java, ikke at de havde tilføjet noget). Det kan jeg kun se som at de er bange for at miste nogle af deres andre lock-ins og vil skabe et nyt og det er jeg kraftigt modstander af.
Mht. .NET er min pointe blot at når man stiller .NET og Java overfor hinanden må Java alt andet lige ses som en mere stabil og kendt platform med de fordele det bringer, og .NET som noget mere nyt, men knap så stabilt og kendt (relativt set - har nu ikke erfaring for at .NET app's ligefrem crasher). En af de absolutte fordele for .NET er i den sammenhæng, som jeg nævner, at .NET så er mere logisk opbygget da der ikke er så meget legacy der skal tages hensyn til. Præcis som NT platformen er mere logisk end 9x platformen af præcis samme årsag.
Personligt anser jeg den manglende mulighed for at vælge .NET app server og serverplatform leverandør som det største problem med .NET, omend jeg nok ville vente til 2008 før jeg ville turde binde an på at binde infrastruktur til .NET platformen - noget jeg ikke ville have noget problem med at gøre med Java platformen - præcist fordi .NET stadigvæk er lidt for nyt i den sammenhæng. Men til webapp's er det da fint nok, og det er også min oplevelse at det i den sammenhæng har nogle styrker og er Java overlegent.
Spørgsmålet er så om ikke næste udgave af J2EE springer foran .NET igen.
Når det så er sagt har jeg aldrig rigtigt forstået hvorfor MS har været så forhippede på at udvikle .NET fremfor at gå ind i Java processen - basalt set løser de jo samme problem, og der er jo, modsat MS påstand om andet, intet til hinder for at udvide java ift. standarden, så længe man overholder minimumskravene (og det var det, som var problemet med MS java, at de havde fjernet dele af java, ikke at de havde tilføjet noget). Det kan jeg kun se som at de er bange for at miste nogle af deres andre lock-ins og vil skabe et nyt og det er jeg kraftigt modstander af.
#32 ->
Ja. http://www.php-compiler.net/
Om der findes flere ved jeg ikke. Google kender sikkert flere
#3
"Microsoft frigiver ganske rigtigt CLI'en og C# som ECMA-standarder, så andre kan se hvordan de fungerer og har mulighed for at lave alternative implementationer. Men nye tiltag til den næste version af .NET-platformen dikteres kun et sted fra: Microsoft."
Se der tror jeg netop at det er super at det er Microsoft som egenhåndig styrer frameworket. Hvis man kigger på frameworkets udvikling, kan man især med de næste versioner se hvor retningen går.
#56:
"Kun C# og CLI er ECMA standardiseret, som blinklys nævner, simpelthen ved at MS kommer og siger "dette skal være standard"."
Ja det er faktisk sådan det foregår når man vil have oprettet en standart. Microsoft kunne reelt have ladet være med at få det standartiseret
"Men det er .NET jo ikke, og det er her der er en betydelig forskel for al funktionaliteten kommer fra API'et, og det er stadig lige så lukket som det altid har været."
APIet lukket? Du kan da bare bruge reflector, og se hvordan de forskellige klasser er opbyggede. De indbyggede klasser er også ren .net. Hvad vil du ha kildekoden på, så finder jeg det flux.
"Mht. .NET er min pointe blot at når man stiller .NET og Java overfor hinanden må Java alt andet lige ses som en mere stabil og kendt platform med de fordele det bringer, og .NET som noget mere nyt, men knap så stabilt og kendt (relativt set - har nu ikke erfaring for at .NET app's ligefrem crasher)."
Næh, det synes jeg godt nok ikke. Hvilke problemer har der været?
Ja. http://www.php-compiler.net/
Om der findes flere ved jeg ikke. Google kender sikkert flere
#3
"Microsoft frigiver ganske rigtigt CLI'en og C# som ECMA-standarder, så andre kan se hvordan de fungerer og har mulighed for at lave alternative implementationer. Men nye tiltag til den næste version af .NET-platformen dikteres kun et sted fra: Microsoft."
Se der tror jeg netop at det er super at det er Microsoft som egenhåndig styrer frameworket. Hvis man kigger på frameworkets udvikling, kan man især med de næste versioner se hvor retningen går.
#56:
"Kun C# og CLI er ECMA standardiseret, som blinklys nævner, simpelthen ved at MS kommer og siger "dette skal være standard"."
Ja det er faktisk sådan det foregår når man vil have oprettet en standart. Microsoft kunne reelt have ladet være med at få det standartiseret
"Men det er .NET jo ikke, og det er her der er en betydelig forskel for al funktionaliteten kommer fra API'et, og det er stadig lige så lukket som det altid har været."
APIet lukket? Du kan da bare bruge reflector, og se hvordan de forskellige klasser er opbyggede. De indbyggede klasser er også ren .net. Hvad vil du ha kildekoden på, så finder jeg det flux.
"Mht. .NET er min pointe blot at når man stiller .NET og Java overfor hinanden må Java alt andet lige ses som en mere stabil og kendt platform med de fordele det bringer, og .NET som noget mere nyt, men knap så stabilt og kendt (relativt set - har nu ikke erfaring for at .NET app's ligefrem crasher)."
Næh, det synes jeg godt nok ikke. Hvilke problemer har der været?
APIet lukket? Du kan da bare bruge reflector, og se hvordan de forskellige klasser er opbyggede. De indbyggede klasser er også ren .net. Hvad vil du ha kildekoden på, så finder jeg det flux.
What? Sammenligner du introspection med at have kilden til rådighed? Det næste blir' vel en kommentar om at man da bare kan dekompilere .NET runtime filerne?
#43
Helt enig.
Jeg har selv arbejdet som Java udvikler i flere år, og jeg kan ærligt talt ikke mindes en eneste gang jeg har haft behov for at se hvordan en af API'erne var opbygget.
Hvis det ikke virkedede var der en overhængende sandsynlighed for at jeg havde lavet noget forkert :) Kan kun mindes jeg har fundet en enkelt bug i API'en og den var forlængst blevet indrapporteret.
p.s. Hvilket også er sket med .net api'erne.
Helt enig.
Jeg har selv arbejdet som Java udvikler i flere år, og jeg kan ærligt talt ikke mindes en eneste gang jeg har haft behov for at se hvordan en af API'erne var opbygget.
Hvis det ikke virkedede var der en overhængende sandsynlighed for at jeg havde lavet noget forkert :) Kan kun mindes jeg har fundet en enkelt bug i API'en og den var forlængst blevet indrapporteret.
p.s. Hvilket også er sket med .net api'erne.
#36 mrmorris:
Det gør absolut ingen forskel, at Microsoft.NET binder sig op imod Windows API'et. Microsoft.NET og .NET er jo ikke det samme. .NET er en standard, og Microsoft.NET er Microsofts implementering til Windows-platformen. På tilsvarende vis gør Mono f.eks. brug af Gtk, og det er da igen en afhængighed, men det betyder intet, når afhængigheden findes i implementeringen og ikke i standarden.
Implementeringen (Microsoft.NET, Mono og DotGNU) skal blot kunne afvikle .NET-applikationer (MSIL), men selve implementeringen må gerne binde sig imod operativsystemet, særlige libraries og lignende. Det ville da være dumt at skulle opfinde den dybe tallerken forfra, når disse interne afhængigheder ikke gør .NET-applikationer mindre portable.
Jeg vil da godt indrømme, at pga. afhængighederne til Windows API'et, så kommer Microsoft.NET aldrig til at køre ordentligt på andet end Windows, men det er jo heller ikke meningen (.NET skal derimod være kompatibelt).
#30 Kun C# og CLI er ECMA standardiseret, som blinklys nævner, simpelthen ved at MS kommer og siger "dette skal være standard".
Men det er .NET jo ikke, og det er her der er en betydelig forskel for al funktionaliteten kommer fra API'et, og det er stadig lige så lukket som det altid har været.
Det gør absolut ingen forskel, at Microsoft.NET binder sig op imod Windows API'et. Microsoft.NET og .NET er jo ikke det samme. .NET er en standard, og Microsoft.NET er Microsofts implementering til Windows-platformen. På tilsvarende vis gør Mono f.eks. brug af Gtk, og det er da igen en afhængighed, men det betyder intet, når afhængigheden findes i implementeringen og ikke i standarden.
Implementeringen (Microsoft.NET, Mono og DotGNU) skal blot kunne afvikle .NET-applikationer (MSIL), men selve implementeringen må gerne binde sig imod operativsystemet, særlige libraries og lignende. Det ville da være dumt at skulle opfinde den dybe tallerken forfra, når disse interne afhængigheder ikke gør .NET-applikationer mindre portable.
Jeg vil da godt indrømme, at pga. afhængighederne til Windows API'et, så kommer Microsoft.NET aldrig til at køre ordentligt på andet end Windows, men det er jo heller ikke meningen (.NET skal derimod være kompatibelt).
#14;
haha, så dårlig er m$'s .net runtime ikke, selvom den er lort i forhold til mono...
og desuden, IL kode kørt i mono/m$.net runtime kan sagtens køre hurtigt, så dit statement siger mere om dig selv end teknologien..
#28:
hahaha, mono har basically alt .net 1.1, og meget af 2.0, blandt andet en generics compiler..
#45:
jeg ved ikke af, at mono gør brug af gtk.. dog findes der gtk C# bindings some nogle programmer gør brug af.
og btw, så vidt jeg ved har microsnot en implementation af m$.net til BSD, dog er jeg ikke sikker på om SWF er med.
haha, så dårlig er m$'s .net runtime ikke, selvom den er lort i forhold til mono...
og desuden, IL kode kørt i mono/m$.net runtime kan sagtens køre hurtigt, så dit statement siger mere om dig selv end teknologien..
#28:
hahaha, mono har basically alt .net 1.1, og meget af 2.0, blandt andet en generics compiler..
#45:
jeg ved ikke af, at mono gør brug af gtk.. dog findes der gtk C# bindings some nogle programmer gør brug af.
og btw, så vidt jeg ved har microsnot en implementation af m$.net til BSD, dog er jeg ikke sikker på om SWF er med.
#46
Hvorfor er MS.NET noget lort i forholdet til Mono?
Jeg oplever at mit program er gennemsnit 5-10% langsommere og under visse opgaver bruger 25% mere CPU under .NET.
Samme problem med en MP3 player. Der er forskel på CPU forbruget fra en player til en anden. Det betyder dog ikke at programmet er langsommere målt i tid. Et nummer på 3 minutter tager jo 3 minutter at afspille lige meget hvad, men hvis programmet æder alt CPU er der ikke meget tilbage til andre programmer. Det kan da godt være at udvikleren så er en dårlig programmør, men det kan jo også være at han har valgt et forkert værktøj til opgaven. Med den kodebase vi har i dag er .NET ikke det rigtige valg for os.
Jeg har ikke sagt at .NET er en dårlig teknologi. Den er måske bare ikke helt moden endnu og det er bestemt ikke universalt. Det passer ikke til alle opgaver.
Hvorfor er MS.NET noget lort i forholdet til Mono?
Jeg oplever at mit program er gennemsnit 5-10% langsommere og under visse opgaver bruger 25% mere CPU under .NET.
Samme problem med en MP3 player. Der er forskel på CPU forbruget fra en player til en anden. Det betyder dog ikke at programmet er langsommere målt i tid. Et nummer på 3 minutter tager jo 3 minutter at afspille lige meget hvad, men hvis programmet æder alt CPU er der ikke meget tilbage til andre programmer. Det kan da godt være at udvikleren så er en dårlig programmør, men det kan jo også være at han har valgt et forkert værktøj til opgaven. Med den kodebase vi har i dag er .NET ikke det rigtige valg for os.
Jeg har ikke sagt at .NET er en dårlig teknologi. Den er måske bare ikke helt moden endnu og det er bestemt ikke universalt. Det passer ikke til alle opgaver.
#42 Disky
Og da leverandøren i form af, at være den eneste med kildekoden, er den eneste som kan løse ens problem. Så bliver det ret kritisk, hvis de ikke er deres ansvar ordentligt bevidst. Derfor er det et alvorligt minus, som alt for få anerkender alvorligheden af.
NÅR det fungerer er det praktisk talt, sikkert fint nok alt sammen. Når det så som det tit viser sig, ikke virker som det er meningen, så er der et monopol på supporten af disse problemmer. Og så er servicen pænt sagt, temmelig svingende.
#45 Acro
Det er MEGET trist, at de finder på den slags.
Men i det lange løb, næppe noget som kommer til at hindre portabiliteten. Det vil dog sløve det, hvilket er beklageligt. Men sikkert helt efter planen.
Hvilket kun gør det endnu mere spøjst.
Først laver de en standard, og så er de selv de første til at forplumre den... Ohh well... ;)
Og hvad hindre Microsoft i at inkludere GTK#, QT# og andre?. Intet, absolut intet.
De bør ikke binde sig til libraries, medmindre disse bredt kan implementeres, i alle implementationer uden problemmer.
Det er ikke Microsofts mening. Men det er naturligvis ikke op til dem at bestemme... ;)
At noget er en lukket blackbox betyder for mange udviklere/firmaer absolut intet, bare det virker. Virker det ikke kontakter man sin leverandør
Og da leverandøren i form af, at være den eneste med kildekoden, er den eneste som kan løse ens problem. Så bliver det ret kritisk, hvis de ikke er deres ansvar ordentligt bevidst. Derfor er det et alvorligt minus, som alt for få anerkender alvorligheden af.
Nogle gange er det okay at koden er åben, men et ultimativt krav er det ikke, det fungerer også fint når det ikke er.
NÅR det fungerer er det praktisk talt, sikkert fint nok alt sammen. Når det så som det tit viser sig, ikke virker som det er meningen, så er der et monopol på supporten af disse problemmer. Og så er servicen pænt sagt, temmelig svingende.
#45 Acro
Det gør absolut ingen forskel, at Microsoft.NET binder sig op imod Windows API'et.
Det er MEGET trist, at de finder på den slags.
Men i det lange løb, næppe noget som kommer til at hindre portabiliteten. Det vil dog sløve det, hvilket er beklageligt. Men sikkert helt efter planen.
Microsoft.NET og .NET er jo ikke det samme. .NET er en standard, og Microsoft.NET er Microsofts implementering til Windows-platformen.
Hvilket kun gør det endnu mere spøjst.
Først laver de en standard, og så er de selv de første til at forplumre den... Ohh well... ;)
På tilsvarende vis gør Mono f.eks. brug af Gtk, og det er da igen en afhængighed, men det betyder intet, når afhængigheden findes i implementeringen og ikke i standarden.
Og hvad hindre Microsoft i at inkludere GTK#, QT# og andre?. Intet, absolut intet.
Implementeringen (Microsoft.NET, Mono og DotGNU) skal blot kunne afvikle .NET-applikationer (MSIL), men selve implementeringen må gerne binde sig imod operativsystemet, særlige libraries og lignende. Det ville da være dumt at skulle opfinde den dybe tallerken forfra, når disse interne afhængigheder ikke gør .NET-applikationer mindre portable.
De bør ikke binde sig til libraries, medmindre disse bredt kan implementeres, i alle implementationer uden problemmer.
Jeg vil da godt indrømme, at pga. afhængighederne til Windows API'et, så kommer Microsoft.NET aldrig til at køre ordentligt på andet end Windows, men det er jo heller ikke meningen (.NET skal derimod være kompatibelt).
Det er ikke Microsofts mening. Men det er naturligvis ikke op til dem at bestemme... ;)
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