Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Allgemeines (OffTopic) » Glaubenskrieg: Java gegen .net

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ] [ 3 ]
000
09.02.2003, 12:43 Uhr
~0xdeadbeef
Gast


In diesem Forum, Thread "Delphi" kamen wir leicht vom Thema ab, es begann sich ein Glaubenskrieg zwischen Bruder Leif und mir abzuzeichnen. Kurze Rekapitulation:

0xdeadbeef: .NET? Au weia, da brauchst du wohl gleich ganz Kolumbien...

Bruder Leif: Hm, besser .NET und Kolumbien als Java und den Rest der weltweiten Kaffeeproduktion

~0xdeadbeef: Hey, in Java hab ich bisher noch jedes Projekt fertig gekriegt, und zwar stressfreier als es mit jedem Microsoft-API je ginge. Außerdem liefen die Dinger dann auch auf anderen Plattformen. (Ich weiss, .NET soll auch plattformunabhängig sein, aber das ist ein einziger Witz. Das Ding bedient sich bei jeder Gelegenheit beim Windoze-API)

Bruder Leif: ...womit wir wieder einmal beim Thema "Glaubenskrieg" und "nicht kennen, aber trotzdem nicht mögen" wären *ggggggggg*
Was macht eigentlich Delphi?

~0xdeadbeef: Ich mach mal nen neuen Thread dazu auf.

So, und hier steig ich wieder ein: Ich hab mich zwar nicht sonderlich lange mit .NET beschäftigt, weil es mir einfach zu grausam war, aber ich hab zumindest ne grobe Idee, wovon ich spreche. Ich sag nur Windows.Forms.

Happy Flaming!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
09.02.2003, 19:25 Uhr
Bruder Leif
dances with systems
(Operator)


Flamebait entsorgt ;-)

Mal im Ernst: Ich denke mal, keiner von uns wird auch nur einen Mikrometer von seinem Standpunkt abweichen ;-) Du bist von Java überzeugt und kannst mit .NET nichts anfangen, ich bin trotz Microsoft von .NET begeistert und verabscheue Java. Letztlich ist das Geschmackssache...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
09.02.2003, 22:44 Uhr
~Hans
Gast


Könnt Ihr beiden vielleicht mal für die Unwissenden näher erläutern, was Euch daran jeweils so ärgert, bzw. was Ihr für eine besonders gelungene Lösung haltet?

Hans
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
10.02.2003, 08:07 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

Aber gerne doch *g*

Was mich an Java stört:


.NET ist standardisiert, Java nicht. Microsoft kann am .NET-Konzept nicht so einfach was verändern, wie Sun das schon ein paarmal mit Java getan hat.

.NET unterstützt verschiedene Programmiersprachen, die in einem Programm gemischt werden können. Du schreibst eine Klasse in C#, leitest in C++ eine Klasse davon ab, und benutzt sie in einem VB.NET-Programm. Für jede Aufgabe die Sprache, die am besten dafür geeignet ist. In Java hast Du nur eine Sprache - Java.

Die GUI-Elemente von .NET werden vom Betriebssystem bzw. der VM gezeichnet, sind daher rasend schnell und die Programme fügen sich vom Aussehen her ins Betriebssystem ein. Unter Java werden die AWT- und Swing-Controls von den Java-Klassen gezeichnet, und das geht auf Kosten der Geschwindigkeit und des Look&Feel.

.NET: Eine .EXE-Datei, auf Wunsch mehrere Module. Java: Tausende winziger .class-Dateien, die einzeln nachgeladen werden. Alibi-jar-Archive sind keine wirkliche Lösung.

Garbage Collector ist in Java fest eingebaut. In .NET hast Du die Möglichkeit, Deine eigene GC-Routine zu schreiben.

Die .NET-VM ist zwar auch stackbasiert wie die von Java, aber der Stack ist anders aufgebaut (interne Darstellung von Objekten, Skalaren etc.) -> JIT-freundlicher

.NET unterstützt Properties, Java nicht (get-set-Dilemma)

.NET unterstützt Delegaten, Java nicht (also für jeden Event eine eigene inline-Klasse)

