Programmieren lernen - besser kein OOP.

Ich bin da immer für funktionale Sprachen.
Meist ist Java z.B. sehr hinderlich, weil die ganzen Schlüsselwörter wie public, static entweder direkt erklärt oder ignoriert werden müssen.
Daher bin ich für sehr simple Sprachen, mit denen man schnell Ergebnisse erzielen kann, an kleinen Codebeispielen die Funktionsweise erklärt und dann erst weiter in die Sprache eindringen kann.
Bei vielen Sprachen existieren schon in Hello World so viele Schlüsselwörter und zu beachtende Faktoren, dass die Arbeit damit vergleichsweise schwieriger wird.

Interessant ist auch der umgekehrte Weg Mikroprozessorarchitektur. Der Weg über Transistoren, Machinencode, Assembler hin zu höheren Sprachen ist manchmal einer der erfolgreichsten, wenn auch um einiges aufwändiger.
Ich z.B. habe vor diesem Weg schon programmieren können, aber trotzdem noch so einiges dazu gerlernt (und wieder vergessen :D) und halte den Weg garnicht für so überdimensioniert.
Man muss ja keine heutigen Rechner durchnehmen, aber ein kurzer Durchschuss durch die Entwicklung eines PCs, auch mal 3 Zeilen Maschinencode, hilft ungemein.
Aber das sollte dann doch lieber jeder selbst entscheiden.

Cpp_Junky

Du findest C noch zu "freundlich" und nicht wirklich maschinennah? Was programmierst du denn den ganzen Tag? Assembler oder gleich das Binary im Hex Editor?

lolz

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht und erst in zweiter Linie um die Implementierung mit einer (beliebigen) Sprache.

Ich kenne keine gute Einsteigersprache (von Pascal hab ich es zwar schon gehört, aber ich kenne Pascal zu wenig um das beurteilen zu können), eine Sprache zum Lernen sollte auf keinen Fall ein komplexes Programmierparadigma haben, da es den Lernprozess kompliziert macht. Der Lernende muss so das Entwerfen von Algorithmen und das Implementieren dieser in einer Programmiersprache lernen. Für den Anfang sollte die Sprache daher sehr einfach gehalten sein.

C ist vielleicht einfach im Bezug auf das Programmierparadigma und die Menge an Schlüsselwörtern, aber der Code wirkt doch sehr kryptisch, das lenkt den Anfänger zu sehr vom Wesentlichen ab.

Bashar

lolz schrieb:

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht und erst in zweiter Linie um die Implementierung mit einer (beliebigen) Sprache.

Das ist ein Standpunkt von vor mindestens 30 Jahren. Stichwort Softwarekrise. Viele Entwicklungen seit dieser Zeit, strukturierte Programmierung, OOP, OOD usw. haben gerade nicht das Ziel, den Entwurf von Algorithmen zu erleichtern. Die Sprache ist wichtig, und nicht beliebig, denn die Möglichkeiten, die sie bietet, entscheiden darüber, auf welche Art und Weise man sich einem Problem nähert.

Simon2

lolz schrieb:

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht ...

Also DAS würde ich jetzt mal bezweifeln.

Wenn man schon verallgemeinert, dann vielleicht gerade noch, dass es um "Datenverarbeitung" geht, aber heutzutage hat gaaaanz viel mit Datenhaltung,- transport, -kombination, -strukturierung, -anzeige, .... zu tun und viel weniger damit, einen (mathematischen) Algorithmus auf einen Satz identischer Daten loszulassen.

wenn Du natürlich JEDE Form von Datenverarbeitung als "Algorithmus" definierst, bleibt Deine Aussage vielleicht korrekt .... aber leider in ihrer Allgemeinheit eher wertlos.

Gruß,

Simon2.

Hi,

Kinder lernen Laufen nicht auf stelzen, aber auch nicht mehr in irgendwelchen Laufvorrichtungen oder Laufgittern.

In C kann ich mich mit printf() und malloc() in Watte packen lassen, könnte aber das was die Funktionen (die nicht Bestandteil der eigentlichen Sprache sind) - wenn ichs denn könnte - auch selber zu Fuß machen.

