C oder C++?

krümelkacker schrieb:

Für OOP erstmal Java schrieb:

Anstatt von C auf C++ umzusteigen ist es besser nach C erstmal auf Java umzusteigen und erst dann am Schluß C++, wenn nicht andere Sprachen wie Hasjell oder Python dazwischen kommen.

Grund:
Die objekt orientierte Programmierung lernt man mit Java besser und leichter.
In C++ kann man so viel zwischen Objekt Orientiertem Design und prozeduralen Design vermixen, daß am Ende nur halbgarer Müll rauskommt, das weder gutes C noch gutes Objekt orientiertes Design ist.

Deswegen sollte man diese Reihenfolge einhalten:
1. C
2. Java
3. ne Scriptsprache wie Python
4. C++
5. Haskell

Vor Java C zu können erleichtert es auch zu verstehen, was Java intern mit Objekten macht.

Das sehe ich ganz anders. Lernst Du vor C++ Java, wirst Du erstmal in C++ überall abstrakte Klassen (statt Interfaces) definieren wollen und alles in Klassen zwingen wollen. Das ist auch großer Käse. Ich spreche da aus eigener Erfahrung (Basic/Pascal/Java/C++/Python). Du stellst den OOP/Prozedural-Mix als etwas schlechtes dar. Das ist er aber gar nicht. Es macht einfach keien Sinn, alles irgendeiner Klasse zuzuordnen. Und eines der wenigen Abstraktionsmittel, die ein Java Programmierer kennt, ist die Sache mit der Vererbung und den Interfaces. Da hat C++ noch ein bisschen mehr zu bieten. Die Stile, die sich nach und nach in Java und in C++ rauskristallisieren sind sehr verschieden. Wenn Du C++ programmieren willst, lern C++ und nicht vorher noch zig andere Sprachen, die mit C++ kaum etwas zu tun haben.

Wenn es um das Programmieren an sich geht, was zu lernen ist, dann würde ich mir die erste zu erlernende Sprache gut überlegen und eine aussuchen, die am Anfang den Frustfaktor minimiert ... vielleicht Python.

Cheers!
kk

Es geht darum erstmal ordentliches OOP Design zu lernen und das geht eben mit Java am Besten, weil Java nicht mehr bietet als OOP.
Bei C++ wird er ein gutes ordentliches OOP Design nie lernen, da wird es dann Kraut und Rüben.

Statt Java wäre C# auch noch eine gute Alternative.

314159265358979

Java ist krampfhaftes OOP, da kann ich kruemelkacker nur zustimmen.

_kermit

314159265358979 schrieb:

Java ist krampfhaftes OOP, da kann ich kruemelkacker nur zustimmen.

Inwiefern?

314159265358979

Man muss Dinge in Klassen stopfen, die mit Klassen absolut nichts am Hut haben.

_kermit

314159265358979 schrieb:

Man muss Dinge in Klassen stopfen, die mit Klassen absolut nichts am Hut haben.

Das ist kein spezielles Java-Problem, sondern ein Problem der klassenbasierten Objektorientierung.

314159265358979

Das mag schon sein. Was aber dann trotzdem gegen Java spricht.

_kermit

314159265358979 schrieb:

Das mag schon sein. Was aber dann trotzdem gegen Java spricht.

...und gegen alle anderen, nicht-hybriden OO-Sprachen. Heureka.

314159265358979

Was du nicht sagst.

Bist du im echten Leben eigentlich auch so unsympathisch Pi?

314159265358979

Hängt von der Person ab, die mir gegenübersteht.
Generell: Ja. :p

Für OOP erstmal Java schrieb:

Es geht darum erstmal ordentliches OOP Design zu lernen und das geht eben mit Java am Besten

nö. Am besten geht das mit einer lupenreinen objektorientierten Sprache (smalltalk)

Für OOP erstmal Java schrieb:

, weil Java nicht mehr bietet als OOP.

java ist ein Kompromiß aus C-ähnlicher Syntax, statischer Typisierung (die eigentlich dem Grundgedanken der OOP zuwiderläuft) und OOP.

volkard schrieb:

Und am Wichtigsten: Nicht so auf die C++-Basher hören.
Es gibt hier ein paar (oder einen mit mehreren Namen), die wollen damit nur provozieren. Im Zweifelsfall bei kontroversen Themen nicht auf Unregistrierte hören.

Oder man kann es so sehen: volkard hat sich einfach zu sehr auf C++ verkrampft.

dot

!rr!rr_. schrieb:

[...] statischer Typisierung (die eigentlich dem Grundgedanken der OOP zuwiderläuft) [...]

Oho, wie das denn?

weil statische Typisierung die "späte Bindung" erschwert bis verunmöglicht. C++ wird formal seit STL unter anderem deshalb immer komplexer, weil man in C++ die ganz offenbar gewünschte Flexibilität der dynamischen Typisierung mit den Mitteln statischer Typisierung simulieren muß.

Eine Figur aus Metall so zu bauen, daß sie hinterher die Flexibilität einer Figur aus Knetmasse hat, ist eben komplizierter als die Figur gleich aus Knetmasse zu bauen.

Artchi

!rr!rr_. schrieb:

weil statische Typisierung die "späte Bindung" erschwert bis verunmöglicht. C++ wird formal seit STL unter anderem deshalb immer komplexer, weil man in C++ die ganz offenbar gewünschte Flexibilität der dynamischen Typisierung mit den Mitteln statischer Typisierung simulieren muß.

Eine Figur aus Metall so zu bauen, daß sie hinterher die Flexibilität einer Figur aus Knetmasse hat, ist eben komplizierter als die Figur gleich aus Knetmasse zu bauen.

Metall? Knete? Was hat das mit Late-Binding zu tun? Fragen über Fragen...

Aber lass dir gesagt sein, das Late-Binding in C++ mit dem virtual Keyword erreicht wird. Und wenn das nicht für OO ausreicht, solltest du nochmal die Schulbank drücken.

Übrigens benutzt Smalltalk doch gar keine Member-Function-Aufrufe, sondern Nachrichten. Aber was haben Nachrichten mit OO zu tun? Dann hat das ja das Win32-Nachrichten-System schon lange perfekt OO-artig gemacht?

NAchrichten sind also nicht das Maß der Dinge, um OO zu erfüllen. Es ist allein entscheidend, zur Laufzeit zu entscheiden, welches Verhalten (sprich Code) aufgerufen wird. Und das erfüllt C++ mit virtual vollständig.

dot

!rr!rr_. schrieb:

weil statische Typisierung die "späte Bindung" erschwert bis verunmöglicht. C++ wird formal seit STL unter anderem deshalb immer komplexer, weil man in C++ die ganz offenbar gewünschte Flexibilität der dynamischen Typisierung mit den Mitteln statischer Typisierung simulieren muß.

Und was hat das jetzt mit OOP zu tun?

wie "was hat das jetzt mit OOP zu tun" ?

Artchi schrieb:

Aber lass dir gesagt sein, das Late-Binding in C++ mit dem virtual Keyword erreicht wird. Und wenn das nicht für OO ausreicht, solltest du nochmal die Schulbank drücken.

soso, sollte ich. Du verwechselst scheinbar dynamic dispatch mit late-binding. Daß C++ mit "virtual" eine Art von dynamic dispatching unterstützt, bezweifelt niemand. Das ist eben die angesprochene "Simulation" von Flexibilität zur Compilezeit.

compul

wollt ihr euch noch weiter austoben oder closen? meine fragen wurden zur genuege beantwortet