c++ vs. java... was hat zukunft
-
rüdiger schrieb:
Das in der C++-Welt sorgfältiger entschieden wird sehe ich eher als Vorteil an. Gerade die Generics zeigen doch was passiert, wenn man schnell schnell ein Feature mit dem x.y-Release rausbringen will, weil es die Sprache Z (hier eben C#) schon hat.
Das in der C++Welt sorgfältiger entschieden wird, scheint eine Grundannahme von Dir zu sein. Wie kommst Du eigentlich darauf? IMHO müssen die Änderungen, die da mit dem neuen Standard kommen, erst noch zeigen, dass da irgendetwas sorgfältiger gemacht wurde. Wie sieht es denn in der Vergangenheit aus? Ich kann mich da an folgendes erinnern: Als ich 2001 in dieses Forum gekommen bin, hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. Das deutet schonmal darauf hin, dass die Standardisierung von der Infrastruktur bzw. von der Organisation her nicht besonders sorgfältig oder professionell ist. Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?
BTW: Java hatte die Generics vor C#. ...nur, um das mal klarzustellen. Und der Vorschlag, Generics Java hinzuzufügen, kam eh lange bevor C# auch nur ein feuchter Traum der MS-Entscheidungsträger war.
rüdiger schrieb:
Und so hat man ja auch das Problem, dass die Sprache schon weiter ist, als die meisten Nicht-SUN-SDKs. IBM setzt ja immer noch auf Java 1.4.
JDK5 für AIX32, AIX64: http://www-128.ibm.com/developerworks/java/jdk/aix/service.html
JDK5 für Linux: http://www-128.ibm.com/developerworks/java/jdk/linux/download.html
JDK5 für z/OS: http://www-03.ibm.com/servers/eserver/zseries/software/java/JDK6 early release für diverse Plattformen: https://www14.software.ibm.com/iwm/web/cc/earlyprograms/ibm/java6/index.shtml
Was genau meinst Du eigentlich?
-
Gregor schrieb:
...hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. ... Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?...
Nicht, dass ich prinzipiell widersprechen wollte, ich finde das nur lustig. Es zeigt IMO den klassischen "Paradigmenkonflikt" zwischen Java- und C++Denke. Javaisten sind eher am schnellen Praxiseinsatz und C++er eher an "konzeptioneller Reinheit" interessiert (natürlich nur tendentiell und verallgemeinert).
Die einen neigen zum "zu kurz springen", die Anderen zum zum "gar nicht springen" (Mein Chef sagte immer so schön: "Man kann auch in Schönheit sterben !")
Gruß,
Simon2.
-
CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
Aus meiner Sicht geht es bei Java nicht darum, möglichst objektorientiert zu sein. Es geht vielmehr darum, Entwicklern ein Werkzeug zur Verfügung zu stellen, mit dem sie effektiv und effizient entwickeln können. Ein Werkzeug, mit dem sie ihre Vorhaben geradlinig und direkt realisieren können, ohne sich sich den vielfältigen Möglichkeiten des Werkzeugs zu verlieren. Es geht mehr um den "goldenen Mittelweg" aus technischen Interessen, wirtschaftlichen Interessen und so weiter. Also um Pragmatismus.
CStoll schrieb:
@Gregor: Und Java ist ausgereift? Nur die Tatsache, daß die Entwickler dort häufiger neue Versionen definieren, ist noch lange kein Zeichen für Qualität. Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).
Ich habe nirgendwo behauptet, dass Java ausgereift ist. Aber die Schwachstellen von Java werden stärker angegangen, als das in der C++Welt der Fall ist. Da konnte man sich ja auch beim nächsten Standard noch nicht darauf verständigen, C++ eine umfassende Standardbibliothek zu verpassen. ...eine ganz massive Schwachstelle, die einfach mit dem Hinweis auf Toaster usw. ignoriert wird.
-
Simon2 schrieb:
Gregor schrieb:
...hat man C++ vorgeworfen, dass praktisch kein Compiler standardkonform ist. 3 Jahre nach dem 98er Standard. ... Ich kenne auch wen, der vor kurzem einen Job im C++ Umfeld angenommen hat, bei dem ihm erstmal ausdrücklich klar gemacht wurde, dass er Templates nur unter vorheriger Absprache in Ausnahmefällen nutzen darf. Deutet das auf ein sorgfältig ausgearbeitetes Sprachfeature hin? Wenn man es im produktiven Einsatz erstmal generell nicht nutzen darf?...
Nicht, dass ich prinzipiell widersprechen wollte, ich finde das nur lustig. Es zeigt IMO den klassischen "Paradigmenkonflikt" zwischen Java- und C++Denke. Javaisten sind eher am schnellen Praxiseinsatz und C++er eher an "konzeptioneller Reinheit" interessiert (natürlich nur tendentiell und verallgemeinert).
Dem stimme ich zu.
Die Frage ist halt, was man selbst erreichen möchte. Das perfekte Programm? Unabhängig von den Kosten? Dann ist C++ sicherlich die erste Wahl. Aber dann betreibt man das Programmieren auch zum Selbstzweck.
-
CStoll schrieb:
Das C++ Kommitee durchdenkt die Verbesserungen halt gründlicher anstatt solche Schnellschüsse herauszubringen (die dann auf ewig im Sprachkonzept zurückbleiben).
Redest Du von export?
-
Gregor schrieb:
BTW: Java hatte die Generics vor C#. ...nur, um das mal klarzustellen.
Ist aber irrelevant, denn die .NET-Generics sind trotzdem um Welten besser implementiert als die in Java. – Und das ist echt schlimm, denn die .NET-Generics sind wirklich grottenschlecht und außer für allgemeine Containerklassen und einige simple Abstraktionen kaum zu gebrauchen.
-
Gregor schrieb:
...Das perfekte Programm? Unabhängig von den Kosten? Dann ist C++ sicherlich die erste Wahl. Aber dann betreibt man das Programmieren auch zum Selbstzweck.
Schön !! Gruß,
Simon2.
-
Gregor schrieb:
CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
Aus meiner Sicht geht es bei Java nicht darum, möglichst objektorientiert zu sein. Es geht vielmehr darum, Entwicklern ein Werkzeug zur Verfügung zu stellen, mit dem sie effektiv und effizient entwickeln können. Ein Werkzeug, mit dem sie ihre Vorhaben geradlinig und direkt realisieren können, ohne sich sich den vielfältigen Möglichkeiten des Werkzeugs zu verlieren. Es geht mehr um den "goldenen Mittelweg" aus technischen Interessen, wirtschaftlichen Interessen und so weiter. Also um Pragmatismus.
OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt? Ein möglichst einfach zu nutzendes Werkzeug ist sicher recht praktisch, nur leider schränkt es neben den Problemfeldern auch die möglichen Anwendungsbereiche ein.
(wo du schon von Werkzeugen sprichst: ein Kreuzschlitz-Schraubendreher ist auch einfacher zu handhaben als ein Akkuschrauber ;))
-
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"
mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...
Möglich. Aber das ist nicht der Hauptzweck meiner Klassen
Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.die klassen in Java können das, wofür sie gemacht wurden, das ist in deiner lieblingssprache auch nicht anders
aber wieso sollten sich objekte wie eingebaute ints verwenden lassen?
das würde doch mehr verwirrung stiften als nützen.
wenn du z.b. in C programmierst, ist es doch auch von bedeutung, ob du mit einem int, float, oder array arbeitest.
objekte zu 'tarnen' und sie wie etwas anderes aussehen zu lassen, macht wenig sinn, das ist bestenfalls eine fehlinterpretation von 'information hiding'.CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
ist es ja auch, es übertreibt nur nicht damit.
-
CStoll schrieb:
OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?
Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ..wow: Wieviel Zeit Du dadurch in der Entwicklung gespart hast! Unfassbar.
-
pale dog schrieb:
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
dem Anwender ist die "Referenz bi" egal (und nur ein Mittel zum Zweck) - für ihn zählt das "Objekt bi"
mittel zum zweck natürlich schon, aber egal trotzdem nicht. man kann z.b. das objekt wegschmeissen mit 'bi = null; bi2 = null;', man kann bi oder bi2 auf ein neues objekt verweisen lassen usw. usw...
Möglich. Aber das ist nicht der Hauptzweck meiner Klassen
Meine Klasse soll (z.B.) rechnen können und sich dabei möglichst genauso verwenden lassen wie die eingebauten int's - und jetzt verrat mir mal, wie du das hinbekommen willst.die klassen in Java können das, wofür sie gemacht wurden, das ist in deiner lieblingssprache auch nicht anders
Aber wenn ich künstlich darin beschränkt werde, was ich meinen Klassen beibringen darf, sehe ich den Sinn dahinter nicht.
aber wieso sollten sich objekte wie eingebaute ints verwenden lassen?
das würde doch mehr verwirrung stiften als nützen.Gegenfrage: Warum sollen "meine" BigInt's sich anders verhalten als die eingebauten int's? Beide stellen eine Zahl dar, also sollte man auch mit beiden vernünftig (und unter vergleichbaren Bedingungen) rechnen können.
wenn du z.b. in C programmierst, ist es doch auch von bedeutung, ob du mit einem int, float, oder array arbeitest.
(*schaut auf den Thread-Titel*) C steht hier aber nicht zur Debatte.
objekte zu 'tarnen' und sie wie etwas anderes aussehen zu lassen, macht wenig sinn, das ist bestenfalls eine fehlinterpretation von 'information hiding'.
Eine Zahl in einem Objekt zu verstecken und ihre Verwendung hinter irgendwelchen Methoden zu verbergen, macht noch weniger Sinn. Und wenn, dann sollte Java bitte so konsequent sein und auch int und Kollegen als Objekte anbieten.
CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
ist es ja auch, es übertreibt nur nicht damit.
Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?
Edit @Gregor:
Gregor schrieb:
CStoll schrieb:
OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?
Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ..wow: Wieviel Zeit Du dadurch in der Entwicklung gespart hast! Unfassbar.
Erstens: Kann man BigInteger-Werte genauso verwenden wie 'normale' int's?
Und zweitens: Die BigInt waren nur ein Beispiel
Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.
-
CStoll schrieb:
Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?
Wenn man von der Objektorientiertheit von Java spricht, dann meint man doch nicht, dass OOP da zu 100% perfekt umgesetzt wird. Meistens werden solche Bemerkungen im Vergleich zu C++ gemacht. Und man spricht dabei vor allem Anfänger an. C++ ist im Gegensatz zu Java eine Multiparadigmensprache: Insofern hat der Anfänger, der sich u.a. noch nicht mit OOP auskennt, erstmal ganz viele Wege offen, wie er etwas erreichen kann. Wenn es dem Anfänger allerdings darum geht, OOP zu lernen, dann ist das nicht hilfreich. Java setzt da geradliniger auf OOP, ohne es damit zu übertreiben. Aus diesem Grund trifft man in OOP-Vorlesungen auch eher Java als C++ zur Illustration der verschiedenen Konzepte an.
-
Gregor schrieb:
CStoll schrieb:
OK, bleiben wir mal bei einem meiner letzten Beispiele: Wie kann ich in Java eine (z.B.) BigInt-Klasse entwickeln, die möglichst nahe an der natürlichen Semantik von int's liegt?
Im Allgemeinen würdest Du Dich in Java gar nicht mit der Programmierung so einer Klasse aufhalten, sondern eher java.lang.BigInteger nehmen. ...
Mal aus Interesse: Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?
Gregor schrieb:
...[C++] ...erstmal ganz viele Wege offen, wie er etwas erreichen kann. Wenn es dem Anfänger allerdings darum geht, OOP zu lernen, dann ist das nicht hilfreich. Java setzt da geradliniger auf OOP, ohne es damit zu übertreiben. Aus diesem Grund trifft man in OOP-Vorlesungen auch eher Java als C++ zur Illustration der verschiedenen Konzepte an.
eben "frei" vs. "den"
Gruß,
Simon2.
-
CStoll schrieb:
Und zweitens: Die BigInt waren nur ein Beispiel
Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.Wie schon gesagt: Um Perfektionismus geht es nur bei C++. Bei Java geht es um Resultate. Und der Kompromiss, eine Klasse aus der Standardbibliothek zu nehmen, anstatt einer selbstgeschriebenen Klasse, die etwas besser passen würde, ist oft ein sehr guter Kompromiss. Vor allem, wenn man bedenkt, dass hinter Klassen der Standardbibliothek sehr viel Aufwand steckt. Die Leute, die daran arbeiten, verstehen ihr Handwerk. Die haben viel Zeit investiert, um verschiedene Algorithmen usw. zu evaluieren und so eine Klasse ist das Resultat davon. Nicht nur das, sondern in die Standardbibliothek wird auch unabhängig von Dir weiterhin jede Menge Arbeit gesteckt. Die Klassen dort werden mit der Zeit besser (zum Beispiel performanter).
Im Übrigen machen viele Operatoren, die man bei ints nutzt, bei BigIntegers deutlich weniger Sinn. Zum Beispiel die ganzen Bit-Operatoren. Insofern sollte man die möglichst gleichartige Verwendung durchaus in Frage stellen.
-
Simon2 schrieb:
Mal aus Interesse: Wie ist denn java.lang.BigInteger geschrieben ? Können die mehr als der normale Javaprogrammierer ?
Ganz normale Javaklasse. ...früher war die AFAIK über JNI implementiert. Aber es hat sich glaube ich herausgestellt, dass Java da alleine performanter arbeitet.
-
Gregor schrieb:
CStoll schrieb:
Und zweitens: Die BigInt waren nur ein Beispiel
Aber ich bin mir sicher, du kennst die Java-Bibliothek besser als ich - und kannst dort auch für jeden Zweck die perfekte Klasse ausgraben.Wie schon gesagt: Um Perfektionismus geht es nur bei C++. Bei Java geht es um Resultate. Und der Kompromiss, eine Klasse aus der Standardbibliothek zu nehmen, anstatt einer selbstgeschriebenen Klasse, die etwas besser passen würde, ist oft ein sehr guter Kompromiss. Vor allem, wenn man bedenkt, dass hinter Klassen der Standardbibliothek sehr viel Aufwand steckt. Die Leute, die daran arbeiten, verstehen ihr Handwerk. Die haben viel Zeit investiert, um verschiedene Algorithmen usw. zu evaluieren und so eine Klasse ist das Resultat davon. Nicht nur das, sondern in die Standardbibliothek wird auch unabhängig von Dir weiterhin jede Menge Arbeit gesteckt. Die Klassen dort werden mit der Zeit besser (zum Beispiel performanter).
Genauso kannst du in C++ mit den verfügbaren Bibliotheken arbeiten (die Standard Bibliothek ist recht umfangreich - und daneben gibt es auch Boost und die OS-Libs wie MFC).
Im Übrigen machen viele Operatoren, die man bei ints nutzt, bei BigIntegers deutlich weniger Sinn. Zum Beispiel die ganzen Bit-Operatoren. Insofern sollte man die möglichst gleichartige Verwendung durchaus in Frage stellen.
OK, lassen wir mal Bit-Operatoren außen vor, aber wie sieht es aus, wenn man zwei BigInteger's verrechnen will? Kann ich einfach
bi3 = bi2*bi1;schreiben? Und wenn ja, wie haben die Java entwickler das bewerkstelligt?
-
CStoll schrieb:
OK, lassen wir mal Bit-Operatoren außen vor, aber wie sieht es aus, wenn man zwei BigInteger's verrechnen will? Kann ich einfach
bi3 = bi2*bi1;schreiben? Und wenn ja, wie haben die Java entwickler das bewerkstelligt?Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst. Insofern nutzt Du da natürlich einen ganz normalen Methodenaufruf.
Prinzipiell könnte dort natürlich eine spezielle Behandlung eingebaut werden. Bei der String-Klasse wird das ja gemacht. ...und führt dort immer wieder zur Verwirrung.
-
Gregor schrieb:
Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst.
Hm. Das scheint echt ein Mentalitätsunterschied zu sein. Ich bin fast verrückt geworden, als ich für einen Kurs in Java neuronale Netze implementieren musste und dafür die Jama-Matrixklassen verwendet habe. Und das ging nicht nur mir so sondern allen anderen Kursteilnehmern auch. Es ist einfach extrem blöd, wenn man ohnehin schon komplexe Formeln (na ja … Gauss-Verteilungen und so) durch eine dermaßen textintensive Code-Umsetzung noch komplexer macht. Finde da mal nen Fehler drin.
-
Gregor schrieb:
CStoll schrieb:
OK, lassen wir mal Bit-Operatoren außen vor, aber wie sieht es aus, wenn man zwei BigInteger's verrechnen will? Kann ich einfach
bi3 = bi2*bi1;schreiben? Und wenn ja, wie haben die Java entwickler das bewerkstelligt?Du weißt doch eh, dass man sich bei Java gegen das Operator-Overloading entschieden hat. Eine Designentscheidung, die sicherlich sowohl positive, als auch negative Aspekte hat. Ich habe es bisher zumindest noch nicht stark vermisst. Insofern nutzt Du da natürlich einen ganz normalen Methodenaufruf.
Und was haben wir davon? Jede Zahlenklasse verwendet ihre eigenen Methodennamen (und Parameterkombinationen), um eine bestimmte Operation umzusetzen. Auch nicht gerade förderlich.
Prinzipiell könnte dort natürlich eine spezielle Behandlung eingebaut werden. Bei der String-Klasse wird das ja gemacht. ...und führt dort immer wieder zur Verwirrung.
Erzähl mehr. Hat die String-Klasse tatsächlich überladene Operatoren? Und wenn ja, wie wurde das erreicht?
-
CStoll schrieb:
pale dog schrieb:
die klassen in Java können das, wofür sie gemacht wurden, das ist in deiner lieblingssprache auch nicht anders
Aber wenn ich künstlich darin beschränkt werde, was ich meinen Klassen beibringen darf, sehe ich den Sinn dahinter nicht.
was meinst du mit 'künstlich' beschränkt?
irgendwelche beschränkungen gibt's ja in jeder programmiersprache.CStoll schrieb:
pale dog schrieb:
aber wieso sollten sich objekte wie eingebaute ints verwenden lassen?
das würde doch mehr verwirrung stiften als nützen.Gegenfrage: Warum sollen "meine" BigInt's sich anders verhalten als die eingebauten int's? Beide stellen eine Zahl dar, also sollte man auch mit beiden vernünftig (und unter vergleichbaren Bedingungen) rechnen können.
schau dir mal die methoden von 'BigInteger' an, ist eigentlich alles dabei, was man braucht und mehr (primzahlentest, gcd ;)). intern sind die natürlich anders aufgebaut als die eingebauten int's, aber das ist für den anwender, der damit rechnen will, etc. normalerweise von geringerer bedeutung.
also, was vermisst du?CStoll schrieb:
CStoll schrieb:
Und da behauptet Java immer, objektorientiert zu sein
pale dog schrieb:
ist es ja auch, es übertreibt nur nicht damit.
Wenn es objektorientiert ist, warum drückt es mir dann keine Objekte in die Hand?
wie meinst du denn das?
willst du irgendwelche objekte gleich beim start des programms haben
oder dass 'alles' ein objekt ist, auch einfache ganzzahlen?