Manche Programmierer halten Java hoch, NUR weil es NICHT von Microsoft ist (nach dem Motto, ich beurteile ein Buch nur nach dem Autor, nicht mal nach dem Einband)



Ab hier weiß ich nicht, ob die das in der jetzigen Version geändert haben:


Java hat keine enums

Arrays sind in Java keine Klassen

Keine IDE, die auch nur annähernd an Visual Studio .NET oder SharpDevelop heranreicht (JBuilder ist langsam, instabil und ressourcenhungrig, Visual Cafe wurde offenbar eingestellt, Sun ONE Studio hab ich schneller wieder gelöscht als installiert)

Es gibt nicht mal eine MessageBox-Klasse. Wenn Du eine Meldung anzeigen willst, mußt Du Dir erst einen eigenen Dialog zusammenzimmern.



Was mich an .NET noch stört:

Boxing (dynamische Umwandlung von Skalaren in Objekte) ist noch zu langsam

.NET ist von Microsoft, und deshalb halten es die meisten für grundsätzlich schlecht

.NET ist noch nicht auf so viel Systemen verfügbar wie Java. Aber warten wir mal, bis es auch zehn Jahre auf dem Markt ist...



Was mich an beiden stört:

Wirklich(!) plattformunabhängig sind beide nicht, nur theoretisch

Die Speicherverwaltung ist rein dynamisch. Wer sich selbst um den Speicher kümmern will, hat Pech gehabt, das geht nur unter Verlust der Plattformunabhäbgigkeit.

Der Ressourcenhunger ist bei beiden gewaltig. Für kleinere PCs gibt es sowohl von Java als auch von .NET abgespeckte Versionen, die aber auch nicht die volle Funktionalität haben




Das war mal das, was mir so auf Anhieb einfällt...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
10.02.2003, 12:41 Uhr
~0xdeadbeef
Gast


Dann halte ich mal dagegen:

Punkt 1: Standardisierung.
Java ist in der Tat nicht standardisiert, weil die Sprachbildung nicht abgeschlossen ist. Java wäre fast ein ISO-Standard geworden, Sun ist aber bewusst nicht darauf eingegangen, weil sie wussten, dass man die Sprache noch verbessern kann. Allerdings kannst du alten JDK1.1.8-Code noch mit der J2SE 1.4.1 kompilieren, und eine JRE 1.1.8 kann Bytecode, der mit einer 1.4.1-er Umgebung kompiliert wurde, ausführen.

Die GUI-Elemente in Java stecken in der Klassenbibliothek. Sie sind native, das heißt, es gibt keinen messbaren Geschwindigkeitsnachteil. Der großte Vorteil ist, dass Java damit plattformunabhängig ist, was bei .NET nur für Konsolenprogramme gilt. Zusätzlich kannst du unter Windows, wo die grafische Oberfläche feststeht, der JVM auch sagen, dass sie sich beim Betriebssystem bedienen soll, so dass Java-Programme sich nahtlos ins System einfügen.

Was mehrere Sprachen angeht, so ist das unter .NET mehr eine Alibi-Geschichte. Damit die Sprachen zusammenarbeiten können, mussten sie jeweils so verwässert werden, dass du im Grunde immer in derselben Sprache, nur mit anderen Schlüsselwörtern schreibst.

Warum .jars keine akzeptable Lösung sein soll, verstehe, wer will. Der konsequent modulare Aufbau von Java in verschiedene class-Dateien eröffnet dir ganz neue Möglichkeiten, wie zum Beispiel mehrere main-Methoden.

In Java ist der GC zwar fest eingebaut, du kannst ihm aber mitteilen, wie er sich zu verhalten hat. Stichwort: finalize-Methode. Es macht auch deutlich mehr Sinn, den GC in die VM einzubauen, aus Gründen der Sicherheit. Das Speichermanagement ist keine Application-Level-Sache - aber das hat MS ja nie begriffen. (Deswegen ist WIndows auch so sicher, wie ein Sieb wasserdicht)

Was die JIT-Freundlichkeit angeht, bin ich nicht unterrichtet, aber JIT gibts für Java auch.

Das Properties-Konzept ist bescheuert, darauf kann ich gut verzichten.