Natürlich kann ich mit C extrem kryptisch programmieren. Aber nirgendwo steht, daß ich es auch muß.
Ein WortfürWort aus Pascal nach C übertragener Quelltext sieht auf den ersten blick vieleicht kryptischer aus, weil man als Pascal-Programmierer die vielen Zeichen nicht gewohnt ist. Aber nach einem kurzen Schütteln ist der klarer als das Original. { } || && fallen dem Auge im gesamten Text sofort viel mehr auf als begin end and or. Man sieht auf den allerersten Blick was Kontrollstrukturen, was Variablen und was Funktionen sind. An einem Delphi-Quelltext (Pascal) sieht man nicht einmal an den von der IDE generierten Definitionen ob man Klassen oder Zeiger oder einfache Typen vor sich hat.
Wenn man allen Schnickschnack wegläst und dafür ein wenig in die Kiste von C++ greift (zb. Referenzparameter) und dafür auf Zeiger verzichtet und ganz einfach so wie in einer anderen Sprache programmiert, dann kommt superübersichtlicher und kinderleicht zu verstehender Quellcode heraus.
Dafür ist die eigentliche Sprache mit den ganz wenigen Schlüsselwoten und Regeln sehr schnell zu lernen, und den Rest der Zeit kann man für das wie verwenden.

Der Ersatz von Schlüsselwörtern durch Zeichensymbole ist für den der von woanders kommt ungewohnt, macht Quelltext aber wesentlich übersichtlicher.

Viele Abkürzungen in C (++, += ()?:, ... ) sind, wenn man sie einmal begriffen hat wesentlich natürlicher und übersichtlicher.
In der normalen Sprache sagt mann ja auch nicht mache a zu a plus b sondern sagt erhöhe a um b.

Es geht (aus meiner Sicht) auch in der Programmierung nicht ohne mal kräftig auf die Schnauze zu fallen, damit man Programmierdisziplin aus eigenem erlebten und gefühltem Bauchempfinden einhält und nicht weils irgendwer verlangt.
In C hat man die Möglichkeit, dieses AHA-Erlebnis recht früh zu haben, bevor man entgültig mental festgelegt ist.

Eine Hängematte wird, egal in welchem Zusammenhang im Leben - nun mal nicht als Weg zu einem besseren ICH verstanden und genutzt sondern man läßt sich hineinfallen und genießt die Bequemlichkeit.

Gruß Mümmel

lolz

Bashar schrieb:

lolz schrieb:

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht und erst in zweiter Linie um die Implementierung mit einer (beliebigen) Sprache.

Das ist ein Standpunkt von vor mindestens 30 Jahren. Stichwort Softwarekrise. Viele Entwicklungen seit dieser Zeit, strukturierte Programmierung, OOP, OOD usw. haben gerade nicht das Ziel, den Entwurf von Algorithmen zu erleichtern. Die Sprache ist wichtig, und nicht beliebig, denn die Möglichkeiten, die sie bietet, entscheiden darüber, auf welche Art und Weise man sich einem Problem nähert.

Simon2 schrieb:

lolz schrieb:

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht ...

Also DAS würde ich jetzt mal bezweifeln.

Wenn man schon verallgemeinert, dann vielleicht gerade noch, dass es um "Datenverarbeitung" geht, aber heutzutage hat gaaaanz viel mit Datenhaltung,- transport, -kombination, -strukturierung, -anzeige, .... zu tun und viel weniger damit, einen (mathematischen) Algorithmus auf einen Satz identischer Daten loszulassen.

wenn Du natürlich JEDE Form von Datenverarbeitung als "Algorithmus" definierst, bleibt Deine Aussage vielleicht korrekt .... aber leider in ihrer Allgemeinheit eher wertlos.

Gruß,

Simon2.

Ich hab Algorithmus sehr allgemein gefasst, also alles.

Warum sollte ein Anfänger gleich noch ein Programmierparadigma mitlernen müssen, wenn er dieses noch gar nicht braucht? Ich habe meine Aussage bewusst so allgemein gefasst wie möglich.
Erst mit zunehmender Komplexität der Algorithmen wird es notwendig beim Entwurf ein oder mehrere (geeignete(s)) Programmierparadigm(a|en) einzusetzen.

Und dann ist die Implementierung mit einer Sprache noch immer zweitrangig und an erster Stelle steht weiterhin der Entwurf. Das soll nicht heißen, dass der Entwurf ohne Blick auf die Sprache stattfinden muss.

An OOP sieht man übrigens sehr gut, dass es nicht möglich ist OOD und Programmieren gleichzeitig zu lernen. Alle Anfänge die ich gesehen habe haben eines gemeinsam: es wird nicht objektorientiert programmiert, sondern man packt alles in eine Klasse um die (für einen Anfänger unnötige) Komplexität die durch OOD entsteht zu umgehen.

Aus diesen Erfahrungen stelle ich daher die (gewagte) Behauptung, dass ein Anfänger es leichter hat wenn er erst einmal den Entwurf von Algorithmen übt und das (direkte) Implementieren ohne Verwendung eines Programmierparadigmas.

Simon2

muemmel schrieb:

....
In C kann ich mich mit printf() und malloc() in Watte packen lassen, könnte aber das was die Funktionen (die nicht Bestandteil der eigentlichen Sprache sind) - wenn ichs denn könnte - auch selber zu Fuß machen. ...

Genau wie in C++ !
Wo war jetzt das Argument, lieber mit C anzufangen ?

Gruß,

Simon2.

Hi,

ganz einfach, das Argument für C statt gleich C++ ist das auch ein Künstler erst mal das Handwerk beherrschen muß bevor er Kunstwerke vollbringt.
Wenn einer der nicht mal das eigentliche Handwerkszeug des Programmierers beherrscht gleich den Turm zu Babel bauen will, kanns leicht nur ein großer Misthaufen werden.
Das Handwerkszeug zu lernen heist aber nicht ignorant zu sein und C++ grundsätzlich zu verdammen. Warum nicht schon in der ersten Lernphase strings, referenzparameter und Streamausgaben nützen. Und dabei nebenbei ein paar Eigenheiten von oop mitbekommen auf denen man später aufbauen kann. Oder wie es im Ritchie steht nicht dogmatisch sein.

Gruß Mümmel das Mümmel

Bashar

muemmel schrieb:

Warum nicht schon in der ersten Lernphase strings, referenzparameter und Streamausgaben nützen.

Weil es das in C nicht gibt.

Hi,

ich sagte ja, nicht dogmatisch sein.
C lernen, aber mit nem C++-Compiler und dabei ein paar nützliche Verbesserungen und Vereinfachungen von C++ gleich mit nutzen.
Wen außer einigen die spezielle Hardwaretreiber und.... programmieren interessiert es denn schon wirklich, ob es lupenreines C oder C mit ein paar vernünftigen Anleien an C++ ist.
Es interessiert doch auch keinen ob Putin nun wirklich ein lupenreiner Demokrat ist.

Gruß Mümmel

Bashar

muemmel schrieb:

C lernen, aber mit nem C++-Compiler und dabei ein paar nützliche Verbesserungen und Vereinfachungen von C++ gleich mit nutzen.

Das ist glaub ich das, was die meisten hier "C++ lernen" nennen würden

Undertaker

muemmel schrieb:

C lernen, aber mit nem C++-Compiler und dabei ein paar nützliche Verbesserungen und Vereinfachungen von C++ gleich mit nutzen.

dann haste aber 'komischen' C code, der nicht mehr so richtig C kompatibel ist. es gibt zu viele unterschiede zwischen beiden sprachen. wenn du OOP mit 'richtigem' C machen willst, dann nimm doch das: http://de.wikipedia.org/wiki/Objective-C
:xmas2:

muemmel schrieb:

Wen außer einigen die spezielle Hardwaretreiber und.... programmieren interessiert es denn schon wirklich, ob es lupenreines C oder C mit ein paar vernünftigen Anleien an C++ ist.

Mich, und zwar dann wenn die Leute in ANSI C kommen und ihre (eigentlich) C-Probleme anhand von C++-Code illustrieren.

Entweder man fängt mit reinem C an oder eben mit reinem C++. Hauptsache konsequent und nicht so ein Mischmasch wie C/C++.

Mit welcher Sprache genau man nun anfangen sollte kann man hier eh nicht objektiv diskutieren. C, C++, Asm, BASIC, Cobol, Ada, C#, Java, Erlang, (L(i(s)p)), Python, Ruby... egal... alles ausser PHP

Hi,

da sehe ich jetzt keinen Sinn drin. Die mit Programmierung anfangen wollen doch nicht Ansi-C machen oder C++ sondern irgend ein Problem lösen, also irgend was programmieren. Es muß mit dem Bereich den man als Anfänger überblickt sauber laufen und von einem verstanden werden. Irgendwann werden die sowieso immer mehr zu C++ hindriften, wenns für ihre Arbeit gut ist. Aber für den Anfang nutzen sie erst mal das was problemlos zu lernen ist. Wozu, wenn man nicht für einen Ansi-C-Compiler arbeitet noch so alte Routinen nehmen wie scanf()... und wozu zu viel mit Zeigern rumjonglieren, wenn man z.B. das bei Parametern auch mit Referenzen machen kann. Das Ziel ist doch gerade, wenn einer erst mal mit C anfängt und danach in die OOP einsteigt, daß er sich nicht erst alles das zu eigen macht und in Fleisch und Blut einschleift was nachher in C++ hinderlich wäre.
Warum soll ein Anfänger Pointerjongleur werden, wenn ers später in C++ sowieso anders löst. C soll doch in dem Zusammenhang nicht als reine Lehre sondern als erster Schritt auf dem Weg zu C++ verstanden werden.
Und was stört daran, wenn einer für das was er braucht mit C mit ein paar Ergänzungen ausreicht, wenn er das dann so macht. Sauber programmieren kann man auch zwischen den Sprachen. Wichtig ist doch nur, mit einem kleinen überschaubaren Bereich anfangen, auch in Bezug auf den Sprachumfang und dann in dem Maße wie man es versteht und begreift weitergehen. Oder ist unter Euch jemand, der wirklich ALLE Zipfel von C++ bis in die letzten und neuesten hundertprozentig verstanden hat und täglich anwendet.
Ich kann mir nicht helfen, aber mein Chef bezahlt mich nicht für die Beschränkung auf Ansi-C oder die volle Ausnutzung von C++ sondern für gelöste Aufgaben. Und das so, daß sie auch verständlich und wartbar gelöst sind.

Gruß Mümmel

2am

Simon2 schrieb:

lolz schrieb:

Man sollte nicht vergessen, dass es beim Programmieren um das Entwerfen von Algorithmen geht ...

Also DAS würde ich jetzt mal bezweifeln.

Wenn man schon verallgemeinert, dann vielleicht gerade noch, dass es um "Datenverarbeitung" geht, aber heutzutage hat gaaaanz viel mit Datenhaltung,- transport, -kombination, -strukturierung, -anzeige, .... zu tun und viel weniger damit, einen (mathematischen) Algorithmus auf einen Satz identischer Daten loszulassen. (...)

All den Dingen, die du nennst, liegen doch Algorithmen zugrunde. Was glaubst du, wie dein Editor Zeichenfolgen findet? Der Packer Daten kleiner macht? Die Auto-Vervollständigung deines Browsers funktioniert? Die Liste der Dateien sortiert wird?

Es ist wahr, auf einen Algorithmus zur schnellen Wortsuche kommen 100 Editoren, die ihn verwenden. Dennoch müssen die Grundlagen auch entwickelt werden, und wenn ich mir allein den Bereich der Datenkompression und Verschlüsselung ansehe, gibt es da immer noch Bedarf. 3D-Grafik wäre ein weiteres Feld, dass mir in den Sinn kommt.

2am

muemmel schrieb:

Hi,

ich sagte ja, nicht dogmatisch sein.
C lernen, aber mit nem C++-Compiler und dabei ein paar nützliche Verbesserungen und Vereinfachungen von C++ gleich mit nutzen.
Wen außer einigen die spezielle Hardwaretreiber und.... programmieren interessiert es denn schon wirklich, ob es lupenreines C oder C mit ein paar vernünftigen Anleien an C++ ist.

Jeden, der schon einmal vor der Aufgabe stand, ein Projekt von DOS nach Win32 oder von Win32 nach Linux zu portieren. Es ist dabei sehr unangenehm, wenn du 100.000 Stellen im Code patchen musst, um Compiler-Special x oder y, die Microsoft-Extension z oder die spezielle Header-Datei aus der Borland Turbo-Blubb Library zu entfernen.
Ein Beispiel (aus der Hölle): Kompressionsroutinen in 16-Bit Assembler in 32-Bit C-Code verwandeln... Der Coder hatte auch nur nützliche Verbesserungen der Sprache benutzt, nämlich Inline-Assembler.

Undertaker

muemmel schrieb:

Irgendwann werden die sowieso immer mehr zu C++ hindriften, wenns für ihre Arbeit gut ist.

so ein hindriften gibt es nicht wirklich. ein C++ compiler frisst keine vernünftigen C programme, nur ganz triviales zeug und umgekehrt geht's auch nicht.

muemmel schrieb:

Ich kann mir nicht helfen, aber mein Chef bezahlt mich nicht für die Beschränkung auf Ansi-C oder die volle Ausnutzung von C++ sondern für gelöste Aufgaben.

Und genau dazu solltest du C++ ausnutzen.

muemmel schrieb:

Und das so, daß sie auch verständlich und wartbar gelöst sind.

Deswegen müssen die anderen auch C++ können. (Aber das ist kein Problem, meine Oma muss das eh nicht warten.)

Hi,

trotz allem gehe ich da nicht mit mit Euch. Wer programmiert denn heute noch für DOS. Doch höchstens (mit Ausnahme von Anfänger-Übungsaufgaben ohne praktischen Nährwert) Sachen die für Win nicht sinnvoll sind. Die werden dann aber auch in 120 Jahren noch nicht für Win sinnvoll sein.
Ein sinnvolles Übernehmen von Programmen von DOS nach Win gibt es sowieso (fast) nie, da sind die Programmphilosophien einfach zu unterschiedlich und die Systemschnittstellen auch.
Und was die Kompressionsroutinen betrifft, damals, als die Rechner noch sehr viel langsamer waren und in jeder Ausgabe einer beliebigen Computerzeitschrift mindestens 3 Tests drinstanden ob nun Arj, Lha, Zip oder Rar 0,5% schneller sei war es in vielen Fällen schon richtig, daß man für sowas mittels Inlineassembler das Letzte aus der Mühle rausgeholt hat.
Und was die Portierung nach Linux betrift, sein wir doch mal ehrlich, wieviele Programme werden denn wirklich nach Linux portiert? Ich behaupte mal, das das keine 5% aller erstellten Programme sind. Alles spricht von Portablität, aber außer im Workstations- und Serverbereich steht praktisch auf JEDEM Schreibtisch ein Windows-Rechner.
Eigentlch ist es doch in vielen Fällen fast anders herum, daß im Laufe der Zeit viele Programme von Unix nach Win rübergehoben wurden.
Bei Programmen, wo man aber von vornherein weis oder annimmt, daß sie mal portiert werden müssen, solte man gleich von Anfang an anders rangehen, und die eigentlich Verarbeitung radikal von der Bedienung trennen. Ein Aufbau der zumindest der Philosophie vom C++Builder etwas konträr läuft und irgendwo Einschränkungen in der realisierbaren Schnittstelle zum Benutzer erfordert.
Das C Programme keine C++-Programme sind gehe ich so auch nicht ganz mit. Zum Beispiel sind ALLE Programe aus dem Ritchie auch C++-Programme. Und da nun mal kein fertiger C++Programmierer vom Himmel fällt, muß man in der Anfangsphase Abstriche machen. Und da sind aus meiner Sicht ein an sich sauberer Programmierstil und eine perfekte Handwerkszeugbeherrschung wesentlich wichtiger als das vollle Ausnutzen der C++-Möglichkeiten. Was nützt ein C++-Programm das alles Möglichkeiten der Sprache ausnutzt, aber ansonsten übelster Schrott ist.

Gruß Mümmel