[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:19] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:21] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:26] In dieser Episode geht es um häufige Fragen im Fachgespräch rund um die Programmierung.

[0:32] Viel Spaß dabei.

[0:37] Hallo zusammen. Das Fachgespräch steht mal wieder vor der Tür.

[0:41] In der letzten Episode habe ich mich ja der Projektpräsentation gewidmet.

[0:45] Heute würde ich noch mal ein bisschen was zu häufigen Fragen im Fachgespräch erzählen,

[0:51] und zwar mit Fokus auf die Programmierung.

[0:53] Meine Reihe zu Fragen rund um die Objektorientierung habe ich schon abgeschlossen.

[0:57] Und um jetzt nicht zu einem ganz anderen Thema so vorzuwechseln,

[0:59] habe ich mir gedacht, ich trage noch mal so ein paar häufige Fragen zusammen,

[1:03] die im Zusammenhang mit der Programmierung auftreten.

[1:06] Das muss nicht mit Objektorientierung zusammenhängen,

[1:08] sondern es gibt auch so ein paar ganz allgemeine Sachen, die man da klären kann.

[1:11] Einige von den Fragen haben einen Bezug zur Objektorientierung heute,

[1:14] aber das meiste sind ganz allgemeine Fragen, die man eigentlich jedem stellen kann,

[1:18] der irgendwie mal programmiert hat, egal in welcher Sprache er bislang programmiert hat.

[1:22] Ich gehe die Liste einfach mal von oben nach unten durch und erzähle ein bisschen was dazu.

[1:26] Zu der einen Frage mal ein bisschen mehr, zu der anderen ein bisschen weniger.

[1:29] Ganz so, wie ich Lust habe und was mir dazu gerade mal einfällt.

[1:33] Ich habe einfach mal eine große Liste erstellt.

[1:35] Ich habe die auch ein bisschen untergliedert.

[1:37] Einmal in allgemeine Programmierfragen, dann Fragen zu Eigenschaften von Programmiersprachen,

[1:43] dann doch eher noch etwas in Richtung Objektorientierung

[1:47] und zum Schluss nochmal Fehlerbehandlung und auch etwas tiefergehendes,

[1:52] was ich vielleicht nicht jeden fragen würde,

[1:54] aber wenn ich rausfinde, Mensch, der Prüfling, der da sitzt, der hat technisch durchaus Ahnung

[2:00] und da ist auch tiefergehendes Wissen vorhanden, dann kann ich mal auch in die Richtung nachfragen,

[2:04] um dann quasi so den Einser-Eindruck auch nochmal abzurunden.

[2:08] Dann fange ich einfach mal an mit allgemeinen Programmierfragen.

[2:12] Das geht ganz einfach los.

[2:13] Was ist ein Algorithmus?

[2:15] Ein Algorithmus, das ist ein Wort, das viele Programmierer eigentlich täglich verwenden,

[2:19] aber wenn man sie dann fragt, was eigentlich dahinter steckt, dann ist es schwierig.

[2:23] Dann wissen sie eigentlich gar nicht, wie man es so richtig definieren soll.

[2:25] Und ich habe eine relativ einfache Definition für einen Algorithmus,

[2:28] nämlich eine Beschreibung zur Lösung eines Problems.

[2:31] Punkt. Das würde mir schon reichen.

[2:34] Man kann auch dazu sagen, dass diese Problemlösungsbeschreibung ein definiertes Endergebnis haben sollte

[2:40] und wenn möglich auch wiederholbar sein sollte.

[2:43] Und als Beispiel dafür nehme ich immer gerne ein Kochrezept oder ein Backrezept.

[2:48] Nimm Eier, nimm Mehl, mische beides in einer Schüssel,

[2:54] dann verstreiche das auf dem Backblech, packe es für 30 Minuten in den Ofen, fertig ist der Kuchen.

[3:00] Das ist etwas, was ich wiederholt anwenden kann, wo explizit drin beschrieben ist,

[3:04] was ich tun muss, um einen Kuchen zum Beispiel zu erhalten.

[3:07] Und nichts anderes ist auch ein Algorithmus, den wir mit einer Programmiersprache umsetzen,

[3:12] nur dass wir da meistens etwas abstraktere Probleme lösen und nicht vielleicht einen Kuchen backen,

[3:16] sondern zum Beispiel eine Liste sortieren.

[3:19] Sortieralgorithmen, das kennen bestimmt die meisten, da gibt es eine ganze Stange von.

[3:22] Und alle haben eigentlich nur ein Ziel, nämlich eine Liste, die vorher optional unsortiert war, zu sortieren.

[3:29] Und das kann man in einer endlichen Anzahl Schritte tun.

[3:35] Man kann beschreiben, was man tun muss, um diese Liste zu sortieren.