Java unterstützt Delegaten und inline-Klassen. C# hat das von Java geklaut. Unter Java kannst du auch für ein Event mehrere Adapterklassen anhängen.

Bei den enums hast du einen Punkt - auch wenn man die Dinger fast nie braucht.

Arrays sind in java schon seit Java 1 Klassen.

Es gibt tausende vernünftiger IDEs für Java _umsont_. Nimm zum Beispiel JCreator.

Die MessageBox-Geschichte klingt wie aus der J/Direct-Hilfe abgeschrieben. Meine Güte, nach dem Ptinzip write once, run anywhere - schreib dir eine und benutz sie wieder. Ich hab auch mein wu.global-Package zusammengeschustert, mit Sachen, die ich immer wieder brauche.

Was mich sonst noch an .NET stört:

.Net wird nie so plattformunabhängig sein wie Java. Sun hat ein Interesse daran, dass Java überall läuft, Microsoft will mit .NET sein Windows-Monopol erhalten - auf eine ähnlich hinterhältige Tour wie damals mit J++. Das sieht man schon daran, dass du C# ständig irgendwelche DllImport-Statements hast, und dass Steve Ballmer schon meinte, er könne sich nicht vorstellen, dass das Mono-Projekt Microsofts Copyrights nicht verletzen würde, und daran, dass .NET im .exe-Format kommt, und, und, und.

Was mich an .NET und der Sun JVM stört:

Der Source-Code liegt nicht offen.

Mehr kommt, wenn ich wieder Zeit und Lust zu flamen habe.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
10.02.2003, 12:54 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat:
Bruder Leif postete

[...]
.NET unterstützt verschiedene Programmiersprachen, die in einem Programm gemischt werden können. Du schreibst eine Klasse in C#, leitest in C++ eine Klasse davon ab, und benutzt sie in einem VB.NET-Programm. Für jede Aufgabe die Sprache, die am besten dafür geeignet ist. In Java hast Du nur eine Sprache - Java.
[...]


Ich kenn mich jetzt nicht mit .NET so aus, daher würde mich dieser Punkt näher interessieren: Wie funktioniert denn die Intergration? - Ich würde spontan an DLLs denken; aber das wäre ja ein alter Hut, der auch von Java (JNI) und Perl (XS), COM und anderen Sprachen bekannt ist; wobei dieser alte Hut auch immer die Macke hat, daß er eigentlich nicht mit dem Linkage klar kommt, welches OO Sprachen a la Java oder C++ erfordern (würden), nämlich Namemangling.

Zu dem grundsätzlichen Glaubenskrieg kann ich nicht viel beitragen: Ich würde schon vermuten, daß .NET vom Microsoft als Gegenentwurf zu Java entwickelt wurde und daher gegenüber Java den Vorteil haben mag, daß man in .NET nicht alle Fehler wiederholt hat, die man bei Java gemacht hat... Microsofttypisch wäre allerdings das Einbauen neuer Fehler...
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
10.02.2003, 19:04 Uhr
Bruder Leif
dances with systems
(Operator)


Moin moin!

The Empire strikes back


Allerdings kannst du alten JDK1.1.8-Code noch mit der J2SE 1.4.1 kompilieren, und eine JRE 1.1.8 kann Bytecode, der mit einer 1.4.1-er Umgebung kompiliert wurde, ausführen.
Das schon, aber ich bekomme andauernd "deprecated"-Meldungen, nach denen das Programm in der nächsten Java-Version nicht mehr laufen wird. Altlasten abzuwerfen ist ja gut und schön, aber wenn mein Programm schon veraltet ist, bevor ich es fertig habe... können eigentlich wie bei .NET mehrere VM-Versionen nebeneinander koexistieren, und das Programm sucht sich automatisch die Version der Klassenbibliothek aus, die am besten zu ihm paßt? Dann ziehe ich das Argument zurück ;-)

