letzter Beitrag von Wigo am
Habe den Text jetzt gelesen. Klingt sehr plausibel. Was auf mich natürlich nicht zutrifft: ich will den Beruf nicht ausüben. Ich will nur eine Platine ein paar Sachen ausführen lassen. Ich will das Programm ja nicht verkaufen und deshalb bis ins Kleinste optimieren. - Dennoch fasst der Text einige Probleme beim Schopfe.
Danke, Paradroid.
jomodore
Basic auf dem Raspi? Dann stilecht mit RiscOS! Da gibt's ein Image bei riscos.org, dass direkt in den Basicinterpreter startet. Und das volle RiscOS hilft einem über die Weihnachtstage... aber: Dreitastenmaus ist ein Muss.
Wie fängt so eine Datei an? Was steht im ersten Bit, was im zweiten? Wann und ab welchem Byte kommen die tatsächlichen Sounddaten?
An dieser Frage läßt sich ablesen, daß Deine Vorgehensweise nicht zu der Art und Weise paßt, wie man heute Programme schreibt.
Wichtig: Ein Programmierer weiß nicht, wie die Sounddatei aufgebaut ist. Er kann es auch gar nicht wissen. Woher? Und er muß es auch nicht wissen. Du schreibst nicht dabei, welchen Dateityp diese Datei hat. Welch Wunder. Es gibt ja eine ganze Reihe von Sounddateien: WAV, FLAC, OGG, MP3... , und einige davon packen die Sounddaten auch noch. Um zu verstehen, wie das geht, sollte man dann "ein wenig" Mathe können. Mit anderen Worten: Es wäre viel zu kompliziert und zu aufwendig, wenn der Programmierer für alle Dateien, die es so gibt, wissen müßte, wie diese aufgebaut sind. Der Versuch zu lernen, wie all diese Dinge funktionieren, entspricht dem Versuch, das Meer leer zu trinken. Das ist schlicht unmöglich. Die Zeiten, wo man noch die einzelnen Bits und Bytes kannte, sind längst vorbei. Es gibt nur noch einen kleinen Kreis von Programmierern, die sich darum kümmern, und das sind dann Experten. Daher sind die Informationen, die man dann bekommt, auch nur für Experten gemacht. Alle anderen Programmierer verwenden Sounddateien (oder Bilddateien oder...) ganz anders.
Wenn ein Programmierer heute eine Sounddatei benutzen will, verwendet er ein vorgefertigtes Unterprogramm (eine Art GOSUB-Routine), das andere vor ihm irgendwann mal geschrieben haben. Ein Bündel solcher Unterprogramme nennt sich "Bibliothek". Die meisten Bibliotheken sind nach Themen geordnet. So gibt es z. B. eine Bibliothek für die Graphik auf dem Bildschirm oder eine zum Tonerzeugen. Letztere enthält dann Unterprogramme zum Laden einer Sounddatei und zum Abspielen usw. Diese Bibliotheken kann der Programmierer bei Bedarf seinem Programm hinzufügen. Das ist so, als würdest Du hinten an Dein BASIC-Programm noch einen Haufen weiterer Zeilen anhängen, die aber nicht von Dir sind, sondern ein anderer Autor irgendwann mal geschrieben hat.
Die Verwendung dieser Bibliotheken erfolgt allein aufgrund ihrer Beschreibung, d. h. der Programmierer weiß nicht, wie die Unterroutine innen drin genau funktioniert. Er weiß nur, was sie ungefähr macht. Wenn da steht: "Dieses Unterprogramm lädt eine Sounddatei", dann nimmt man diese halt, wenn man eine Sounddatei laden will. In der Regel steht dann auch dabei, welche Angaben dieses Unterprogramm verlangt, z. B. einen Dateinamen, denn sonst weiß es ja nicht, was es da laden soll.
In BASIC würde man sowas in etwa so schreiben:
In einer Hochsprache sieht das dann ähnlich aus, z. B. so:
Anstelle einer Zeilennummer hat man hier einigermaßen sprechende Namen, und alles, was das Unterprogramm an Informationen braucht, packt man in Klammern dahinter.
Diese Bibliotheken sind jedoch nicht immer fester Bestandteil der Sprache selbst. In C gibt es z. B. Standardbibliotheken, die immer gleich sind. Das liegt daran, daß weltweit Programmierer sie über Jahrzehnte immer wieder und wieder gebraucht haben. Daneben gibt es aber auch jede Menge anderer Bibliotheken, z. B. eine Bibliothek zum Malen und Tönerzeugen. Welche Unterprogramme darin enthalten sind, erfährt man aus der Beschreibung. Diese Beschreibung nennt sich API (engl. für application programming interface, s.Programmierschnittstelle). Voraussetzung, um die Beschreibung zu verstehen, ist allerdings, daß man die Sprache an sich bereits beherrscht. Wenn man z. B. nicht weiß, was ein String ist, nützt es einem nichts, wenn da steht: "Der Dateiname wird als String übergeben."
Wenn ich es richtig sehe, so wäre es zum Verständnis moderner Hochsprachen wichtig für Dich, daß
a) Du Dich von den Zeilennummern trennst. Zeilennummern sind nervig. Wenn da steht: "gosub 5000", weiß man nicht, was da passiert. Wenn da aber steht "sound.play", dann versteht man das sogar ohne Kommentar.
b) Du Dich von dem Gedanken trennst, Du könntest alles genau auf Bits und Bytes verstehen. Das kann kein Mensch. Und es macht auch keinen Sinn. Wenn andere Leute bereits schon fertige Unterprogramme geschrieben haben, gibt es keinen Grund, es noch einmal zu tun. Die Zeit kann man sich sparen.
Und mit Shell ist einfach nur sowas gemeint wie der Direktmodus beim C64 minus Basic. Also Du kannst Befehle eintippen wie LOAD "blabla", und dann passiert etwas. Der Unterschied dabei ist nur, daß die Befehle jetzt anders lauten und anderes machen. Was genau, erfährst Du dann in den Beschreibungen über die Shell. Aber wenn Du mit dem C64 vertraut bist, sollte Dir so eine "Shell" kein Problem bereiten.
Jomodore, Ich habe eher das Gefühl, deine geistigen Scheuklappen fallen einzig und allein aus Trotz darüber, das das alles numal kein 80er-Jahre Heimcomputer-Basic mehr ist.
Übrigens kannst du über /sys/class/gpio/ mit jeder beliebigen Sprache auf dem Pi die GPIO-Pins ansteuern. Einfacher geht's garnicht mehr.
a) Du Dich von den Zeilennummern trennst. Zeilennummern sind nervig. Wenn da steht: "gosub 5000", weiß man nicht, was da passiert. Wenn da aber steht "sound.play", dann versteht man das sogar ohne Kommentar.
Vielleicht noch kurz etwas Hintergrund(*), wieso es überhaupt zu Zeilennummern kam: Es gab mal die Zeit, in der Computerprogramme auf Lochkarten gespeichert wurden - eine Programmzeile pro Karte. Ausserdem waren die Computer zur damaligen Zeit nicht besonders leistungsfähig und ihr Betrieb war sehr teuer, so dass gerne bestimmte Dinge vereinfacht wurden (oder verkompliziert, je nach Sichtweise) um die Rechenzeit des Systems besser auszunutzen. Manche Programmiersprachen (z.B. Fortran) haben deswegen festgelest, dass die ersten fünf Spalten einer Karte (entsprechend den ersten Zeichen der Zeile) reserviert sind für Marker, die als Sprungziel verwendet werden und dass diese Marker nur aus Zahlen bestehen dürfen - wenn eine Zeile keine Zahl als Sprungziel braucht, sind diese fünf Spalten stattdessen mit Leerzeichen zu füllen. Das vereinfacht natürlich die Auswertung der Zeile, da der Code auf jeden Fall erst in Spalte 6 anfangen kann und reduziert den Speicherbedarf für die Liste der bekannten Sprungziele, weil nur Zahlen statt Buchstabenfolgen gespeichert werden müssen.
So ein Programm in Lochkartenform hat in der Praxis einen deutlichen Nachteil: Die Reihenfolge der Karten ist wichtig und wird leicht durcheinandergebracht, wenn man den Stapel fallen lässt. Es gab diverse Tricks um in der Situation das Sortieren zu erleichtern - denn vertauschte Programmzeilen machen ja nicht unbedingt das was man will - wie z.B. diagonale Striche über den Kanten des Stapels, aber bei Programmiersprachen mit reservierten Positionen für einen Marker am Zeilenanfang kann man den Job einfach den Maschinen überlassen: Man gibt jeder Zeile einen Marker (auch wenn sie eigentlich keinen bräuchte) und vergibt die Marker in numerisch aufsteigender Reihenfolge. Ein so präparierter Stapel Lochkarten lässt sich einfach mit einer Sortiermaschine wieder in die richtige Reihenfolge bringen und Lochkarten-Sortiermaschinen gab es tatsächlich schon vor den ersten Computern. Spätestens an diesem Punkt kann man also von der Geburt der Zeilennummer sprechen - und auch hier wurden die mit Abstand vergeben, um bei Bedarf später Karten mit weiteren Befehlen einfügen zu können, ohne die nachfolgenden Karten mit neuen Nummern neu stanzen zu müssen.
An dieser Stelle splittet sich die Geschichte ein wenig: In der "Lochkarten-Welt" erlaubten andere Programmiersprachen wie z.B. SNOBOL die Verwendung von beliebigen Zahlen- und Buchstabenkombinationen als Zeilenmarker, weil das zwar mehr Aufwand für den Rechner ist, aber ein lesbarer Name für den Programmierer angenehmer zu handhaben und weniger fehleranfällig ist als alle Sprünge über Nummern abwickeln zu müssen. Zudem weichte irgendwann die feste Formatierung der Zeilen auf, so dass Zeilen ohne Marker nicht unbedingt mit fünf Leerzeichen anfangen mussten.
Parallel zur Lochkarten-Welt entwickelten sich zudem interaktive Terminals, an denen ein Benutzer einen direkten Dialog mit dem System führen konnten statt wie in der Lochkarten-Welt ein Programm als Kartenstapel mit Ausführungsanweisung abzugeben, welches von den Systembetreibern irgendwann laufengelassen wurde und dessen Ergebnisse man dann später abholen durfte. Allerdings nutzten solche interaktiven Terminals zunächst nicht wie heute bekannt einen Monitor zur Ausgabe, sondern einen Drucker. Das sorgt natürlich für eine Reihe von Einschränkungen, z.B. kann ein Drucker nicht besonders gut zu vorherigen Ausgaben zurückgehen um sie zu ändern. Der Dialog mit dem System funktionierte stattdessen eher zeilenorientiert: Der Benutzer gibt einen Befehl ein, das System druckt darunter seine Antwort usw. Wenn man mit so einem System den Quellcode eines Programms bearbeiten will, kann man natürlich nicht einfach das Papier ein Stück zurückdrehen und die Änderung mit Tippex vornehmen - stattdessen lässt man das System das Programm (oder einen Teil davon) drucken, teilt ihm mit welche Zeile man davon ändern möchte und gibt diese neu ein oder verwendet weitergehende Kommandos, um Teile davon auszutauschen. Ein frühes Programmiersystem, welches auf diesem Weg arbeitete war.... Dartmouth BASIC, das allererste BASIC überhaupt (von 1964). Bei dessen Entwicklung kam man auf die Idee, dass man doch die Zeilen-Marker aus der Lochkartenwelt auch gleich dazu verwenden könnte, dem Programmeditor mitzuteilen, welche Zeile man gerade bearbeiten möchte und machte daher die Verwendung von Zeilennummern verpflichtend. Wie schon bei den Lochkarten wurde zudem die aufsteigende Ordnung der Zeilennummern dazu verwendet, die Reihenfolge der Programmzeilen bei der Ausführung festzulegen.
Aber wie wir wissen blieb die Welt nicht bei Druckerterminals stehen, irgendwann waren auch Monitor-basierte Terminals günstig genug, um Benutzer darauf loszulassen. Natürlich kann man dort im Prinzip die gleiche Interaktion wie bei einem Drucker-Terminal verwenden, allerdings wird das unübersichtlicher als bei einem Drucker (der Ausdruck bleibt, der Monitor zeigt nur begrenzt viele Zeilen). Aber da man bei einem Monitor an beliebige Stellen Ausgaben vornehmen kann und einmal ausgegebenes auch wieder beliebig ändern kann entwickelten sich schnell Interaktionsmethoden für Monitor-Terminals, die diese Vorteile ausnutzten um die Bearbeitung von Programmcode zu vereinfachen: Statt die zu bearbeitende Zeile immer ausdrücklich anwählen zu müssen kann das System den ganzen Bildschirm mit Programmzeilen füllen und einem so auch noch Kontext für die zu bearbeitende Stelle präsentieren. Dadurch sind Zeilennummern auch nicht mehr so wichtig wie bei Lochkarten oder Druckerterminals, man spart sich also den dafür notwendigen Platz auf dem Bildschirm und verwendet Marker nur dort, wo sie wirklich benötigt werden. Zusammen mit einer Programmiersprache, die die Verwendung von Buchstabenkombinationen statt nur Zahlen als Marker verwendet sieht das Resultat schon deutlich mehr wie ein modernes BASIC aus als die historisch bedingte Zeilennummer-Methode nach Dartmouth.
Leider haben die Homecomputer dann wieder die Zeilennummer-Variante des BASIC ausgegraben, unter anderem weil die allerersten Homecomputer keinen Monitor boten sondern ein externes Terminal verwendet haben, was teilweise noch Drucker-basiert war - billig zu beschaffende Altgeräte aus der Grossrechnerwelt. Auch bei den Geräten mit Monitor funktionierte die BASIC-Eingabe oft wie bei Drucker-Terminals, da das mit weniger Aufwand zu implementieren ist als ein Vollbild-Editor wie ihn Commodore verwendet hat.
(*) Mit diversen Auslassungen, Vereinfachungen und plausibel klingenden Lügen
Wenn man mit so einem System den Quellcode eines Programms bearbeiten will, kann man natürlich nicht einfach das Papier ein Stück zurückdrehen und die Änderung mit Tippex vornehmen - stattdessen lässt man das System das Programm (oder einen Teil davon) drucken, teilt ihm mit welche Zeile man davon ändern möchte und gibt diese neu ein oder verwendet weitergehende Kommandos, um Teile davon auszutauschen.
Unter Unix ist "ed" der zeilenbasierte (Ur-)Editor, der auch heute noch mit jedem Linux-System geliefert wird, da er auch gerne noch in Shell-Skripten Verwendung findet.
Ich kenne dieses Problem. Es gibt keine schlechten Schüler, sondern nur schlechte Lehrer. So heißt es oft und an dem Spruch ist auch etwas dran. Ich sage nur Harald Lesch (Alpha Centauri) und Jörn Loviscach (Mathe auf Youtube). Bei manchen Beispielen in meinen Büchern weiß ich bis heute nicht, was mir der Autor damit sagen will.
Meine Schüler sagen mir manchmal: "Wenn wir das auf der Schule gehabt hätten, dann ....". Ich kann das gut nachfühlen. Mir gings als Schüler ähnlich. Ich hatte überhaupt keinen inneren Zugang zu Physik (und zu Mathe) bis zum Abi, weil bei mir der Funke nicht übersprang. Lag vielleicht am Elternhaus. Vater war bei der Presse. Aber danach wuchs mein Interesse, weil ich merkte, was man mit physikalischem Wissen alles machen kann. Und so kam ich während des Studiums plötzlich aus reinem Interesse zum C64. Das war ein großes Abenteuer für mich. Aber es blieb privat. Nur eine kurze Episode mit MIDI-Kompositionen konnte ich beruflich nutzen. Aber das war marginal. Der C64 ist und bleibt eine schöne Beschäftigung mit diesen Bits und Bytes - eine Art Abenteuer für den Grips.
Da ich seit 40 Jahren in der Forschung und Lehre bin (bezw. war), kann ich für mich sagen, dass ein guter Lehrer das A und O ist. Schon im Gymnasium konnte ich beobachten, was ein guter und was ein schlechter Lehrer war. Und ich würde in Ansätzen dem Satz zustimmen, dass es keine schlechten Schüler gibt, nur schlechte Lehrer. Denn die schlechten Schüler sind nicht nur faul, sie hatten auch schlechte Eltern oder schlechte Lehrer. Genau kann man es aber nicht aufdröseln.
Wenn ich während des Studiums einen Professor als gut empfand, dann, weil er mir Türen aufschloss, Türen der Imagination, Zusammenhänge aufdeckte, Kausalitäten klar machte, die für mein Gesamtverständnis sehr wichtig waren. Und so bin ich selber gestrickt. Ich versuche, meinen Studenten die Gegend um den "Weg" zu verdeutlichen, nicht nur den Weg. Oft hängt Verständnis von einer kleinen Nebenbemerkung ab. Und dort entscheidet sich Wissen. Weiß man es nun, oder nicht.
Danke an diejenigen, die sich hier reingehängt haben, mich doch noch auf den richtigen Weg zu stoßen - oder es wenigstens versucht haben. Ich werde den Tipps und Hinweisen nachgehen und schauen, ob sich dadurch eine neue Gerade hinter der Biegung der Kurve ergibt.
Falls, werde ich davon berichten. Und ich bin immer noch dankbar, wenn mir einer ein Buch nennen kann, das den Aufbau von Dateien, das Erscheinungsbild (egal ob mp3, mp4, prg-Dateien für den C64 usw.) und die Verarbeitung dieser Dateien "systematisch" erklärt. Denn ein PRG in Basic hat ja vorne ein paar Bits, die der Shell (ich meine das Betriebssystem) andeuten, was da jetzt geladen wird. Vielleicht gibt es ja so ein Buch. Ich habe einige Commodore Bücher, aber keins, das diese Fragen systematisch abhandelt.
Ein Buch, das mich sehr geprägt hat, ist "Hardwarebasteleien für den C64" von einem Mann namens Uwe (?) Gerlach (aus der Erinnerung). Der hat sehr schön einen roten Faden gesponnen, so dass blutige Außenseiter dennoch was damit anfangen konnten. - Und so was in der Art suche ich für den Bereich Daten. Also nicht wie Dezimal- oder Hex-Zahlen gebildet werden, sondern wie Dateien aufgebaut sind und wie sie verarbeitet werden.
Einen schönen Sonntag wünsche ich dann noch -
jomodore
Übrigens kannst du über /sys/class/gpio/ mit jeder beliebigen Sprache auf dem Pi die GPIO-Pins ansteuern. Einfacher geht's garnicht mehr.
Genau das habe ich ja vor. Ein paar Relais schalten, die von einigen IF_THEN Programmzeilen gesteuert werden. Aber bis es so weit ist, muss ich mich durch die ganzen Preliminarien beim Raspi kämpfen. Und da haperts bei mir erheblich.
Aber Dein Tipp macht mich wieder angriffslustig. Das will will ich eines Tages schaffen.
jomodore
Vielleicht noch kurz etwas Hintergrund(*), wieso es überhaupt zu Zeilennummern kam:
Danke, Unseen für den historischen Rückblick. Es scheint also bei Software immer auf die Bedingungen der Hardware Rücksicht genommen zu werden. Das hatte ich mir vorher nicht so bewusst gemacht. Apollo 11 hatte ja auch einen Bordcomputer, der beim Landeanflug der Mondfähre einen Fehler anzeigte, der zu einem Abbruch der Landung geführt hätte (vielleicht zu noch Schlimmerem). Und einer der Entwickler im Kontrollzentrum konnte im letzten Moment eine Erklärung für den FATAL ALERT geben. Ich glaube, Armstrong hat dann das Ding per Hand überstimmt. Da ging es um die Wurst.
Mit meinem Minimalwissen zum C64 kann ich solche Weltraum-Bücher natürlich viel besser verstehen, als wenn ich keinen Schimmer von Computern hätte.
Ist schon spannend - das Thema.
jomodore
Meine Schüler sagen mir manchmal
Was bringst Du denen bei, wenn ich fragen darf? Theologie?
Genau das habe ich ja vor. Ein paar Relais schalten, die von einigen IF_THEN Programmzeilen gesteuert werden. Aber bis es so weit ist, muss ich mich durch die ganzen Preliminarien beim Raspi kämpfen. Und da haperts bei mir erheblich.
Dann reicht es ja mit Shell (Command-Line-Interpreter) auf /sys/class/gpio/... Ausgaben zu tätigen. Da kann man wunderbar herumprobieren, braucht keinen Compiler oder Entwicklungsumgebung. Da findest du auch ein if ... then ... z.B. bei Bash (bash). Das ist halt "Scripting", wie man es so auch immer wieder gut brauchen kann ... 
Was bringst Du denen bei, wenn ich fragen darf? Theologie?
Witzig. Wie kommst Du denn da drauf? - War wohl ein Scherz. - Nein, die Studenten lernen bei mir, wie man Filme herstellt. Da braucht man einiges an technischem Wissen und natürlich auch an inhaltlichen Konzepten. Programmieren gehört jetzt nicht unbedingt dazu, aber ein paar zarte Einblicke in Reed-Solomon oder analoge Tontechnik müssen sein. Damit der ARD "Tatort" noch besser wird, als er schon ist.
Aber Ihr werdet lachen: ich bin in den letzten 6 Stunden intensiver Beschäftigung mit Python nach einigen Monaten Frust endlich fündig geworden. Kam per Zufall dazu. Es gibt auf YT eine ca. 40 teilige Folge "Python Tutorial" von Diddy Development - auf Deutsch. Der Typ erklärt an einer "Shell", wie man mit IDLE die ersten Programmierschritte unternimmt und sich dann steigert. Das fängt etwas zäh an, aber dann kommt der Kerl schnell zur Sache. Ich habe jetzt 7 Folgen angesehen und habe die Beispiele hier am Rechner mitgemacht. Das hat mir extrem viel gebracht. Da kann kein Buch mithalten. Film ist nun mal für solche Fälle die effektivste Methode, Informationen zu vermitteln. - Kann ich nur empfehlen für Laien, wie ich es - in Programmierfragen - bin. Der Typ hat's drauf.
Schaut mal rein.
@JeeK, Danke für den Hinweis. Der Sache werde ich nachgehen. Das klingt gut.
jomodore
Genau das habe ich ja vor. Ein paar Relais schalten, die von einigen IF_THEN Programmzeilen gesteuert werden. Aber bis es so weit ist, muss ich mich durch die ganzen Preliminarien beim Raspi kämpfen. Und da haperts bei mir erheblich.
Mein Gott und dafür der ganze Aufwand? Sowas macht man mit einem Arduino.
Einfach einen Arduino und ein Relais-Shield kaufen, Arduino IDE installieren, Arduino anstöpseln (USB) ein paar Zeilen Code eintippen und die Relais klappern.
Das hat man als Laie in nicht mal 15 Minuten am Laufen.
Und ohne dass man's gemerkt hat, hat man in C++ programmiert.
Ich packe immer das Popcorn aus, wenn ich sehe, wie versucht wird, aus dem Raspi und Python ein Steuerungsrechner zu machen.
Einfach einen Arduino und ein Relais-Shield kaufen, Arduino IDE installieren, Arduino anstöpseln (USB) ein paar Zeilen Code eintippen und die Relais klappern.
Das hat man als Laie in nicht mal 15 Minuten am Laufen.
Geht doch auf dem Pi mindestens genauso schnell, vorausgesetzt man steht nicht komplett auf dem Schlauch und muss "Shell" nicht in Anführungszeichen schreiben. Wer sich allerdings schon von fehlenden Zeilennummern bis zur totalen intellektuellen Paralyse verwirren lässt, für den sind beide Wege wohl gleich herausfordernd. Dann kann es ja nur noch an der mangelnden Didaktik anderer liegen, klarer Fall
Es gibt keine schlechten Schüler, sondern nur schlechte Lehrer.
Ist dem wirklich so? Wie haben wir es dann geschafft, autodidaktisch zum Beispiel Assembler zu lernen? So ganz ohne Lehrer und dieses neumodische Zwischennetz.
Wie haben wir es dann geschafft, autodidaktisch zum Beispiel Assembler zu lernen?
Naja, "auto" heißt ja "selbst". Als Autodidakt bist Du Dein eigener Lehrer, besorgst Dir Dein eigenes Material, suchst Dir eine geeignete Lernmethode, bestimmst das richtige Lerntempo usw. Das kann tatsächlich nicht jeder, und dann kommt es auch noch darauf an, welches neue Gebiet da erschlossen werden soll. Es gibt genug Leute, die für sich selber ein schlechter Lehrer sind und die dann halt auf andere angewiesen sind, die sie in den Lernstoff einführen. Das ist nichts ungewöhnliches, denn wenn alle Leute super Autodidakten wären, bräuchten wir ja keine Lehrer, Professoren... mehr.
Theologie?
Vooorsicht. Sowohl evangelische als auch katholische Theologie sind eine Zusammensetzung aus u. a. Rechtswissenschaften, Geschichtswissenschaften, Sprachstudium, Kunsthistorik, Philosophie usw. Ein ziemlicher Brocken, an dem schon so mancher gescheitert ist.
Ich habe mir selbst Python und Java Script beigebracht und muss sagen es funktioniert. Nur um englische Seiten, Bücher und Tutorials kommt man nocht rum finde ich. Die deutschen Ünersetzungen sind einfach schlecht gemacht. Zumindest die die ich gefunden habe.
So und ich habe absichtlich geschrieben das ich mir die zwei Sprachen beigebracht habe denn genau das war es was ich gemacht habe. Ich kann die Syntax, kann Programme lesen und verstehen aber selber schreiben? Ein klares Jein. Dazu fehlte mir einfach das Verständnis wie komplexere Dinge funktionieren. Gerade lerne ich selbst programmieren und das durch ein sehr gutes Bich das ich nur Empfehlen kann und zwar „ Programming: Principles and Practice using C++“
Das ist im Grunde ein programmier Kurs, geschrieben von einem der Entwickler von C++
Für Python kann ich ansonsten nur „Sentdex“ empfehlen. Einfach mal auf Youtube suchen.