[3:38] Dann will ich jetzt nicht alle durchgehen, die verschiedenen Algorithmen, die es da gibt,

[3:41] aber letztlich ist es einfach nur eine Beschreibung, wie ich aus einer Liste eine sortierte Liste mache.

[3:45] Und dafür kann ich verschiedene Bausteine benutzen, die eigentlich alle Algorithmen gemeinsam haben.

[3:52] Und diese drei Bausteine, das wäre jetzt nämlich meine nächste Frage,

[3:56] was sind denn die drei grundlegenden Bausteine von Algorithmen?

[3:59] Und das ist auch recht einfach. Es gibt die Sequenz, die Verzweigung und die Wiederholung.

[4:05] Oder auf Englisch Sequence, Branching und Looping oder Repetition.

[4:10] Sequenz ist so ziemlich das Einfachste, was wir uns vorstellen können.

[4:13] Es ist nämlich einfach eine Reihenfolge von Befehlen, die nacheinander abgearbeitet werden.

[4:17] Das ist also eigentlich alles, was ich in meiner Programmiersprache aufschreibe, was hintereinander passiert.

[4:22] Das ist eigentlich schon eine Sequenz.

[4:24] Zum Beispiel sowas wie in Java jetzt System.out.println Hello, System.out.println World.

[4:30] Die beiden Sachen werden hintereinander ausgeführt und das führt dazu, dass zwei Zeilen auf der Konsole ausgegeben werden.

[4:36] Das ist schon eine Sequenz.

[4:38] Wenn wir dann das nächst komplexere Ding uns angucken, die nächst komplexeren Bausteine, ist das die Verzweigung.

[4:44] Da gibt es mindestens mal zwei Alternativen, wie der Code weiterlaufen kann.

[4:48] Zum Beispiel, ganz klassisch, die IF-Anweisung, die eine Prüfung macht und dann entweder etwas ausführt

[4:55] oder wenn die Prüfung nicht zutrifft, etwas anderes ausführt.

[4:58] Also eine Verzweigung.

[5:00] Eine andere Form der Verzweigung wäre das Switch-Statement, wo ich auch eine mehrfache Verzweigung haben kann, nicht nur zwei Richtungen.

[5:07] Aber die IF-Anweisung ist schon das Einfachste, was man hier als Beispiel anführen kann.

[5:11] Und dann haben wir zuletzt die Wiederholung oder auch, wie gesagt, auf English Repetition oder Looping.

[5:17] Und Loop, das geht schon in die richtige Richtung.

[5:19] Es geht nämlich um Schleifen.

[5:21] Also wie kann ich Anweisungen wiederholt durchführen?

[5:24] Und dafür gibt es halt verschiedene Arten von Schleifen, die wir uns gleich auch nochmal im Detail anhören.

[5:29] Aber das sind so die drei grundlegenden Bausteine für Algorithmen.

[5:32] Und mit diesen Bausteinen kann ich eigentlich jeden Algorithmus, den man sich vorstellen kann, abbilden.

[5:37] Ich brauche also nicht zwangsläufig eine objektorientierte Sprache oder eine funktionale Sprache.

[5:42] Es reicht, wenn meine Premiere-Sprache diese drei grundsätzlichen Dinge abbildet.

[5:46] Und damit könnte ich jeden Algorithmus, den ich mir vorstellen kann, erstmal schon mal lösen.

[5:51] Jetzt kann man im Anschluss an diese Frage direkt mal bei der Wiederholung noch tiefer eintauchen.

[5:56] Und dann würde ich fragen, welche zwei grundlegenden Formen von Schleifen es denn eigentlich gibt.

[6:01] Und da ist die Antwort. Es gibt zwei, nämlich die kopfgesteuerte oder die abweisende Schleife und die fußgesteuerte oder akzeptierende Schleife.

[6:11] Was ist da der Unterschied? Die fußgesteuerte Schleife wird mindestens einmal durchlaufen.

[6:17] Das ist es schon. Die kopfgesteuerte könnte also, deswegen auch abweisend genannt, in ihrer Bedingung dazu führen, dass sie nicht ein einziges Mal durchlaufen wird,

[6:26] weil die Bedingung schon vor dem Betreten der Schleife geprüft wird und eventuell schon falsch sein könnte.

[6:32] Und wenn ich eine fußgesteuerte Schleife habe, wird die Bedingung erst am Ende der Schleife geprüft, nachdem sie eben mindestens einmal durchlaufen ist.

[6:39] Wenn ich jetzt so in häufigen Promiersprachen wie Java zum Beispiel schaue, dann ist die kopfgesteuerte Schleife meistens die While-Schleife und die fußgesteuerte die Do-While-Schleife, wo eben erst am Ende geprüft wird.