Die GUI-Elemente in Java stecken in der Klassenbibliothek. Sie sind native [...]
Moment. Entweder sie sind native, also in der VM integriert, oder sie sind Teil der Klassenbibliothek. Das AWT ist soweit ich weiß ein Teil der VM, aber mit einem derartigen Subset von Komponenten kann man doch kein vernünftiges Programm schreiben! Die Swing-Klassen sind Java, und sie sind langsam. Deshalb dachte ich bis vor kurzem auch, Java sei generell lahm, aber das scheint nur auf Swing-Programme zuzutreffen. Eine vernünftige Alternative wären die SWT (s. C'T 3/2003), aber die sind nicht offiziell Teil der VM...

Der großte Vorteil ist, dass Java damit plattformunabhängig ist, was bei .NET nur für Konsolenprogramme gilt
Einspruch! ;-) .NET ist genauso plattformunabhängig wie Java. Schau Dir mal auf www.go-mono.com die Screenshots an, das sind ganz normale Windows.Forms-Programme, die problemlos mit Gtk# unter Linux laufen. In Sachen Plattformunabhängigkeit gilt für .NET genau dasselbe wie für Java: Es läuft auf jedem System, für das es eine VM gibt. Nur daß Java eben knapp zehn Jahre Vorsprung und damit mehr VMs anzubieten hat.

[...] der JVM auch sagen, dass sie sich beim Betriebssystem bedienen soll, so dass Java-Programme sich nahtlos ins System einfügen.
Das würde mich interessieren! Wie mach ich das? Kein Scherz, das interessiert mich jetzt wirklich!

Was mehrere Sprachen angeht, so ist das unter .NET mehr eine Alibi-Geschichte. Damit die Sprachen zusammenarbeiten können, mussten sie jeweils so verwässert werden, dass du im Grunde immer in derselben Sprache, nur mit anderen Schlüsselwörtern schreibst.
Wie kommst Du denn darauf? C# mußte gar nicht verwässert werden, das wurde komplett neu entwickelt. Visual C++ wurde sogar noch weiter in Richtung ANSI angepaßt, nur mit den optionalen Erweiterungen zum Ansprechen von .NET-Klassen. Und Visual Basic ist eh keine Programmiersprache... nein, im Ernst: Visual Basic hatte zwar halbherzige OO-Ansätze, aber für .NET wurde eben eine echte OO-Sprache draus. Wenn Du eine Verbesserung als "Verwässern" bezeichnen willst, OK...
Außerdem: Wenn Du's so genau nimmst, sind C, PASCAL, FORTRAN, COBOL und so weiter auch ein und dieselbe Sprache, nur mit anderer Syntax, anderer Klassenbibliothek, anderen Konzepten usw.

Das Speichermanagement ist keine Application-Level-Sache - aber das hat MS ja nie begriffen.
Millionen andere Programmierer auf dieser Welt auch nicht. Oder warum sind C und C++ nach wie vor so beliebt, obwohl man den Speicher selbst allokieren und wieder freigeben muß? WIE der Speicher jetzt allokiert wird, sollte eh Sache des Betriebssystems sein, und nicht der VM. Außerdem kann es für manche Programme sehr hilfreich sein, eine eigene GC zu verwenden, die auf die speziellen Bedürfnisse optimiert ist und noch ein Quentchen mehr Leistung rausholt...

Achja, mit "JIT-freundlich" meine ich nicht, daß JITting überhaupt möglich ist, sondern, daß der Native Code, der beim Compilieren rauskommt, besser an das jeweilige System angepaßt ist.

Java unterstützt Delegaten und inline-Klassen. C# hat das von Java geklaut. Unter Java kannst du auch für ein Event mehrere Adapterklassen anhängen.
Java kann Delegaten? Hups, dann nehm ich das zurück. Ich kenn nur die Version, wo ich mir für einen einfachen Event eine eigene inline-Klasse schreiben muß. In .NET schreib ich z.B.

C++:
textBox1.TextChanged += new EventHandler(Funktionsname);

und fertig. Weiß nicht mehr, wie die Zeile jetzt genau in Java aussehen würde, aber sie wäre wesentlich komplexer... Was eine solche Befehlskette jetzt bedeutet, erschließt sich aus dem Quelltext dann nur sehr schwer. Und das mit dem Klauen... Linux hat von Unix geklaut, OS/2 hat von Mac OS geklaut, die NASA hat von der ESA geklaut... entscheidend ist, was mit der "übernommenen" Idee gemacht wird.

