PureBoard

@Danilo
Ich nur stimme dir bei dem Meisten was du geschrieben hast nicht zu.
Ich will mir nur ein paar Beispiele herausgreifen:

Sie gewöhnen sich an unsichere Programmierung

Leute die gleich mit in C++ anfangen werden genau so unsicher programmieren, wenn ihnen keiner sagt das man sich auch um Fehlerbehandlung kümmern muss.
Es ist eben besser wenn man zunächst den "niederen Dreck". Dieses von Oben nach unten lernen ist gut fürs Hobby, aber nicht wenn man Profi oder Experte werden will.

daran das es in C keine Strings gibt

Und das ist auch gut so. Da durch lernt man das Strings nicht leicht zu handhaben sind. Es ist ein häufiges Problem. Ich konnte es gut im Studium beobachten, Leute die vorher in Java oder Pascal programmiert habe wüssten nicht mit welchem Rechenaufwand handhaben von Strings verbunden ist(im vergleich zu einfachen Daten-Typen) .

primitiven 'Highlevel-ASM' C

Ich verstehe nicht warum du so abfällig über C schreibst. Außerdem sei mir bitte nicht sauer aber das glaubs du doch selbst nicht, weil es einfach Unsinn ist. Und das merkt man sofort wenn man so eine "primitive" Funktion wie sprintf selbst implementieren muss.

MARTIN hat geschrieben:Leute die gleich mit in C++ anfangen werden genau so
unsicher programmieren, wenn ihnen keiner sagt das man
sich auch um Fehlerbehandlung kümmern muss.

Da Exception Handling zum Standard gehört, wird einem
das in jedem ordentlichem Lehrbuch gesagt und gelernt.

MARTIN hat geschrieben:Es ist eben besser wenn man zunächst den "niederen Dreck".

Es ist also besser wenn ein Anfänger ganz unten anfängt
und sich dann steigert?
Erst Maschinensprache für irgendeine Architektur. Alles wieder
vergessen und dann steigern auf C. Alles wieder vergessen
und dann C++/C#/Java. Oder wie?

MARTIN hat geschrieben:Dieses von Oben nach unten lernen ist gut fürs Hobby, aber
nicht wenn man Profi oder Experte werden will.

Bevor man lernt ein modernes Auto zu fahren, muß man
doch auch nicht erst 2 Jahre mit der Pferdekutsche fahren,
nur weil es das früher gab.

MARTIN hat geschrieben:

daran das es in C keine Strings gibt

Und das ist auch gut so. Da durch lernt man das Strings
nicht leicht zu handhaben sind. Es ist ein häufiges Problem.
Ich konnte es gut im Studium beobachten, Leute die vorher
in Java oder Pascal programmiert habe wüssten nicht mit
welchem Rechenaufwand handhaben von Strings verbunden
ist(im vergleich zu einfachen Daten-Typen) .

Dann empfehle halt den PB-Neueinsteigern auch erstmal
C oder ASM zu machen, bevor sie eine Sprache nehmen die
sogar Strings bietet.

Das hab ich bei (Pure-)Basic, Java und C# noch nie gehört
das da einer meinte man soll erstmal C lernen bevor man
sich an diese Sachen wagt, weil die schon Strings haben.
Nur bei C++ hat es sich eingebürgert zu empfehlen erstmal
C zu nehmen.
Im übrigen lernt man auch mit modernen Sprachen was Arrays,
Datenstrukturen usw. sind, genauso wie Algorithmen etc.
Um diese Programmiergrundlagen zu erlernen muß man nicht
auf moderne Sprachen verzichten.

Sollte ein PB-Einsteiger auch erstmal DirectX, SDL und OpenGL
lernen, so daß er sieht wie schwierig das ist, bevor er dann
OpenScreen() und Sprites verwenden darf?
Auf diese Idee würde niemand kommen. Interessiert viele
Leute garnicht wie das intern funktioniert, die wollen es
einfach nur benutzen und damit etwas schaffen. Genauso
wollen sie einfach 'String3 = String1 + String2' schreiben
und nicht lowlevel die Inhalte der Strings rumkopieren und
aneinanderhängen.

MARTIN hat geschrieben:

primitiven 'Highlevel-ASM' C

Ich verstehe nicht warum du so abfällig über C schreibst.

Vielleicht weil es aus der Steinzeit der Computerära kommt?