[6:53] Es gibt aber auch noch andere Formen von Schleifen, wobei sie sich alle runterbrechen lassen auf Kopf- oder Fußgesteuert.

[7:00] Aber zwei prominente Beispiele, die man auch nochmal nachfragen könnte, wären dann zum Beispiel die Zählerschleife.

[7:06] Das ist die allseits beliebte Vor-Schleife, was aber nichts anderes ist als eine Vereinfachung oder eine schönere Syntax für eine While-Schleife.

[7:15] Man kann jede Vor-Schleife in eine While-Schleife überführen und umgekehrt.

[7:19] Und es gibt auch noch die For-Each-Schleife, was so ein bisschen so ein Konstrukt ist, um durch ein Array zu laufen.

[7:25] Im Prinzip die Vereinfachung einer Vor-Schleife, die durch ein Array läuft, also auch eine kopfgesteuerte Schleife.

[7:32] Die Zählerschleife nennt man eben auch gerne so, weil deren Ansatz es hauptsächlich ist, eben mit einem Zähler zu arbeiten.

[7:39] Und in einer While-Schleife müsste ich diesen Zähler eben vor der Schleife definieren und dann hochzählen und hin und her.

[7:44] Und weil ich das vergessen könnte, gibt es halt eine kompaktere Syntax.

[7:47] Das ist die Vor-Schleife, wo dann eben drin definiert wird, der Zähler wird deklariert, er wird initialisiert und er wird definitiv auch am Ende der Schleife hochgezählt.

[7:56] Und ich kann dort also etwas weniger Fehler einbauen, als wenn ich eben eine While-Schleife benutze und das damit selber nachbaue.

[8:03] Dann kommen wir doch als nächstes zu einer weiteren Liste, die aus drei Teilen besteht, nämlich den drei grundlegenden Datenstrukturen, die es in der Poemierung gibt.

[8:13] Und da kann man einfach sagen, es gibt einmal die Variable, es gibt ein Array und es gibt ein Struct oder Objekt oder Record oder wie auch immer man das nennen will und in welcher Sprache man sich bewegt.

[8:24] Ich sage jetzt einfach mal Objekt, weil wir uns ja meistens in objektorientierten Sprachen bewegen.

[8:29] Was haben jetzt diese drei Datenstrukturen gemeinsam bzw. wo ist der Unterschied?

[8:33] Also eine Variable, das ist ein Wert, der einen Datentyp hat.

[8:38] Zum Beispiel String, Test. Ein Wert, ein Datentyp.

[8:42] Ein Array ist quasi das nächstgrößere, da habe ich einen Datentyp, aber mehrere Werte.

[8:48] Zum Beispiel ein String Array, da habe ich halt mehrere Strings drin, aber eben nur Strings und nicht noch ein Int oder sowas dabei.

[8:55] Und wenn ich jetzt noch einen Schritt weiter gehe, dann habe ich mehrere Werte und auch noch mehrere Datentypen.

[9:00] Und dann bin ich bei einem Objekt, wo ich mir frei definieren kann, welche Instanzvariablen dieses Objekt hat, welchen Typ die haben und wie viele es davon gibt.

[9:09] Und die können auch alle unterschiedliche Typen haben.

[9:11] Das heißt, so würde ich mir das auch merken.

[9:13] Ein Typ, ein Wert ist die Variable, ein Typ, mehrere Werte ist das Array und mehrere Typen, mehrere Werte ist dann eben das Objekt.

[9:23] Dann können wir bei diesem Zusammenhang noch eine weitere Frage klären, nämlich was ist der Unterschied zwischen Call by Value und Call by Reference?

[9:33] By Value bedeutet, dass beim Aufruf zum Beispiel einer Funktion, die einen Parameter bekommt, der Wert, der in diesem Parameter steht, in eine neue Variable quasi überführt wird und nur innerhalb dieser Funktion dann zur Verfügung steht.

[9:48] Wenn ich innerhalb der Funktion diesen Wert dann ändere, dann hat das keine Auswirkung auf den Aufrufer.

[9:54] Das heißt, wenn der Aufrufer eine Variable in die Funktion reingibt, dann ist die Variable nach dem Aufruf nicht verändert.

[10:02] Wenn ich das haben will, wenn ich also eine Funktion aufrufe, ihr eine Variable reingebe, die Funktion soll die Variable ändern und auch bei mir, beim Aufrufer, ist nachher der Wert dieser Variablen verändert, dann muss ich den Call by Reference benutzen.

[10:15] Und jetzt ist es in vielen aktuellen PoE-Mir-Sprachen so, dass der Standard erstmal By Value ist, aber wenn ich mit Objektreferenzen arbeite, wird, wie der Name schon sagt, eine Referenz übergeben.

[10:28] Also wenn ich eine Methode habe, die einen Int als Parameter bekommt, dann ist der Aufruf definitiv By Value.

