nein, ich meinte den letzten satz durchaus nicht sarkastisch. leicht ĂŒbertrieben, ja.
java hat sicher seine berechtigung und seine vorteile (systembedingt), wenns um embedded systeme oder gröbere applikationen mit webfrontend geht. (ich weiss, das ist nicht das einzige)
Allerdings stresst's ich mich jedes mal, wenn ich vor einem java-GUI sitze. Mir kommen die dinger einfach irgendwie trĂ€ge rein. Am meisten nervt mich Eclipse. Des weiteren fehlen wichtige Sprachkonstrukte (enum's, templates oder operator overloading, u.v.m). Das wird in der nĂ€chsten version wenigstens teilweise verbessert. Eine der grössten Ursachen fĂŒr meine Haltung gegenĂŒber Java ist jedoch, dass das ganze systemtechnisch/konzeptinell hĂ€sslich gelöst wurde. Es werden sich zu viele unnĂŒtze Vorteile ĂŒber die Performance erkauft. Damit meine ich in erster Linie nicht mal die VM, obwohl die natĂŒrlich auch Leistung frisst. Sie hat jedoch wegen der Portierbarkeit noch eine gewisse Berechtigung. Wenn ich aber sehe, was da noch fĂŒr Service-Threads laufen, das muss einfach nicht sein. Garbage Collector zum Beispiel brauchts schlicht und einfach nicht. Sollen die Programmierer doch bitte selber ihen Dreck wegrĂ€umen. Es wird zu viel spĂ€t gebunden. Es wird viel zu viel vererbt. (Vererbung ist ein ziemlicher Performance-Killer)
Alles in allem empfinde ich Java ein bisschen als Kinderspielzeug. Java versucht's dem Programmierer so einfach wie möglich zu machen, obwohl das nicht nötig wĂ€re. DafĂŒr werden in meinen Augen etwas zu viele Unschönheiten in Kauf genommen.
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.
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.
Ein Handgemalter 9 Punkte Pixelfont sieht besser aus als alles Antialiaste. Ich bin gerade mit Suxus sehr zufrieden. Mit etwas Aufwand laesst sich der auch unter Windows nutzen.
Normalerweise hast du ja TrueType Fonts, die als Vektordaten vorliegen und skalierbar sind. Die sehen nie wirklich gut aus, deswegen muss man mit Antialiasing arbeiten.
Ein 'handgemalter' Font ist ein Font, der gerade mal in einer groesse erhaeltlich ist, aber in dieser Groesse komplett von Hand als Pixel-Font erstellt wurdel. Er verliert zwar die Skalierbarkeit, sieht dafuer um laengen besser aus als jeder TrueType Font.
Das ist sicher nichts fuer eine WYSIWYG Textverarbeitung, aber gerade fuer Terminalemulatoren ein idealer Font.
die .fon sind eben genau die bitmap fonts. google findet da ein paar wenn ich "bitmap fonts" suche. allerdings keine so schönen wie die die ich bei einigen leuten im terminal gesehen habe.
andererseits kann man ttfs auch so machen dass sie in einer gewissen grösse schön aussehen. ich finde verdana und tahoma zb verdammt nett. hald keine fixed-width fonts, drum nicht zum c0d0rn.
Du brauchst ein Programm das den Font in TTF-Bitmap Fonts (also, Bitmap Fonts, die in ein .ttf ``encapsulated'' sind) umwandeln kann. Ich hab das mal soweit hingebracht, das ich den Font unter MacOS X mit Terminal.app nutzen kann.
Unter Windows verwende ich den Cygwin X11 Server, der .pcf Fonts native laden kann. Mein .ttf tut unter Windows nicht (war ein typischer WFM Versuch). Versuch mal dein Glueck, das original findest du hier: http://www.goof.com/pcg/marc/suxus.html.
Falls dir der Font nicht passt, such nach weiteren Linux-Terminal Fonts. Es gibt bis 14 Punkte sehr schoene, handgemalte Fonts. Ideal zum Code schreiben, oder in einem CLI arbeiten.
