Was ist der Unterschied von Assembler und Maschinencode?
7 Antworten
Maschinencode ist Binärcode.
Assemblersprachen ordnen jedem Befehl eines Prozessors ein Kürzel (das so genannte Mnemonic) zu (z. B. MOV, LDR, STR, ADD, ...).
Der Assembler übersetzt die Mnemonics und Registernamen (z. B. R0, ..., R15 (general purpose register), PC/RIP (program counter / instruction pointer), RAX (accumulator register), RBX (base register), RCX (counter register), RDX (data register), SP/RSP (stack pointer), RBP (base pointer), RSI (source index), RDI (destination index), LR (link register), ...) in die entsprechenden Binärcodes.
Zum besseren Verständnis solltest du mal ein wenig Recherche im Internet zur "Geschichte der Programmierung" betrieben. Du solltest allgemein auch recherchieren, was überhaupt eine "Anwendung, Programm oder App" überhaupt ist. Schließlich solltest du noch im Internet recherchieren, was eine "Generation" einer Programmiersprache ist. "Genration" ist ein wichtiges Stichwort und da wirst du viel auf die "Geschichte der Programmierung" stoßen und das Stichwort "Generation" wird deine Frage verständlich und korrekt beantworten.
Ich garantiere nicht für die absolute Richtigkeit meiner Antwort ;D, aber hier ist das, was mir gerade selbst noch aus meiner Ausbildung und Studium einfällt:
Es gibt in der Programmierung mehrere Generationen von Programmiersprachen. Man unterscheidet zur Zeit fünf Generationen von Programmiersprachen. Ich sage deshalb "zur Zeit", weil es eine 6. Generation auch irgendwann geben wird. Aber dazu gleich mehr.
Die 1. Generation ist die so genannte "Maschinensprache". Ich weiß nicht, wie viel du dich schon mit der Computertechnologie beschäftigt hast, aber ein Computer ist eigentlich strohdoof, denn ein Computer rechnet nur mit "0" oder "1". :-D
Der Computer berechnet im so genannten Binärsystem, kennt also nur zwei Zustände. "0" für keine Spannung, "1" für Spannung.
Deshalb ist die "Maschinensprache" die "interne Sprache" des Computers. Beim Programmieren in Maschinensprache verwendet man also nur die beiden Symbole 0 und 1, die der Computer auch nur kennt. In "Maschinensprachen" zu programmieren beherrschen weltweit heutzutage kaum noch Menschen und ist eigentlich auch nicht mehr üblich. Aber das hat einen historischen Hintergrund, denn das Kind musste ja auch erstmal geboren werden! Also hat man ernsthaft ursprünglich in "0" und "1" programmiert!
Um z.B. zwei Zahlen zu addieren musste man in dieser Form programmieren:
1100 0100 0000 0100
1000 0000 1100 0011 1101 0101
Also diese 0 und 1 sind tatsächlich eine einfache Additon, sagen wir mal 1+1 = 2.
Ich bin mir selber nun mehr sicher, was für eine 0 und 1 Kombination ich da eingeben ;D, wollte aber auch nur ein Beispiel geben.
(Also das 1 + 1 ist nur ein Beispiel. Habe nun keine Lust binär nachzurechnen. :-D)
An Hand dieses Beispiels sieht man auch schon die Problematik dieser Art der Programmierung!
Denn es ist sehr zeitaufwändig, zudem unübersichtlich, feheranfällig und hat man einen Fehler gemacht (und das wird man! :-D),
dann ist ebenfalls schwer, den Fehler zu lokalisieren, weil man bei dementsprechend größeren Programmen einen riesengen "Quellcode" von
"0" und "1" hätte.
Aber wie ich schon sagte, musste das Kind ja irgendwie geboren werden und die Geburt war, dass man anfing, in "Maschinensprache" zu programmieren,
weil man es auch musste. Man musste die Erziehung des Kindes übernehmen. Aber irgendwann war das Kind fit für den Kingergarten bzw. für die Schule,
also hat man in Maschinensprache "Assembler" programmiert.
Assembler, so heißen die Programmiersprachen und übrigens auch die fertigen Programme heißen "Assembler" enthielten bereits "Befehle", wie wir es aus
modernen Programmierensprachen kennen. Diese Befehle waren sehr einfach, aber jedoch sehr einprägsam bzw. symbolischer und somit verständlicher und weitaus
weniger fehleranfälliger, denn die Befehle hatten folgende Form: MOVE, ADDITION, SUBTRACTION usw.
Z.B.
ADDITION 1 BL
ADDITION 1 BL
Das wäre 1 + 1.
Das Problem an Assemblern ist aber auch gewesen, dass diese in Maschinensprache übersetzt werden müssen, dass diese überhaupt ausgeführt werden können.
Umgekehrt war eben der Vorteil da, dass Assembler immer und immer erweitert wurden, sodass man nach und nach immer weniger mit der "Maschinensprache" direkt
zu tun hatte, denn jeder Assembler-Befehl wird 1:1 umgesetzt, was man vorher manuell machen musste, nämlich das niederschreiben der richtigen Kombination von "0" und "1".
Und hat man nur einen Fehler gemacht, war schon das Rechergebnis falsch oder im schlimmsten hat sich der Computer "zerschossen".
Assembler sind, was die Performance angeht, aber verdammt schnell gewesen. Nachteil war, dass Assembler hardwareabhängig waren, also Architektur des Prozessors.
Nun kommt die 3. Generation ins Spiel. Die 3. Generation kennt "jeder" von uns, der sich schon mit Computertechnologie beschäftigt hat, eine Ausbildung hat, etc.
Mit Hilfe von Assemblern wurden irgendwann Programmiersprachen entwickelt, die noch einfacher zu verwenden waren, da es mehr Befehle gab und man dann schon eher sowas
wie einen vernünftigen "Quelltext" hatte, der entweder, je nach Programmiersprache, compiliert oder interpretiert wurde.
Vor allem wurden Programmiersprachen der 3. Generation auch dafür entwickelt, die nun andere Zwecke erfüllen sollten, denn jede Programmiersprache hat einen anderen Zweck
bzw. Anwendungsbereich (auch heute noch). Mit der 3. Generation hatte man erstmalig Programmiersprachen, die maschinenunabhängig funktionieren konnten!
Beispiele für Programmiersprachen und deren Zwecke / Anwendungsbereiche sind z.B.
COBOL für mathematische Aufgaben, kaufmännische und administrative Aufgaben,
REXX für Großrechner-Systeme,
PL/1 (enthält COBOL-Code und wurde von IBM für Großrechner entwickelt für mathematische Zwecke)
Java (Bedingt Plattformunabhängig, gute Portabilität, Entwicklung von Software auf PDAs, Handhelds, etc.)
Und das beste Beispiel, was "jeder" von uns kennt ist die Programmiersprache "C", die auch zur 3. Generation gehört.
Der Zweck von "C" ist das Entwickeln von Programmiersprachen selbst, LOL. Mit einer Programmiersprache eine Programmiersprache entwickeln. LOL
Ist aber eben die Geburt eines weiteren Kindes. Sprachen, die z.B. mit "C" entwickelt wurden sind "C++", "C#" und "Java (und auch Android)"
Ein anderer Einsatz von "C" wäre das Programmieren von Treibern und auch kleine Betriebssysteme (z.B. das BIOS).
Übrigens, man nennt die 3. Genration auch "prozedurale Programmierung" (hast vielleicht schonmal gehört) oder auch "strukturiete Programmierung", wobei man auch in "Java", "C#"
und auch allen anderen Sprachen "strukturiert" programmieren kann. Aber mit "prozedural" oder "Strukturierte" Programmierung ist die "nicht objektorientierte Programmierung" gemeint,
aber dazu komme ich gleich. Prozedural heißt also, dass man die Anweisungen so aufschreibt, wie der Computer auch tatsächlich technisch arbeitet. Man spricht ja immer davon, dass Computer
"multitasking-fähig" heutzutage sind. Technisch gesehen stimmt das nicht so ganz (außer bei Mehrprozessorkernen). Ein Computer arbeitet IMMER! genau der Reihenfolge nach (also sequentiell).
Deshalb schreibt man bei der prozeduralen Programmierung alle Befehle auch so auf, wie sie in der Reihenfolge ausgeführt werden sollen. (Sprungbefehle sind theoretisch auch möglich, aber egal :-D)
Nun noch ein Beispiel für die Programmiersprache "C".
Summe = 1 + 1; ---> Das sieht doch schon leserfreundlich für den Menschen aus, nur mit dem Unterschied, dass der Mensch es vielleicht so auf Papier bringen würde:
1 + 1 = 2 (Summe)
Mathematisch gesehen ist es egal, auf welcher Seite was steht bei der Berechnung, denn das = Zeichen meint beide Richtungen.
Aber in "C" werden die Befehle von rechts nach links gelesen, nicht von links nach rechts, wie es die meisten Menschen / Ländern tun. :-D
Die 4. Generation von "Programmiersprachen" sind die wiederum "nicht prozeduralen" Programmiersprachen :-D.
Z.B. SQL, MySQL, Natural
Streng genommen sind es eher "deskriptive" (beschreibende) Sprachen, also keine "richtigen" Programmiersprachen, sondern
der Sinn und Zweck sind eher "Abfragen" zu machen an Hand von "Beschreibungen". SELECT * FROM Datenbank für MYSQL z.B. wäre eine Abfrage einer Datenbank.
Die 4. Generation (ist zwar Ansichtssache und abhängig von der Sprache) verfügt eher über "Befehle" wie man auch mit einem "Menschen" reden würde.
SELECT * FROM Datenbank. "Wähle alles aus der Datenbank "Datenbank" aus".
Nun wird es spannend!
Zu guter Letzt das Abitur des Kindes! Die 5. Generation ist (heutzutage) die meist genutzte Generation überhaupt, was nicht überraschend sein dürfte.
Die 5. Generation sind entweder "wissenschaftliche" oder "künstliche Intelligenz" oder "objektorientierte" Sprachen.
Die Vorteile der 5. Generation sind, dass sie "objekorientiert" sind,
d.h. Programmierer entwickeln "Apps" und greifen dabei auf "Code" zurück, den ein anderer geschrieben hat :-D.
Das ist heutzutage Gang und Gebe, also sehr üblich. 50-75 % sind quasi "Fremdcode" und den Rest programmiert man selber,
weil es dafür z.B. keine Bibilothek gibt für die jeweilige Anforderung.
Also man hat die Möglichkeit der "Wiederverwendbarkeit" von Code. Das hat einen Vorteil, den man früher nicht hatte:
Es gibt nämlich Anforderungen in einer App, die so gut wie fast jedes Programm / App hat / nutzt / braucht.
Z.B. Programmierranfänger lernen, wie man eingebene Daten auf der Tastatur im Programm ausliest. In Java würde man z.B. den Import machen
import java.io.BufferedReader; ---> Das ist im Prinzip ein fertiges "Programm", was man nutzt und importiert und was da alles hinter steckt... (würde man sowas selber programmieren müssen)
private BufferedReader input;
private String buffer;
input = new BufferedReader (new InputStreamReader (System.in) );
buffer = input.readLine ( );
Diese "Wiederverwendbarkeit" reduziert die Fehleranfälligkeit enorm. Mit den Jahren "veralten" auch Klassen, Methoden, Funktionen einer Progammiersprache.
Aber grundsätzlich gilt: Es gibt Dinge, die man in "jedem" Programm braucht!
Objektorientiert hat auch den Vorteil, dass der Programmiercode an sich reduziert wird. In Java kann man z.B. eine Methode schreiben und diese Methode
kann in der eigene App an mehreren Stellen genutzt werden, wenn erforderlich. Man brauch also die Befehle nicht alle noch mal neuschreiben sondern ruft
die Methode einfach nochmal neu auf.
Z.B.
private void beenden ( )
{
Runtime.getRuntime ( ).exit (0); // Programm beenden
}
Man könnte z.B. eine Menüleiste haben mit dem Menüpunkt "Beeden". Dann wird diese Methode aufgerufen beenden ( );
Es wäre auch denkbar, das Programm durch einen Klick auf einen Button zu beenden. Dann einfach wieder beenden ( ); aufrufen.
So das wars eigentlich.
Am Anfang erwähnte ich noch die "6. Generation". Es wird darüber nachgedacht (oder ist bereits schon in Entwicklung, keine Ahnung), Computer so "umfunktionieren", dass sie
nicht mehr binär arbeiten, sondern "trinär". Das wäre theoretisch sehr viel schneller, jedoch weitaus komplizierter.
Denn in der Computertechnologie sind wird heutzutage mittlerweile auf ein Problem angekommen... denn wir haben die Grenzen erreicht, was technisch von der Geschwindigkeit möglich ist.
Das wurde aber auch schon vor 30 Jahren oder so vorausgesagt, dass ungefähr im Jahre 2018-2020 ca. die Grenzen erreicht werden. Also Computer werden nicht mehr viel schneller werden.
Natürlich, man versucht das zu umgehen, indem Computer immer mehr mit "Threads", mehr Kernen, etc. arbeiten. Auch wird sich die Rechenleistung per Netzwerk bei vielen System geteilt,
Lasten werden verteilt, was zudem auch einen Sicherheitsaspekt hat (Schutz vor Hackerangriffen).
(Es ist sogar möglich, dass man seine eigene Rechenleistung an andere über das Internet abgibt / verkaufen :-D). In Zeiten, wo man seinen Rechner natürlich nicht nutzt.
Mir fällt natürlich der Name leider gerade nicht mehr ein, wer das "damals" vorausgesagt hat.
Auch wird bereits fleißig daran geforscht, Quantencomputer zu entwicklen. Die wären so mega schnell... Dann wäre ein Quatencomputer so schnell wie alle Rechner auf der Welt.
Aber ist wohl noch eher Sci-Fi und würde uns dann auch wiederum neue Generation von Programmiersprachen einbringen :-D.
So, gute Nacht. Ich hoffe die Informationen haben dir geholfen. :-D
Ich entschuldige mich für die Rechtschreibfehler. Normalerweise bin ich gut in der Rechtschreibung,
aber ich habe nun keine Lust gehabt, darauf zu achten und habe den Text so schnell geschrieben, sorry. :-D
Danke, dass du uns deine Erfahrungswerte mitgeteilt hast. ;) <3
Wow! Für diese Antwort muss man ja fast einen Pfeil nach oben geben, auch wenn in der Tat nicht alles stimmt. :-) (Aber es stimmt zumindest "so grob". ;-) )
So kann man z. B. natürlich auch in imperativen/prozeduralen Programmiersprachen "Fremdcode" komfortabel nutzen. So ist ein import in Java ja letztlich nicht viel mehr, als ein include in C.
Auch ist Objektorientierung bei weitem nicht so "revolutionär" (oder gar "ein Paradigmenwechsel") gegenüber "normaler" imperativer/prozeduraler Programmierung. Als Entwickler sehe ich das ganze sehr viel pragmatischer, denn eine Klasse (class) ist letztlich nicht viel mehr, als ein struct, das auch Funktionen enthält, auch wenn diese dann plötzlich "Methoden" genannt werden. Das kann ich mit jedem "normalen" struct "emulieren", indem ich Funktionen dazu bastel, die als ersten Parameter einen Pointer auf das struct übergeben bekommen, der dann in einer lokalen Variablen abgelegt wird, die this heißt.
Ich programmiere beispielsweise auch sehr viel in Go und der Code ist im Grunde genau so strukturiert, wie ich ihn beispielsweise auch in Java strukturieren würde und das, obwohl Go überhaupt keine Klassen unterstützt. Es unterstützt allerdings so genannte receiver functions. Eine receiver function ist eine Funktion mit zwei Parameterlisten, eine "links" vom Funktionsnamen und eine "rechts" vom Funktionsnamen, wobei man die "linken" Parameter beim Aufruf vor einen Punktoperator schreibt. Warum wohl? Damit es "aussieht", wie Objektorientierung. Genau das soll es auch "emulieren". ;-) Aber auch ohne diese receiver functions ließe sich "Objektorientierung" natürlich einfach "emulieren", indem man Konventionen einführt, wie z. B. "der erste Parameter einer Funktion ist die Datenstruktur (das 'Objekt'), auf der (dem) sie operieren soll".
Mir stehen beispielsweise immer die Haare zu berge, wenn irgendein Software Engineer daherkommt und meint, bei objektorientierten Programmen würden Objekte Nachrichten aneinander senden. Ein Methodenaufruf ist letztlich ein ganz normaler Funktionsaufruf. Er ist völlig synchron, die Codeausführung wird beim Methodenaufruf unterbrochen und wird fortgesetzt, nachdem die Methode zurückgekehrt ist. Die Parameter (einschließlich des impliziten this) und die Rücksprungadresse werden beim Aufruf auf den Stack gelegt, dann wird an den Anfang der "Methode" gesprungen, sie läuft durch, holt am Ende die Rücksprungadresse vom Stack, legt stattdessen die Parameter drauf und springt zurück. Da ist nix mit Nachrichten, kein FIFO, keine Asynchronität, nichts. Es ist exakt das selbe, wie jeder Funktionsaufruf, nur dass ein implizites struct mit "Attributen" mit dranhängt, das per Pointer auf dem Stack mit übergeben wird. There's absolutely no "magic". Und die zusätzliche Abstraktion, die es bietet, ist ebenfalls ... "überschaubar". Objektorientierung in einer nicht-objektorientierten Sprache zu emulieren ist wirklich vergleichsweise einfach, jedenfalls sehr viel einfacher, als z. B. strukturierte Programmierung (Schleifen, Verzweigungen, etc.) in einer Assemblersprache zu implementieren, die ja nur bedingte Sprünge kennt. (Auch das ist natürlich möglich, aber aufwändig und "unleserlich".) Es gibt meines Erachtens überhaupt keinen Grund, dies als eine Art "Paradigmenwechsel" zu betrachten. Warum um alles in der Welt erzählt man Leuten, es sei "etwas anderes". Es ist es nicht. Sie können ihr Wissen weiterverwenden, auch wenn sie von einer imperativen/prozeduralen in eine objektorientierte Sprache wechseln, denn es ist letztlich hauptsächlich "syntaktischer Zucker".
Bei Vererbung sieht das ganze ein bisschen anders aus, allerdings sind ohnehin viele Leute der Meinung, dass man, wenn überhaupt, dann ohnehin nur von Interfaces bzw. rein abstrakten Klassen "erben" sollte und wenn man die Funktionalität einer anderen Klasse benötigt, dies lieber durch "embedding" (was nichts anderes heißt, als: einen Pointer auf ein anderes "Objekt") lösen sollte.
Ein guter Kommentar!
Hey, vielen Dank für deinen Kommentar und die positive Bewertung. Ich habe auf deinen Kommentar auch mal ein "Like" gegeben und du hast dir wesentlich mehr Mühe gegeben als ich, denn du hast nicht mal einen einzigen Rechtschreibfehler :-D. Ich liebe solche Diskussionen ja so sehr und finde es interessant, andere Meinungen zu lesen. Nun, wie ich am Anfang bereits darauf hingewiesen habe, kann ich nicht für die absolute Richtigkeit garantieren. Ich habe es tatsächlich eher so "grob" beschrieben. Natürlich hätte ich noch mehr schreiben können. :-D Die Informationstechnik ist ohnehin ein komplexes Fach an sich. Man kann eigentlich nie ein Ende finden :-D. Danke, dass du meinen Kommentar an so manchen Stellen richtig korrigiert hast, denn ich habe mich in der Tat ziemlich falsch ausgedrückt :-D.
Du hast natürlich recht, dass man auch in der "3. Generation" "Fremdcode" komfortbabel nutzen kann, indem man z.B. in "C" die "Includes" inkludiert. Verglichen mit "Java" ist ein "Import" natürlich genau dasselbe wie ein "Include" in "C". Was ich aber eigentlich damit sagen wollte ist, dass es in der "5. Generation" einen viel, viel wesentlicheren Anteil einnimmt, denn die "Erfindung / Einführung" der "5. Generation" hat tatsächlich genau diesen (historischen) Hintergrund in der Programmiergeschichte! Die Ziele der "objektorientierten" Programmierung sind nämlich, die "Wiederverwendbarkeit" von Programmen, Programmcodes / Quellcodes zu vereinfachen. Viele Imports (in Java) z.B. sind heute nur so "perfekt", weil jahrelang daran gearbeitet wurde. Wie ich bereits sagte gibt es auch viele Imports, die mit jeder neuen Version der Programmiersprachen veralten, also "decrepated" sind. Diese "Perfektheit" der "fremden Quellcodes" minimiert natürlich in der objektorientierten Programmierung die Fehleranfälligkeit von Anwendungen enorm, da diese "Imports" natürlich viele routinemäßigen Aufgaben enthalten, die man eigentlich in "jeder App" braucht, die entwickelt wird. Vergessen habe ich, du hast es aber bereits erwähnt, dass es in der objektorientieren Programmierung auch Techniken gibt, um der "Perfektheit" noch ein Stückchen näher zu kommen. Techniken sind z.B. die "Kapselung" von Daten und die "Vererbung".
Ich würde bei der "objektorientierten" Programmierung auch nicht von einer mega "Revolution" reden, aber für die Geschichte ist die "Objektorientierung" schon ein "Programmierparadigma(wechsel)". :-D
Die "objektorienierte" Programmierung hat sich nun mal im Laufe der Zeit "in der Geschichte der Programmierung" bis heute etabliert. Aber die prozedurale oder imperative Programmierung nun mal auch :-D.
Klar und du hast absolut recht, dass es in "Java" "Klassen" sind, die in "C" sowas wie das "struct" sind und dass die "Funktionen" in "Java" "Methoden" heißen. :-D
Heißt nur eben halt anders. Aber jede Programmiersprache hat ohnehin evtl. andere Bezeichnungen für etwas. Es gibt hunderte Programmiersprachen. Ich beherrsche leider nicht alle :-D, aber man kann davon ausgehen, dass etwas evtl. anders bezeichnet wird. Es gibt eben nur eine Sache, die wirklich bei allen Programmiersprachen gleich ist: nämlich das Prinzip, die Logik dahinter und was Programmieren eigentlich für einen Sinn hat bzw. am Ende die "Apps". :-D
Das schöne an Programmieren ist: Wenn es einmal "Klick" gemacht hat und man eine Programmiersprache schon "ganz gut" kann, dann fällt es auch nicht mehr so schwer, eine neue Programmiersprache zu lernen. Aber ist evtl. auch Ansichtssache!? Der Anfang jeder neuen Programmiersprache ist halt manchmal echt nervig, dieses ganze auswendig lernen :-D. Wie war die Syntax noch :-D ? Wie hieß der "Befehl" noch :-D ? Ich habe mich schon mit so vielen Programmiersprachen beschäftigt und es gibt auch Programmiersprachen, die echt ekelhaft sind. Ist aber auch Ansichtssache :-D.
Grundsätzlich finde ich "C", "C++", "C#", "Java" / "Android" ziemlich cool. Es sind Programmiersprachen, die nicht so eine ekelhafte Syntax haben, gut leserlich sind, Spaß machen, leicht zu lernen sind und man kann viele coole Sachen damit machen. Ist aber nun meine persönliche Meinung. Jeder hat auch in der Programmierung andere Vorlieben und ob etwas einfacher oder schwerer zu lernen ist, ist auch Ansichtssache und vor allem Interesse.
Zu den Generationen ist evtl. noch zu erwähnen, dass die 3.-5. Generationen bzw. die Programmiersprachen, die in diesen Generationen katagorisiert sind, nicht immer eindeutig trennen lassen, welcher Generation die Programmiersprache "X" nun angehört. Die 1. und 2. Generation ist wohl eindeutig, aber die 3.-5. Genertion wird in der Literatur "von jedem" immer anders erklärt.
Oh, keine Zeichen mehr übrig :-D.
...
Viele Programmiersprachen kommen und gehen bzw. entwickeln sich ständig weiter. Bei der Weiterentwicklung einer Programmiersprache fand bei einigen Programmiersprachen auch ein "Generationswechsel" statt. Z.B. die Programmiersprache "B" wurde mit Assemblern entwickelt. "BCPL" wurde wiederum aus "B" und "CPL" entwickelt :-D und "B" und "BCPL" wurden dazu verwendet, um die heute der bedeutsamsten und "coolsten" Programmiersprache "C" zu entwickeln :-D. "C" ist, was den "Kern" betrifft relativ gering und hat nicht viele "Schlüsselwörter". "C" wurde dazu verwendet um davon eine "objektorientierte" Version zu erstellen, nämlich "C++". Daraus entstanden z.B. auch "Java" und "C#". Das ist wahrscheinlich auch der Grund dafür, warum sich diese Programmiersprachen ziemlich ähnlich sind in Syntax und Performance.
"C/C++" sind meiner Meinung nach nur deshalb so "geil", weil man damit wirklich ALLES machen kann.
Aber nunja, ich mache nun mal schluss. Reicht ja auch. :-D
Das schöne an Programmieren ist: Wenn es einmal "Klick" gemacht hat und man eine Programmiersprache schon "ganz gut" kann, dann fällt es auch nicht mehr so schwer, eine neue Programmiersprache zu lernen. Aber ist evtl. auch Ansichtssache!?
Ja, das geht mir ähnlich.
Meine "letzten" Sprachen habe ich tatsächlich binnen Wochen erlernt. Das heißt natürlich nicht, dass ich danach "perfekt" darin war. Aber ich konnte die Sprachen anschließend produktiv nutzen und auch größere und komplexere Anwendungen darin entwickeln.
Ich achte schon kaum noch auf die Sprache. Ich frage mich inzwischen manchmal fast, warum in Stellenausschreibungen überhaupt nach einer bestimmten Sprache gesucht wird. Ich denke mir so oft, dass die Sprache doch im Grunde egal ist. Wenn ich ne bestimmte Sprache brauche, die ich noch nicht beherrsche, kann ich sie mir binnen einiger Wochen aneignen. Das heißt natürlich nicht unbedingt, dass das dann eine meiner bevorzugten Sprachen wird. Aber ich kann darin arbeiten. Außerdem wollen Unternehmen ja in der Regel Probleme lösen. Probleme lassen sich auf vielerlei Arten lösen und die Wahl des geeigneten Werkzeugs (der geeigneten Sprache) müsste doch eigentlich sogar dem Entwickler selbst überlassen bleiben. Wenn ein Handwerker zu mir kommt, schreibe ich ihm ja schließlich auch nicht vor, welche Zange er zu verwenden hat, sondern überlasse das dem Fachmann.
Nur mit anderen Paradigmen ist es dann doch wieder anders. Ich würde mir z. B. nicht zutrauen, "mal eben" eine funktionale Programmiersprache zu erlernen. Ich denke da bräuchte ich dann doch mehr Ressourcen und Zeit.
Einen "Power-Kurs" kann man auch schon an einem kompletten Wochende belegen, um eine neue Programmiersprache zu erlernen :-D. Natürlich wird man dann in der Programmiersprache noch überhaupt nicht gut darin sein, aber es reicht zum ersten kennen lernen erstmal aus. Ein "Power-Kurs" macht aber auch nur für die Leute Sinn, die schon andere Programmiersprachen gut beherrschen, bei denen es also schon "Klick" gemacht hat. Richtig "gut" kann man tatsächlich schon in ein paar Wochen in einer neu erlernten Programmiersprache werden. Es dauert also insgesamt nicht mehr ganz so lange wie am Anfang, als man überhaupt mit der ersten Programmiersprache anfing. Programmieranfänger, also die, die die ihre erste Programmiersprache lernen, brauchen ca. ein halbes Jahr bis zu einem Jahr, sagt man so im Durchschnitt, bis es "Klick" macht. Das klingt für viele so lang und abschreckend, aber es lohnt sich sehr, weil es dann bei einer weiteren Programmiersprache wesentlich schneller geht.
Du hast geschrieben, dass du viel mit "Golang" arbeitest. Darin habe ich bisher nur so einen "Power-Kurs" gemacht :-D. Reichte mir aber bisher zum kennen lernen aus und denke, es ist eine Programmiersprache, die in den nächsten Jahren sehr viel Potential bekommen wird. Ist ja insgesamt noch eine relativ junge Programmiersprache. Aber das hat man vor einigen Jahren auch bei "Java und Co." gesagt und ich finde "Java" hat sich in den letzten auch enorm positiv weiter entwickelt (und ist mittlerweile auch schon "alt", also nicht mehr so jung). Vor allem ist "JavaFX" ein sehr geiles Framework. Das sollte sich jeder mal anschauen, der es noch nicht kennt! Leider ist "JavaFX" vielen noch immer kein Begriff. Vor allem ist es so: Wer "JavaFX" beherrscht hat auch einen sehr leichten Einstieg, "Android" zu lernen, da es enorm viele Parallelen gibt. In Android wird das Layout und Design überlicherweise in einer "XML"-Datei deklarativ erzeugt. Ich liebe diese Trennung von Code / Logik und Layout / Design. Umgekehrt verhält es sich natürlich genauso. Wer schon Android beherrscht, hat es einfacher, das Framework "JavaFX" zu erlernen, da man in JavaFX üblicherweise das Layout und Design auch deklarativ erzeugt und vom Code trennt. In JavaFX wird das Layout auch in (F)XML definiert und das Design wird mit CSS verschönert! CSS kennt wohl jeder, der schon mal eine "Internetseite" erstellt hat.
Ich achte auch nicht so auf die Sprache, sie sollte nur nicht so ekelhaft sein wie "VB". Da kriege ich echt das kotzen. Das so eine Programmiersprache überhaupt so entwickelt wurde, wie sie ist, war schon meiner Meinung nach eine Schande an sich :-D. Es ist aber, wie immer, Ansichtssache. :-D
Aber die Erfinder solch "ekelhafter" Programmiersprachen müssen meiner Meinung nach auf den Stuhl der Schande, LOL.
Es gibt aber auch viele Programmiersprachen, die wirklich keiner kennt und die man auch ganz sicherlich nicht unbedingt kennen lernen muss, aber vielleicht mal zufällig darauf stößt und diese unbekannten Programmiersprachen sind tatsächlich ekelhaft und schon eher "esoterisch" und auch nicht für den produktiven Einsatz gedacht. :-D
Ein Beispiel wäre die "Programmiersprache" "Brainfu**". Da ist der Name bereits Programm, im wahrsten Sinne des Wortes. Einfach mal im Internet rechcherchieren. "Hello World!" sieht darin so aus:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>
Man! :-D
Ich finde die Vorschrift von Softwareunternehmen auch nicht so klasse, welche Programmiersprachen verwendet werden sollen bzw. welche man schon perfekt können muss. In einigen Szenarien macht es vielleicht Sinn, explizit auf die Erfahrung einer bestimmten Programmiersprache in der Stellenanzeige hinzuweisen. Aber einige Unternehmen verlangen das auch trotzdem "einfach so ohne einen Grund". Z.B. macht es für ein Unternehmen, dass Spiele entwickelt evtl. mehr Sinn explizit nach bestimmten Sprachen zu fragen. Für das Entwickeln von Spielen gibt es auch so eher "Standards", welche Programmiersprachen gut geeignet sind. z.B. "Boo", C#, "JavaScript", "Java" und "Android" sind da oft gefragt, wobei es auch noch viele andere gute Sprachen dafür gibt. Aber ein allgemeiner anderer Grund für dieses "einfach so" ist, dass viele Unternehmen keinen Bock auf Leute haben, die etwas nicht können, wenn nach der Sprache gefragt wird, weil das bereits existierende Team in dem Unternehmen erfahren damit ist und sie keine Lust darauf haben, bis das neue Mitglied sich (so langsam) integriert hat, was bei jemanden, der es schon kann, schneller geht. Unternehmen wollen halt Zeit und Geld sparen. Zeit ist nunmal Geld. Gerade, wenn "größere Projekte" in dem Unternehmen Gang und Gebe sind.
Aber prinzipiell hast du recht und es ist ein gutes Argument mit dem Handwerker. Ich bin schließlich auch der Meinung, dass man dem Entwickler überlassen soll, welches "Werkzeug" er denn gerne benutzen möchte als Fachmann.
...
...
Eine "mal eben" "funktionale" und gut und schnell zu erlernende und vor allem sich sehr lohnende Programmiersprache ist "Scala"! Schau's dir mal an und mach mal einen "Power-Kurs", wenn du "Scala" noch nicht kennst. "Scala" baut auf "Erlang" und "Java" auf. "Java" kennst du natürlich. In "Scala" kann man "Java-Frameworks" wie "Swing", "JavaFX" und "Android" einbinden, etc. Auch das Einbinden von Bibilotheken aus Java und JARs ist möglich. In "Scala" ist allerdings alles ein "Objekt". Also "Scala" ist auch eine "objektorientierte Sprache".
Die Syntax ist an Java angelehnt und auch ein wenig an Erlang. In "Scala" kann man allerdings auch die Semikolons weglassen am Ende der Anweisung. Das müsstest du ja ganz gut aus "Go" kennen.
"Scala" hat eine richtig gute Performance und erbt zwar auch die "Thread-Klassen" von Java, erbt aber auch die Nebenläufigkeit von "Erlang". Man muss halt abwägen. Performanter ist es bei wenigen Threads, auf das Erbe von Java zurückzugreifen. Für Power-High-End-Anwendungen kann man besser auf das Erbe von Erlang zurückgreifen, da "Erlang" ja ganz gerne zum Einsatz kommt, wenn es sich um eine Anwendung handelt die auf allerhöchste Nebenläufigkeit auslegt sein soll.
Es gibt viele gute Menschen auf der Welt, die so gut / kompetent / schlau / genial sind und auch reich wurden :-D. Ein richtiges gutes Beispiel (und mega intelligentem Einsatz) für "Erlang" und allerhöchstem Niveau von Nebenläufigkeit einer Anwendung wäre "WhatsApp". Jan Koum und Brian Acton sind schon zwei sehr geniale Typen. Die Anwendung, die auf dem Server läuft und die eingehenden Nachrichten der Chatter ampfängt und an die richtigen Chat-Teilnehmer weiterleitet, ist in Erlang entwickelt worden. Warum ich das genial finde ? Es ist ein richtiges gutes Beispiel und richtiger guter Einsatz von Erlang. Die beiden Gründer haben das also sehr clever durchdacht und haben es defintiv verdient mit ihrer Genialheit reich zu werden. Ich persönlich hätte diesen geilen Messenger allerdings nicht an Salzberg verkauft. Sehr schade. :-D
Denn reich waren die beiden so oder so schon. es wurde halt durch den Verkauf an Facebook noch ein drauf gelegt ;-). Zuckerberg hat halt Panik bekommen :-D.
Naja :-D. Erlang zu lernen lohnt sich also auch :-D.
Maschinencode ist das, was direkt die CPU bekommt und damit was anfangen kann. Der Assembler ist ein Compiler, der wie auch andere Compiler Maschinencode erzeugt. Der Code ist aber sehr maschinennah, fast 1:1 übertragbar. Der wesentliche Unterschied zum Maschinencode ist, dass Adressen symbolisch (durch Vergabe eines beliebigen Namens) dargestellt werden können und binäre Zahlenwerte in hexadezimaler Schreibweise. Auch gibt es Makros für häufig verwendete Befehlsfolgen. Ein Assemblercode ist damit für den Menschen noch lesbar.
Also an sich beschreiben sowohl Assembler, als auch Maschinencode das gleiche. Es ist lediglich eine andere Darstellung. Assembler menschenlesbar, Maschinencode die platzsparende Variante in Bits kodiert. Von der Seite - so wies mich ein Informatiker darauf hin - sei Assembler keine Abstraktionsebene höher.
Etwas anderes dürfte es mit Makroassembler sein. Makros sind so Art Funktionen... und der Übersetzer in Maschinencode setzt diese dann an die entsprechende Stelle ein - oder so. Das entstehende Programm lässt sich aber nicht mehr 1:1 zurückübersetzen.
Maschinencode wird tatsächlich von der CPU ausgeführt. Assembler ist noch eine Stufe höher, so dass er auch für Menschen lesbar ist. Jedoch entspricht hier im Gegensatz zu Hochsprachen (meist) ein Mnemonic auch wirklich einem Opcode.
Beispiel für den Unterschied:
Maschinencode Assembler
BC007C MOV SP,7C00
PS: Assembler muss noch in Maschinencode übersetzt werden durch einen Compiler.
Der "Compiler" heißt in diesem Fall selbst Assembler. ;-)
Ja, "Compiler" bezeichnet aber den Überbegriff für die Übersetzung von Quellcode in der einen Sprache in Maschinensprache oder Intermediate-Code. Ich habe bewusst diesen Begriff gewählt, um die Unterscheidung zwischen der Sprache Assembler und dem Compiler/Assembler beizubehalten.
Nunja, streng genommen gibt es ja nicht die (eine) Sprache Assembler.
Es gibt die Sprachfamilie der Assemblersprachen.
Jede Assemblersprache sind letztlich ein Abbild der ihr zugrundeliegenden Maschinensprache. Jede Prozessorarchitektur hat ihre eigene Maschinensprache und daher auch ihre eigene Assemblersprache.
Ja, aber wenn sich die Frage nach der Unterscheidung zwischen Maschinencode und Assemblercode stellt, dann ist das Haarspalterei :-)
Mit einer derartigen Qualität der Rechtschreibung bist du als Programmierer ungeeignet, dort wird jeder Schreibfehler hart bestraft.