Nächster C++ Standard in 2009?
-
Kann sein dass mir der Standardisierungsprozess net ganz geläufig ist, aber gerade bei Java wo Sund ja eh die Sprache kontrolliert, müssts doch einfacher sein aus einem festen Stand(von mir aus die aktuelle Version) den Standard zu machen. Oder denk ich da ganz falsch?
-
Im Übrigen finde ich nichts schlimmes daran, dass Java von Sun gehandelt wird, ich mag die Jungs bei Sun. Bei C# ist ja auch keiner angepisst, nur weil MS dahinterteckt, oder? Weiß nicht, aber mir sind jetzt keine Fehlentscheidungen von Sun bzgl. Java bekannt, die durch einen ISO - Standard hätten vermieden werden können...
-
Talla schrieb:
Kann sein dass mir der Standardisierungsprozess net ganz geläufig ist, aber gerade bei Java wo Sund ja eh die Sprache kontrolliert, müssts doch einfacher sein aus einem festen Stand(von mir aus die aktuelle Version) den Standard zu machen. Oder denk ich da ganz falsch?
Sieh doch einfach folgendes als "Standard" an:
1. Java Language Specification
2. Java Virtual Machine Specification
3. Java API SpezifikationenWas willst du mehr?
-
GPC schrieb:
Weiß nicht, aber mir sind jetzt keine Fehlentscheidungen von Sun bzgl. Java bekannt, die durch einen ISO - Standard hätten vermieden werden können...
Hab da eines aus der Praxis: Wir haben hier ApplicationServer (WebSphere) von IBM auf Solaris-Maschinen laufen... natürlich alles mit J2EE-Zertifikat. So, alles schön per RMI, so wie es von Sun propagiert wird. So nach dem Motto, vergesst CORBA, RMI und Java sind cooler. OK... So, Java-Clients sind Java 1.3 gewesen. Gut, haben wir uns gedacht, steigen wir doch mal zumindest mit den Clients auf Java 1.4 um, Server können ja erstmal weiter auf 1.3 laufen (kannst ja nicht in einem Welt-Konzern wie Volksw*** so ebend mal über Nacht auf neue Server-Versionen migrieren).
Wir erste Tests mit Java1.4-Runtimes auf den Clients ausprobiert... AUTSCH! Das hätte man nicht tun dürfen!
Java 1.4 und Java 1.3 sind über RMI binär inkompatibel. Nix ging! Gut... macht nichts, können wir halt die Clients erstmal nicht auf 1.4 laufen lassen.So, toller Standard, wenn Sun einfach das binäre serielle Format von einer Java Version auf die andere ändert. Vorallem in Enterprise-Umgebungen.
Jetzt machen wir alles über SOAP, weiß zwar nicht warum wir dann noch Java benutzen, könnten ja auch .NET mit C# nehmen oder gar C++.
Die Migration der ganzen J2EE-Applikationen auf Java 1.4-Server macht IBM jetzt erstmal bis zum nächsten Jahr kostenlos, weil keiner das sonst bezahlen will, abe IBM natürlich seine neuen AppServer hier verticken will.
Ja, die tolle Java-Welt...
-
GPC schrieb:
Bei C# ist ja auch keiner angepisst, nur weil MS dahinterteckt, oder?
Im Gegensatz zu Java ist aber C# immerhin von MS für den ECMA-Standard frei gegeben worden. Genauso wie das Basis-.NET-Framework.
-
hm das war erstmal weder positiv noch negatiov gemeint: es ist einfach ein Fakt, dass Sun die Rechte behalten will und daher kein ISO-Standard für Java möglich ist. Daher ist dieser "Politik-Rotz" in dem Zitat, dass Artchi von dem Javamann gepostet hat einfach total fehl am Platz.
Gregor@Home schrieb:
Als Kritik am Entwicklungsmodell von Java höre ich meistens nur "Was ist, wenn Sun pleite geht?" oder "Was ist, wenn Sun plötzlich Geld haben will?". Ich bitte euch: Solche Gedankenspiele gehen sowas von an der Realität vorbei, da kann man sich nur wundern, dass Leute so argumentieren.
Vor nicht allzu langer Zeit hat Sun rote Zahlen geschrieben. Soooooooooooooooo abwegig ist das nun nicht, klar morgen wirds nicht passieren, aber dennoch muss man sowas zumindest im Auge behalten.
Zum Thema Stanard verweis ich gern auf artchis Post vor mir
Gregor@Home schrieb:
[C++ hatte doch lange Zeit ganz ähnliche Probleme: Wie lange hat man C++-Compiler genutzt, die alles andere als standardkonform waren? Da konnte man sich als Programmierer nicht an irgendeinen Standard halten, sondern musste immer ganz genau gucken, mit was der eigene Code eigentlich kompiliert. Auch beim nächsten C++ Standard wird es sicherlich wieder so sein, dass man sich lange Zeit nicht sicher sein kann, wo was läuft.
Diese Probleme gab es VOR der Verabschiedung des Standards. Das kurz danach dann noch auf einmal "alte" Compiler im Umlauf und gebrauch sind ist klar.
Bei Java dasselbe, siehe Artchi-POst(mal wieder^^)
-
Gregor@Home schrieb:
Sun hat leider die Erfahrung machen müssen, dass es sehr wichtig ist, diese Rechte zu haben. Sonst kann man inkompatiblen Versionen nichts entgegenhalten. Die "JVM" von Microsoft hätte so nicht bekämpft werden können und das hätte möglicherweise dazu geführt, dass Java zerfallen wäre.
MS hat doch nur sein eigenes Java gemacht, eben weil Sun die Rechte daran hat. Hätte Sun es an ISO frei gegeben, hätte MS so verfahren wie bei C++: so weit wie möglich an den ISO-Standard ran kommen, was sie mit C++ auch gut geschafft haben.
Würde Java ein ISO-Std sein, hätten wir heute wahrscheintlich kein .NET. Und IBM würde sich nicht mit Sun streiten, Java frei zu geben (ja, komisch das auch IBM das fordert).
-
Artchi:
He he, da habt ihr ja eine ganz schöne Scheiße
Na gut, Sun hat sich das Recht vorbehalten bzw. in Anspruch genommen, die 1.4 RMI inkompatibel zur 1.3 zu gestalten, ich schätze sie hatten ihre Gründe dafür, auch wenn ihr jetzt blöd dasteht und die Suppe auslöffeln dürft. Trotzdem denke ich, dass ein, sich entwickelnder, Standard Probleme hätte, kompatibel zu bleiben. Meinst nicht?MS hat doch nur sein eigenes Java gemacht, eben weil Sun die Rechte daran hat.
Dann hätten sie aber wenigstens ein zu Sun konformes Java rausbringen können.
Btw. Es ist egal ob wir das jetzt gut finden oder nicht, es ist halt so und wir müssen auch jeden Tag damit klarkommen. That's the way it is...
-
Dann hätten sie aber wenigstens ein zu Sun konformes Java rausbringen können.
...oder auf Java statt C# setzen können. J ein Sharp zu verpassen hats nicht gebracht. Jetzt versuchen sie es mit C.
MfG SideWinder
-
Pellaeon schrieb:
Vor nicht allzu langer Zeit hat Sun rote Zahlen geschrieben. Soooooooooooooooo abwegig ist das nun nicht, klar morgen wirds nicht passieren, aber dennoch muss man sowas zumindest im Auge behalten.
[...]
Diese Probleme gab es VOR der Verabschiedung des Standards. Das kurz danach dann noch auf einmal "alte" Compiler im Umlauf und gebrauch sind ist klar.
Bei Java dasselbe, siehe Artchi-POst(mal wieder^^)1. Sun hatte die ganze Zeit liquide Mittel in der Höhe von etwa $7Mrd.. Da hätten sie noch sehr lange rote Zahlen in der Größenordnung schreiben können, bevor sie ein Problem gehabt hätten.
2. Also hier im Forum war das Problem der nicht standardkonformen Compiler zumindest so 2001 noch sehr aktuell. 3 Jahre nach dem Standard. ...ganz schön lange in der IT-Branche, heh? Kann man dann 2012 damit rechnen, dass der neue Standard, der für 2009 geplant ist, halbwegs eingehalten wird?
Artchi schrieb:
Würde Java ein ISO-Std sein, hätten wir heute wahrscheintlich kein .NET. Und IBM würde sich nicht mit Sun streiten, Java frei zu geben (ja, komisch das auch IBM das fordert).
Ja, mag schon sein, dass es dann kein .NET geben würde. Dann hätte MS die Javawelt gespalten. Es ist ja sehr schnell so, dass man die Variante von MS als "den Standard" ansieht. Ist ja bei C++ genauso. Wie oft sagt hier einer, dass er "MS-VC++" lernen will. ...und irgendwann wundert man sich dann, dass man eben nicht das gelernt hat, was man eigentlich lernen wollte, sondern stattdessen die MFC oder so als Standard angesehen hat. Ist ja bei .NET genauso: Das ist nur teilweise standardisiert. Viele wichtige Bibliotheken sind Erweiterungen von MS, aber darum kümmert sich natürlich fast keiner, der das lernt. Wenn man soetwas nicht vorher weiß, hat man es ja auch schwer, das festzustellen.
-
GPC schrieb:
Artchi:
He he, da habt ihr ja eine ganz schöne Scheiße
Na gut, Sun hat sich das Recht vorbehalten bzw. in Anspruch genommen, die 1.4 RMI inkompatibel zur 1.3 zu gestalten, ich schätze sie hatten ihre Gründe dafür, auch wenn ihr jetzt blöd dasteht und die Suppe auslöffeln dürft. Trotzdem denke ich, dass ein, sich entwickelnder, Standard Probleme hätte, kompatibel zu bleiben. Meinst nicht?Deswegen mögen Programmierer Sprachen mit langsameren Updatezyklen, die auf ein stabiles Minimum setzen um rumgepunsche zu vermeiden. Hier schlägt C++ in die Bresche. C++ ist vielleicht minimal vom Umfang, benötigt dafür aber nicht alle x Jahre ein Update.
Naja, schlimmer als Java sind da noch Skriptsprachen wie Python oder (würg) PHP, die ja regelmäßig größere Updates fahren, weswegen man ständig mehrere Versionen davon benötigt.
@Artchi
Das mit MS und der EMCA ist ja auch zum größten Teil Augenwischerei. Zum einen sind Teile des Frameworks patentiert, weswegen sich Red Hat zB weigert Mono mit auszuliefern und andere Teile, die besonders propagiert werden, wie ADO.NET, WinForms und co, sind nicht Teil des Standards. Das ist eben der typische MS mix. Man schafft oder nimmt einen Standard, baut aber genug drum rum, dass der Kunde dennoch an MS gebunden bleibt. Das gleiche versuchen sie ja jetzt wieder bei Office Formaten. Bei Java haben sie es ja versucht, aber Sun hat dagegen ja prozessiert. Da MS aber genug Kleingeld hat, ist das natürlich kein Problem für die ein neues Framework wie .NET zu entwickeln.
-
ich war mal dafür das topic zu beachten...
also ich fand XML , Netzwerk (alle also TCP/IP4/IP6/UDP/SPX/IPX)
und evtl ne GUI wo halt STD elemente(Buttons, LAbels, EDIts und PaintAreas sind)
die keine spezielle L&F haben drin sind oder vill ne Console/Printer Farb-output??
naja XML und Network sind wichtiger...
-
ich fände sowas wie Swing (Java) ziemlich interessant
-
xindon schrieb:
ich fände sowas wie Swing (Java) ziemlich interessant
darauf kannst du lange warten
