Abgesehen von HTML(Keine richtige Programmiersprache) kann ich einbisschen Phyton und daher weiß ich, dass "print" auch haüfig in Programmiersprachen vorkommt.^^
Genauso wie "else" usw...
Abgesehen von HTML(Keine richtige Programmiersprache) kann ich einbisschen Phyton und daher weiß ich, dass "print" auch haüfig in Programmiersprachen vorkommt.^^
Genauso wie "else" usw...
Sollte ich machen. Danke.^^Zitat von R.F.
Es gibt allerdings einen Unterschied zwischen "eine Programmiersprache lernen" und "eine Programmiersprache beherrschen", letzteres erlaubt nämlich, dass dir auch andere solche Sprachen leichter fallen. Wenn man nämlich weiß, welche Sachen sich in den verschiedenen Sprachen ähneln (z.B. die altbekannte "if"-Anweisung), dann kann man eine neue Sprache schonmal praktisch zu 50%. Such dir also erstmal eine relativ einfache Sprache und guck dir die Grundzüge an
--Schuld und Sühne Forum (mit SoB Unterforum)+Drachen+NABU
"Solange der Mensch das Böse im Dunkeln sucht, wird er es nicht finden."
Was an der Stelle zu erwähnen ist, das, wonach du hier fragst, ist für einen Anfänger unnötig trickreich. Es hat einen Grund warum man nicht in Assembler programmiert und wenn du aus fremdem Assembler-Code schlau werden willst, braucht das Erfahrung und Zeit - beides erheblich. (ich war mir zu faul, Cherrys Link durchzulesen aber ich nehm mal an, dass selbst die Dokumentation nicht gerade trivial ist)
Wenn du was in die Richtung machen willst, bastel dir lieber direkt ein Spiel mit einer Hochsprache wie C++ statt mit Patches anzufangen.
(google allgemein mal nach C-Tutorials, sorg dafür, dass du danach weißt was Pointer/Zeiger, Arrays und Klassen sind und such dir dann ein Tuto zu einer guten Bibliothek wie OpenGL
Zu phyton, das is ganz nett um die Grundzüge üblicher Syntax zu lernen, interpretiert aber (d.h. der Code wird nicht in Maschinensprache übersetzt bevor man das Programm ausführt) und ist daher langsam (was du bei einfachen Programmen nicht merkst aber je komplexer das Proggi wird eben schon) - phyton empfehl ich dir genau dann, wenn du gute Tutorials in phyton hast.
Fazit: Schau dich lieber im Programmiererforum um wenns dir um sowas geht. Vor ´Luki und Cherry hatte es ne halbe Ewigkeit keine Patches (in der deutschen Szene) und das hat einen Grund.
Mit diesem Wissen solltest du vielleicht erstmal eine richtige Programmiersprache wie Python oder Ruby richtig lernen - dann hast du auch im XP etlich mehr Möglichkeiten als von Hause aus - bevor du dich an Patches und Assembler begibst.
Alle Programmiersprachen, sei es Ruby, Python, Lua oder sogar C(++) (das ich nicht unbedingt als Anfängerfreundlich einstufen würde) haben eines gemeinsam: Sie wurden für Menschen entwickelt.
Assembler ist da ganz anders. Assembler ist mehr oder weniger nichts weiter als die Sprache des Prozessors, wobei die einzelnen Befehle Namen kriegen, anstatt der Zahlen, mit denen die CPU arbeitet.
Alle Konstrukte, die es so in gängigen Programmiersprachen gibt, wie print, if-else, Schleifen usw. gibt es in Assembler nicht.
Was es gibt sind ein paar Befehle um Speicherinhalte zu bewegen (sowas wie Typen kennt Assembler nicht), einige Rechenbefehle sowie ein paar Befehle um im Code rumzuspringen (direkte Sprünge und bedingte Sprünge).
Assembler mal so eben lernen ist nicht drin. Ich bin noch nicht mal sicher ob man eine Sprache wie Ruby "mal so eben" lernen kann.
Ich hab ein wenig Assembler in der Uni im Rahmen einer Vorlesung lernen müssen und wenn ich eines davon behalten habe, dann daß ich niemals in Assembler arbeiten will und wenn dann bitte nur mit sehr ausführlichen Kommentaren (selbst dann ist es schwer genug).
Aber falls du immer noch interessiert genug bist. Ich kann gerne das (englische) Buch raussuchen, daß uns damals empfohlen wurde (gibts als PDF).
Kann ich nur zustimmen. Wer sich trotzdem das ganze ansehen will und nicht unbedingt seinen PC schrotten will, der kann mal "SPIM" und "MIPS" googlen, bzw. "MARS" gibts da auch noch. Ein Handbuch (PDF) müsste unter Umständen noch als "spimdoku" (oder so ähnlich) zu finden sein. Hierbei handelt es sich einfach nur um Assembler- Simulatoren, allerdings würde ich es mir nicht noch einmal antuen wollen.
Eine kurze Google-Anfrage ergibt, daß du hier wohl etwas verwechselt. Unter dem Begriff "MIPS" finde ich eine Mikro-Prozessor-Architektur, was sich mit den Simulatoren decken würde, da man hier einen Mikroprozessor simulieren muss.
Mikroprozessor-Programmierung ist kein Assembler. Mikroprozessor-Programmierung liegt eine Ebene tiefer unter dem Assembler und ist gewissermaßen die Schnittstelle zwischen Assembler und Hardware.
Assembler braucht man nicht simulieren, man kann es direkt zu einer binary assemblieren und ausführen. (für die in heutigen PCs verwendete x86-Architektur wäre das zB mit NASM möglich)
Mal ein direkter Vergleich von Hochsprachen und Assembler:
Einspruch! µPc ist sehr wohl Assembler, nur halt mit einem etwas anderen Befehlssatz, als man ihn vom PC her kennt - aber was soll's? Der 286er hatte auch einen ganz anderen Befehlssatz und eine andere Register-Struktur als moderne Prozessoren, trotzdem ist beides Assembler. Unterschiedliche Dialekte will ich gerne zugeben, aber immer noch Assembler - genauso wie das, was ich für meine ATMEL-Chips fabriziere.
Ja und nein, also ein klares JeinEs gibt allerdings einen Unterschied zwischen "eine Programmiersprache lernen" und "eine Programmiersprache beherrschen", letzteres erlaubt nämlich, dass dir auch andere solche Sprachen leichter fallen. Wenn man nämlich weiß, welche Sachen sich in den verschiedenen Sprache
n ähneln (z.B. die altbekannte "if"-Anweisung), dann kann man eine neue Sprache schonmal praktisch zu 50%. Such dir also erstmal eine relativ einfache Sprache und guck dir die Grundzüge an"Eine Programmiersprache beherrschen" ist etwas unglücklich ausgedrückt, finde ich. Man kann eine Programmiersprache bis in ihre tiefsten Tiefen kennen, und trotzdem ein sehr schlechter Programmierer sein. "Programmieren lernen" funktioniert weitgehend unabhängig von den Sprachen die man dazu benutzt. Dabei geht es darum, ein Problem exakt zu analysieren, es möglicherweise in seine kleinsten Bestandteile zu zerlegen, um dann mit dem zur Verfügung stehenden Werkzeug, also der Programmiersprache, die man gerade da hat, einen Algorithmus zu entwickeln und zu einer Lösung zu kommen.
Fast jede Programmiersprache ist nach den gleichen Regeln aufgebaut. Auch wenn in Ruby nahezu Alles und Jedes ein Objekt ist, gibt es doch viele Gemeinsamkeiten mit Sprachen, die vermutlich bereits vor der Geburt eurer Eltern ausgestorben waren. Ich erwähne nur mal COBOL. Variablen, Schleifen, Kontrollstrukturen, Bedingungsabfragen, und so weiter, wirst du in jeder Sprache finden, auch wenn es manchmal etwas schwer zu erkennen ist. (Brainfuck, anyone?)
Wenn jemand eine Programmiersprache "beherrscht", sagt das nicht wirklich viel. Wer hingegen das Programmieren gelernt hat, kann seinen Quick-, Heap-, Bubble- Sort-oder Sonstwas-Algorithmus in kurzer Zeit in nahezu jeder Sprache umsetzen.
Modernere Sprachen kommen allerdings mit umfangreichen Funktionsbibliotheken daher, die einem erfahrenen Programmierer schon einen Großteil der alltäglichen Arbeit abnehmen.
Jeder, der gelernt hat, zu programmieren, sollte in der Lage sein, sich in wenigen Stunden mit einer neuen Umgebung vertraut zu machen - ob die IF-Abfrage nun in C++, Python, Ruby, oder sonstwas da steht, macht keinen Unterschied. Um aber herauszufinden, wie eine bestimmte Programmierumgebung ihre Standard-Objekte handhabt, und welche Methoden sie zur Verfügung stellt, braucht man etwas mehr als 'n verkürztes Wochenende.
Wann also "beherrscht" man eine Programmiersprache? Wenn man 'ne WHILE-Schleife ohne Syntaxfehler abtippen kann? Oder ist es doch erst, wenn man alle Standard-Funktionen, -Methoden und -Objekte schon mal zum Essen (Incl. Vor- und Nachspiel) eingeladen hat?
Wenn der Aufruf einer Standard-Funktion in bspw Python nicht so funktioniert, wie ich es erwarte, schaue ich in den Sourcecode wo diese Funktion deklariert ist, und sehe meistens sehr schnell, warum das Ding sich nicht so benimmt wie erwartet, und meistens habe ich dann auch bald eine Idee, wie ich die gewünschten Ergebnisse bekomme. Falls es doch mal länger dauert, liegt es meistens daran, dass ich ich irgendwo einen Denkfehler und/oder ein Logik-Problem habe.
Anyway, man KANN mit einer (nahezu) beliebigen Sprache fast jedes Programmierproblem lösen - es bleibt nur die Frage, ob es die dafür aufgewändete Zeit Wert ist. Mit Grausen erinnere ich mich daran, wie unser Dozent erwartet hat, dass wir eine größere Sammlung von C++-Standard-Funktionen nachprogrammieren und nach unseren (seinen) Wünschen modifizieren können. Aber: das daduch erlangte Wissen und die Erfahrung möchte ich heute nicht mehr missen - auch wenn ich nur noch selten programmiere..
Nein. Nicht, so wie ich es sehe. Einer Sprache beherrschen bedeutet für mich, dass man wirklich mit jedem Standad-Objekt und jeder Standard-Funktion oder Methode, die die Sprachumgebung zur Verfügung stellt, auf Du-Und-Du steht. Aber wer tut das schon? Wie ich Eingangs erwähnte, dauert es vielleicht einen oder zwei Nachmittage, um sich mit einer neuen Sprache vertraut zu machen - WENN man programmieren gelernt hat. Wenn man das gelernt hat, ist die Sprache wirklich egal, oder nicht?
Um zum Threadstarter zurückzukommen: Es ist egal, mit welcher Sprache du anfängst - du wirst immer mal auf Verständnisprobleme stoßen - da wird sich durchgebissen, das gehört sich so.
Wenn du allerdings glaubst, es braucht nur ein paar Zeilen Code, um alle deine Wünsche zu erfüllen, irrst du dich - um diese paar Zeilen schreiben zu können, musst du nämlich auf die Erfahrungen und das Wissen zurückgreifen können, die du dir in vielen tausend vorhergehenden Zeilen erarbeitet hast. Ja, ich habe auch schon mal 2000 Zeilen Code geschrieben um ein Problem zu lösen, welches sich nach Klärung eines Verständnisproblems und Aufbesserung einer Wissenslücke mit 15 Zeilen lösen ließ. So ist das Leben.
Geändert von Das'O' (04.07.2010 um 16:30 Uhr) Grund: Typo
Berechtigungen
Zitieren