[10:35] Wenn ich aber eine Methode aufrufe, die ein Objekt als Parameter bekommt, dann ist der Aufruf eigentlich auch By Value.

[10:45] Das heißt, ich kann die Referenz auf das Objekt nicht einfach auf ein anderes Objekt setzen.

[10:50] Aber wenn ich ein Objekt hereinbekomme in eine Methode, kann ich sehr wohl die Eigenschaften dieses Objektes verändern und das hat natürlich auch eine Auswirkung auf den Aufrufer.

[11:00] Das heißt, die Werte des Objekts sind beim Aufrufer nachher tatsächlich auch verändert.

[11:04] Das könnte also ein Call by Reference sein, wobei im technischen Detail es eben doch kein Call by Reference ist, weil nur eben die Eigenschaften des Objekts verändert werden können.

[11:14] Die Referenz selbst, die ich übergebe, die kann ich nicht verändern.

[11:18] Als Beispiel, was würde das heißen?

[11:20] Ich würde eine Methode haben, wo ich ein Objekt erwarte und ich setze dann in der Methode diese Objektreferenz auf New irgendwas.

[11:29] Das heißt, ich erzeuge ein neues Objekt und weise dieses neue Objekt dem alten zu.

[11:34] Das hätte dann keine Auswirkung auf den Aufrufer, denn die Referenz beim Aufrufer zeigt weiterhin auf das alte Objekt.

[11:41] Das heißt, diese Referenz selbst, die kann ich nicht verändern, aber wohl das Objekt, was hinter der Referenz sich verbirgt.

[11:47] Das heißt, die Eigenschaften dieses Objekts werden dann beim Aufrufer eben geändert sein.

[11:52] So, dann kommen wir noch zu einem ganz anderen Thema, nämlich der Rekursion.

[11:58] Auch das ist eigentlich programmiersprachlich unabhängig.

[12:00] Ich kann rekursiv oder das Gegenteil dazu wäre die Iteration, also iterativ programmieren.

[12:06] Und was ist jetzt Rekursion?

[12:08] Ich beschreibe es am besten mit einem Beispiel.

[12:10] Eine Funktion, die sich selbst aufruft, die ist rekursiv.

[12:14] Also, das bedeutet, ich habe ein Stückchen Programmcode, was irgendwo in seinem Ablauf sich selbst noch einmal aufruft.

[12:21] Was ist da jetzt Vor- und Nachteil bei der Rekursion?

[12:24] Der Vorteil ist, dass man bestimmte Algorithmen sehr schön rekursiv lösen kann, weil sie zum Beispiel mathematisch auch rekursiv definiert sind.

[12:33] Das schönste Beispiel, was ich auch immer in meine Einführungsveranstaltung nehme, ist die Fakultät.

[12:37] Die Fakultät, zum Beispiel so etwas wie 5 Fakultät, geschrieben, 5 Ausrufezeichen.

[12:43] Das bedeutet ja, dass ich das Produkt von 5 und allen Zahlen, die kleiner sind als 5, bis zu 1 ermittle.

[12:52] Also, bei 5 Fakultät habe ich 5 mal 4 mal 3 mal 2 mal 1.

[12:55] Wobei ich mir das mal 1 eigentlich sparen kann, weil das ja das Produkt nicht mehr verändert.

[12:58] Aber wie ist das jetzt mathematisch definiert?

[13:01] Ich kann sagen, die Fakultät von 1 ist 1 und die Fakultät von n ist n mal Fakultät von n-1.

[13:10] Und hier kommt genau der rekursive Aufruf.

[13:12] Die Fakultät wird definiert als n mal die Fakultät von n-1.

[13:18] Der Vorteil ist also, ich habe eine sehr kurze Funktionsdefinition.

[13:22] Das sind teilweise nur ein ganz paar Zeilen.

[13:24] Und diese Definition ist sehr nah an der mathematischen Definition.

[13:27] Man kann quasi die mathematische Formelschreibweise für solche rekursiven Definitionen 1 zu 1 in Code übersetzen

[13:34] und sieht, ach Mensch, das passt, das ist korrekt.

[13:36] Der Nachteil dabei ist, dass die meisten Programmiersprachen, die wir so benutzen, C Sharp, Java und so weiter,

[13:42] nicht dafür optimiert sind, rekursiv zu arbeiten.

[13:45] Das heißt, bei jedem Aufruf einer rekursiven Funktion kann es sein, dass der Stack am Ende überläuft.

[13:52] Der Stack, wer das nicht mehr so genau weiß, das ist ja der Speicherbereich, in dem die Funktionszeiger abgelegt werden,

[13:59] wodurch die Programmiersprache weiß, wenn sie eine Funktion abgearbeitet hat, wohin sie zurückspringen muss.

