POLL (Programmiersprachen)
-
finix schrieb:
Aber gut, noch einmal: was meinst du mit "wesentlich objektorientierter (in Bezug auf Wiederverwendbarkeit)"?
Steht doch bereits oben. Zum Beispiel kann ich von java.util.List ableiten wenn das sinnvoll ist, oder ich leite eine neue Implementation von java.util.LinkedList ab und verwende sie über das java.util.List-Interface. Bridge-Pattern sei dank.
finix schrieb:
Wieviel mehr an "tatsächlicher Funktionalität" bietet denn java.util.Vector gegenüber std::vector, oder std::set oder was auch immer, und wozu soll dann java.util.Collections überhaupt gut sein?
Wo steht, dass sie mehr tatsächliche Funktionalität haben? Aber ich schätze z.B. Features wie: Austauschbare Implementierung, threadsichere Versionen, etc.
MfG SideWinder
-
Ganz persönliches Problem noch: Java mag zwar auch nicht stur objektorientiert sein, aber als 'hybrid' würde ich es auch nicht bezeichnen. Das in C++ immer mehr mit Meta-Programmierung gearbeitet wird stört mich.
MfG SideWinder
-
SideWinder schrieb:
Beispiel: kingruedi entwickelt ein neues GUI-Framework und macht sich erstmal fast ein Jahr um seine Konfigurationsschnittstelle Gedanken. Die passt dann zwar höchstwahrscheinlich perfekt für sein Framework, andererseits hat er ein Jahr Entwicklungskosten die bei Verwendung einer anderen Programmiersprache nie aufgetaucht werden.
Das ist absoluter Blödsinn den du da schreibst.
1. handelt es sich bei dem Projekt um keine Entwicklung in einem wirtschaftlichen Umfeld, sondern um das Streben nach Perfektion. Daher ist es eh schwachsinnig irgend eine Vorstellung von Entwicklungskosten und co anzubringen.
2. hat die Programmiersprache damit nichts zu tun. Für C++ gibt es genauso XML und was weiß ich Parser. Vielleicht kommst du mal dahinter, das wir kein XML nehmen wollten.
Und irgend wann lernst du sicher auch einmal, das 0815-Denken, 0815-Projekte, 0815-Programmiersprachen auch nur zu einem 0815-Gehalt führen und dass die Welt nicht hinter dem Tellerrand aufhört.
Und in der Realität), wird C++ sehr erfolgreich eingesetzt von sehr erfolgreichen Firmen, die damit sehr erfolgreich Geld machen, mit sehr realen und sehr erfolgreichen Produkten. Was auch für Programmiersprachen gilt, die du als esotherisch abtun würdest.
-
SideWinder schrieb:
Ganz persönliches Problem noch: Java mag zwar auch nicht stur objektorientiert sein, aber als 'hybrid' würde ich es auch nicht bezeichnen. Das in C++ immer mehr mit Meta-Programmierung gearbeitet wird stört mich.
Warum?
Generisches Programmieren sorgt doch für eine höhere Wiederverwendbarkeit von Software. Ich finde eher den Ansatz der in Java immer populärer wird schwierig. Code-Generatoren in Preprozessor-Style. Da habe ich lieber C++-Code, der mir C++-Code generiert.
Wiederverwendbarkeit von Software ist einfach eine Frage, wie das in Firmen gehandhabt wird. Gibt es eine (interne) Bibliothek, die für die Projekte genommen, erweitert und gepflegt wird oder wird jedes mal das Rad neu erfunden.
-
Da das hier (wie immer) eh in einen Flamewar ausartet, kann ich ja mal meinen Senf dazu geben:
Ich habe (den subjektiven!) Eindruck, dass C++ immer mehr lediglich in speziellen Performance-kritischen Bereichen eingesetzt wird (überspitzt gesagt kommt es mir so vor, als würde nur noch die Computerspielebranche und diverse Simulationen für Neuentwicklungen auf C++ setzen). Der ganze breite Markt benutzt irgendwie fast nur noch Java/.NET etc., seien das nun Webanwendungen, Frontends, Application Server, Middlewarelösungen oder oder oder.
Die Entwicklung kann ich absolut nachvollziehen. Wann immer ich nen Studentenjob als Programmierer angenommen hab, war ich froh wenn ich nicht mit C++ in Berührung kam. In Java und .Net fällt einem alles irgendwie leichter, weniger kryptisch und man braucht nicht Tonnen von Detailwissen um guten Code zu schreiben. Ehrlich gesagt sehe ich neben der Performance überhaupt keinen Grund mehr heute auf C++ zu setzen. Aber wie gesagt, alles meine persönliche(n) Meinung/Erfahrungen.
-
rüdiger schrieb:
Das ist absoluter Blödsinn den du da schreibst.
Und das ist jetzt wohl deine 0815-Antwort?
rüdiger schrieb:
1. handelt es sich bei dem Projekt um keine Entwicklung in einem wirtschaftlichen Umfeld, sondern um das Streben nach Perfektion. Daher ist es eh schwachsinnig irgend eine Vorstellung von Entwicklungskosten und co anzubringen.
...aber umbedingt an der Konfiguration beginnen - selbst ganz ohne Entwicklungskostendenken. Naja ich mische mich in euer Perfektionsprojekt nur ungern (dafür umso öfter :D) ein. Gehört auch im Rahmen des Threads nicht unbedingt dazu. Fakt bleibt: Projektplanung ist ein wichtiger Punkt in einem Projekt.
rüdiger schrieb:
Und irgend wann lernst du sicher auch einmal, das 0815-Denken, 0815-Projekte, 0815-Programmiersprachen auch nur zu einem 0815-Gehalt führen und dass die Welt nicht hinter dem Tellerrand aufhört.
Wenn man über Programmiersprachen redet muss man nunmal auch über 0815-Projekte reden. Sonst ist Prolog plötzlich die richtige Programmiersprache für eine MediaLibrary. Über ein 0815-Gehalt kommt man in erster Linie wenn man für Probleme die richtigen Lösungswege findet. Hier gilt es nunmal über den C++-Tellerrand hinauszuschauen. Ist C++ wirklich die beste Sprache wenn ich einen Pokerclient schreibe? Ist Java brauchbar für 3D-Programmierung? Ist mein Mini-/Riesen-Webportal wirklich mit EJB/PHP richtig bedient?
rüdiger schrieb:
Und in der Realität), wird C++ sehr erfolgreich eingesetzt von sehr erfolgreichen Firmen, die damit sehr erfolgreich Geld machen, mit sehr realen und sehr erfolgreichen Produkten.
Was genau willst du uns damit sagen? Full ACK auf jeden Fall.
rüdiger schrieb:
Was auch für Programmiersprachen gilt, die du als esotherisch abtun würdest.
Hrhr, ABAP z.B.
rüdiger schrieb:
Ich finde eher den Ansatz der in Java immer populärer wird schwierig. Code-Generatoren in Preprozessor-Style.
Kenne ich nur aus MDA, und das steckt noch in den Kinderschuhen soviel ich da immer sehe. Generiert und geschrieben wird kaum noch Code, geht doch mehr alles in Richtung Framework-Verwendung.
rüdiger schrieb:
Wiederverwendbarkeit von Software ist einfach eine Frage, wie das in Firmen gehandhabt wird.
Ich möchte die Anzahl der TCP-Socket-Bibliotheken für C++ nicht kennen *g*
MfG SideWinder
-
@this->that: Aufpassen, die großen Firmen können es sich sehrwohl leisten die richtigen Spezialisten zu holen, viele interne Bibliotheken zu warten, etc. Da geht dann auch gleich viel mehr mit C++.
MfG SideWinder
-
SideWinder schrieb:
rüdiger schrieb:
Das ist absoluter Blödsinn den du da schreibst.
Und das ist jetzt wohl deine 0815-Antwort?
0815-Antwort auf 0815-Side-Blödsinn
rüdiger schrieb:
1. handelt es sich bei dem Projekt um keine Entwicklung in einem wirtschaftlichen Umfeld, sondern um das Streben nach Perfektion. Daher ist es eh schwachsinnig irgend eine Vorstellung von Entwicklungskosten und co anzubringen.
...aber umbedingt an der Konfiguration beginnen - selbst ganz ohne Entwicklungskostendenken. Naja ich mische mich in euer Perfektionsprojekt nur ungern (dafür umso öfter :D) ein. Gehört auch im Rahmen des Threads nicht unbedingt dazu. Fakt bleibt: Projektplanung ist ein wichtiger Punkt in einem Projekt.
Wer sagt überhaupt, das wir mit der Konfiguration angefangen haben? Ich glaube kaum, dass deine Kenntnisse der Interna dieses Projekts aussreichen um das wirklich beurteilen zu können.
rüdiger schrieb:
Und irgend wann lernst du sicher auch einmal, das 0815-Denken, 0815-Projekte, 0815-Programmiersprachen auch nur zu einem 0815-Gehalt führen und dass die Welt nicht hinter dem Tellerrand aufhört.
Wenn man über Programmiersprachen redet muss man nunmal auch über 0815-Projekte reden. Sonst ist Prolog plötzlich die richtige Programmiersprache für eine MediaLibrary. Über ein 0815-Gehalt kommt man in erster Linie wenn man für Probleme die richtigen Lösungswege findet. Hier gilt es nunmal über den C++-Tellerrand hinauszuschauen. Ist C++ wirklich die beste Sprache wenn ich einen Pokerclient schreibe? Ist Java brauchbar für 3D-Programmierung? Ist mein Mini-/Riesen-Webportal wirklich mit EJB/PHP richtig bedient?
Nein, man muss nicht über 0815-Projekte reden. Welche Programmiersprache und welche Werkzeuge die richtigen sind hängt vom Problem ab und ich schaffe mir kein künstliches 0815-Problem um dann zu sagen "hey, schaut die 0815-Lösung funktioniert. Also ist sie die beste". Außerdem schaue ich regelmäßig über den C++-Tellerrand. (Vermutlich deutlich öfters als du über deinen Java/C++-Tellerrand guckst). Ich habe hier auch nicht behauptet, dass C++ die beste Programmiersprache sei oder C++ gar für ein spezifisches Problem empfohlen.
rüdiger schrieb:
Und in der Realität), wird C++ sehr erfolgreich eingesetzt von sehr erfolgreichen Firmen, die damit sehr erfolgreich Geld machen, mit sehr realen und sehr erfolgreichen Produkten.
Was genau willst du uns damit sagen? Full ACK auf jeden Fall.
Das du nur rumtrollst.
rüdiger schrieb:
Wiederverwendbarkeit von Software ist einfach eine Frage, wie das in Firmen gehandhabt wird.
Ich möchte die Anzahl der TCP-Socket-Bibliotheken für C++ nicht kennen *g*
das sagt was aus?
@this->that
schein und sein. Wie willst du das beurteilen können? Das war ja auch das Ursprungsproblem des Threads aus dem dieser Thread entstanden ist.
-
SideWinder schrieb:
finix schrieb:
Aber gut, noch einmal: was meinst du mit "wesentlich objektorientierter (in Bezug auf Wiederverwendbarkeit)"?
Steht doch bereits oben. Zum Beispiel kann ich von java.util.List ableiten wenn das sinnvoll ist, oder ich leite eine neue Implementation von java.util.LinkedList ab und verwende sie über das java.util.List-Interface. Bridge-Pattern sei dank.
Das hat ja mal rein gar nichts mit dem Bridge-Pattern zu tun, sondern eher mit konsequenter Anwendung des OCP.
-
Das du dich immer gleich persönlich angegriffen fühlst. Ich spendier' dir bei Gelegenheit mal ein Bier
MfG SideWinder
-
Apollon schrieb:
Das hat ja mal rein gar nichts mit dem Bridge-Pattern zu tun, sondern eher mit konsequenter Anwendung des OCP.
Warum hat das nichts mit dem Bridge-Pattern zu tun?
MfG SideWinder
-
Wenn Du dir das Pattern nochmal anschaust, wirst Du erkennen, dass Abstraction eine Referenz auf Implementor haelt und die Aufrufe delegiert (aehnlich wie bei Strategy oder Object-Adapter). Desweiteren wirst Du erkennen, dass Du einer Referenz auf Abstraction eine RefinedAbstraction zuweisen kannst, welche wiederrum eine Referenz auf RefinedImplementor haelt. Dies geht in dem von dir beschriebenem Beispiel nicht. Vielmehr hast Du einfach nur die Vererbung beschrieben.
In der STL wird uebrigens auch Abstraktion von der Implementierung getrennt (zumindest bei Containern bei denen es Sinn macht). Allerdings auf eine andere Art. Austauschbare Klassen bieten da gleiche Schnittstelle an und die Abstraktion geschieht im Kopf, anstatt im Code. Nachteil: Implementierung ist nicht zur Laufzeit austauschbar.
-
Hab jetzt den Thread nicht gelesen, aber das Resultat ist wirklich erstaunlich
-
Ja, immer wieder erstaunlich was eine bestimmt Gruppierung hier im Forum bzgl. wöchlichem Flamewar leistet.
-
Artchi schrieb:
Ja, immer wieder erstaunlich was eine bestimmt Gruppierung hier im Forum bzgl. wöchlichem Flamewar leistet.
Du verwechselst Präferenzen mit Fakten. Die Statistiken, die hier manchmal über Job-Angebote und so gepostet werden, sind völlig unabhängig davon, ob hier 5% Java bevorzugen oder 95%. Das ändert diese Statistiken nicht.
-
Es wär ja besser, der Thread würde schnell versinken, aber...
Java is für fleißige,
C++ für faule Programmierer....
:p
c ya, cPanther
-
ajcPanther schrieb:
Es wär ja besser, der Thread würde schnell versinken, aber...
Java is für fleißige,
C++ für faule Programmierer....
:p
c ya, cPanther
Ich glaub ja eher umgekehrt
-
Ich glaub ja eher umgekehrt
Nee
, is schon bewusst so gewählt, Java fördert fleiß.c ya, cPanther
-
Apollon schrieb:
SideWinder schrieb:
finix schrieb:
Aber gut, noch einmal: was meinst du mit "wesentlich objektorientierter (in Bezug auf Wiederverwendbarkeit)"?
Steht doch bereits oben. Zum Beispiel kann ich von java.util.List ableiten wenn das sinnvoll ist, oder ich leite eine neue Implementation von java.util.LinkedList ab und verwende sie über das java.util.List-Interface. Bridge-Pattern sei dank.
Das hat ja mal rein gar nichts mit dem Bridge-Pattern zu tun, sondern eher mit konsequenter Anwendung des OCP.
bei vererbung von containerklasse ist sehr viel vorsicht angebracht: http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip
bzwl. allgemein bei vererbung von implementation.nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
-
mathik schrieb:
nichtsdestotrotz finde ich, dass die stl hätte mehr objektorientiert designed werden können. besonders wie die streams aufgebaut sind, finde ich ganz schlimm.
die sind nicht Objektorientiert?