Hallo,
ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum
besser.
nun stelle ich mir folgende Frage
kann jeder Mensch das Programmieren lernen, oder brauchst man dafür
tatsächlich Talent?
Dass nicht jeder perfekt programmieren wird ist komplett klar.
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.
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. Meistens finde ich die Funktion
auch, aber ich verstehe die Erklärung beim besten Willen nicht.
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.
(zum void * möchte ich keine Erklärung haben)
Selbstverständlich habe ich das auch mit den Büchern probiert.
Am Anfang läuft alles super, aber bereits nach paar Seiten geht das zu
weit für mich, so dass ich die Materie auf einmal nicht mehr verstehe.
Ich habe einen gewissen Level erreicht, wo ich Funktionen erstellen kann
und nur mit if(){} programmiere.
Für alltägliche Sachen reicht das, aber ich weiß echt nicht, wie ich
besser werden soll.
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.
Habt ihr Tipps für mich?
:
Verschoben durch User
Schlechter Programmierer schrieb: > (*(*ang_zeiger).chef).chef = (struct ang_info *) malloc(sizeof(struct > ang_info)); Der Brocken läßt sich ja noch mit Hilfe des Kompilerhandbuchs/CStandards aufdröseln. Ohne den Kontext zu kennen, würde ich sagen, das riecht nach Liste/Baum.
>Ohne den Kontext zu kennen, würde ich sagen, das riecht nach Liste/Baum.
Vielen Dank,
das war nur als Beispiel gemeint. Habe ich mit Hilfe von google gerade
gefunden die Zeile.
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.
:
Bearbeitet durch User
Nunja, ich kann dir eigentlich nur sagen, wie ich dahin gekommen bin, wo ich jetzt bin. Und wie weit ich bin mag ich kaum beurteilen, da ist noch viel Luft nach oben. Erstmal: Die Einstellung ist wichtig! Selbstsuggestion: Schlechter Programmierer schrieb: > Bei mir ist das leider so, dass ich z.B. pointer überhaupt nicht > verstehe,.. Je öfter du dir das selber sagst, desto wahrer wird das. Besser ist: "Das werde ich verstehen, wenn nicht Heute, dann Morgen." Ansonsten, ich habe einige Sprachen geübt. Die grundlegenden Algorithmen, Listen Bäume, sortieren auf 1000 Arten, Rekursion, Permutationen, uvm., in allen erreichbaren und für mich nützlichen Sprachen. Eigenes kleines Forth-System gebaut, usw. Viele Jahre PHP, etwas Java, viel Pascal, ein paar Assembler. Naja, als Tipp bleibt wohl nur: Positive Einstellung und viel üben.
Schlechter Programmierer schrieb: > Selbstverständlich habe ich das auch mit den Büchern probiert. Bücher sind schon mal der richtige Ansatz. > Am Anfang läuft alles super, aber bereits nach paar Seiten geht das zu > weit für mich, so dass ich die Materie auf einmal nicht mehr verstehe. Und dann gibst du einfach auf? So klappt das nicht... du musst das unverständliche auseinander nehmen und ggf. Details dazu googlen, bis du es verstanden hast. Es hilft auch jemanden persönlich zu fragen (konkrete Fragen!) und es dir erklären zu lassen. Schlechter Programmierer schrieb: > Ich versuche es wirklich sehr. Wenn ich was "komisches" sehe, versuche > ich das über google heraus zu finden. Einzelne Stückchen zu googlen klappt nicht gut, es ist besser eine durchdachte Einführung (Bücher! ) zu lesen. Aber Programmieren ist einfach nicht für jeden das Richtige...
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.
Schlechter Programmierer schrieb: > nun stelle ich mir folgende Frage > kann jeder Mensch das Programmieren lernen, oder brauchst man dafür > tatsächlich Talent? Ich bin davon überzeugt, dass nicht jeder alles kann und es unterschiedliche Denkstrukturen gibt - wobei letztere auch die Berufswahl beeinflussen. Ich könnte jetzt sagen "Du kannst es mangels passender Denkstrukturen nicht". Damit habe ich aber ein Problem: Du hast es freiwillig als Hobby angefangen, Du musst also doch irgendwie eine Beziehung zum Thema haben. Ich bin Elektroniker mit einem starken Hang zur Digitaltechnik, aber mich kneifen regelmäßig meine fehlenden Mathematikkenntnisse, zu diesen habe ich keine Beziehung und werde die auch niemals mehr aufbauen. Was bleibt: Wir akzeptieren unsere persönlichen Grenzen und versuchen, innerhalb dieser das bestmögliche Ergebnis zu erzielen.
Und vor allem die ausführliche Kommentierung im Quelltext nicht vergessen!
Schlechter Programmierer schrieb: > Für alltägliche Sachen reicht das, aber ich weiß echt nicht, wie ich > besser werden soll. Was sind denn für dich "alltägliche Sachen"? Gewöhnlich haben Computer strukturierte Befehle, die man auch abstrakt nutzen kann. Die Abstraktion ist aber für viele Menschen dann nicht mehr verständlich, weil die mit der einfachen Begreifbarkeit des Alltags nicht mehr viel gemein hat. Einzige Möglichkeit ist, Strukturen so zu vereinfachen und zu dokumentieren, dass Abstraktionen möglichst vermieden werden. Schlechter Programmierer schrieb: > Wenn ich so was sehe wie: > (*(*ang_zeiger).chef).chef = (struct ang_info *) malloc(sizeof(struct > ang_info)); Benutze doch mal den Debugger. Dann siehst du, was die Software aus der Befehlszeile macht und das Schritt für Schritt. Struct, Malloc und Sizeof stehen ja im Tutorial und sollten leicht begreifbar sein. Zeiger arbeiten in einem Speicherbereich von bis und mehr muss man da auch nicht wissen.
Schlechter Programmierer schrieb: > ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum > besser. PC oder uC? Web klammere ich mal aus.
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.
Martin G. schrieb: > 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! Der TO hat sicher keinen Schlafmangel. Er ist lediglich ein Samstag Troll.
Vielen Dank für die Antworten. Ich programmiere uC. Habe schon zahlreiche und unterschiedliche Projekte gemacht. Das mit der if Schleife war natürlich leicht übertrieben. Und ich bin kein Samstagstroll. Ich habe alle Antworten durch gelesen und werde versuchen da Rückschlüsse draus zu ziehen. Mach das Sinn, einen Lehrgang für die C Programmierung zu besuchen? Es ist natürlich eine Frage der Finanzen, denn die Elektronik ist nur ein Hobby, auch, wenn ich beruflich ein wenig damit zu tun habe.
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.
void erschließt sich einem nur durch Studieren und Meditieren.
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.
schau dir galileo c an fand ich sehr vernünftig geschrieben http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/ https://www.rheinwerk-verlag.de/openbook/
...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.
Wenn du wirklich ernsthaft seit 10 Jahren programmierst und Probleme mit Pointern hast oder leicht komplexeren Strukturen, dann würde ich mir ein anderes Hobby suchen. Oder hast du 10 Jahre nur BASIC programmiert und hast jetzt Probleme mit richtigen Programmiersprachen. Und ja, man braucht ein gewisses Talent zum Programmieren. Ich würde ja auch nicht auf die Idee kommen mir morgen eine Leinwand und Farben zu kaufen und dann Maler zu werden. Beim Programmieren ist es 50% Talent und 50% Erfahrung. Zum Talent zählen für mich z.B.: Die Fähigkeit komplexe Zusammenhänge herzustellen. Aus einfachen Bausteinen, die man kennt, komplexe Abläufe herstellen. Heutzutage ist Programmieren nicht mehr so komplex, wie noch vor 20 Jahren, als man noch ASM oder InLineASM benutzt hat, um schnellen Code hinzukriegen. Damals musste man noch die Hardware kennen, als Programmierer. Heutzutage gibt es für alles schwere Libs und man setzt sie nur noch zusammen. Aber Pointer sind was ganz elementares. Wenn du 10 Jahre programmierst, kann es nicht sein, dass du mit Pointern nicht klarkommst. Das ist als wärst du Sternekoch, hättest aber noch nie Milch gekocht.
Siggi S. schrieb: > 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. Man sollte ja auch nicht mit C anfangen, sondern mit einer höheren Sprache, wie z.b. BASIC. Dort lernst du die einfachen Dinge, wie z.b. Datentypen und erst wenn du in BASIC brauchbare Ergebnisse hinkriegst und an seine Grenzen kommst, dann solltest du erst auf C/C++ umsteigen.
Schlechter Programmierer schrieb: > Vielen Dank für die Antworten. > Ich programmiere uC. > Habe schon zahlreiche und unterschiedliche Projekte gemacht. > Das mit der if Schleife war natürlich leicht übertrieben. > Und ich bin kein Samstagstroll. > > Ich habe alle Antworten durch gelesen und werde versuchen da > Rückschlüsse draus zu ziehen. > > Mach das Sinn, einen Lehrgang für die C Programmierung zu besuchen? > Es ist natürlich eine Frage der Finanzen, denn die Elektronik ist nur > ein Hobby, auch, wenn ich beruflich ein wenig damit zu tun habe. Hab erst jetzt gesehen, dass du uC programmierst. Ok, das verändert alles. Du bist also kein richtiger Programmierer. uCs kann man tatsächlich 10 Jahre programmieren und immer noch keinen Plan von Pointern haben. Aber das ändert sich gerade, uC werden immer Machtvoller und das Programmieren der kleinen Dinger immer anspruchsvoller. Du musst also keine Programmiersprache neu lernen, sondern nur komplexe Zusammenhänge moderner Datentypen. Die wirst du bei uCs noch nie benutzt haben. Dann ist ein Kurs das beste. Vornehmlich einer, wo nicht zu viele Leute sitzen und du Fragen stellen kannst, vieles wirst du ja von uCs her schon kennen.
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.
:
Bearbeitet durch User
>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.
Zum Programmieren braucht man Intelligenz. Je weniger man davon hat, desto schwieriger wird es. Das ist nicht negativ gemeint. Genauso braucht man zum Basketballspielen Körpergröße. Entweder man hat Glück und hat sie, oder man hat seine Stärken woanders. Beides kann man aber auch durch Übung teilweise ausgleichen. Mir hilft es bei solchen grundlegenden Problemen oft, mit einfachen Beispielen auszuprobieren. Manchmal auch Fälle, die in der Praxis kaum vorkommen. Damit kann man einerseits sehen, was das Konstrukt macht, andererseits aber auch ausprobieren, ob man es verstanden hat.
Schlechter Programmierer schrieb: > ich programmiere schon seit ca. 10 Jahren und ich werde nicht/kaum > besser. Wie alt bist Du? Wieviel Stunden in der Woche/Monat programmierst Du? Was schätzt Du, wieviel Zeilen Du insgesamt schon geschrieben hast?
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 :)
Kauf dir ein Buch und arbeite die Grundlagen ausgiebig durch. Am besten eins das Übungsaufgaben zu allem enthält. Vielleicht hast du ja jemand im Bekanntenkreis der dir bei einigen Sachen weiterhelfen kann wenn du total auf dem Schlauch stehst. Ich denke bei einigen von deinen Problemen hilft es wenn dir jemand an einem praktischen Beispiel zeigt wofür das gut ist und wie meinen seinen Code damit deutlich eleganter aufbauen kann. Im übrigen kenne ich mehrere Leute die nach 20 Jahren "professioneller" Softwareentwicklung auf deinem Stand sind. Die denken, im Gegensatz zu dir, aber das die es total drauf haben und haben kein Interesse was zu verbessern.
Schlechter Code ist Code der schwer zu verstehen ist und der schwer zu ändern ist. Wenn du glaubst das du ein guter Programmierer wenn du solchen Code schreibst, nur weil ihn dann andere nicht mehr verstehen dann irrst du dich. Besser du versuchst erst gar nicht ein "Guter Programmiere" zu werden.
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.
Schlechter Programmierer schrieb: > Habt ihr Tipps für mich? Ja, besuche mal eine TROLL Schule und bilde dich weiter. Eigendlich solltest du dich 'Schlechter Trollierer' nennen.
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.
H-G S. schrieb: > Das objektorientierte Coden macht mir auch Kopfschmerzen - man muss > einfach durch zuviele Ebenen denken. Zuviel denken ist auch nicht immer gut. Ich arbeite gerne OO. Völlig schmerzfrei. Ich würde sogar soweit gehen, und sagen: "Das Konzept liegt mir!" Ich gebe zu, dass die ganzen "OOP Design Pattern" nicht alle leicht zu verstehen sind. Aber wenn man den Grund für diese Pattern am eigenen Leib gespürt hat, gehts plötzlich besser. Also auch hier wieder: Üben, üben üben... Und: An der Einstellung zum Thema arbeiten.
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.
C++ Programmierer schrieb: > hast jetzt Probleme mit > richtigen Programmiersprachen Ja und C/C++ ist eine "richtige Programmiersprache"? Ich glaube, alle Andeen sind es! Auch BASIC! Gruss Chregu
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.
> die Datentypen den Rest gegeben
Ich habe schon viel mit Systemen ohne explizite Typisierung, oder auch
mit "lax" typisierten Sprachen, gearbeitet.
Das ist auch mit Problemen verbunden.
Nein, ich eigentlich ganz froh, wenn ich mit streng typisierten Sprachen
arbeiten darf.
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
[ OT ] Paul B. schrieb: > http://www.wartburg-cabrio311.de/resources/_wsb_463x308_Jawa+2.jpg Fein! Haste dafür noch einen Anhänger + Kupplung? Auf sowas bin ich schon scharf. Aber das war leider früher schon Mangelware ... [ /OT ]
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
Paul B. schrieb: > Das andere Java will ich nicht haben... Ich auch kein Fan davon bin ... Ebenso c und C++, mir keine Wollust Rufe entlockt. Man nimmt eben das Werkzeug, welches der Situation angemessen ist.
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. ;-)
:
Bearbeitet durch User
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.
H-G S. schrieb: > Damit habe ich Java gelernt - zumindest bis ich erkannt habe dass mir > der Kopf schmerzt davon. Zuviel Kaffee ist ja auch ungesund. 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.
> 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.
Sheeva P. schrieb: > Ordentliche Editoren benutzen keine Tabs. Weder in Python, noch in einer > anderen Sprache. 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.
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
Sheeva P. schrieb: > Ordentliche Programmierer benutzen kein ASM. ;-) Was für eine Frequenz und Auflösung schafft man denn so bei einer 16-Kanal-Software-PWM auf einem ATmega in Python?
Jörg W. schrieb: > Oi oi oi, lass das mal keinen Java-Programmierer hören. ;-) Nunja, es gibt auch genug Leute, die glauben, daß sie HTML programmieren.
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.
Aja, ich bin schon gespannt auf die ersten XML-Programmierer :)
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.