[14:04] Und wenn wir jetzt eine rekursive Funktion aufrufen, die sich immer wieder selber aufruft,

[14:09] dann wird bei jedem dieser Aufrufe ein weiterer Zeiger auf den Stack gelegt.

[14:14] Und wenn diese Rekursion jetzt sehr, sehr lange dauert, also sehr viele rekursive Aufrufe stattfinden,

[14:19] dann läuft dieser Stack irgendwann über und dann macht die Programmiersprache die Grätsche im Prinzip.

[14:25] Das passiert relativ schnell. Man könnte jetzt meinen, so ein paar tausend Aufrufe müssten da eigentlich möglich sein.

[14:30] Ist aber nicht der Fall. Kann man einfach mal ausprobieren.

[14:33] Das geht relativ fix, dass es dann so ein Stack-Overflow-Error gibt und die Programmiersprache die Grätsche macht.

[14:39] Es gibt einige Programmiersprachen, einige modernere Sprachen, die auf solche rekursive Aufrufe optimiert sind.

[14:45] Das nennt man auch Tail-Call-Optimization.

[14:48] Dort wird die Rekursion überführt durch den Compiler in eine Iteration.

[14:52] Das heißt, wir haben diesen Nachteil der Stack-Overflows nicht mehr.

[14:57] Und das ist jetzt auch gleich eine Anschlussfrage, die ich dann stellen würde.

[15:00] Muss man denn Rekursion einsetzen für diese tollen Probleme, die sich doch so schön rekursiv lösen lassen?

[15:06] Die Antwort ist nein. Man kann jede Rekursion durch eine Iteration ersetzen.

[15:11] Und dieser iterative Code hat dann eben Vor- oder Nachteile.

[15:15] Je nachdem wie man sieht, der Vorteil wäre eben, dass der Stack dort nicht überlaufen kann.

[15:19] Und Programmiersprachen, die diese Tail-Call-Optimization unterstützen oder eingebaut haben,

[15:24] da sorgt halt der Compiler dafür, dass schon direkt beim Kompilieren aus der Rekursion eine Iteration gemacht wird.

[15:30] Das heißt, er überführt dann diese Rekursion in, ich sag jetzt einfach mal ganz platt, eine Schleife, die da durchläuft.

[15:37] Gut, damit wären wir mit dem ersten Teil durch. Allgemeine Programmierfragen, die mir so eingefallen sind.

[15:42] Kommen wir zum nächsten. Hier geht es jetzt um den Bereich der Eigenschaften von Programmiersprachen.

[15:47] Und da fangen wir mal ganz unten an, nämlich mit Begriffen, die wir eigentlich tagtäglich benutzen,

[15:51] die man aber auch vielleicht mal definieren können müsste.

[15:53] Nämlich, was ist denn z.B. Source-Code, Byte-Code und Maschinen-Code?

[15:58] Der Source-Code wird im Deutschen auch gerne als Quell-Text oder als Quell-Code oder Source-Text,

[16:03] habe ich es noch nicht gehört, aber es gibt da bestimmte Formulierungsabweichungen.

[16:07] Das ist aber alles immer das Gleiche, was da gemeint ist. Ich spreche jetzt hier von Source-Code.

[16:11] Und Source-Code ist das, was der Mensch schreibt, ist also das, was der Programmierer erzeugt tatsächlich.

[16:17] Das ist die High-Level-Sprache, sowas wie vor, Klammer auf und so weiter.

[16:22] Das muss der Mensch verstehen und kann der Mensch auch verstehen.

[16:25] Das ist der Quell-Text.

[16:27] Der Quell-Text wird dann normalerweise übersetzt in Maschinen-Code.

[16:31] Das ist die Sprache, die der Computer versteht, also auf Deutsch gesagt 001, ein Binär-Code.

[16:36] Das ist das, was der Computer direkt ausführen kann.

[16:39] Dann packt er in seine CPU und dann läuft das durch und dann macht er da irgendwas.

[16:42] Das ist für Menschen relativ schwer zu lesen. Nicht nur relativ, es ist wirklich sehr schwer zu lesen.

[16:47] In den Anfangszeiten der Programmierung, da ging es nicht anders, da musste man als Programmierer Maschinen-Code schreiben.

[16:52] Aber aus diesen Zeiten sind wir eigentlich raus.

[16:55] Wir können mit sehr abstraktem Source-Code programmieren und der wird dann übersetzt in diesen Maschinen-Code.

[17:01] In einigen populären Sprachen kommt aber noch so ein Ding dazwischen, das ist der sogenannte Byte-Code.

[17:06] Zumindest in Java heißt der Byte-Code und das ist sowas dazwischen.

[17:10] Das ist teilweise noch durch Menschen lesbar, aber auch nicht so richtig.