Arrays sind in java schon seit Java 1 Klassen.
Hups, das war mir nicht bewußt. Erinnere mich nur an eine Diskussion in der Uni, in der es hieß, Arrays wären "simple Typen"...

Es gibt tausende vernünftiger IDEs für Java _umsont_. Nimm zum Beispiel JCreator.
Mit dem JCreator hab ich auch schon gearbeitet. Mir kommt es bei einer IDE aber nicht nur auf ein bißchen Code Completion, Parameterhinweise und Syntaxhervorhebung an, ich will einen ordentlichen GUI-Designer! Und die paar, die ich bisher ausprobiert hab (s.o.) sind hinsichtlich Ressourcenverbrauch, Geschwindigkeit und vor allem Stabilität unter aller Sau.

Die MessageBox-Geschichte klingt wie aus der J/Direct-Hilfe abgeschrieben. Meine Güte, nach dem Ptinzip write once, run anywhere - schreib dir eine und benutz sie wieder.
Das mit der JDirect-Hilfe kann ich nicht beurteilen, da hab ich noch nie was mit gemacht. OK, es ist ein wenig spitzfindig. Aber mir geht es nicht nur um MessageBoxes. Ich bin bei meinen ersten Versuchen, mit Java warm zu werden, immer wieder auf Klassen bzw. Methoden gestoßen, die ein vernünftiges Framework bieten sollte ("wenn ich mir die grundlegendsten Sachen erst selbst schreiben muß, kann ich mir auch gleich das gesamte Framework selbst schreiben"). Gut, das meiste hat Sun in den neuen Versionen inzwischen nachgezogen, aber es hinterläßt trotzdem den Eindruck, naja, dann pflastern wir hier halt auch noch schnell was dazu...


Net wird nie so plattformunabhängig sein wie Java[...]
Das sieht man schon daran, dass du C# ständig irgendwelche DllImport-Statements hast[...]
[...]dass .NET im .exe-Format kommt[...]
Siehe oben. Wenn erst mal genug VMs für andere Systeme existieren, laufen .NET-Programme auch dort. Es ist zwar möglich, über PInvoke auf plattformspezifisches zuzugreifen, aber nicht notwendig. Ist doch legitim, in der Übergangsphase per Wrapper-Klasse ein paar ActiveX-Komponenten einzusetzen, und im endgültigen Release mal eben auf ein reines .NET-System umzustellen. Mich würde übrigens interessieren, wo in C# ständig DllImports vorkommen. Im C++-Teil von .NET gibt es die schon, aber da bedeuten sie genau dasselbe wie die import-Statements in Java: Eine Assembly ("Package") soll eingebunden werden. Und die Programme und Assemblies heißen bei .NET eben ".EXE" und ".DLL". Mit dem ursprünglichen PE-Format von Windows haben die deshalb aber nicht viel gemeinsam, nur ein paar Stubs und fertig. Ich nehme an, die haben die Erweiterungen einfach aus Gewohnheitsgründen übernommen, nach dem Motto, achja, das kenn ich doch.



@virtual: Die sprachunabhängige Vererbung läuft über einzelne Assemblies. Du faßt z.B. mehrere Klassen, die zu einem Namespace gehören, in einer "Assembly" zusammen. Das Ergebnis ist eine EXE oder DLL, wohlgemerkt nur dem Namen nach. Wenn Du jetzt von einer Klasse in dieser "DLL" ableitest, kommt es auf die Sprache nicht mehr an, da alle .NET-Sprachen in die "MS Intermediate Language" MSIL übersetzt werden (ähnlich dem Java-Bytecode). Und die Datentypen werden als "Common Type System" zusammengefaßt. Insofern ist es schon ein alter Hut, die Windows-VM von .NET ist ja auch auf COM+ aufgebaut. Mono geht hier ganz ähnliche Wege, nur eben "the Linux way" ;-)
Stell Dir vor, Du hast einen Compiler, der C# in eine Art OO-Assembler (MSIL) übersetzt, einen entsprechenden Compiler für VB.NET, einen für C++ und so weiter. Und um das Name Mangling und die vTables kümmert sich dann der IL-Assembler. Das praktische daran ist, daß Du Dich nicht mehr mit COM-Kram rumplagen mußt, Du sagst einfach, OK, in dieser Datei steckt eine Klasse, und von der will ich jetzt ableiten...