Wenn jemand C kann oder lernen will, dann soll er das tun.
Einem Neueinsteiger sollte man aber nicht empfehlen erstmal
die Steinzeit durchzumachen, wenn er auch gleich in der
modernen Welt lernen kann.
Das gilt für C++, C# und Java gleichermaßen. Sogar bei PB
würde ich niemandem raten erstmal Steinzeit-C zu machen,
bevor er sich mit PB beschäftigt.

Wenn Du Deinem kleinen Sohn lernen willst wie er die moderne
Heizung im Haus selbst anschalten/einstellen kann, wirst Du
ihm doch auch nicht erst lernen wie man mit 2 Hölzern ein
Feuer macht, nur weil man das in der Steinzeit so gemacht hat,
um es dann schön warm in der Höhle zu haben.

MARTIN hat geschrieben:Und das merkt man sofort wenn man so eine "primitive"
Funktion wie sprintf selbst implementieren muss.

Solche Funktionen sind dazu noch unsicher, weil sie eine
unbegrenzte Anzahl Argumente nehmen und auch der
Typ egal ist. Kennst ja das Argument '...' - sowas sollte
man garnicht erst benutzen.

Du bist halt einfach ein C-Coder der nicht davon ablassen will.
Kein Problem, solange Du nicht jedem Einsteiger erzählst er
sollte auch erstmal damit anfangen. Das ist einfach Quatsch.
Ich kann aber nachvollziehen das Du so denkst - war früher
auch jahrelang auf einem ASM-Trip.
Allerdings habe ich mich deutlich weiterentwickelt und empfehle
Einsteigern heute gleich eine moderne Sprache zu lernen.
Warum sollten die erst Jahre mit uraltem Zeug verschwenden,
wenn sie es dann wieder vergessen müßen, um sauberen
Code für die modernen Sprachen zu schreiben?

Naja, mir kann es letztendlich auch egal sein ob Blackskyliner
erstmal ein paar Jahre mit ASM oder C verschwendet, um dann
später auf C++/C#/Java umzusteigen und die moderne Programmierung
zu erlernen.

Dich wird man eh nicht davon überzeugen können. Habe
gesagt was ich davon halte, fertig.

Danilo hat geschrieben:

MARTIN hat geschrieben:Dieses von Oben nach unten lernen ist gut fürs Hobby,
aber nicht wenn man Profi oder Experte werden will.

Bevor man lernt ein modernes Auto zu fahren, muß man
doch auch nicht erst 2 Jahre mit der Pferdekutsche fahren,
nur weil es das früher gab.

Du vergleichst Äpfel mit Birnen Danilo.
Was hat ein Auto mit einer Pferdekutsche zu tun?
Ein Auto baut nicht auf einer Pferdekutsche auf.
Die Technik ist eine völlig andere. C++ baut aber
auf C auf.

Ich stimme Danilo grundsätzlich zu. Ich beobachte bei mir in der Uni immer wieder, dass viele Leute mit C anfangen und dann mit C++ nichtmehr weitermachen KÖNNEN. Es ist nunmal leider so, dass die Grenze zwischen C und C++ nicht klar erkennbar ist, wenn man von C auf C++ umsteigt. Ich versuche jetzt, mir C seit gut 3 Jahren abzugewöhnen. Fehlanzeige. Ein bisschen was schleicht sich immer ein und ich hoffe, ich werde diese 'Reste' in 1-2 Jahren los sein

Kristel hat geschrieben:Was hat ein Auto mit einer Pferdekutsche zu tun?

Die Pferdekutsche ist ein Vorgänger vom Auto.

Kristel hat geschrieben:Ein Auto baut nicht auf einer Pferdekutsche auf.

Räder, Fahrer- und Beifahrersitz, Rücksitzbank, Kofferraum/Ablage hinten,
und vorne fette PS. Schon früher konnte man wählen wieviel PS
man möchte, bzw. wieviel man sich leisten kann. Pferdekutschen
gab es schliesslich mit 1, 2, 4 oder 6 PS (Pferdestärken).
Das Lenkrad war auch etwas einfacher. Nannte man Zügel.

Damals gab es halt noch keine Strings, Objekte und Exception Handling.
Ähh.. ich meinte damals gab es noch keinen Elektromotor in
der Kutsche, keine Fensterheber und Airbags zum abfangen.
Auch Pferdekutschen gab es geschlossen und als Cabrio.

Kristel hat geschrieben:Die Technik ist eine völlig andere. C++ baut aber
auf C auf.

Die Grundsyntax ist gleich, so wie bei C# und Java auch.