[17:15] Da sind auch schon so steuernde Anweisungen drin.

[17:18] Das ist also so ein Mischmasch aus beidem und der Vorteil dabei ist, dass dieser Code auf einer virtuellen Maschine,

[17:24] zum Beispiel auf der JVM bei Java, eben ausgeführt werden kann und dadurch plattformunabhängig ist.

[17:30] Der Maschinen-Code hat den Nachteil, dass er nur auf einer Maschine läuft, für die er kompiliert wurde.

[17:35] Also zum Beispiel für, ich weiß es nicht, Intel-CPUs unter Windows.

[17:39] Und wenn ich diesen Maschinen-Code habe, dann kann ich den eben leider nicht auf einer AMD-CPU unter Linux laufen lassen.

[17:45] Und das ist bei diesem Byte-Code anders.

[17:47] Das braucht zur Ausführung eben die virtuelle Maschine, die da drunter liegt.

[17:52] Und wenn ich diese virtuelle Maschine auf Linux oder Windows oder Mac oder wo auch immer installiere,

[17:57] dann ist dieser Byte-Code dort lauffähig und ich muss ihn nicht mehrfach übersetzen.

[18:03] Ja, dann komme ich gleich zur nächsten Frage. Wie komme ich denn jetzt überhaupt zu meinem Maschinencode? Wer macht denn das? Und die Antwort ist, das macht der

[18:08] Compiler. Und da gibt es klassischerweise

[18:10] Compiler und Interpreter, nach denen man immer gern mal fragen kann, was ist denn da der Unterschied und wer macht was? Der Compiler ist im Prinzip, wenn ich das

[18:18] übersetze, einfach ein

[18:19] Übersetzer und der übersetzt Quelltext in entweder Byte- oder Maschinencode, je nachdem, welche Sprache wir haben.

[18:26] Klassischerweise eben in Maschinencode. Das heißt, wir schmeißen dort unseren Source-Code rein und wir kriegen

[18:31] Maschinencode raus. Das macht der Compiler. Dieser Maschinencode ist dann direkt auf dem Computer ausführbar.

[18:38] Der Interpreter, der macht ein bisschen was anderes, der übersetzt nichts, sondern der liest den Quelltext einfach ein und führt ihn direkt aus.

[18:46] Das ist häufig so bei Skriptsprachen, wie zum Beispiel PHP oder Ruby. Da läuft der Interpreter über den Source-Code und

[18:53] macht daraus eine Folge von Anweisungen und übersetzt die quasi zur Laufzeit so, dass die Maschine, auf der er läuft,

[19:00] diese Befehle ausführen kann. Dort gibt es also nicht ein Endergebnis, wie beim Compiler, das

[19:06] Kompilat, wo also wirklich der Maschinencode drin ist, sondern der Interpreter, der erzeugt nichts, der geht einfach über den Code und führt ihn dann aus.

[19:15] Wichtige Eigenschaft von PoEM-Sprachen ist immer die Unterscheidung zwischen statischer und dynamischer

[19:20] Typisierung. Was ist was? Die statische Typisierung, da haben wir die Information über die

[19:27] Datentypen meiner Variablen zum Beispiel bereits zur Compile-Zeit. Das heißt, der Compiler kann schon prüfen,

[19:34] ob ich zum Beispiel einen Typfehler gemacht habe, weil ich meinetwegen eine Zahl einer String-Variable zuweisen will oder noch schlimmer umgekehrt.

[19:42] Das meckert mein Compiler schon an und sagt, Moment mal, hier, da passen die Typen nicht zusammen, sieh mal zu, dass du das gerade ziehst.

[19:49] Und bei der dynamischen Typisierung, da prüft der Compiler nichts, beziehungsweise häufig werden die dynamischen PoEM-Sprachen

[19:56] auch nicht kompiliert, sondern die werden interpretiert.

[19:58] Und da gibt es in dem Sinne keine Compile-Zeit, wenn man so will. Da gibt es also niemanden, der diese

[20:04] Typisierung prüft. Da wird erst zur Laufzeit geprüft, ob die Sachen denn passen, die wir da machen. Also

[20:09] wenn wir dann irgendwie eine Zahl in einen String reinschieben, dann

[20:14] erkennt der Compiler das nicht, weil es den vielleicht auch gar nicht gibt, sondern das stelle ich dann erst fest, wenn das Programm

[20:19] ausgeführt wird, dann gibt es halt einen Laufzeitfehler und erst dann merke ich, oh, da habe ich einen Fehler eingebaut.

[20:24] Hat beides so ein bisschen Vor- und Nachteile. Die Vorteile von statischer Typisierung sind eben, dass ganz viele

[20:30] Fehler mir schon quasi vorweggenommen werden. Der Compiler sagt mir, hier hast du einen Fehler gemacht, guck dir das an.

