Nur eine Frage. Wie schwer ist es eigentlich Lua zu erlernen. Ich bin nämlich auf dem Gebiet von Programmiersprachen überhaupt nicht bewandert.
Nur eine Frage. Wie schwer ist es eigentlich Lua zu erlernen. Ich bin nämlich auf dem Gebiet von Programmiersprachen überhaupt nicht bewandert.
--Schuld und Sühne Forum (mit SoB Unterforum)+Drachen+NABU
"Solange der Mensch das Böse im Dunkeln sucht, wird er es nicht finden."
Da du nicht auf diesem Gebiet "bewandert" bist, denke ich dur wirst wohl etwas länger brauchen, aber allgemein gilt eigentlich wie für alle Sprachen, es ist nicht schwer nur zeitaufwendig. Du musst dich einfach nur eingehend mit der Sprache beschäftigen, dann wird das schon
Edit:
Übrigenss ist die Syntax sehr an Pascal angelehnt, soweit ich das mitbekommen habe, das hilft vllt.
--
Das esetwas dauern könnte, ist natürlich richtig. Aber ich habe noch ein Leben zum Lernen vor mir. Wenn es auch nicht schwer ist, dann werde ich vielleicht einiges darüber in Erfahrung bringen. Dann könnte sich einiges anstellen lassen.Zitat von R.D.
Da du nicht auf diesem Gebiet "bewandert" bist, denke ich dur wirst wohl etwas länger brauchen, aber allgemein gilt eigentlich wie für alle Sprachen, es ist nicht schwer nur zeitaufwendig. Du musst dich einfach nur eingehend mit der Sprache beschäftigen, dann wird das schon
--Schuld und Sühne Forum (mit SoB Unterforum)+Drachen+NABU
"Solange der Mensch das Böse im Dunkeln sucht, wird er es nicht finden."
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
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.^^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.
Vielleicht meinen wir hier jeweils mit Assembler nur etwas anderes. Bei uns wurde in Info2 Mikroprozessor-Programmierung seperat von Assembler behandelt und eben eine Ebene tiefer angesetzt. Vermutlich kann man das auch als Assembler bezeichnen, ich habe hier im Thread aber mit Assembler implizit die x86-Architektur gemeint und dessen Befehlssatz wie er eben von NASM erzeugt wird.
Denn hier im Thread geht es nunmal immer noch um Patches für den Maker und demzufolge mMn um das Verändern der Maker-Exes, der nunmal in x86-Code vorliegt.
Kann gut sein. Hamburger glauben auch nicht, dass Bayern Deutsch sprechen können.
Da würde mich echt mal interessieren wieso? Ob ich meinen MOV AX Sonstwas nun auf 'nem X86 oder auf 'nen ATMEL ausführen lasse, ist doch Wurscht - beides ist Assembler.
Allein bei den X86ern gibt's -zig Dialekte die auch auf Verlangen von NASM passend erzeugt werden können. Im Standardfall nimmt er halt den kleinsten gemeinsamen Nenner - aber IIRC, kann er sogar für ATMEL, PICaxe und sonstwas passenden Maschinencode erzeugen. Alles Assembler, in meinen Augen, aber ich will mich da nicht streiten.
In welchem? Dem von Intel, oder dem von AMD, oder gar ganz rustikal in dem von CYRIX?
OK, ich will mich wirklich nicht streiten, aber für mich ist Assembler eine Suppe, die jeweils passend für den Prozessor zugeschnitten (gewürzt) wird/wurde, auf dem sie ausgeführt (gekocht) werden soll. Ob der Topf nun Intel, AMD, Atmel, oder sonstwie heißt, interessiert mich nicht. Zumindest so lange nicht, wie es nicht um Zeit-kritische Anwendungen geht, wo zB der AMD 1 bis 2 Prozessorzyklen mehr für einen Assembler-Befehl braucht als der Intel - oder umgekehrt, je nach Situation.
Geändert von Das'O' (04.07.2010 um 17:50 Uhr) Grund: Typo
Ein Assembler ist einfach nur ein Übersetzungstool für beliebige Befehlssätze (MIPS, x86, ARM, PowerPC, usw, wobei es in der Regel noch weiter zwischen Dialekten unterschieden wird, wie Das 'O' bereits bemerkte).
Was MagicMagor wohl mit "Mikroprozessor-Programmierung" meint, ist die Implementierung eines Befehlssatzes mittels des Mikrobefehlssatzes der zugrunde liegenden Hardware, was jedoch vom Hardwarehersteller selbst vorgenommen wird. Der Begriff "Mikroprozessor-Programmierung" ist hier anscheinend nur unglücklich gewählt.
Mit Mikroprozessor/-controller-Programmierung verbinde ich, wie auch Das 'O', die Programmierung eines Mikroprozessors/-controllers mittels eines Befehlssatzes, oder einer höheren Programmiersprache wie etwa C.
Geändert von Kyuu (04.07.2010 um 18:11 Uhr)
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
