Christopher Spies hat geschrieben:
(keine Spielzeugsprache wie Java oder VB
Komisch, wußte garnicht, daß ich mit Spielzeug meine recht anständigen Lenze verdiene...
Wenn das meine Kunden auch so sehen würden, dann müßte ich mich wohl auch wieder mit Pointern, sinnloser Mehrfachvererbung und überschriebenen Heapadressen rumärgern.
ImmoBirnbaum hat geschrieben:
Gerade im geschäftlichen Bereich sehe ich es als doch recht riskant an, eine Sprache zu verwenden, die nur von einem einzigen Hersteller angeboten wird und die nicht quelloffen ist. Diesbezüglich begibt sich Java ja langsam auf den richtigen Weg.
Wieso riskant? Wo hat denn Delphi die weiteste Verbreitung? Neben einigen Oberflächenanwendungen vorallem im Bank- und Versicherungssoftwarebereich. Wenn es riskant wäre, dann würden die Banken und Versicherungen doch am lautesten gegen Delphi schreien oder?
und zum Thema Quelloffen:
1. was willst Du mit einer Sprache, in der jeder dahergelaufene 13jährige Programmierer, mit seinen WinAmps-Clones und Dateiverwaltungstools für Simulatorprogramme darin rumfuschen kann, nur weil er meint, einen Pointer auf ein Flag im Heap ist "ökonomischer" als das Flag direkt zu addressieren?
2. hier möchte ich nochmals auf die Softwarepatent-Diskussion verweisen.
ImmoBirnbaum hat geschrieben:
Bei Java stört mich, dass es meistens recht lange dauert und sehr viel Zuspruch braucht, bis Sun neue Sprachelemente einbaut (wie alt ist Java jetzt schon? Und wie lange wurden von den Anwendern schon Sachen
wie Generics gefordert und all das, was jetzt endlich in 1.5 drin ist?)
und dann aber noch ewig lange auf Kompatibilität zu den älteren
VM-Versionen besteht (sehr schönes Beispiel: die Date-Klasse. Wie
lange ist die jetzt schon deprecated?
Was glaubst Du eigentlich, wieviele Kunden sich vor den Kopf gestoßen fühlen, wenn Du denen mitteilst, sie sollen auf Java 1.5 migrieren, bloß weil Du mit dem Sprachumfang von 1.4 nicht zurechtkommst?
Weißt Du, was es für einen Aufwand ist, in einer Firma mit ca. 250 Mitarbeitern ein dort auf jeden Rechner installiertes JRE zeitnah zu migrieren, um Dein Update (was natürlich nicht mehr mit der alten JRE läuft) zu verteilen?
Zum Thema Kompatibilität: SUN ist es eben wichtig, daß der Slogan "write once - run everywhere" erfüllt wird und das mit Recht. Wieviel Änderungen sind denn notwendig, bis eine W32-C++ Anwendung auf Linux tatsächlich läuft?
Ich wüßte auch nicht, wo in C++ und/oder Delphi und/oder VB irgendwo in den letzten Jahren tatsächlich Änderungen in der Grundsprache vorgenommen worden sind. Wenn, dann betrifft dies Änderungen in Zusatz-API's, aber nicht in den Sprachkonstrukten.
ImmoBirnbaum hat geschrieben:
Und dann ist da noch das nio-
package: keiner traut sich, das alte io-package rauszuwerfen, denn es
wird ja noch verwendet, obwohl es eigentlich Mist ist).
Das zeigt mir - und sicherlich allen anderen Java-Entwicklern, daß Du KEINE AHNUNG von Java hast. Das java.nio.* ist KEIN Ersatz für java.io.* und war auch nie so gedacht. Der Sinn, weshalb SUN das nio-package entwickelt hat, ist die Schwäche der Streams und Reader/Writer-Konzepte bezüglich Zeichensatz und Zeicheninformationsbreite.
Daß mit dem nio-package nun auch irgendwelche Buffers etc. dazukam, ist eigentlich nur "Beiwerk"...
Wenn java.io.* Mißt wäre, dann möchte ich Dich bitten, eine Socketverbindung zum z.B. Zusi-Simulationsserver nur mit Hilfe des java.nio-Packages zu basteln oder eine XML-Datei einzulesen und - ohne die Anwendung des SAXParsers (denn der benutzt ja auch java.io) - in ein DOM zu wandeln.
ImmoBirnbaum hat geschrieben:
Zu Deinem Beispiel mit Together: das ist schon deswegen so grottenlangsam, weil es AWT/Swing verwendet, da würde ich doch lieber sowas wie Eclipse als Positiv-Beispiel verwenden...
AWT/Swing ist nicht langsam. Du bist nur unfähig, aus AWT bzw. Swing das rauszuholen, was wirklich drin steckt. Stattdessen möchtest Du zig Farbverläufe in Buttons, Millionen von Farben, umschaltbare Skins oder Look'n'Feels und tausende von Icons und Toolbarbuttons haben. Diese sollten dann auch noch ständig refresht werden und sich automatisch an die jeweilige Fenstergröße anpassen, damit die Anordnung der Komponenten immer gleich aussieht.
Tja... und jetzt wirfst Du SWT ins Feld.
Wie lange hat es gedauert, bis SWT auch unter Linux mit Framebuffer lief? Wann kommt denn die erste SWT-Version, die auch unter Symbian OS so stabil läuft, daß ich meine Java-Anwendung ohne großen Aufwand (wie heute mit AWT möglich) auch auf das Handy/PDA portieren kann?
Wenn Du heute eine typische Anwendung nimmst, dann kannst Du zwar mit SWT super die verschiedenen Perspektiven/Views/Fenster abbilden und brauchst Dich nicht um deren Anordnung zu kümmern. Aber wenn es darum geht, einen TreeView so zu gestalten, daß ordentliches Drag'n'Drop möglich ist, sich die einzelnen Nodes entsprechend der Aktionen des Benutzers ordentlich darstellen oder per Tooltip z.B. eine "Kindervorschau" basteln willst, wirst Du mit SWT Schwierigkeiten bekommen.
Ok, es ist ein Glaubenskrieg. Entweder man hat alles in Java und kümmert sich ein wenig darum, keine unnötigen Objekte zu instanziieren oder Eventhändler offen zu lassen - oder man nutzt eben die API's der Betriebssystem auf Kosten der Plattformunabhängigkeit.
ImmoBirnbaum hat geschrieben:
Es wird wohl also noch dauern, bis wir die perfekte Programmiersprache
haben, und bis dahin gibts ja noch Assembler...
Das ist dann wohl der Widerspruch in sich!
Einerseits kannst Du keine gescheit-schnelle Swing-Anwendung basteln, weil Du Dich eben nicht um die Speichernutzung Deines Programms kümmerst, andererseits propagierst Du hier eine Sprache, in der man schon von Grund darüber im Klaren sein muß, wann an welcher Stelle im Speicher welche Daten stehen und wie man diese Daten beeinflussen kann.
Merkwürdige Logik.
Nichtsdestotrotz: Auch hier wieder die Aufgabe: Versuche mal die sog. Double-Werte in Assembler abzubilden.
Oder verwalte einen x-beliebig-langen String MIT Formatierungen = RTF in Assembler. Viel Spaß! Achja. Bitte recht schnell und mit wenig Pagings und kleinem Overhead.
Wieder mal ein ob seiner Mitmenschen kopfschüttelnder
Robert