[20:35] Dafür bin ich aber etwas eingeschränkt bei meiner Programmierung. Ich muss teilweise bei bestimmten Problemen sehr

[20:43] mit diesem Typsystem kämpfen, sagt man auch mal gerne. Und das ist bei dynamischen Sprachen nicht so. Da probiere ich das einfach mal aus und lass

[20:50] das laufen und dann funktioniert das und ich muss mich nicht an diesen Typen so festklammern.

[20:54] Es gibt aber zahlreiche Studien, die auch zeigen, dass bei großen Software-Systemen die statische Typisierung immer noch die Nase vorn hat.

[21:03] Denn für Menschen ist es sehr schwierig, diese ganzen Probleme, die eventuell bei der Laufzeit auftreten, im Kopf zu haben und der Compiler nimmt

[21:11] uns wenigstens diese Typ-Probleme wirklich ab, denn der weist uns explizit darauf hin, hier ist ein Problem, das musst du dir angucken.

[21:17] Und das gibt es bei der dynamischen Typisierung eben in dieser Form nicht. Deswegen ist es für große Software-Systeme so, dass sich gezeigt hat,

[21:25] dass dieser Compiler, der eben viele Fehler vorher findet, dazu führt, dass wir eine höhere Software-Qualität haben und die Poemierer auch besser mit der Software

[21:33] arbeiten können, als wenn wir in einer dynamischen Poemiersprache arbeiten würden.

[21:37] Im Zusammenhang mit der Typisierung gibt es jetzt noch zwei weitere Begriffe, die man mal abgrenzen können müsste, und zwar die starke und die schwache

[21:45] Typisierung. Das ist nicht dasselbe wie die statische und dynamische Typisierung. Das bringen die Leute gerne mal so ein bisschen durcheinander

[21:51] und sagen dann auch stark und statisch, das ist das gleiche, aber das ist nicht der Fall. Zur Wiederholung noch mal, die statische Typisierung

[21:59] bedeutet, dass die Datentypen bereits zur Compile-Zeit feststehen. Die starke Typisierung bedeutet, dass keine implizite

[22:07] Typumwandlung erlaubt ist in meiner Poemiersprache. Was bedeutet das? Schauen wir uns ein Beispiel an, wo

[22:12] keine starke Typisierung vorliegt, zum Beispiel PHP. In PHP kann ich aus int-Variablen

[22:19] implizit boolsche Variablen machen. Ich kann dort zum Beispiel sowas schreiben wie if 1

[22:25] und dann schreibe ich meine If-Anweisung. Und das würde bedeuten, dass PHP hergeht und diese 1

[22:31] umwandelt in einen boolschen Wert. Und in PHP ist es jetzt so, dass einfach jede int-Zahl, die nicht 0 ist, auf true

[22:40] umgewandelt wird und 0 wird auf false umgewandelt.

[22:43] Diese implizite Typumwandlung aus zwei Typen, die eigentlich nichts miteinander zu tun haben, nämlich int und bool,

[22:49] das ist ein Merkmal von schwacher Typisierung.

[22:53] Da gibt es einige Poemiersprachen, PHP ist ein Beispiel. PHP ist dynamisch typisiert und

[22:59] schwach typisiert. Es gibt aber auch dynamische Poemiersprachen, die stark typisiert sind, wie zum Beispiel Ruby. Ruby ist dynamisch typisiert, ich muss keine Datentypen angeben,

[23:07] aber wenn ich zur Laufzeit sowas mache wie if 1, dann wird die Laufzeitumgebung sehr schnell sagen, Moment mal, was hast du denn hier vor?

[23:15] Eine Zahl, ein int, das ist kein boolscher Wert, das funktioniert schon mal gar nicht. Das heißt, eine starke Typisierung steht dahinter.

[23:22] Also, man kann diese

[23:24] Merkmale statisch und dynamisch und stark und schwach miteinander kombinieren und dann kann man für jede dieser

[23:30] Kombinationsmöglichkeiten, die vier, die es da gibt, kann man dann Poemiersprachen finden, die diese Kombination

[23:37] umsetzen, sage ich mal. Die häufig anzutreffende Kombination ist statisch und stark. Das wären so Klassiker, Java, C-Sharp.

[23:45] Da muss ich zur Compilezeit festlegen, welche Datentypen meine Variablen haben und ich kann auch nicht zur Laufzeit einfach mal sowas machen wie

[23:52] Wandel mal den int in bool um. Das passiert da nicht. Das heißt, das sind sicherlich die

[23:56] verbreiteten Poemiersprachen, die man auch in Abschlussprüfungen häufig sieht. Auf der anderen Seite haben wir aber