Bei C++ kommt dazu das man damals (vor über 25 Jahren)
C komplett mit eingebunden hat. Hätte sich sonst nicht
durchgesetzt wenn es nicht kompatibel gewesen wäre.
Es ist trotzdem eine eigene Sprache, so wie auch C# + Java,
und das sollte man sich auch bewußt machen und nicht wild
mixen, wo es nur geht.

Sebe hat geschrieben:Ich versuche jetzt, mir C seit gut 3 Jahren abzugewöhnen.
Fehlanzeige. Ein bisschen was schleicht sich immer ein und
ich hoffe, ich werde diese 'Reste' in 1-2 Jahren los sein

Bevor man etwas macht, darf man sich nicht fragen "Wie mache
ich das jetzt am besten?", sondern man muß sich immer ganz
bewußt fragen "Wie mache ich das jetzt am besten *mit C++*?".

Statt char-Arrays nimmt man halt grundsätzlich Strings und
statt der C-Funktionen für char-Arrays nimmt man dann die
Methoden der Stringklasse und Stringstreams.
Statt für mehrere Datentypen 5 überladene Funktionen 'Str'
oder 'ToString' zu schreiben, die einen Pointer zu einem
char-Array liefern, macht man halt eine Templatefunktion die
mit allen Datentypen geht und einen String oder Stream
zurückliefert.
Oder man benutzt nicht mehr 'int' sondern macht sich eine
Klasse 'Integer' dafür. Genauso für andere Typen.
Die enthält dann auch 'ToString' und man schreibt für Bytes,
Words, Longs/Integer, Floats, Doubles usw. immer einheitlich:
'string1 = i.ToString()'.

Ich nehme mir da immer ein bissl ein Beispiel an C# und Java
und schaue wie es dort funktioniert. Gäbe es C# schon länger
(überall verbreitet) und wäre es nativ kompiliert wie C++, so
wäre das IMO eh die beste Wahl. Wenn das .NET Framework
dann wirklich überall in einer aktuellen Version verfügbar ist,
gibt es nichts besseres mehr für Anwendungsprogrammierer.

Ich sehe es ebenfalls keinesfalls als notwendig an, C zu beherrschen, bevor man sich an C++ setzt.
Ich kann da zwar nur aus meiner Erfahrung mit Java sprechen, aber da wird sich bzgl. C++ nicht so viel tun.
An der Uni gab es bei uns eine gute Einführung in Java, die sämtliche Aspekte dessen OOP beleuchtete, bis später hin zu Monitoring, RMI und anderen Späßen. Ganz nebenbei lernte man dabei die Grundkonstrukte wie Schleifen, Verzweigungen, Methoden, etc. (ebenso wird man auch C nebenher lernen, wenn man C++ lernt.) Der Schwerpunkt ist aber latent immer bei der Denkweise beim Programmieren mit einer OOP-Sprache, die eine ganz andere als bei z.B. C ist. Eine Softwareidee wird ganz anders angefangen umzusetzen, eben indem man seine Struktur untersucht, und diese dann durch Klassenhierachien modelliert. Nebenbei gibt es solch mächtige Hilfmittel, wie Strings (Hurra), Garbage Collector (zumindest bei Java), Exception-Handling, Objektserialisierung (z.B. um komplette Objektinstanzen mit all ihren Arrayobjekten, Variablenwerten, etc. mit einem Befehl in eine Datei zu streamen, um die Daten später wiederherzustellen - ade du umständlich selbstgemachtes Dateiformat). Solche Dinge vereinfachen vieles bzw. ermöglichen ganz neue Herangehensweisen, und es ist sicherlich wichtig zu erkennen, was hinter der Kulisse passiert, z.B. wo Speicher- oder Laufzeitprobleme sind; man muss es aber nicht alles schonmal selbst per Hand umgesetzt haben. Ich finde es herrlich, sich bei Java nicht um lästigen Ballast kümmern zu müssen, und mächtige Hilfmittel nutzen zu können (reguläre Ausdrücke? BigDecimal? UniCode? XML-Parser? Netzwerkbefehle? ...? alles da)
Ich kann bis heute nur absolut rudimentäres C. Insbesondere dessen String-Blödsinn hat mich davon abgehalten.

Fazit: Ich finde es sinnvoller, sofort eine der Sprachen C++, C# oder Java zu lernen, als erstmal C, um dann auf eine der erstgenannten umzusteigen.