Hey, das fängt an, Spaß zu machen *g*
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
10.02.2003, 20:16 Uhr
~0xdeadbeef
Gast


Die 'deprecated'-Meldungen sagen nur, dass der Code irgendwann in der Zukunft möglicherweise nicht mehr kompiliert - der Bytecode läuft immer noch. Du kannst natürlich mehrere JVMs nebeneinander laufen lassen, allerdings macht es in aller Regel keinen Sinn, eine veraltete zu benutzen, weil die JVM mit jeder Version schneller wird.

Was die native-bestandteile der Bibliothek angeht - die Grafikklassen sind schon Teil der Klassenbibliothek. Allerdings sind die rechenintensiven Methoden native, und darauf kommt es ja an. Was Swing angeht - mit den neuen JVMs ist auch Swing schneller geworden - auch wenn es da noch deutlich besser geht.

Was die Plattformunabhängigkeit angeht - nach dem Argument sind alle Programme plattformunabhängig, weil du sie per Wine theoretisch zum Laufen kriegen kannst. Microsoft hat schon ein Statement rausgegeben, dass ihrer Ansicht nach Mono gegen ihre Copyrights verstößt.

Der JVM zu sagen, dass sie sich beim System bedienen soll, geht unter Windows mit

Code:
UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");


unter Linux wird das wie das normale metal behandelt.

Was mehrere Sprachen angeht: Verschiedene Konzepte ist das Stichwort. C ist maschinennah gehalten, COBOL ist prozedural, mit Fortran kenne ich mich nicht aus, Pascal ist ein einziger Sumpf, Lisp und seine Derivate sind konsequent funktional, Java objektorientiert, C++ generisch objektorientiert. Da gibt es überall deutliche Unterschiede. Dagegen ist es ziemlich egal, ob man sein .NET-Programm in C# oder Visual Basic schreibt, weil die Dinger im Endeffekt genau dasselbe können. Wenn das nicht verwässert ist, weiss ich auch nicht.

was den GC angeht - das ist wohl Geschmackssache.

was JIT angeht - beim JIT-kompilieren ist nicht nur interessant, wie schnell der Code ist, der nachher rauskommt, sondern auch, wie schnell der JIT-Compiler fertig ist. Beides ist eigentlich eher compiler- und nicht, oder nur in geringem Maße sprachabhängig.

Bei Java ist das mit dem Delegieren zugegeben ein bisschen umständlicher. Ich würde mir da einfach ne Adapterklasse ranhängen, die dann auf die entsprechende Methode der Klasse, der sie zugeordnet wurde, zugreift. Allerdings finde ich schon, dass der Code dann nachher einfacher zu lesen ist, weil markant ausführlicher.

Hups, das war mir nicht bewußt. Erinnere mich nur an eine Diskussion in der Uni, in der es hieß, Arrays wären "simple Typen"...
Du darfst nicht alles glauben, was dein Prof dir erzählt

IDEs: Geschmackssache. Ich kann gut damit arbeiten, und ich lege auch keinen Wert auf einen GUI-Designer - die Dinger erzeugen fast immer grauenvollen Code. Ich selbst benutze Emacs.

Fehlende Klassen in der Bibliothek: Es gab eigentlich nichts, das ich wirklich vermisst habe. Außerdem sagt niemand, C++ wäre ne schlechte Sprache, weil du von Haus aus kein Windowing Toolkit hast.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
11.02.2003, 17:43 Uhr
Bruder Leif
dances with systems
(Operator)


Moin!

Der Wine-Vergleich hinkt ein wenig, weil nicht alle Teile der Windows-API offenliegen, da gibt es zu viele Unklarheiten. Die .NET-CLI ist voll standardisiert und dokumentiert, da ist es wesentlich einfacher, eine entsprechende Bibliothek nachzubauen. Das Microsoft-Statement würde mich mal interessieren, weil die Jungs von Mono wirklich penibel darauf achten, KEINE Copyrights zu verletzen. Auf der Mono-Homepage stehen auch keine Kommentare dazu...