[24:01] Poemiersprachen wie PHP, die eben genau das Gegenteil sind. Die sind dynamisch typisiert und lassen eine implizite Typierung zu, sind also schwach

[24:08] typisiert. Aber es gibt auch noch die anderen beiden

[24:11] Schnittpunkte. Eine habe ich gerade gesagt. Ich habe eine dynamische Typisierung, aber stark. Das wäre Ruby. Oder ich habe eine statische

[24:18] Typisierung, aber trotzdem eine schwache

[24:21] Typisierung. Das Beispiel wäre C. Da kann ich auch meine Variablen zur Compilezeit, oder muss sie sogar, mit einem Typen versehen.

[24:27] Ich kann aber sehr wohl zur Laufzeit das einfach auf irgendeinen anderen Datentyp

[24:32] ummünzen und das heißt, ich habe dort auch eine schwache Typisierung drin.

[24:37] Die letzte Frage zu diesem

[24:39] Bereich der Eigenschaften von Poemiersprachen wäre dann, was ist ein Cast? Das lässt sich dann ganz gut mit dieser Typisierung

[24:46] eben erklären, denn ein Cast ist eine explizite Typumwandlung. In statisch typisierten

[24:52] Programmiersprachen kann ich eben nicht sowas machen, wie den einen Datentyp dem anderen zuweisen. Das geht eben nicht. Aber ich kann

[24:59] quasi die Poemiersprache dazu zwingen, das zu tun, indem ich den Cast Operator benutze. In Java sind das zum Beispiel einfach die

[25:06] ganz normalen runden Klammern. Da kann ich also zum Beispiel sowas sagen wie

[25:10] Double A gleich 123,5 und dann mache ich mein Int B gleich in Klammern

[25:18] Int A.

[25:20] Das heißt, ich forciere den Cast, die explizite Typumwandlung von Double nach Int, indem ich der Poemiersprache sage,

[25:28] ich weiß, es gibt hier ein Problem. Das sind nicht dieselben Datentypen, aber ich will, dass du die

[25:34] umwandelst, dass du die castest, indem eben dieser Cast Operator benutzt wird.

[25:41] So, ich schaue mal auf die Uhr und sehe, dass ich schon fast eine halbe Stunde voll habe. Deswegen

[25:46] mache ich hier an der Stelle mal Schluss und verschiebe die Beantwortung der noch übrigen Fragen mal auf die nächste Episode.

[25:54] Die Shownotes zu dieser Episode findet ihr wie gewohnt unter

[25:58] anwendungsentwicklerpodcast.de

[26:01] slash 12 für die zwölfte Episode.

[26:03] Ich würde mich freuen, wenn ihr mir Feedback gebt oder mich weiter empfehlt. Am liebsten wäre mir ein Review bei iTunes, wenn ihr

[26:11] euch die Minute eben Zeit nehmen würdet und mir dort ein ehrliches Review hinterlasst. Das würde mich sehr freuen.

[26:16] Das trägt dazu bei, dass dieser Podcast noch etwas bekannter wird und ich vielleicht noch mehr

[26:21] Prüflinge auf dem Weg zur Abschlussprüfung helfen kann.

[26:26] Ihr könnt mir auch gerne Fragen stellen. Wenn ihr irgendetwas wissen wollt rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung,

[26:32] dann schreibt mir gerne eine Mail unter mail at anwendungsentwicklerpodcast.de

[26:38] oder nutzt das Kontaktformular auf der Website.

[26:42] Und wenn ihr ganz viel Lust habt, dann könnt ihr euch auch für mein Newsletter anmelden unter anwendungsentwicklerpodcast.de

[26:49] slash Newsletter. Da bekommt ihr immer einmal die Woche die neuesten Informationen

[26:52] aus meinem Blog und aus dem Podcast und auch den Link der Woche. Den verschicke ich da immer schon im

[26:59] Voraus. Bevor ich ihn am Freitag veröffentliche, kriegt ihr montags schon den Newsletter.

[27:03] Außerdem bekommt ihr als kleines Dankeschön für die Anmeldung eine oder mehrere Checklisten eigentlich, aber die längste ist sicherlich die für die Projektdokumentation.

[27:11] Aktuell mit über 100 Punkten, die ihr durchgehen könnt, bevor ihr eure Projektdokumentation

[27:17] abgibt. Und die bekommt ihr sofort in eurer E-Mail-Postfach, sobald ihr euch angemeldet habt unter anwendungsentwicklerpodcast.de

[27:25] slash Newsletter. Ich hoffe, ich konnte euch mit dieser Episode ein wenig bei der Vorbereitung auf das Fachgespräch

[27:32] helfen. Ich würde mich, wie gesagt, über euer Feedback freuen.

[27:36] Ansonsten sage ich noch einmal vielen Dank fürs Zuhören und bis zum nächsten Mal.