Das Pferdekutschenmodell ist meiner Meinung nach ganz treffend.
Insbesondere das Cabrio.

Mal eine Meinung von außerhalb unserer erlauchten Kreise:
http://www.joelonsoftware.com/articles/ ... dvice.html
(und vergesst den Link im Text nicht:
http://www.joelonsoftware.com/articles/ ... 00319.html)

Ich gebe damit betont keine Wertung ab, ich habe mich nur daran erinnert
dies vor einiger Zeit einmal gelesen zu haben und wollte euch an dieser
tollen Erfahrung teilhaben lassen

nette artikel.

schreibt der immer so unterhaltsam und aussagekräftig?


und hier drin hab ich auch eine zeile gefunden, die mir ermöglicht,
meine erste aussage zu illustrieren.
dies ist eine für C typische konstruktion. hier wird etwas gemacht,
was man in vielen anderen hochsprachen nicht machen kann.*
und es ist nur ein beispiel, C kann noch mehr.

und es ist definitiv C, nicht C++, denn hier ist nichts objektorientiert.

(es geht nicht darum, dass das hier aus ner string-bearbeitung stammt,
und ob jetzt strings oder nicht in C++ oder C oder C# oder wo auch immer)

es geht um die form der konstruktion.

das meinte ich, als ich sagte, man solle zuerst C lernen.
die fähigkeit zu solchen konstruktionen machen die stärke der
sprache der C-Familie aus, und wer das nicht kann,
der hat auch nix von den ganzen tollen möglichkeiten,
die ++ und # mehr bieten als ihr "veraltetes vorgängermodell".

ob man das auch vernünftig lernen kann, wenn man gleich mit C++ anfängt,
hängt vom Lehrbuch/Lehrkörper ab, aber man sollte es lernen,
wenn man eine sprache aus der C-Famly benutzen will.

-----------------------------------------------------------
* dadurch, das vergleichsoperator und zuweisungsoperator
unterschiedlich geschrieben werden, ist es möglich,
die zuweisung in einer vergleichsabfrage einzubinden.
ist das ende des string, der mit *src adressiert wird, erreicht,
wird der ganze ausdruck false.

Kaeru Gaman hat geschrieben:nette artikel.

schreibt der immer so unterhaltsam und aussagekräftig?

Kannst du leicht selbst herausfinden indem du die restlichen Artikel auch noch liest: http://www.joelonsoftware.com/Archive.html

P.S.: Nimm dir ein paar Stunden Zeit dafür!

Konstrukte wie gehen so auch in Java. (Inkrementierung vor/nach Ausdrucksauswertung durch ++V, bzw. V++) Dort schreibt man aber um einen String zu kopieren lieber


Solche Konstrukte sind eh nervig. Sie sparen zwar Codezeilen, aber werden dadurch ja nicht automatisch 'schneller'. Außerdem gibt es viele andere Aspekte Code als qualitativ hochwertig einzustufen. Dazu gehören Dinge wie Kommentierung, Verständlichkeit, Änderbarkeit, Erweiterbarkeit. Insbesondere die letzten 3 Punkte werden durch solche Konstrukte nicht erfüllt.

C ist wunderbar geeignet für Pointer-Schweinereien. (Wie PB auch)
Es gibt allerdings nichts, wobei man auf manuelle Pointerveränderungen angewiesen ist. Das macht den Code einfach nur schwerer nachvollziehbar.
(Der Geschwindigkeitsvorteil, der sich manchmal durch sowas ergibt, sollte von guten Compilern wettgemacht werden.)

Völlig einer Meinung mit dem Autor von freedimensions Link bin ich aber in dem Punkt, das Lernende verstehen sollen, was hinter den Kulissen passiert. Das bedeutet, sich mit Rechnerarchitekturen auseinanderzusetzen (Register, Speicher, CPU, ...), dann vielleicht ein wenig in Assembler schnuppern, und dann verstehen, wie Hochsprachen auf Assembler aufsetzen. Das kann allerdings durchaus in ein paar Tagen abgehakt werden.
Auch macht es Sinn, die verschiedenen Konzepte von Programmiersprachen zu verstehen (imperative Sprachen (prozedural/objektorientiert), funktionale Sprachen, logische Sprachen).
Nicht allerdings sehe ich darin die Notwendigkeit, erst die konkrete Sprache C lernen zu müssen, ebensowenig, wie die Notwendigkeit, zunächst irgendeine prozedurale Programmiersprache lernen zu müssen, bevor man mit einer objektorientierten anfängt.