Naja, es ist allgemein bekannt dass C# schöner ist. Ohne dass ich jetzt wirklich grob Ahnung von den beiden hätte. C# ist hald auch neuer. Ausserdem stinkt sun ;) (und c# ist wenigstens n ECMA Standard)
Ist deine Meinung von Java die, die einem in Rappi beigebracht wird oder ist das deine eigene hand-crafted Meinung?
Nein, das ist meine eigene Hand-Crafted Meinung nach 1 semester java und 1 semester c++. Unser Java-Prof. ist der Java-Fan schlechthin. Er was bei der Entwicklung von Anfang an dabei. (hab ich dir ja mal erzählt) Im Gegenzug lässt es sich unser C++ Lehrer natürlich nicht nehmen, ab und zu Sprüche über Java zu reissen. Fakt ist jedoch, dass die relativ deutliche Mehrheit der Diplomarbeiten mit C++ oder C# gecodet werden.
AWT / Swing ist nicht so super. Vor allem wegen der Performance. Einige Java Programme benutzen aber natives GUI.
J2SE 1.5 wird Enums und Generics haben, welche ähnlich sind wie C++ templates. Operator Overloading wäre schön...
GC find ich auch nicht so super, obwohl man ein bisschen schneller programmiert hat.
Viel vererben muss man ja nicht, wenn einem die Performance wichtiger ist.
Joh, allgemein ists Performance Mässig einiges schlechter als C u.ä, wegen Garbage Collector, VM etc... aber Kisten werden schneller, und man verwendet ja heutzutags auch nicht mehr für alle Applikation Assembler, sondern baut auf "Performance-Luxusgütern" wie zb. OO auf - was ich nicht als "unnützen Vorteil" empfinde.
wobei asm gegenüber c nur einen geschwindigkeitsvorteil hat wenn der coder wirklich _verdammt_ gut ist. ansonsten würd ich mich lieber auf die optimierungen des c compilers verlassen ;)
Blöd ist nur, dass alles von Object abgeleitet ist. Ausserdem ist die Lib vollgestopft mit Vererbung über mehrere Stufen. Besonders im Bereich Container (Java-Leute nennen das Collections) und Streams.
OO ist vom Prinzip her schon nicht schlecht. Ich finde aber trotzdem, dass man mit OO sparsam sein sollte (eben wegen der Performance). Von daher kommt es einem schon sehr zu gute, wenn nicht gleich alles eine Klasse resp. n Objekt sein muss.
Bei Performance-intensiven Applikationen, wie z.B. 3D-Sachen wird immer noch sehr viel Assembler eingesetzt.
Zu Swing noch n kleiner Hinweis: Bitte benutzt das nicht. Das wird euch sogar in den Bergen auf den Sesselliften beigebracht. Da steht nämlich auf den Tafeln an den Masten: "Do not swing!"
Das mit dem "sehr viel assembler" müsstest Du mir wirklich zeigen. Es schadet sicher nciht wenn mans kann, bzw wenn man weiss was in etwa so aus dem compiler rauskommt wenn man c schreibt, aber ich bezweifle dass "sehr viel assembler" performancemässig ein vorteil ist, vorallem da compileroptimierungen eigentlich besser sein sollten als der durchschnittliche asm monkey..
Du hast in allen Punkten recht, aber bedenke dass es Anwendungsbereiche gibt wo die Performance nicht essentiell ist, und wo man auch recht viel Entwicklungszeit sparen kann wenn man Java verwendet statt eine lower-level Programmiersprache.
Nimm zum Beispiel eine Anwendersoftware wie zb. Abacus. Ich finde für sowas Java ziemlich gut. (Plattform unabhängig, Netzwerkfähig).
Ich fänds schon recht edel wenn die neue Version in C wäre, aber dann müsste man sich glaub um einiges mehr kümmern.
und irgendwie pfeif ich auf das "compile once run anywhere" geschiss. cross-platform gui toolkits a la qt, verbreitete sprache wie c++ oder evtl python oder was auch immer, und das ding läuft auch überall (sofern man heute etwas auf mehr als 2-3 platformen am laufen haben will).
jab, hab auch schon ein bisschen was damit geschrieben, wurde aber nicht fertig (war aber trotzdem witzig, ne kleine 2d game engine mit parallax scrolling und plugins). LibSDL ist ne nette Sache für Games, aber ist kein GUI Toolkit. (ich weiss, es gibt ParaGUI und so zeugs, aber ich würd trotzdem kein Notepad.exe mit SDL schreiben)
plattformunabhaengig? ich lach mich krumm, echt. so nen guten witz habe ich schon lange nicht mehr gehoert.
also nicht, dass das konzept es nicht erlauben wuerde... aber man muesste fuer die plattformunabhaengigkeit halt schon jeweils ne vm haben. und da hapert es ziemlich.
Wenn aber jemand merkt, dass das Objekt welches er braucht einen Bug hat, dann schreib er sein Programm so, dass es diesen Bug umgeht.
Anschliessend fixt jemand den Bug und das Programm läuft nicht mehr. Ausser er arbeitet bei Microsoft, die würden denn Bug dann emulieren, dass das Progamm weiterhin läuft..
hm? Mir leuchtet der Zusammenhang zwischen OO und deinen Punkten nicht ein. Glaubst Du mit prozeduraler Programmierung schreibt man allen Code mehrmals?
ich bin ja nicht grad anti-OO, aber deine Argumente versteh ich nicht.
ich habe eigentlich nur gelernt, dass man bei OO keine sachen machen soll wie "class.variable = wert", weil das unschoen sei und so.
aber es ist imho ein ziemlicher spast, wenn man immer extra ne auslese/reinschreib-funktion basteln muss, weil es den code elend unuebersichtlich macht (hinter einer funktion getspast kann sich schliesslich so etwa alles verstecken, was es an code so gibt, d.h. man muss sich die funktionen immer erst von hand reinziehen, damit man das programm kapiert. und imho sollte man nur funktionen machen fuer aufgaben, die auch etwas komplexer sind als nur einen wert auszulesen oder zu schreiben.
na es dürfte schon vorteile haben. du hast schön vordefiniert wo du wie zugreifen darfst und so. und klasseninternes zeug lässt sich leicht verstecken. vielleicht möchtest du mal mit einer setspast() funktion mehr machen als nur eine variable setzen oder so, dann ists wüst wenn du noch an 500 orten class.spast = sepp hast.
ich finds vom konzept her schon ne feine sache.
eben das ist das problem: wenn man mehr funktionalitaet braucht, kann man ja ne funktion machen.
wenn nicht, ist es quatsch, extra ne "funktion" dafuer zu schreiben.
und ich bin generell eher abgeneigt gegenueber solchen komfortpaketen, wenn sie dafuer die ganze chose lahm machen und nur wenig bringen.
ist ja, wie wenn man nen "suv" kauft und damit in der stadt und so rumholzt. man hat viel komfort, ein "krasses" auto und _koennte_ damit ins gelaende (bei dem beispiel zwar auch nicht :-)) und so... aber es kann ps haben wie es will: es ist einfach nur lahm und unangebracht.
get / set Funktionen braucht man in Java "nur", damits Thread-Safe ist. Es lohnt sich dies aber von Anfang an - auch der Schönheit des Codes zuliebe - vorzusehen.
OTOH stimmts natürlich dass das "java ist langsam" wohl noch von früher kommt, als java wirklich schweinelangsam war ;)
Aber der test tut hald auch gui toolkits nicht mit einbeziehen, könnte noch was ausmachen.
Mir egal, ich find java alleine aus Benutzersicht wüst, weil es sich auf keinem OS so anfühlt als sei es zuhause. Ich hätt da schon einen Song den man während der JDK/JRE Installation spielen könnte.
ich hab zwar keine ahnung von der materie und hab schon leute gelesen die meinten gc funktioniere, ich kann mir das aber irgendwie nicht so richtig vorstellen ;)
Das einzige, was man in C++ selber machen muss, ist objekte selber wieder aus'm Heap zu löschen, wenn sie nicht mehr gebraucht werden. Bei kleinen Applikationen muss man nicht mal unbedingt, aber es ist natürlich schöner wenn mans trotzdem macht. Dazu ist nur eine Zeile Code notwendig. Es ist also überhaupt nicht aufwändig oder schwierig das selber zu machen.
Der Nachteil des GC ist meiner Meinung nach viel überwiegender als dessen Vorteil. Er frisst Performance, da er immer checken muss, ob Referenzen auf ein Objekt vorhanden sind und man weiss nicht mal genau, wann er abläuft.
Das Aufräumen von Objekten ist wie gesagt das einzige, was man machen sollte. Des weiteren gibt es im Bereich Memory-Managemant aber noch viele weitere Dinge, die man machen kann, um seinen Code zu optimieren. So kann man z.B. dem Compiler sagen, er solle versuchen eine häufig verwendete Variable in ein Register laden, dann läuft der Zugriff schneller. In Java hast du in diesem Bereich überhaupt keine Optimierungs-Möglichkeiten. Das ist ein gewaltiger Nachteil.
