Mehr als eine Programmiersprache. segen oder qual?
-
Ja, und die Methodik ist von Sprache zu Sprache unterschiedlich. Wer natuerlich nur Sprachen aus dem OO-Umfeld benutzt, wird nur diese Methodik lernen. Deswegen sind fuer mich beispielsweise C++ und Java in einer Gruppe und zaehlen nicht wirklich als verschieden.
-
knivil schrieb:
Ja, und die Methodik ist von Sprache zu Sprache unterschiedlich. Wer natuerlich nur Sprachen aus dem OO-Umfeld benutzt, wird nur diese Methodik lernen. Deswegen sind fuer mich beispielsweise C++ und Java in einer Gruppe und zaehlen nicht wirklich als verschieden.
Sehe ich ähnlich. Neben einer OOP-Sprache z.B. noch eine funktionale kennenzulernen, hat möglicherweise größeren Mehrwert, als Sprachen aus derselben Gruppe zu kennen. Im besten Fall reflektiert man dadurch ein wenig über seinen Stil in seiner "Muttersprache" und findet bestimmte Konzepte aus der anderen Welt, die einem in dieser Sprache helfen.
Was aber eben nicht bedeutet, auf biegen und brechen alles das, was man in Haskell kennengelernt hat, jetzt in C++ umsetzen zu wollen.
-
Was macht man anders schrieb:
hustbaer schrieb:
In Java (und den meisten "GC Sprachen") macht man so ziemlich alles ziemlich anders.
Beispiele?
In diesem Thread habe ich ein paar wichtige Unterschiede aufgelistet.
-
knivil schrieb:
Ja, und die Methodik ist von Sprache zu Sprache unterschiedlich. Wer natuerlich nur Sprachen aus dem OO-Umfeld benutzt, wird nur diese Methodik lernen. Deswegen sind fuer mich beispielsweise C++ und Java in einer Gruppe und zaehlen nicht wirklich als verschieden.
Das steht in keinem Widerspruch zu meiner Aussage. Viele Wege führen zum Ziel, wenn ich die mir zur Verfügung stehenden Mittel und Methoden benutze, um zum Ziel zu kommen, brauche ich keine weiteren. Die Rahmenbedingungen müssen allerdings schon stimmen, ich würden mit Logo keinen Treiber programmieren wollen (vermutlich auch nicht können).
Mit Methodik meinte ich eigentlich Dinge wie Zerlegung des Gesamtproblems in Teilprobleme oder die Auswahl und Implementation der korrekten Algorithmen. Das alles ist sprachunabhängig und lässt durch die Paradigmen der konkreten Sprache realisieren.
-
DocShoe schrieb:
Mit Methodik meinte ich eigentlich Dinge wie Zerlegung des Gesamtproblems in Teilprobleme oder die Auswahl und Implementation der korrekten Algorithmen. Das alles ist sprachunabhängig und lässt durch die Paradigmen der konkreten Sprache realisieren.
Der beste Entwurf berücksichtigt auch die Implementierungssprache. Ohne diese im Auge zu haben, wird es leider nur zweitbestig (, was meistens vollkommen ausreichend ist).
-
gut =),
und ich dachte schon java zu lernen wäre überflüssig
-
kantaki schrieb:
und ich dachte schon java zu lernen wäre überflüssig
Mit deiner Erfahrung wuerde ich etwas vorsichtiger mit Aussagen wie "ueberfluessig" sein.
-
Was macht man anders schrieb:
hustbaer schrieb:
Java zusätzlich zu C++ ist schon ne sehr gute Idee.
In Java (und den meisten "GC Sprachen") macht man so ziemlich alles ziemlich anders.Beispiele?
Pointerarithmetik in C++, ok, aber OOP?
Guck mal wo in Java/C# überall Interfaces, Factories oder ganz allgemein dynamische Polymorphie eingesetzt wird. In typischem Java-Code findet man kaum einen Abschnitt mit ein paar hundert Zeilen, wo nicht irgendwo mit Interface- oder Basisklassen-Referenzen rumhantiert wird. In C++ ist es eher umgekehrt, da muss man in vielen Programmen die Stellen suchen wo mit abstrakten Klassen gearbeitet wird.
Patterns wie RAII sind bei Java/C# wenig verbreitet, RRID quasi nicht-existent. In C++ ist RAII/RRID "Standard".
Shared-Ownership von Objekten die "unmanaged" Resourcen verwalten ist etwas, was man in Java/C# meidet wie die Pest. In C++ ist es dank shared_ptr kein Thema, und wird auch häufig gemacht.
In C#/Java legt man (gezwungenermassen) fast alles mit "new" an, in C++ ist "new" eher was seltenes.
In C++ sind Singletons und class-static Variablen einigermassen verpönt, da die korrekte Umsetzung alles andere als trivial ist. In Java/C# wird damit recht freizügig umgegangen, da die Umsetzung viel einfacher ist (Initialisierung kann man threadsafe mit lock/synchronized machen, und freigeben tut man einfach nix).
...
-
abstract polymorphe basisklasse halbherzig zusammengeschustert durch weltfremden langzeitfrickler
-
hustbaer schrieb:
RRID
Das Acronym musste ich erstmal googlen ...
-
knivil schrieb:
hustbaer schrieb:
RRID
Das Acronym musste ich erstmal googlen ...
Resource Reclamation Is Destruction. Ist sozusagen das Gegenteil von RAII - oftmals wird RAII aber für beides zusammen gebraucht, für RAII/RRID.
-
DocShoe schrieb:
Mit Methodik meinte ich eigentlich Dinge wie Zerlegung des Gesamtproblems in Teilprobleme oder die Auswahl und Implementation der korrekten Algorithmen.
Schön aus dem Lehrbuch. Mehr auch nicht.
-
Auch wenn RAII als Bezeichnung ungluecklich gewaehlt ist, beinhaltet es RRID. RAII verliert sonst seine Bedeutung, da ich meine Variablen sowieso beim Deklarieren initialisiere.
-
knivil schrieb:
Auch wenn RAII als Bezeichnung ungluecklich gewaehlt ist, beinhaltet es RRID. RAII verliert sonst seine Bedeutung, da ich meine Variablen sowieso beim Deklarieren initialisiere.
ifstream file;
-
Michael E. schrieb:
ifstream file;pöses Michael E.!
-
knivil schrieb:
Wer natuerlich nur Sprachen aus dem OO-Umfeld benutzt, wird nur diese Methodik lernen. Deswegen sind fuer mich beispielsweise C++ und Java in einer Gruppe und zaehlen nicht wirklich als verschieden.
Und weil du C++ nie richtig verstanden hast, wie man an deinen Post vor der Haskell Zeit sieht.
-
Verstanden haben und gleicher Meinung sein, sind zwei verschiedene Dinge. Genauso wie sich hinter einem Unreg zu verstecken im Vergleich zu einem Reg.