Bist Du sicher, daß sich Java mit dem Befehl bei Windows bedient? Für mich sieht das eher nach einem Umstellen vom Standard-Skin auf ein anderes aus, nach dem Motto "Hey Swing, zeichne Dich doch mal so, daß Du nach Windows aussiehst"...

Der Vorteil der verschiedenen .NET-Sprachen ist nicht, daß sie unterschiedliche Konzepte verfolgen, sondern die vereinfachte Portierung bzw. das Einlernen. Ein Umstieg von C++ nach Java ist ganz OK, nur daß die Quelltexte größtenteils umgeschrieben werden müssen. Ein Wechsel von ANSI-C++ nach .NET ist kein Problem, einfach neu compilieren und fertig. Visual Basic-Programme können über Kompatibilitäts-Komponenten recht einfach übernommen und dann schrittweise ganz nach .NET umgebaut werden. Außerdem ist Visual Basic (leider) immer noch eine der typischen Einsteigersprachen. Nicht zuletzt hat jeder - wie man an dieser Diskussion sehr schön sieht *g* - seine persönliche Lieblingssprache, die er gegen keine andere eintauschen will. Bei mir war es lange Zeit C++, jetzt ist es eben C#.
Was mich in dieser Hinsicht auch an Java stört, ist, daß es grundsätzlich objektorientiert ist. C++ ist hybrid, da hast Du die Wahl, ob strukturiert oder OO. Nicht immer ist Objektorientierung wirklich vorteilhaft...

Du darfst nicht alles glauben, was dein Prof dir erzählt
Denen glaub ich eh kein Wort mehr. Das Statement kam von einem Mitstudenten, der für ein Praktikum mit Java arbeiten mußte und inzwischen noch weniger davon hält als ich ;-)

[...]die Dinger erzeugen fast immer grauenvollen Code.
Wenn Du Dein erstes 300'000 LOC-Programm hinter Dir hast, ist Dir der Quelltext der GUI ziemlich egal ;-) Dann ist eine optimierte Geschäftslogik wichtiger. Die GUI soll in erster Linie für den Benutzer einfach zu handhaben, und für den Entwickler schnell und einfach aufzubauen sein. Ob für das Anlegen der GUI-Elemente zur Laufzeit jetzt 50 oder 100 LOC draufgehen, ist Nebensache. Ich seh das wie mit den "optimierenden" Compilern. Klar kann ein Compiler nie so eleganten Code erstellen, wie ein Mensch von Hand. Aber wenn ich einen Bubblesort in handoptimiertem Assembler mit einem Quicksort in compiler-"optimiertem" C vergleiche...

Außerdem sagt niemand, C++ wäre ne schlechte Sprache, weil du von Haus aus kein Windowing Toolkit hast.
Aber wenn es ein Windowing Toolkit hätte, in dem elementare Funktionen fehlen, dann würden das eine ganze Menge Leute sagen... wie gesagt, Sun hat ordentlich nachgebessert. Aber der Eindruck, den ich dabei bekommen habe, sieht ziemlich nach Flickwerk aus...
--
Mit 40 Fieber sitzt man nicht mehr vor dem PC.
Man liegt im Bett.
Mit dem Notebook.

Dieser Post wurde am 11.02.2003 um 17:44 Uhr von Bruder Leif editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
12.02.2003, 09:38 Uhr
virtual
Sexiest Bit alive
(Operator)


Also mal völlig losgelöst von den Features einer Sprache, gibt es sicherlich mindestens einen Grund von .NET die Finger zu lassen:
www.heise.de/newsticker/data/anw-11.02.03-002/
Java kommt hingegen von Sun, und wenn man mal so die strategischen Entscheidungen von Microsoft und Sun nebeneinander hält, dann stellt man schnell fest, wer von beiden offener und damit Vertrauenswürdiger ist (auch in der Vergangenheit). Ich will damit jetzt nicht sagen "Microsoft gehört zur Achse des Bösen" oder so; aber wenn ich die Wahl zwischen zwei Herstellern habe, dann wird Mircosoft bei seiner Politik bei mir stets der Zweite sein.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ] [ 3 ]     [ Allgemeines (OffTopic) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: