Warum werde ich beim Programmieren nicht besser?

Schlechter Programmierer schrieb:
> Ich habe einen gewissen Level erreicht, wo ich Funktionen erstellen kann
> und nur mit if(){} programmiere.

Das passt nicht damit zusammen:

Schlechter Programmierer schrieb:
> ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum
> besser.

Wie kann man 10 Jahre nur mit if Abfragen programmieren? Machst du das 
im professionellen Umfeld oder privat? Ansonsten: Einfach Projekte 
ausdenken, die du gerne umsetzen möchtest und die sich voneinander 
unterscheiden. Wenn du nicht weiter kommst: googlen und im schlimmsten 
Fall eine Frage im Forum stellen.

Schlechter Programmierer schrieb:
> Bei mir ist das leider so, dass ich z.B. pointer überhaupt nicht
> verstehe

K&R gelesen?

Schlechter Programmierer schrieb:
> genau so wie lange Zeilen mit irgendwelchen Registern und
> ^|&<< dazwischen.

Für die Register braucht man das entsprechende 
Handbuch/Manual/Datasheet. Bitoperationen rechnet man hexadezimal im 
Kopf - da ist das kinderleicht. Im Zehnersystem hat man verloren.

Ich denke hier wirds mit dem Weiterkommen auch am Schlafmangel liegen, 
daß es nicht besser wird.

Ich z.B. kann unausgeschlafen nicht denken. Wie z.B. jetzt.


Also, ab ins Bett!

Du mußt als allererstes Dein Gedächtnis trainieren.
Und dann mußt Du Deine Denkweise anpassen.
Der Unterschied zwischen einer if Schleife und den von Dir nicht 
verstandenen Strukturen entspricht etwa dem zwischen Einmaleins und 
Mengenlehre.

Troll hin oder her, oft liegt es auch an den Büchern.
Manche versteht man gut, aus anderen wird man gar nicht schlau.
Schwabl-Schmidt, der kann sicher perfekt ASM, verstehe ich aber 
überhaupt nicht.
Jürgen Wolf, C, er erklärt gleich im Anfang was (void) macht, zwar ohne 
ins Detail zu gehen, aber das will man doch wissen.
Manche Bücher lese ich dann erst, wenn ich die Materie schon etwas 
verstanden habe und dann wird auch klarer, was der Autor sagen will.

Siggi S. schrieb:
> Und dann mußt Du Deine Denkweise anpassen.

Am besten kaufst Du dir eines der vielgepriesenen C-Bücher.
Dann mußt Du versuchen das erste undurchsichtige Objekt in if Schleifen 
aufzudröseln.
Das ist genau das was der Compiler macht. Auf Machinenspracheebene 
existiert keine Mengenlehre und keine Objekte.
Allerdings kann man in Maschinensprache auch strukturiert programmieren 
wenn man sich geeignete Regeln auferlegt.

...Regeln die Dir bei Verwendung einer Hochsprache der Compiler 
auferlegt.

Ich hab auch mehrmals angefangen C zu lernen. Erst hab ich mir einen 
Wolf nach einer Liste der formatierungszeichen für print gesucht um mal 
einen Überblick zu bekommen (indem ich sie an den Monitor klebe) bis mir 
dann die Datentypen den Rest gegeben haben.
Je-des-mal.

Schlechter Programmierer schrieb:
> kann jeder Mensch das Programmieren lernen, oder brauchst man dafür
> tatsächlich Talent?

Ja, jeder Mensch kann Programmieren lernen. Nein, man braucht dazu keine 
besonderen Talente: die sind hilfreich, aber nicht nötig. Programmieren 
ist allemal ein Handwerk.

> [...]

Das Meiste, was Du beschreibst, sind Verständnisschwierigkeiten bei der 
Syntax einer bestimmten Programmiersprache, und dortbei insbesondere bei 
zwei bestimmten Basis-Features: Zeigern und Strukturen.

> Habt ihr Tipps für mich?

Vielleicht besuchst Du mal einen Linux-Stammtisch in Deiner Nähe. Da 
gibt es nette Leute, die Dir gerne helfen.

Eventuell magst Du auch mal eine Programmiersprache wie Python 
probieren, die Dich von Deinen syntaktischen Albträumen befreit.

Sheeva P. schrieb:
> Eventuell magst Du auch mal eine Programmiersprache wie Python
> probieren, die Dich von Deinen syntaktischen Albträumen befreit.

also nicht wirklich, falsche Einrückungen machen in C nichts, aber in 
Python.

OK mit Pointer habe ich auch Schwierigkeiten, aber deswegen Python? 
NEVER!

Programmieren ist doch meist die Kunst einen Ablauf detailiert zu 
beschreiben, wer das schafft aus:

"Kaffeekochen oder Kuchen backen" haarklein bis zu den Zutaten 
beschaffen zu beschreiben so das andere das nachmachen können der wird 
auch programmieren können.

Die Frage ist auch, wie sich deine Programmieraufgaben ändern. Wenn du 
z.B. seit 10 Jahren nur Zweipunktregelungen machst, dann wird sich da 
auch nicht viel am Programmierstil oder den Kenntnissen ändern. Denn man 
wächst mit der Aufgabe.
Bei z.B. einer selbstgebauten GUI auf einem Grafikdisplay mit ATMega8 
wirds ohne Pointer vermutlich nicht klappen, auch structs und typedefs 
sind dann sehr nützlich.
Und es muss auch nicht immer 'if-else' sein, manchmal ist auch 
'switch-case' die elegantere Lösung und zumindest mal eine Abwechslung.

Nicht zu unterschätzen (und so mache ich das oft) ist - wie machens die 
anderen? Ich wühle mich also durch Sourcecode von anderen Projekten und 
schau mir an, was ich davon für mich verwenden kann, und ob das besser 
ist oder ein Holzweg.

>Der Unterschied zwischen einer if Schleife und den von Dir nicht
>verstandenen Strukturen entspricht etwa dem zwischen Einmaleins und
>Mengenlehre.

http://www.if-schleife.de/

Gruß Jonas

Schlechter Programmierer schrieb:

> ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum
> besser.

Wie oft?
Seit 10 Jahren beruflich 40 Stunden die Woche?
Seit 10 Jahren alle paar Wochen mal ein paar Zeilen am Wochenende?
Besser wird man durch üben, üben, üben - bzw anwenden, anwenden, 
anwenden. Je nach persönlichen Grenzen geht das halt schneller oder 
langsamer.

> Bei mir ist das leider so, dass ich z.B. pointer überhaupt nicht
> verstehe, genau so wie lange Zeilen mit irgendwelchen Registern und
> ^|&<< dazwischen.
> Bei 2, max 3 Variablen verstehe ich das noch. Wenn es mehr wird,
> verliere ich sofort den Überblick.

Dann brich die Statements so weit auf dass sie für dich verständlich 
sind - "Divide et impera".

> Beispiel von heute: (void *)
> Selbst nach ca. 1,5h weiß ich immer noch nicht was das ist, warum das im
> Beispielprogramm ist, und wie ich das in der Zukunft selbst anwenden
> kann.

Lass es weg und schau was der Compiler sagt und ob das Programm 
funktioniert. Wenn nicht, ist das schon mal ein Hinweis wofür du es 
brauchst...

> Wenn ich so was sehe wie:
>  (*(*ang_zeiger).chef).chef = (struct ang_info *) malloc(sizeof(struct
> ang_info));
> dann kann ich das beim besten Willen nicht begreifen. Nicht mal
> ansatzweise verstehen, was da los ist.

Das ist meiner persönlichen Meinung nach auch schlechter Programmierstil 
weil schlecht leserlich. Als jemand der C nur sehr gelegentlich 
verwendet habe ich da auch meine Probleme.

In einer objektorientierteren Sprache könnte das z.B. so aussehen:

ang_instance.chef.chef=ang_info.create;

und damit deutlich angenehmer zu lesen sein.

Andreas K. schrieb:
> Das ist meiner persönlichen Meinung nach auch schlechter Programmierstil
> weil schlecht leserlich.

Kommt auf den Standpunkt an.
Bis in die 80er war dieser Stiel Goldwert :)

Zu meiner Anfangszeit mit C64 / C128 gas es, wenn überhaupt, nur 
Assembler als Programmierwerkzeug.
Ich muss sagen es ist ein beruhigendes Gefühl zu Wissen das alle 
Hochsprachen aus dem Assemblerbefehlssatz des Controllers bestehen 
müssen.
Mit Hochsprachen kommt man natürlich schneller zum Ziel, aber die 
Erkenntnis dafür, was dahinter eigentlich steckt wird ohne 
Assemblerkenntnisse ausbleiben.

Sheeva P. schrieb:

> Ja, jeder Mensch kann Programmieren lernen. Nein, man braucht dazu keine
> besonderen Talente: die sind hilfreich, aber nicht nötig. Programmieren
> ist allemal ein Handwerk.

So wie jeder Mensch lernen kann zu Malen, zu Komponieren oder zu Tanzen? 
Irgendwie sicher. Aber auf professionellem Niveau? Das glaube ich nicht.

Strukturierte Programmierung auf Mikrocontrollern

http://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675/ref=sr_1_1?ie=UTF8&qid=1444238128&sr=8-1&keywords=weniger+schlecht+programmieren

Wobei es bei allen Dingen im Leben halt auch Leute gibt, denen es an 
Talent, Potential, Disziplin und schlicht Interesse fehlt, um eine Sache 
gut zu erlernen und danach gut zu machen.

Also ich lese hier immer zur Verbesserung, das jemand sich mit dem 
Sachen alleine beschäftigen soll. Das ist leider unter 
Hobby-Programmieren sehr üblich, ich habe jedoch die Erfahrung gemacht, 
das genau hier das Problem liegt: Man kocht im eigenen Saft, kommt nicht 
mehr weiter. Was in professionellen Projekten dagegen hilft ist der 
Erfahrungsaustausch mit anderen bei z.B. Pair-Programming oder Reviews 
(evtl. auch verpflichtend).

Allerdings was verstehst du unter "besser Programmieren"? Das was du 
hier aufzählst, ist besseres codieren, das ist für mich nur die 
"unterste" Ebene von Programmieren und meiner Meinung nach die 
einfachste. Denn oftmals ist es eher nebensächlich, wie man etwas 
hinschreibt, wenn es gemäß der Spezifikation funktioniert und getestet 
werden kann (klar, es sollte lesbar sein und einigen Standards folgen). 
Programmieren ist jedoch mehr, als nur solche Konstrukte zu lernen, da 
gehört vor allem auch die Vorgehensweise, wie man etwas strukturiert, 
kapselt und architekturell aufstellt dazu.

Oben habe ich den Tipp mit Python gelesen: Auch wen es einige 
verteufeln, gerade Python oder eine andere objektorientierte Sprache 
erleichtert die Schulung gerade der anderen Fähigkeiten zu Abstraktion 
und in Architekturen zu denken deutlich mehr, als C auf einem uC, da 
dort die Möglichkeiten offensichtlicher sind.

Ansonsten üben, üben, üben ... ich muss mir vieles auch nach vielen 
Jahren intensiver C++-Codierung mit sicherlich einiger 100k geänderter 
oder neuer Code-Zeilen immer noch Konstrukte erarbeiten, wenn ich sie 
lesen möchte, ich würde sie jedoch nie so schreiben. Das ist wie in 
einer normalen Sprache auch, man hat sein Wortschatz und seine 
Sprachkonstrukte, die man immer wieder ändert. Ich kann allerdings viel 
mehr lesen, als ich selbst codieren würde. Das macht aber dann die 
Erfahrung in der täglichen Arbeit.

@Schlechter Programmierer (Gast)

>ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum
>besser.

Wenn das kein Trollversuch ist, hast du 10 Jahre viel falsch gemacht.

>Bei mir ist das leider so, dass ich z.B. pointer überhaupt nicht
>verstehe,

Nach 10 Jahren? Nur Basic programmiert?

>genau so wie lange Zeilen mit irgendwelchen Registern und
>^|&<< dazwischen.

Grundlagen.

>Bei 2, max 3 Variablen verstehe ich das noch. Wenn es mehr wird,
>verliere ich sofort den Überblick.

Dann hast du wohl eine medizinische Disposition, welche eine halbwegs 
erfolgreiche Beherrschung des Themas Programmieren unmöglich macht. Such 
dir ein anderes Hobby.

>Es ist überhaupt nicht so, dass ich das nicht lernen möchte.
>Ich versuche es wirklich sehr. Wenn ich was "komisches" sehe, versuche
>ich das über google heraus zu finden.

In Zeitalter VOR google (ja, da gab es noch Dinosaurier!) haben die 
Leute auch gelernt, teilweise besser als heute MIT google. Denn sie 
haben (gute) Bücher gelesen, nachgedacht und die Dinge geübt. Heute 
denken viele, daß man sich alles Wissen und vor allem FÄHIGKEITEN 
einfach zusammengoogeln kann. Ein fataler Irrtum! Grundlagen muss man 
LERNEN und ÜBEN!

>Ich habe einen gewissen Level erreicht, wo ich Funktionen erstellen kann
>und nur mit if(){} programmiere.

Wenn das mal kein Troll ist . . .

>Für alltägliche Sachen reicht das,

Kaum.

>Wenn ich so was sehe wie:
> (*(*ang_zeiger).chef).chef = (struct ang_info *) malloc(sizeof(struct
>ang_info));

Sowas hab ich selten gesehen. Das ist nur ein gutes Beispiel, wie man 
NICHT programmieren sollte!

>dann kann ich das beim besten Willen nicht begreifen. Nicht mal
>ansatzweise verstehen, was da los ist.

>Habt ihr Tipps für mich?

-> anderes Hobby suchen.

Das objektorientierte Coden macht mir auch Kopfschmerzen - man muss 
einfach durch zuviele Ebenen denken.

Zum Beispiel zeigt ein Stern oder Punkt auf ein anderes Konstrukt 
irgendwo im Code - einfach ätzend wenn man das alles im Kopf 
visualisieren will.


Eventuell könnte es dir helfen wenn du alles immer 
ausdruckst/aufschreibst und die Blätter dann auf einer Pinnwand oder so 
anheftest/anordnest. Dann siehst du immer die referenzierten Code-Teile 
die hinter den Objekt-Punkten und Ähnlichem stecken.

Jonas B. schrieb:
> http://www.if-schleife.de/

if-schleife:

1

int i=0;

2

start:

3

4

(...)

5

6

7

if (++i < 10) goto start;

;-)

H-G S. schrieb:
> Das objektorientierte Coden macht mir auch Kopfschmerzen - man muss
> einfach durch zuviele Ebenen denken.

Da läuft dann einfach was grundsätzliches im Verständnis schief oder es 
ist tatsächlich Veranlagung.
OOP und jede anderen Art der Abstraktion nehmen ja gerade die 
Komplexität und die Notwendigkeit sich jedes mal durch alle Ebenen zu 
denken. Wer das trotzdem tut verwendet das Konzept gar nicht.

Siggi S. schrieb:
> is mir dann die Datentypen den Rest gegeben haben.

Weil in der Ferne waren schon die Horden der lauernden libs zu erkennen.

Versuche mal, zuerst mit Papier und Bleistift zu programmieren und nicht 
gleich alles stumpf in den PC reinhacken zu wollen.
D.h. male Dir irgendwie den Programmablauf auf, als PAP der sonstwie und 
versuche alles in kleine übersichtliche Module zu unterteilen.
Es ist nicht verboten, ein Modul zu schreiben, das nur 3 Zeilen Code 
enthält, wenn es eine bestimmte Aufgabe erfüllt, die man fürderhin 
einfach nur aufrufen muß, ohne sie jedesmal neu verstehen zu müssen.
Copy&Paste im Programm ist der Tod eines jeden Programmierers. Alles was 
man ähnlich an 2+ Stellen benötigt, mach ne Funktion draus.

Finger weg von Java !

Davon hatte ich die meisten Kopfschmerzen :-)

> Warum werde ich beim Programmieren nicht besser?

Allenfalls auch der falsche Beruf. Dauerfrust sollte man sich nicht 
antun.

H-G S. schrieb:
> Finger weg von Java !

Kann ich nicht sagen. Ich hatte eine 350er, die lief wie ein 
Länderspiel.

So sieht's aus:

http://www.wartburg-cabrio311.de/resources/_wsb_463x308_Jawa+2.jpg

MfG Paul

Arduino F. schrieb:
> Haste dafür noch einen Anhänger + Kupplung?

Nein. Ich habe auch das Motorrad nicht mehr.
Das andere Java will ich nicht haben....
:)
MfG Paul

Manche lernen eher aus Büchern, manche in der Praxis.
uController Programmieren lernen ohne Bücher ist schwer.

Wenn Du jemand bist, der schlecht aus Büchern lernt, brauchst Du einen 
Mentor. Die Qualität eines C-Lehrgang kann ich nicht einschätzen. Ich 
vermute aber, dass du schon zuviel weißt hierfür. Das führt zu 
Unaufmerksamkeit für Dinge, die du dort genauer kennenlernen 
könntest/solltest.

Such Dir lieber jemanden im Bekanntenkreis. Wenn der Knoten einmal 
geplatzt ist, helfen dir auch die Bücher wieder weiter.

Joachim B. schrieb:
> Sheeva P. schrieb:
>> Eventuell magst Du auch mal eine Programmiersprache wie Python
>> probieren, die Dich von Deinen syntaktischen Albträumen befreit.
>
> also nicht wirklich, falsche Einrückungen machen in C nichts, aber in
> Python.

Ja, das hab' ich am Anfang auch gruselig gefunden. Aber dann sah ich, 
daß viele erfahrene und fähige Entwickler auch aus meinem engeren 
Freundes- und Bekanntenkreis für Python schwärmten und sie für Skripting 
und Steuerung ihrer Projekte genutzt haben, beispielsweise OpenOffice, 
KDE, PostgreSQL, und daß auch die Mitglieder der 
C++-Standardisierungsgremien einiges für Python übrig haben -- sonst 
wäre es nicht die einzige Sprache, für die es so etwas wie Boost::Python 
gibt. Und dann habe ich bemerkt, daß Python auch in der Datenanalyse und 
-Visualisierung sehr beliebt ist...

Danach bin ich dann sehr ins Grübeln gekommen und habe dann entschieden, 
ihm eine Chance zu geben und es mir genauer anzuschauen. Und wenn ich 
eins dazu sagen kann, dann: ich habe es keine Sekunde bereut und meine 
bis dahin verwendete Skriptsprache Perl nie wieder angeschaut. Jahre 
später bin ich dann über diesen [1] Text von Eric S. Raymond gestoßen, 
dem es ähnlich ergangen ist, und der es besser beschreibt als ich es 
könnte.

Insofern: doch, wirklich. Richtig, Einrückungen machen in Python was aus 
-- vor allem zwingen sie einen dazu, sauber strukturierten und lesbaren 
Code zu schreiben. Und genau das ist ein wesentlicher Unterschied zu 
Perl und vielen anderen Sprachen: während man in den meisten anderen 
Sprachen Disziplin und Erfahrung braucht, um sauberen Code zu schreiben, 
ist es in Python genau andersherum: da muß sich anstrengen, um 
unlesbaren Code zu schreiben.

[1] http://www.linuxjournal.com/article/3882

> OK mit Pointer habe ich auch Schwierigkeiten, aber deswegen Python?
> NEVER!

Ach, weißt Du, es gibt zwei Sorten von Entwicklern: die, die sich immer 
stur an Standardrezepte und -Ideologien halten, und die, die sich 
trauen, auch mal nach Rechts und Links zu schauen und was Neues 
auszuprobieren. ;-)

Die "Für Dummies"-Bücher sind sehr gut zum Lernen.

Damit habe ich Java gelernt - zumindest bis ich erkannt habe dass mir 
der Kopf schmerzt davon.

> Sheeva P. schrieb:
>> Und dann habe ich bemerkt, daß Python auch in der Datenanalyse und
>> -Visualisierung sehr beliebt ist...
>
> Kannst Du abschätzen, wie die Performance von Python im Vergleich zu C++
> ist? Speziell für den Raspi suche ich da noch was.

Darauf kann ich nur mit "kommt darauf an" antworten. Natürlich ist 
Python in vielen Bereichen deutlich langsamer als C++, aber 
GUI-Programme bis zu mittlerer Größe sind für Python kein Problem, 
Millionen von Datensätzen auch nicht. In der Datenexploration und 
-Analyse profitiert Python sehr wesentlich von kompilierten, typsicheren 
Bibliotheken wie numpy und Co.

Zudem können sehr einfach C- und -- mit dem oben erwähnten Boost::Python 
-- auch eigene oder fremde C++-Bibliotheken eingebunden, und Python dann 
als Glue-Code verwendet werden. Und wenn es um extrem große Datenmengen 
und besonders komplexe Berechnungen geht, kann man mit Python und Apache 
Spark auch in einem DC-Cluster rechnen lassen. ;-)

Bisher hatte ich nur genau einen Fall, in dem ich Python komplett durch 
C++ ersetzt habe, nämlich bei einer nicht gänzlich trivialen, täglichen 
Konsolidierung einer 70 GB großen Datenbank mit Versicherungsfällen. Da 
braucht SQL wegen einer "NOT IN"-Where-Clause gut neun Tage, eine 
externe Lösung mit Python kommt auf 11 Stunden und in C++ geht es dann 
-- dank der sehr effizienten Implementierung von std::map -- in unter 
einer Stunde. Aber das ist ein sehr besonderer Fall, bei der es fast 
ausschließlich um die Effizienz von Python-Dictionaries versus 
C++-std::map geht -- klar, daß C++ dabei die Nase deutlich vorne haben 
muß.

Von allen Skriptsprachen, die ich besser kenne -- Perl, Ruby, Python und 
PHP (ich war jung und brauchte das Geld) -- ist Python die mit mal mehr, 
mal weniger Abstand performanteste. Wenn Du mir genauer beschreibst, was 
Du ungefähr vorhast, liefere ich gerne eine bessere Schätzung. Was ich 
sagen kann, ist: für alle Alltagsaufgaben ist Python bei Weitem schnell 
genug und besticht wegen seiner schnellen Entwicklungszeit. HTH, YMMV.

Sheeva P. schrieb:
> Ach, weißt Du, es gibt zwei Sorten von Entwicklern: die, die sich immer
> stur an Standardrezepte und -Ideologien halten, und die, die sich
> trauen, auch mal nach Rechts und Links zu schauen und was Neues
> auszuprobieren. ;-)

mach ich wenn ich mir Vorteile von verspreche, bin von purem C aus dem 
AVR Studio zum Arduino gewechselt, musste da einiges neu lernen, 
profitiere aber von den LIBs, ansonsten lässt meine (Restlebens)Zeit 
kein überflüssiges lernen für mich mehr zu.

Joachim B. schrieb:
> Sheeva P. schrieb:
>> Ach, weißt Du, es gibt zwei Sorten von Entwicklern: die, die sich immer
>> stur an Standardrezepte und -Ideologien halten, und die, die sich
>> trauen, auch mal nach Rechts und Links zu schauen und was Neues
>> auszuprobieren. ;-)
>
> mach ich wenn ich mir Vorteile von verspreche, bin von purem C aus dem
> AVR Studio zum Arduino gewechselt, musste da einiges neu lernen,
> profitiere aber von den LIBs, ansonsten lässt meine (Restlebens)Zeit
> kein überflüssiges lernen für mich mehr zu.

Tja, der Appetit kommt bekanntlich oft erst beim Essen, will meinen: 
häufig sieht man die Vorteile von etwas erst, wenn man es ausprobiert. 
Zumal einer der Hauptvorteile von Python ja ist, daß es ausgesprochen 
klar, einfach und absolut geradeaus ist, auf jeden syntaktischen Zucker 
dankend verzichtet und deswegen besonders leicht zu lernen ist; manche 
sprechen sogar von ausführbarem Pseudocode. Eric S. Raymond sagt, daß 
Python seine Gedankenstrukturen so gut abbildet, daß er sich nicht mehr 
mit der Sprache abmühen muß. Das deckt sich auch mit meiner Erfahrung.

Wer jedoch Aversion gegen das Lernen hat, was bei älteren Mitmenschen ja 
leider häufiger auftritt, und zudem beim Umsteig von C auf Arduino-C++ 
Schwierigkeiten hat -- umgekehrt hätte ich das ja noch verstanden -- der 
wird sich der Frage stellen müssen, ob Programmieren wirklich das 
richtige Hobby oder der richtige Beruf für ihn ist. Aber dann ist Dein 
Sprüchlein von der Einrückung ohnehin nur ein ideologisches 
Scheinargument, welches von Deinem eigenen Unwillen ablenken soll. ;-)

Andererseits hast Du anscheinend vornehmlich mit Mikrocontrollern zu tun 
und schon Probleme beim Umstieg von C auf Arduino-C++. Ok, in diesem 
ganz speziellen Fall ist es vermutlich keine gute Idee, Dir jetzt noch 
eine weitere Sprache und wieder eine neue Plattform wie Micropython oder 
den RasPi anzueignen, und Du solltest Deine verbleibende Lebenszeit 
besser darauf ver(sch?)wenden, wenigstens eine Plattform beherrschen zu 
lernen statt mit mehreren herumzudilettieren und keine wirklich zu 
verstehen und auszureizen. Letzten Endes ist jedes Werkzeug natürlich 
immer nur so gut wie der, der es benutzt, da sind Programmiersprachen 
und Mikrocontroller natürlich keine Ausnahme.

Das ist übrigens ein Problem, das mir bei Ein-Sprachen-Programmierern 
oft begegnet ist. Beim Erlernen der ersten Sprache geht es ja immer um 
zwei Aspekte: das Eine ist, das Vokabular, die Syntax und die Grammatik 
einer bestimmten Sprache zu lernen, und das Andere ist, das 
Programmieren zu lernen, also wie ein Entwickler zu denken und größere 
Probleme in kleine, lösbare Einheiten aufzuteilen. Für viele 
Ein-Sprachen-Programmierer war oder ist beides zusammen so schwer, daß 
sie sich danach mit Händen und Füßen dagegen wehren, eine zweite Sprache 
zu lernen, weil sie befürchten, wieder denselben Aufwand treiben zu 
müssen wie bei der ersten. Das stimmt zwar nicht, wird aber mangels 
Versuchs nie bemerkt. Und genau hier kommt dann Python ins Spiel: da es 
den ersten Teil ("das Eine") so leicht und einfach macht, kann man sich 
voll auf den zweiten Teil ("das Andere") konzentrieren und hat damit 
viel weniger Streß, als wenn man das ohnehin mühsam Erlernte dann auch 
noch mit den Konstrukten einer Sprache wie C, C++, C# oder Java 
ausdrücken muß.

Mir persönlich ging es bei der Empfehlung von Python nicht darum, Dich 
zu Python zu zwingen -- das kann ich nicht und würde es auch nichtmal 
wollen, wenn ich es könnte -- sondern dem TO etwas zu empfehlen, wie er 
vielleicht seinen momentanen Stillstand überwinden kann. Da er sich 
vornehmlich über fortgeschrittene Konstrukte und Eigenheiten der Sprache 
C beklagt hat, wollte ich ihm durch die Empfehlung von Python die 
Möglichkeit geben, sich auf das Wesentliche zu konzentrieren: nämlich 
zunächst das Programmieren zu lernen, ohne sich dabei ständig Gedanken 
über die spezielle Syntax und Grammatik von nicht trivialen Sprachen 
machen zu müssen.

Was bedeutet besser werden im Programmieren ?

Dass man das Debuggen auch gleich vorsieht.
Dass man bereits eine Library von standardloesungen hat
Dass man weniger Fehler macht
Dass man schneller fertig ist.

Mit der Programmiersprache hat das nichts zu tun.

Sheeva P. schrieb:
> Wer jedoch Aversion gegen das Lernen hat, was bei älteren Mitmenschen ja
> leider häufiger auftritt

Das Argument zieht nicht, im PI Forum häufen sich die Heulthreads 
jüngerer Nutzer die mit C&P durch Python nicht zurecht kommen weil eben 
die Formatierungen flöten gehen, dem C macht ein TAB weniger nichts aus!

Sheeva P. schrieb:
> Aber dann ist Dein
> Sprüchlein von der Einrückung ohnehin nur ein ideologisches
> Scheinargument, welches von Deinem eigenen Unwillen ablenken soll. ;-)

das ist gelinde gesagt nicht wahr, Unwillen gegen Tabs an der richtigen 
Stellen ja, Stress mit falschen Tabs nein danke!

Sheeva P. schrieb:
> Und wenn ich eins dazu sagen kann, dann: ich habe es keine Sekunde
> bereut und meine bis dahin verwendete Skriptsprache Perl nie wieder
> angeschaut.

Damit du auch mal andere Leute kennenlernst. ;-)  Ich benutze Python,
aber genauso gern auch Perl.  Vor allem, wenn es wirklich um
Textverarbeitung mit vielen regulären Ausdrücken geht, ist Python
reichlich umständlich zu handhaben, das schreibe ich in Perl sehr
viel schneller hin.

Und nein, ich kann den Evangelismus mancher Python-Liebhaber überhaupt
nicht ab, sich diesen Zwang zu Einrückungen schön zu reden.  Jeder
vernünftige Mensch strukturiert natürlich seine Programme und rückt
sie ein, aber Leerzeichen als syntaktische Sprachelemente finde ich
auch nach 10+ Jahren Python-Benutzung einfach nur K***e, sorry.  Aber
die Argumente dafür (und dagegen) sind schon hinlänglich breitgetreten
worden.

Das Argument, dass man mit Python automatisch leserlich schreiben
würde, ist ohnehin hanebüchen.  Natürlich kann man in jeder Sprache
unleserliches Zeug dahinrotzen, bei manch Python-Jünger nennt sich
das dann „Optimierung“, was sie im Gegenzug bei einem Perlscript
als “unreadable” tituliert hätten …

Paul B. schrieb:
>> Finger weg von Java !
>
> Kann ich nicht sagen. Ich hatte eine 350er

Die schrieb sich aber mit „w“, nicht mit „v“.  Außerdem war Jawa
schweinisch laut.  OK, heutzutage müssen Motorräder natürlich laut
sein, insofern war sie einfach nur ihrer Zeit 50 Jahre voraus …

Joachim B. schrieb:
> Sheeva P. schrieb:
>> Wer jedoch Aversion gegen das Lernen hat, was bei älteren Mitmenschen ja
>> leider häufiger auftritt
>
> Das Argument zieht nicht, im PI Forum häufen sich die Heulthreads
> jüngerer Nutzer die mit C&P durch Python nicht zurecht kommen weil eben
> die Formatierungen flöten gehen, dem C macht ein TAB weniger nichts aus!

Copy&Paste-"Programmierer" kommen mit überhaupt gar keiner Sprache 
zurecht, und mit C oder gar C++ schon gleich gar nicht -- und zwar ganz 
unabhängig vom Alter, Geschlecht, Haarfarbe oder Religion.

> Sheeva P. schrieb:
>> Aber dann ist Dein
>> Sprüchlein von der Einrückung ohnehin nur ein ideologisches
>> Scheinargument, welches von Deinem eigenen Unwillen ablenken soll. ;-)
>
> das ist gelinde gesagt nicht wahr, Unwillen gegen Tabs an der richtigen
> Stellen ja, Stress mit falschen Tabs nein danke!

Ordentliche Editoren benutzen keine Tabs. Weder in Python, noch in einer 
anderen Sprache.

Siehe dazu auch: 
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Sheeva P. schrieb:

> Ordentliche Editoren benutzen keine Tabs.

Es gibt keinen Grund gegen TABs, sofern die Umstände klar definiert
sind (also TAB aller 4 oder 8 Positionen, darauf läuft es hinaus).

Ordentlichen Editoren kann man das aber sagen, ob und aller wieviel
Spalten sie das machen.

> Siehe dazu auch:

Ausgerechnet eine Python-Quelle hier als Argument anzuführen, taugt
bestenfalls als Argument gegen Python …  Für alle anderen
Programmiersprachen ist es eben nur ein Schönheitsproblem in der
Darstellung (darum muss ich mich nicht unbedingt kümmern, wenn ich
den Code nur benutzen, aber nicht verstehen will), für Python hingegen
ein reales.

Jörg W. schrieb:
> Sheeva P. schrieb:
>> Und wenn ich eins dazu sagen kann, dann: ich habe es keine Sekunde
>> bereut und meine bis dahin verwendete Skriptsprache Perl nie wieder
>> angeschaut.
>
> Damit du auch mal andere Leute kennenlernst. ;-)  Ich benutze Python,
> aber genauso gern auch Perl.  Vor allem, wenn es wirklich um
> Textverarbeitung mit vielen regulären Ausdrücken geht, ist Python
> reichlich umständlich zu handhaben, das schreibe ich in Perl sehr
> viel schneller hin.

Ertappt: ich benutze Perl immer noch oft als Filter ("-pe"), aber sonst 
gar nicht mehr.

> Und nein, ich kann den Evangelismus mancher Python-Liebhaber überhaupt
> nicht ab, sich diesen Zwang zu Einrückungen schön zu reden.  Jeder
> vernünftige Mensch strukturiert natürlich seine Programme und rückt
> sie ein, aber Leerzeichen als syntaktische Sprachelemente finde ich
> auch nach 10+ Jahren Python-Benutzung einfach nur K***e, sorry.  Aber
> die Argumente dafür (und dagegen) sind schon hinlänglich breitgetreten
> worden.

Ich finde das nach etwa ebenso langer Zeit immer noch gut; ist wohl eine 
Frage des persönlichen Geschmacks. Vielleicht begegnet mir auch häufiger 
Code von weniger vernünftigen Menschen als Dir (was Dir sehr zu wünschen 
wäre, am Rande bemerkt). ;-)

> Das Argument, dass man mit Python automatisch leserlich schreiben
> würde, ist ohnehin hanebüchen.  Natürlich kann man in jeder Sprache
> unleserliches Zeug dahinrotzen, bei manch Python-Jünger nennt sich
> das dann „Optimierung“, was sie im Gegenzug bei einem Perlscript
> als “unreadable” tituliert hätten …

Wie gesagt: in Perl muß man sich Mühe geben, wenn man lesbaren Code 
schreiben will, während man sich in Python Mühe geben muß, wenn man 
unlesbaren Code schreiben möchte.

Jörg W. schrieb:
> Es gibt keinen Grund gegen TABs, sofern die Umstände klar definiert
> sind (also TAB aller 4 oder 8 Positionen, darauf läuft es hinaus).
>
> Ordentlichen Editoren kann man das aber sagen, ob und aller wieviel
> Spalten sie das machen.

Genau das ist der wichtigste Grund gegen TABs. Darüber hinaus benutzen 
wir meines Wissens denselben Editor. ;-)

> Ausgerechnet eine Python-Quelle hier als Argument anzuführen, taugt
> bestenfalls als Argument gegen Python …  Für alle anderen
> Programmiersprachen ist es eben nur ein Schönheitsproblem in der
> Darstellung

Spätestens wenn man mit mehreren Personen am selben Code arbeitet, führt 
das zu mehr als nur einem Schönheitsproblem.

Timm T. schrieb:
> Da wäre ich aber in den Arsch gekniffen, wenn ich im Asm meine
> Einrückungen, Weiterrückungen und Kommentare mit Leerzeichen trennen
> müßte. Aber ok,  ordentliche Programmierer benutzen ja auch keine
> Kommentare.

Ordentliche Programmierer benutzen kein ASM. ;-)

Die meiste Software wird eh nicht mehr programmiert (z.B. C), sondern 
mit Script-Sprachen wie Java oder Generative Programmierung (UML, XSLT, 
Elektrobit-Tresos) gemacht.

J. W. schrieb:
> Script-Sprachen wie Java

Oi oi oi, lass das mal keinen Java-Programmierer hören. ;-)

J. W. schrieb:
> mit Script-Sprachen wie Java

geht's noch? :-)

@ TO
Wenn Du schon 10 Jahre nur mit "if" programmiert hast, dann übe mal 
jetzt ein wenig was mit Funktionszeigern ;-)

Jörg W. schrieb:
> J. W. schrieb:
>> Script-Sprachen wie Java
>
> Oi oi oi, lass das mal keinen Java-Programmierer hören. ;-)

Habe den Beitrag von ihm schon gemeldet :-) :-)

> mit Script-Sprachen wie Java

C# kann man auch dazuzählen.

Bülent C. schrieb:

> Habe den Beitrag von ihm schon gemeldet :-) :-)

Nun, es verstößt natürlich nicht gegen die Nutzungsbestimmungen, hier
hanebüchenen Unsinn von sich zu geben …

Jörg W. schrieb:
> Nun, es verstößt natürlich nicht gegen die Nutzungsbestimmungen, hier
> hanebüchenen Unsinn von sich zu geben …

Nein, es hier geradezu ein Gebot das zu tun, um ernst genommen zu 
werden.

:))

MfG Paul

Timm T. schrieb:
> Nunja, es gibt auch genug Leute, die glauben, daß sie HTML
> programmieren.

"HTML IS a Programming Language (Imperative vs Declarative) - 
Computerphile"
https://www.youtube.com/watch?v=4A2mWqLUpzw

Aber gut, ich find es auch befremdlich bei HTML von "programmieren" zu 
reden.

D. I. schrieb:
> Aja, ich bin schon gespannt auf die ersten XML-Programmierer :)

oder die msi zu rpm Wandler.

Schlechter Programmierer schrieb:
> Habt ihr Tipps für mich?

Ja, vergiss so "schwierige" Sprachen wie C und nimm was einfacheres und 
sicheres, z.B. C#. Nimmt dir vieles ab, besonders die ganzen 
Pointergeschichten und zum grossen Teil die dynamische 
Speicherverwaltung.