Programmiersprachen: Was können sie und wann nutze ich sie?
27. Oktober 2016, mit Joel Kaczmarek, Johannes Schaback
Dieses Transkript wurde maschinell erstellt. Wenn dir ein Fehler auffällt, schreib uns gerne zu diesem unter redaktion@digitalkompakt.de.
Joel Kaczmarek: Hallo und herzlich willkommen zu einer neuen Folge Blackbox Tech. Es geht wieder um Technologie und die zu verstehen. Mit mir dabei ist wieder der kompetente, smarte und sympathische Johannes Schaback. Hallo Johannes.
Johannes Schaback: Hallo Joel, grüß dich.
Joel Kaczmarek: So, wie immer, es geht um Technologie. Heute haben wir uns ein ganz spannendes Thema ausgesucht. Was wir eigentlich immer tun, wenn man das mal sagen darf. Ich gucke natürlich so ein bisschen auf so ein Thema als Unternehmer oder versuche das aus so einer Unternehmerbrille zu machen. Sprich, wenn ich mir eine Programmiersprache angucke, geht es so ein bisschen darum zu sagen Welche Programmiersprache ist für mich eigentlich die richtige? Mit Blick auf Faktoren wie, wie viele Mitarbeiter kriege ich zu diesem Thema? Man kriegt das ja mit, manche Programmiersprachen, da stirbt das Personal sogar aus. Bei anderen ist es einfach schwierig und teuer, jemanden zu finden. Also beim Recruiting muss ich mir Fragen zur Programmiersprache stellen. Dann, wie wartbar ist das Ganze, also wie zukunftsfähig ist eine Sprache, die ich anwende und wie technisch performant. Wenn ich die benutze, ist mein Produkt dann hinterher wirklich sehr, sehr schnell, sehr, sehr agil, sehr, sehr interessant, sehr, sehr frisch oder eher nicht. Mobile spielt ja auch viel eine Rolle, kann auch bis irgendwie zu SEO durchschlagen. Also in Google guckt es sich auch an, Ladezeiten von Webseiten. Das ist immer so ein bisschen eine Frage. und natürlich der Faktor Kosten. Also wie viele Leute, was kosten die Leute in dem Bereich, was muss ich sonst an Kosten rechnen etc. pp. Das ist so ein bisschen unser Dach, über den wir uns heute bewegen. Wirst du mit sowas eigentlich oft konfrontiert?
Johannes Schaback: Wenig. Also in der Regel ist es so, dass die Firmen, mit denen wir zusammenarbeiten, diese Entscheidung bereits getroffen haben, in welcher Programmiersprache sie das entwickeln. Manche mischen, manche legen sich sehr eng fest. Eigentlich nicht so häufig. Ja, wirklich.
Joel Kaczmarek: Aber hast du oft den Fall, dass du dann restrukturieren musst, dass du dir dann darauf hinweist, dass es die falsche ist oder eine ungünstige, die sie gewählt haben und es gäbe eine andere, die viel, viel besser und günstiger wäre? oder passiert das nicht so?
Johannes Schaback: Es kommt vor, dass ein Urwald an Sprachen besteht, also insbesondere in Legacy-Systemen, also Systeme, die vor ein paar Jahren gebaut wurden von Leuten, die schon lange nicht mehr Unternehmen sind, dass darauf hingewiesen werden muss, dass eben diese Systeme nicht mehr wartbar sind, dass diese Programmiersprachen, das Wissen zu diesen Programmiersprachen, das Wissen zu diesen Programmen, in denen diese Teile dieses alten Systems programmiert wurden, nicht mehr im Unternehmen besteht und dass entweder der Teil ersetzt werden muss oder vielleicht sogar rausgeschmissen werden kann.
Joel Kaczmarek: Gut, also wir merken, es kann schon Sinn machen, also nach meinem Gefühl, sich da im Vorfeld Gedanken zu machen. Und welche Faktoren dabei eine Rolle spielen, ist das, was wir heute so ein bisschen klären wollen. Erfahrungsgemäß bringt es aber immer relativ viel, ehe man sagt, wie gut eignet sich das, Vorteil, Nachteil, was kann es, was kann es nicht. Wenn man so ein bisschen Basics legt, wenn man so ein bisschen Grundlagen bespricht, was ist das eigentlich, wenn man so ein bisschen versteht. Vielleicht fangen wir mal mit dieser ganz popeligen Frage an. Was genau ist eigentlich eine Programmiersprache?
Johannes Schaback: Eine Programmiersprache kann man sich so ein bisschen vorstellen wie ein Rezept. Also eine Maschine, der Computer ist ja eine Maschine, muss genau und haarklein gesagt bekommen, was er zu tun oder ihm zu lassen hat. Und eine Programmiersprache ist eine Sprache, die der Mensch versteht, aber eben halt auch die Maschine, der Computer. Und um in diesem Bild des Rezepts zu bleiben, kann man sich vorstellen, dass wenn man ein Rezept schreibt, also Drei Eier aufschlagen, in die Pfanne hauen, 60 Grad, zehn Minuten lang brutzeln, dann Öl, Salz, Pfeffer dazugeben. Das sind ja genaue Instruktionen, was man zu tun hat. In dem Fall ist bei einem Rezept natürlich der Mensch die Maschine, nämlich der Koch. Und ganz ähnlich ist es bei Programmiersprachen auch. Zeige Zeichen A an, dann B, dann male ein Dreieck, dann ein Viereck. So sind ohne Programmiersprachen auch. Es gibt im Grunde zwei große Bereiche, in die man Programmiersprachen klassifiziert. Das eine sind diese imperativen Sprachen, die man in Rezeptformen sich vorstellen kann, also eine Anordnung, eine Liste von Instruktionen. Das nennt sich imperativ, weil man im Grunde Befehle gibt der Maschine. Und dann gibt es eine zweite große, große, große Klasse an Programmiersprachen, die nennt sich Definitionen. Deklarativ, das sind Sprachen, die beschreiben nur das Endergebnis. Also um nochmal in diesem Bild des Rezepts oder des Kochens zu bleiben, eine deklarative Sprache würde lediglich den Geschmack des Essens beschreiben. Und wie der Koch dorthin kommt, wie die Maschine dorthin kommt, um zu diesem Ergebnis, ist ihr selber überlassen. Und man würde also schreiben, es soll salzig sein, es soll warm sein, es soll nach Ei schmecken. Und so weiter. Das wäre eine deklarative Programmiersprache. Also gängige Beispiele sind beispielsweise HTML. Also HTML, da beschreibst du ja, wie eine Seite auszusehen hat, aber wie genau das Dreieck, die Vierecke, die Schrift gemalt wird, das überlässt du dann der drunterliegenden Plattform oder dem Browser in dem Fall.
Joel Kaczmarek: Jetzt stellt man sich ja so ein bisschen die Frage, also das ist ja eigentlich was sehr Banales, was ich dich jetzt frage, aber trotzdem, ich habe eigentlich noch nie darüber nachgedacht, fällt mich auch gerade auf, wenn man jetzt sagt, Programmiersprachen sind so ein bisschen ein Esperanto zwischen Menschen und Computern, ja? Also wir versuchen irgendwie eine gemeinsame kommunikative Basis zu schaffen. Warum gibt es dann eigentlich so viele Programmiersprachen?
Johannes Schaback: Genauso, weil es auch so viele Sprachen auf der, also natürliche Sprachen auf der Welt gibt, also zwischen Menschen. Programmiersprachen, das Lustige ist ja, es gibt ja. eigentlich. nur, die Rechner sind ja alle sehr, sehr ähnlich aufgebaut. Die haben eine CPU, eine Central Processing Unit, also das Gehirn. Die haben immer eine Memory, in dem die Sachen abgespeichert werden. Dann gibt es einen Langzeitspeicher, Festplatten, die arbeiten ja alle gleich. Trotzdem gibt es viele unterschiedliche Sprachen, weil die Anforderungen unterschiedlich sind. Also die Probleme, die die Leute lösen wollen, sind unterschiedlich. Gleichzeitig ist es aber auch so, dass eine Sprache immer eine starke, ja, es ist ein bisschen wie Musik, also eine Vorliebe. Es gibt Leute, die haben bestimmte Vorlieben, wie sie etwas ausdrücken möchten oder wie sie dem Rechner Befehle erteilen wollen. Deswegen gibt es einfach sehr unterschiedliche Varianten. Hinzu kommt, dass es auch einfach immer einfacher wird, Programmiersprachen zu entwickeln und sich deswegen auch eine Spezialisierung einstellt. Grundsätzlich sind Programmiersprachen eher darauf ausgelegt, für unterschiedliche Bereiche, also sie wurden einmal geschaffen, um ein spezielles Problem zu lösen, weil man meinte, in einer Programmiersprache x Problem y besser lösen zu können. Und das hat sich durchgesetzt, da wurde es populär, die Leute haben sich daran gewöhnt, die Leute können es, die Leute wollen es sprechen, die Leute träumen in der Sprache idealerweise und wollen dann auch nicht mehr runter. Also ich spreche gerne Deutsch, weil ich es gut kann. Ich spreche auch ganz gerne, aber nicht mehr so gerne Englisch, weil ich es auch noch gut kann, aber mein Französisch ist eine Katastrophe und deswegen fahre ich nicht nach Frankreich und deswegen kenne ich kein Französisch. Und genauso ist es in meinen Programmiersprachen.
Joel Kaczmarek: Ja, das ist ja was, was man sich als Unternehmer mit non-technischem Background immer so ein bisschen fragt. Wenn ich mir einen Techie an Bord hole, der hervorragend in Ruby on Rails ist, der da eine Koryphäe drin ist, kann der dann genauso gut PHP oder Scalar oder R oder Java oder JavaScript? Also gibt es da eine Intersprachenkompetenz, die man per se hat? Wenn man eine Sprache kann, versteht man dann die Basis von anderen Sprachen auch. oder ist das nicht so, wenn man das Vokabular zum Beispiel nicht kennt?
Johannes Schaback: Also es ist in der Tat wirklich so, dass du, wenn du Informatik studierst, dann lernst du eigentlich erstmal primär, wie ein Computer funktioniert, also wie diese ganzen Grundlagen, also das BIOS, Betriebssystem und so weiter funktioniert, auf dem dann Programmiersprachen aufsetzen. Eine Programmiersprache ist schon sehr high level in dem Sinne, dass sie sich immer stärker spezialisiert. Und viele, viele Konzepte und Pattern, die du in Programmiersprachen findest, sind wirklich gleich. Also dass du zum Beispiel Schleifen hast oder dass du Bedingungen programmieren kannst oder dass du bestimmte Ausnahmen werfen musst, wenn ein Fehler auftritt. Also das sind viele Konzepte, die in vielen Sprachen immer wieder auftreten, nur anders benannt sind. Aber es ist eigentlich alter Wein in neuen Schläuchen in dem Sinne. Und das hilft dir natürlich beim Erlernen einer neuen Programmiersprache. Gerade bei imperativen Sprachen, wenn es darum geht, Befehle zu erteilen, ist es häufig so, dass diese Pattern immer wieder auftauchen. Also ein großer Influencer, wenn man so will, war die C-Programmiersprache, die sehr, sehr viele von diesen Konzepten vererbt hat in andere Sprachen, wie beispielsweise Java. Innerhalb der deklarativen Sprache, und jetzt lehne ich mich ein bisschen aus dem Fenster, gibt es auch wiederum viele unterschiedliche Arten, wie beispielsweise SQL, das eben sehr anders ist als HTML. Manche Leute sagen sogar, funktionale Programmiersprachen wären auch eine Art. Also du programmierst nicht nach Befehlen mit funktionalen Programmiersprachen, sondern du baust alles im Grunde mit Funktionen auf. Und es gibt sozusagen kein Stadium, in dem sich ein Programm befindet, so richtig. Die funktionieren dann sehr unterschiedlich und da sind dann die Unterschiede zwischen den Sprachen größer und es erfordert eine längere Lernkurve, um diese Sprachen. In der Regel ist es aber so, wenn du wirklich eine Sprache sehr, sehr, sehr, sehr gut beherrschst, fällt dir der Sprung in die anderen Sprachen leichter als beispielsweise, wenn ich jetzt von Deutsch zu Spanisch springe.
Joel Kaczmarek: Aber wenn du jetzt mal die Technologieperspektive sozusagen widerspiegelst für einen CEO, der darüber nachdenkt, sich einen PHP-Entwickler einzustellen, obwohl er eigentlich einen Ruby-Entwickler braucht. Ist das ein sinnvolles Vorgehen oder nicht? Also macht es Sinn, jemanden einzustellen, der techy ist und eine Programmiersprache beherrscht, man braucht aber eigentlich eine ganz andere. oder ist das irgendwie ein Todesstoß für Motivation, für den gesamten Aufbau?
Johannes Schaback: Das kommt sehr auf den Entwickler an. Wenn der Entwickler das möchte, weil er beispielsweise Programmiersprachen agnostisch ist und sagt, ich lehne ab mich auf eine Programmiersprache festzulegen, sondern ich programmiere grundsätzlich gerne und das unabhängig von der Sprache, weil ich an interessanten Problemen arbeiten möchte, dann ist das natürlich total in Ordnung. Und dann kannst du als Entscheider oder in dem Fall als CTO schauen, könnte derjenige diesen Switch von der Sprache A zur Sprache B hinbekommen. Vielleicht ist das sogar gerade ein positiver Aspekt, weil er eben diese neue Sprache lernen möchte. Das gibt es auch sehr häufig. Da sollte er sagen, okay, ich komme vielleicht von einem Senior Level in Sprache Ruby, möchte mich aber in Rust weiterentwickeln und bin deswegen bereit, da wieder als Junior einzusteigen. Das gibt es durchaus. Das ist schon entscheidend. Also vielleicht nochmal, warum es möglich ist, zwischen Programmiersprachen hin und her zu springen, gerade in Imperativen, ist, weil die Syntax, also die Wörter dieser Sprache unterschiedlich sind, aber die Semantik, also das, was die Programmiersprachen tun, die einzelnen Befehle tun, dann doch wieder sehr, sehr, sehr ähnlich sind. Also wenn ich letztendlich, wenn es wiederum darum geht, ein Dreieck auf dem Bildschirm zu malen, dann wird ein Dreieck immer über drei Ecken beschrieben und das muss ich halt in jeder Programmiersprache machen. Das heißt vielleicht nicht Ecke, sondern das heißt irgendwie Node oder Corner zwischen unterschiedlichen Programmiersprachen, aber letztendlich muss ich dann doch wieder dasselbe Pattern, den selben Lösungsweg.
Joel Kaczmarek: Ich meine, wo du Semantik sagst, das ist eigentlich ganz witzig. Das erinnert mich an die germanistische Fakultät, an der ich studieren durfte, im schönen Örtchen Greifswald an der Ostsee, am Bodden der Ostsee, um genau zu sein. Weil da gab es ein Beispiel, was ein bisschen eine Brücke schlägt zu diesem Thema. Und zwar meinte mein Germanistik-Professor irgendwann mal, ja, der Duden hält ja fest, was richtig ist in Sachen Rechtschreibung und Grammatik. Dann meint er irgendwann so, naja, aber sagen wir jetzt mal, wenn irgendwie drei Viertel der Bevölkerung, wenn die alle sagen, das ist Joel, ihm sein Fahrrad, wo sich natürlich einem jetzt per se erstmal die Fußnägel nach oben räumen, mir geht das immer so, das ist da aber total verbreitet. Das ist für die ganz normal, wenn man sagt, irgendwie Joel sein Auto. Wenn das sehr, sehr viele Leute benutzen, wenn es sozusagen populärkulturell ist, sollte es dann nicht auch richtig sein aus grammatikalischem Sinne. Und jetzt schlage ich die Brücke zu dem ganzen Thema, was wir gerade haben. Ich saß kürzlich mit dem guten Ronny von, ich glaube, Micropsy hieß seine Firma, in einem KI-Podcast, der zu mir sagte, Programmiersprachen sind Popkultur. Also am Ende des Tages sagt die Verbreitung einer Programmiersprache weniger etwas darüber aus, wie gut sie ist, wie effizient, wie toll, sondern eigentlich nur von wie vielen Leuten sie gemocht wird. Das ist sozusagen so ein bisschen der Gedanke, der mir auch wieder kam, ach ja stimmt, wie mein Germanistik-Professor, der sagte, wenn alle das benutzen, so sollte es dann nicht richtig sein, ist es bei einer Programmiersprache auch so, wenn viele sie benutzen, ist sie relevant und dann sollte man sich fragen, ob man sie nicht auch benutzen sollte. Die Frage, die ich jetzt ein bisschen hinaus möchte, ist, wie verbreiten sich eigentlich Programmiersprachen und kann ich einfach eine erfinden? Du hast ja so ein bisschen gesagt, das ist manchmal problemgetrieben. Wie sieht sowas aus?
Johannes Schaback: Früher, als Rechner wirklich noch sehr wenig standardisiert waren, als es kaum, also wirklich in den 70ern, in den 60ern, als es kaum Betriebssysteme gab, war das wirklich so, dass Programmiersprachen sehr, sehr problemorientiert entwickelt wurden. Diese Sprachen wurden damals ja auch absolut nicht mit den noch sehr, sehr komfortablen heutigen Sprachen umgesetzt. und dem dazu existierenden Toolset, um diese Programmiersprachen zu entwickeln, zu vergleichen. Es ist heutzutage total einfach, Programmiersprachen zu entwickeln. Aber klar, es stimmt schon, die allermeisten Programme, die ich heutzutage benutze, könnte ich in einer x-beliebigen Programmiersprache schreiben. Das ist wirklich in den allermeisten Fällen so. Es ist aber natürlich trotzdem so, dass jetzt für Web-Entwicklung sich Ruby on Rails sehr stark durchgesetzt hat. Nichtsdestotrotz gibt es immer noch Leute, die sagen, ja, ich schwöre auf eine Java-Umgebung, also eine andere Sprache. Aber du hast total recht, es ist letztendlich Popkultur, es ist wie Musik. Die Leute hören es gerne. Man möchte auch vielleicht mal neue Sachen ausprobieren, aber ist es sehr stark Präferenzen getrieben. Und weil ich eben in meinen letzten fünf Arbeitsjahren eben in Ruby on Rails programmiert habe und da einfach sehr gut bin, wurden da Tools entwickelt und Bibliotheken entwickelt und Werkzeuge entwickelt, die es mir ermöglichen, noch produktiver zu sein in der Zukunft. Und ich kenne das eben auch, ich habe da Erfahrungen in den letzten fünf Jahren und bin entsprechend dann eben auch weiterhin viel produktiver in dieser Sprache Ruby on Rails. Wenn du jetzt beispielsweise schaust, wenn du jetzt ein Logiksystem programmieren müsstest, also weil du wirklich ein Reasoning bauen möchtest oder weil du ein Atomkraftwerk programmieren möchtest oder ein Flugzeug, Autopiloten, dann kommst du plötzlich in Bereiche, in denen es nicht mehr nur um persönliche Präferenzen geht, sondern in diesem Bereich musst du da sehr stark darauf achten, dass du Code schreibst, der 100 Prozent korrekt ist, der keine Bugs hat, der mathematisch bewiesen werden kann. Und dann bekommst du Bereiche, in denen die Anforderung doch durchaus die Sprache diktiert. Früher, also in den early days of mobile war es eben so, dass du eben Android hattest, das war in Java programmiert, C und Java. Du hattest Apple, du kamst eben um Objective-C nicht rum und musstest eben auch in diesen Sprachen programmieren, Präferenzen hin oder her. Aber mittlerweile ist es in der Tat so, durch unterschiedliche Compiler-Backends, aber auch durch Interpreter und durch Cross-Compiler kannst du eigentlich fast jede deiner präferierten Sprachen auf jede Plattform bringen.
Joel Kaczmarek: Ich meine, man darf ja auch mal dazu sagen, das Ganze hat ja, was ich aus der Ferne als Non-Techie so mitkriege, so ein bisschen den Touch sogar teilweise von so einem Religionskrieg. Das heißt, an dieser Stelle sei mal erwähnt, wenn wir irgendetwas als besonders gut oder besonders schlecht thematisieren, nicht, dass wir in den Kommentaren gesteinigt werden. Das passiert gar nicht aus böser Absicht, aber das ist ja auch ein ganz spannender Umstand, dass das irgendwie so eine gewisse Emotionalisierung oder Emotionalität hat. Jetzt lass uns mal einen Satz sagen zu einem Begriff, den du eben schon eingestreut hast, wie selbstverständlich, der aber, glaube ich, auch noch eine Rolle spielt, das ganze Thema Bibliotheken. Du hast gesagt, das Thema Bibliothek kann eine Rolle spielen. Ich erinnere mich noch, wenn ich irgendwie immer Informatik hatte, ich habe mich dann manchmal gefragt, wo ich dachte so, fuck, warum muss ich jetzt eigentlich hier irgendwie den Scheiß nochmal programmieren? Ich bin bestimmt nicht der Erste, der irgendwie den Case XY programmiert. Was weiß ich, zum Beispiel eine Jobbörse oder in einer Jobbörse den Faktor, wie nehme ich Kontakt mit jemandem auf? Das hat schon jemand anders gemacht. Kann ich da nicht dessen Paket sozusagen aufrufen? Und in so eine ähnliche Richtung, wenn ich es jetzt richtig verstehe, gehen ja, glaube ich, auch Bibliotheken. Also vielleicht kannst du mal ein bisschen den Faktor Bibliothek erklären, was das genau ist und wie das in dem Kontext eine Rolle spielt.
Johannes Schaback: Bibliotheken sind Funktionspakete oder Programmteile, die ein bestimmtes Problem lösen, in einer Art und Weise, dass es übertragbar ist. Ich kann beispielsweise Druckertreiber, ist so etwas, wenn ich jetzt eine Seite ausdrucken möchte, dann kann ich das aus meinem Programm heraus tun, aber ich muss natürlich in irgendeiner Form drücken. Das Format, in dem ich mit dem Drucker spreche, muss ich sprechen können. Und vielleicht kann dieser Drucker PDF, das ist ein spezielles Format, vielleicht kann der Doc. Aber ich muss auf jeden Fall das, was ich dort rausdrucken will, muss ich in irgendeiner Form dort importieren. Damit ich aber jetzt beispielsweise PDF nicht selber programmieren muss, das könnte ich auch gar nicht, da wäre ich ja Monate mit beschäftigt. besorge ich mir so ein Paket, so eine Bibliothek, also ein vorgefertigtes Programm, was ich in mein Programm einbinde, das diese Funktionalität abbildet, also beispielsweise PDFs generiert und dann an den Drucker schickt. Bibliotheken sind in der Regel sehr gut dokumentiert, das heißt, ich weiß genau, wie ich die zu benutzen habe, das heißt also, wie genau ich dieses Unterprogramm anzusprechen ist, welche Parameter ich setzen muss, unter welchen Umständen es welchen Output generiert. Und das muss ich mir durchlesen, das muss ich verstehen und dann muss ich es integrieren in mein Programm. Das ist häufig gar nicht so einfach. Ich muss häufig den Input und Output dieser Bibliotheken konvertieren und dadurch erreiche ich natürlich einen massiven Produktivitätsvorteil, weil ich eben nicht mich um kleinere Funktionalitäten, Low-Level-Funktionalitäten kümmern muss und mich speziell auf das ganz individuelle Problem, was ich lösen möchte, konzentrieren kann.
Joel Kaczmarek: Das alles jetzt mal als Basiswissen gelegt. Lass uns doch mal wieder zu dieser Ausgangsfrage kommen, indem wir so ein bisschen versuchen einzuordnen, woran erkenne ich eine gute Programmiersprache und welche taugt eigentlich für welchen Zweck?
Johannes Schaback: Letztendlich würde ich auf zwei Sachen gucken. Ich würde auf die Qualität gucken und ich würde auf die Zeit, die ich dafür brauche, gucken, um dieses Ergebnis zu erzielen oder mein Problem zu lösen. Viele Leute benutzen Excel. Das ist ein super, super mächtiges Tool, um Tabellenkalkulationen durchzuführen oder einfach schnell mal Dinge auszurechnen. Viele Menschen, gerade nicht unbedingt super technische Leute, sind sehr gut in Excel, können relativ schnell ein paar Zahlen einbauen, ein paar Vögel eintragen, zack, bumms, haben sie am Ende das Ergebnis, was sie haben wollen, ohne dass sie jetzt groß programmieren müssten. Das ist schon interessant. Also entscheidend ist, es geht sehr schnell in Excel, aber möglicherweise ist die Qualität des Ergebnisses nicht so einfach, weil ich es nicht automatisieren kann, weil ich es nicht in der Cloud laufen lassen kann, weil ich es nicht auf meinem Mobile Phone laufen lassen kann, sondern ich habe es einfach nur für mich mal einmal ausgerechnet. Das heißt, das Produkt am Ende ist nicht unbedingt das, was ich mir erwartet habe. Wenn ich also die Frage stelle, welche Sprache ist die richtige, dann muss ich wirklich einfach einmal alle Sprachen, die ich kann, durchgehen. Und die, die ich nicht kann, würde ich außen vor lassen, weil ich einfach in der Ramp-Up-Time, um diese Sprache zu lernen, Ich würde einfach gucken, welche Sprachen machen Sinn auf der Plattform, auf der ich es laufen lassen möchte. Also beispielsweise soll es im Browser laufen, soll es auf dem Server laufen, soll es auf dem Mobiltelefon laufen und dann einfach einmal gucken, wie schnell wäre ich wohl, wenn ich mein Produkt bauen würde in Sprache X. So würde ich vorgehen. Eine weitere Randbedingung kann dann sein, kriege ich dafür Entwickler? In einem Startup-Umfeld ist es in der Regel so, dass du meistens schon mit einem technischen Menschen zusammenarbeitest oder du hast eben schon irgendein Grundsystem. Aber du kannst natürlich darauf schauen, wie teuer sind Entwickler? Bekomme ich da Entwickler für diese Sprache, für diese Umgebung? Also ich überlege, wenn ich jetzt so ein ganz skurriles Embedded-System, also ich irgendwie auch sozusagen in Fernsehern oder in Heizungen spezielle Programme laufen lassen möchte, um Steuerung von diesen Heizungen oder Lichtanlagen vorzunehmen, dann bin ich natürlich in einem sehr, sehr speziellen Domain, was wiederum sehr spezielle Entwickler erfordert. In den allermeisten Fällen möchte ich eine Web-Anwendung bauen oder eine Mobile-Anwendung und dann ist es relativ klar, dann gibt es eine Handvoll Sprachen und da würde ich wirklich einfach darauf gucken, wie schnell wäre ich in welcher Sprache.
Joel Kaczmarek: Jetzt hast du sozusagen ein bisschen gesagt, worauf man achten sollte, aber jetzt gehen wir mal davon aus, jemand, der non-technisch ist, wird ja dann ein relativer Laie sein. Das heißt, der hat jetzt keine Ahnung, ob jetzt irgendwie ein Ruby das Richtige für ihn ist oder ob HTML5 the way to go ist. Wie geht man denn da vor? Also woher weiß ich denn, welche Programmiersprache diese Aspekte, die du gerade angesprochen hast, und ich hatte ja eingangs auch so ein bisschen gesagt, was ich noch angucken würde, so technische Performance, Wartbarkeit etc. Woher weiß ich denn von außen als Laie, welche Sprache sich dann für mich eignet?
Johannes Schaback: Man könnte zum Beispiel darauf schauen, was die Konkurrenz benutzt. Ich könnte mir vorstellen, wenn ich jetzt ein neues Produkt bauen möchte, was in direkter Konkurrenz zu jemand anderem steht, dann schaue ich mir erstmal ein, kriege ich raus, in was der Konkurrent seinen Teil gebaut hat, welche Technologien er nutzt. Häufig ist es ja auch eine Mischung. im Darstellenbereich, also im Frontend, wie man sagt, also alles das, was der User sieht. Wenn ich eine andere Programmiersprache benutze, als ich jetzt beispielsweise im Backend, im Serverbereich, also das, was der User nicht sieht, also für Datenbanken ist SQL sehr gängig, vielleicht benutze ich da Microservices und jeder Microservice benutzt eine andere Sprache. oder meine Microservices stehen aus drei Sprachen, das ist durchaus möglich. Das kriegst du wahrscheinlich nicht immer raus, aber ich würde erstmal versuchen, was ist der Markt, was ist gängig? Das bedeutet natürlich auch, erstens nehme ich das Risiko, dass ich damit einen kompletten Fail hinlege, wenn ich eine skurrile Sprache wähle, wie Brain Fuck beispielsweise, die dann überhaupt nicht wartbar wäre, dass ich das Risiko angehe, dass ich mich auf die Nase lege, weil ich mich verkalkuliere in meinen Technologien. Gleichzeitig kann ich damit aber auch sicherstellen, dass ich wahrscheinlich dafür Entwickler finde. Und ich kann eben auch sicherstellen, dass es eben Bibliotheken gibt, also Werkzeuge, Tools, Funktionen, dass ich produktiv sein kann. Das ist, glaube ich, grundsätzlich eine gute Sache. Dann, wenn es keinen direkten Konkurrenten gibt, dann würde ich schauen, irgendwie vergleichbare Angebote finden, vergleichbare Produkte finden, Programme, Services und versuchen herauszubekommen, in was wurde das gebaut? Also das machen wir auch immer noch, dass wir versuchen, Jetzt beispielsweise bei Ladenzeiten herauszubekommen, wie löst Google ein bestimmtes Problem und was genau setzen die dafür ein? Welche Arten von Algorithmen nutzen die da? In welcher Infrastruktur lassen die das laufen? In welcher Sprache haben die das gebaut? Welche Bibliotheken benutzen die vielleicht sogar, die öffentlich zugänglich sind? Das macht schon sehr viel Sinn.
Joel Kaczmarek: Würdest du Leuten grundsätzlich empfehlen, sich in solchen Fragen auch beraten zu lassen? Es gibt ja durchaus Beratungen, die auf digitale Themen spezialisiert sind. Macht sowas Sinn oder ist das irgendwie falsch investiertes Geld?
Johannes Schaback: Kommt wirklich sehr auf das Produkt an. Wenn ich jetzt ein Atomkraftwerk-Software bauen würde, dann würde ich mich definitiv beraten lassen. Da gibt es sicherlich auch ISO-Standards, die es einzuhalten gilt oder auch im Fintech-Bereich ist das, also Security. Das macht durchaus Sinn, wenn ich in einer Umgebung laufe, wo ich stark darauf angewiesen bin, dass ich bestimmte Normen erfülle. In den meisten Bereichen, wenn es darum geht, ein Konsumentenprodukt zu bauen, was jetzt einen bestimmten Website oder einen Webservice anbietet, glaube ich, muss man sich zumindest nicht beraten lassen, dahingehend, dass man eine Consulting-Firma beauftragt. Ich würde sicherlich immer, wie grundsätzlich bei allen Business-Entscheidungen, versuchen, so viele Meinungen wie möglich einzuholen. So auch hier. Es ist aber ein reversibler Fehler, wenn ich jetzt mich beispielsweise für Java entscheide, Und dann aber merke, okay, Java, da muss ich ein bisschen länger dran arbeiten und ich merke nach, weiß nicht, vielleicht nach einem halben Jahr, okay, Ruby on Rails wäre wirklich besser gewesen, dann heißt das in der Regel nicht, dass ich alles wegschmeißen muss, also gegeben, dass meine Architektur nicht kompletter Mist ist und ich alles neu bauen muss, das wäre wirklich ein irreversibler Fehler, das wäre blöd. Aber in der Regel, wenn du eine vernünftige, wie sagt man, Reactive-Architektur wählst, also eine spezielle Pattern und Schemata einhältst, wie du deinen Code baust und organisierst, dann kriegst du diese Fehler auch wieder ausgemerzt nach hinten raus. Da würde ich mich jetzt nicht allzu sehr beraten lassen, sondern lieber davon treiben lassen, wie schnell bin ich mit den Jungs, die ich vielleicht schon habe. Ich würde jetzt nicht nur, weil ich, wenn ich zum Beispiel jetzt auf Java gestartet bin und weiß, okay, PHP-Entwickler sind preiswerter, deswegen ab der Funding-Runde Series B plötzlich sagen, okay, ich baue jetzt alles um auf PHP. Also diese Transitionskosten wären auch, bin ich mir ziemlich sicher, höher, auch immer noch im Langfristigen gerechnet, als so ein Technologieswitch.
Joel Kaczmarek: Ich meine, am Ende des Tages müssen Programme und Entwicklungen, Produktionen, also Computerproduktionen ja auch irgendwie schnell sein. Habe ich auch schon eingangs ein bisschen erzählt, auch zum ganzen SEO-Aspekt alleine schon, aber auch für den Nutzer. Spielt da die Programmiersprache nicht eigentlich schon eine Rolle und wenn ja, auf welche Art und Weise?
Johannes Schaback: Absolut. Es ist in der Tat wichtig, was du für eine Programmiersprache wählst. Das kommt wieder auf den Bedarf an. Wie schnell, wie responsive, wie schnell muss dein Programm sein? Also beispielsweise bei Realtime-Anwendungen, wie jetzt Computerspielen, komplexe Simulationen mit viel Computergrafik, mit viel Physik im Hintergrund, brauchst du eine Umgebung, jetzt erstmal unabhängig von der Sprache, aber du brauchst, das ist häufig sehr eng verknüpft, brauchst du eine Umgebung, in der dein Programm sehr, sehr schnell läuft. Das heißt, du brauchst erstmal eine gute Hardware. Das ist eine Voraussetzung und wenn das gegeben ist, dann brauchst du eine Programmiersprache, die ein sehr schnelles Programm ermöglicht. Und da ist die Sprache sehr wichtig. In Webentwicklung ist es in der Regel so, dass du sehr viele parallele Anfragen hast. Da kommt es jetzt nicht so sehr darauf an, dass du besonders schnell beispielsweise mit einer Grafikkarte sprechen kannst. Da hat die Programmiersprache leicht andere Anforderungen, dass du beispielsweise sehr schnell parallel Anfragen abarbeiten kannst oder dass du eben bestimmte komplexe Sachverhalte mit Datenbankabhängigkeiten gut abgebildet bekommst. dass du dich gut integrieren kannst in andere Bereiche eines Systems. Das sind dann Sprachen, die mit unterschiedlichen Bibliotheken kommen oder eben unterschiedliche Eigenschaften haben, dass du besser Webservices programmieren kannst oder eben noch nicht. Ein ganz grober Unterschied ist, wenn man wirklich nur auf die Performance, also auf die Laufzeitgeschwindigkeit schaut, ist, ob eine Sprache interpretiert wird. oder ob sie kompiliert wird. Eine kompilierte Sprache ist beispielsweise CC++, der C-Code ist menschenlesbar, wird dann aber kompiliert in eine ganz, ganz auf die Maschine zugeschnittene Maschinensprache, die hammer, hammer, hammer schnell ist. Die ist aber auch nicht mehr veränderbar. Die läuft dann einfach ab und fertig. Eine interpretierte Sprache dagegen läuft im Grunde sehr high level in einer Box, in einer virtualisierten Umgebung. Da wird erstmal ein extra anderes Programm gestartet, beispielsweise ein Interpreter, der dann diesen eigentlichen Source Code deiner Sprache liest und dann einfach Zeile für Zeile liest und es dann ausführt. Das heißt aber, du hast immer diese Schichten dazwischen des Interpreters. Und JavaScript beispielsweise läuft eben im Browser. Du musst erstmal im Browser starten, um ein JavaScript-Programm laufen zu lassen. Und das ist in der Regel erstmal nicht so schnell, hat aber den Vorteil, dass du dich um das Management deiner Ressourcen, also beispielsweise Speicherbedarf, oder File-Systeme nicht kümmern musst, weil es vereinheitlicht ist und eben dieser Interpreter bestimmte Bereiche, bestimmte Aufgaben übernehmen kann. Wenn du beispielsweise einen Fehler hast in deinem Programm, dann kannst du einfach dem Interpreter sagen, so jetzt stopp, pause the world und er stoppt das komplette Programm und du kannst eben ganz genau in diesen Speicher reinschauen von diesem Interpreter und gucken, okay, jetzt in welchem Zustand befindet sich gerade mein Programm. Ich kann beispielsweise in der Java-Virtuellen-Maschine, die eben eine Mischung ist, was kompiliert und interpretiert, Da habe ich erstmal eine Phase, in der interpretiert wird. Der Java-Code wird interpretiert, also der Byte-Code wird interpretiert, also es wird schon noch kompiliert, nur der Byte-Code wird interpretiert. Wie gesagt, das ist eine Mischung, muss man jetzt nicht genau verstehen. Entscheidend ist aber, dass ich dann zur Laufzeit das übersetzen kann in noch schnellere Maschinen-Code. Also es gibt ja auch Mischformen, wenn es eben sehr, sehr, sehr schnell sein muss. Aber immer dann, wenn ich aus der Java-Virtual-Maschine beispielsweise Native meinen Grafikkartentreiber ansprechen möchte für OpenGL beispielsweise, dann bekomme ich Schwierigkeiten, weil ich dann erstmal Speicherbereiche hin und her kopieren muss und dann bin ich nicht mehr so schnell.
Joel Kaczmarek: Was man aber manchmal beachten muss. Da merkt man mal, wie komplex das ganze Thema ist. Dann lass uns doch zum Abschluss mal einige der populärsten, wie ich jetzt sagen würde, Programmiersprachen so ein bisschen kurz einordnen. Also ich würde dir mal kurz den Namen droppen und du sagst, lass uns das versuchen kurz zu halten, dass wir nicht zu sehr ausufern. gibst mal so eine kurze Einordnung, kommentierst kurz, was das ist, wofür es wichtig ist und wie relevant, dass die Leute so eine grobe Vorstellung haben. Macht Sinn? Ja, absolut. Hervorragend. Ich glaube, der Klassiker hast du gerade schon ein bisschen gesagt, Java.
Johannes Schaback: Java ist eine Programmiersprache, die insbesondere im Enterprise-Bereich, also in großen Firmen eingesetzt wird, einen unglaublich großen Bibliotheksschatz mitbringt. Das heißt also, man kann sehr, sehr schnell sehr produktiv werden. Damals der Vorteil, warum Java sich ausgedacht wurde, war diese virtuelle Maschine. Man kann sich das ein bisschen vorstellen wie ein Betriebssystem im Betriebssystem. Also es wurde eine eine Schicht geschaffen, die die unterschiedlichen Betriebssysteme im Grunde zusammenführt, sodass man eben leichter Code oder das gleiche Programm einmal programmieren konnte und auf ganz, ganz vielen unterschiedlichen Computerarten laufen lassen konnte. Und das war auch mit ein Grund, warum es eben im Mobile-Bereich so populär geworden ist, weil eben im Mobiltelefonbereich eben die Hardware so unterschiedlich ist und durch diese Virtualisierung man sozusagen gemeinsame Standards oder einheitliche Interfaces schaffen konnte.
Joel Kaczmarek: Ich will es nicht so sehr ausdehnen, aber mal eine kurze Randfrage noch dazu. Ist Java eigentlich so ein bisschen das nächste Flash? Weil was ich immer so mitkriege ist, also Flash ist ja mittlerweile total verpönt, mag keiner mehr, weil ineffizient scheiße und öh. Und bei Java habe ich das Gefühl, ist manchmal auch so, weil das irgendwie virenanfällig ist, hackeranfällig. Ist das ein bisschen so oder ist das nicht?
Johannes Schaback: Die Verbreitung von Java heute ist eine ganz andere als Flash damals. Flash war eben dafür da, dass du dynamische Inhalte oder echte Programme in Browser-Umgebungen laufen lassen konntest, mit einem Plugin in der Regel damals. Das hat Java als kleinen Zuteil auch. Es gibt sozusagen auch eine JavaFX oder eine Java-Umgebung, die im Browser läuft, die wirklich eher an Flash erinnert. Darüber hinaus ist es aber unvorspellbar zum jetzigen Zeitpunkt, dass es einen ähnlichen Werdegang nimmt, weil Du natürlich im Server-Bereich, aber auch eben im Mobile-Bereich eine ganz andere Verbreitung, eine ganz andere Anwendung hast von Java als im Flash damals.
Joel Kaczmarek: Zweite Programmiersprache C bzw. C++.
Johannes Schaback: C, C++ wurden vor, ich glaube, irgendwann in den 70er Jahren entwickelt, um Betriebssysteme zu programmieren, letztendlich. Und damals war es wirklich so, das war wirklich revolutionär, dass mal jemand eine Sprache gebaut wurde, die sehr, sehr, sehr schnell ist, sehr, sehr gut sozusagen wird. hardware-nah programmieren kann, sehr wenig Latenz hat, du kannst sehr genau deinen Speicher managen, gleichzeitig ist sie noch sehr gut lesbar. Die ganze Linux-Welt ist sehr populär geworden und auch viele, viele Linux-Tools oder Unix-Tools, die heute noch existieren, sind in C geschrieben. C++ ist im Grunde eine Erweiterung von C durch Objektorientierung. Das ist eine spezielle Art und Weise, wie man im Grunde Code verwaltet und auch wie man im Grunde Code strukturiert. Das ist, nach welchen Schemata man diesen Code programmiert, also Objektorientierung ist sehr schwierig zu erklären, in einem Satz und setzt aber im Grunde auf dieser C-Syntax auf und erfreut sich heutzutage schon noch sehr großer Popularität, insbesondere wenn du sehr nah an der Hardware programmieren möchtest. Also wenn du beispielsweise für Spiele oder latenzkritische Anwendungen, also viele wissenschaftliche Rechnungen, Bibliotheken, wo es wirklich um Number Crunching geht, sind in C++ geschrieben, teilweise sogar noch in Fortran, was noch eine ältere Sprache ist. Wo es wirklich einfach nur darum geht, ganz, ganz, ganz schnell ganz viel zu berechnen und wirklich sozusagen Hardcore-Performance. Also Betriebssysteme sind bis vor zehn Jahren noch sehr viel in C, C++ geprogrammiert worden. Treiber beispielsweise werden auch noch häufig in C geschrieben.
Joel Kaczmarek: Daran anschließend ein bisschen vielleicht Advantage, also zumindest ist auch ein C drin, C-Sharp.
Johannes Schaback: C-Sharp wurde von Microsoft entwickelt als Konkurrenzsprache zu Java. Java wurde ja ursprünglich von Sun Microsystems entwickelt, hat eben diesen großen Vorteil damals mit der virtuellen Maschine gehabt. C-Sharp ist dann zwei, drei Schritte weitergegangen, hat eine ähnliche Umgebung geschaffen, aber etwas flexibler, möchte man sagen, ist aber zumindest jetzt in meiner Wahrnehmung nicht so populär wie Java. Es gibt Beispielsweise jetzt im Gaming-Bereich ein großes Framework, das nennt sich Unity. Das wird in C-Sharp programmiert. Es ist etwas moderner als Java, das muss man schon der Fairness halber sagen. Java entwickelt sich aber auch weiter. Es ist letztendlich ein Konkurrenzprodukt gewesen. Nur die reine Sprache, das damalige .NET-Framework, was erstmal unabhängig von C-Sharp ist, ist durchaus nochmal innovativ. Also ich freue mich auf eine größere Popularität, einfach weil es sozusagen mehr Sprachen laufen lassen konnte damals und ist jetzt außerhalb der Microsoft-Welt nicht so wahnsinnig groß.
Joel Kaczmarek: Python.
Johannes Schaback: Python ist eine Script-Sprache. Sie wird interpretiert, ist auch objektorientiert und ist insbesondere in der wissenschaftlichen, also in der ganzen Data Science, Machine Learning Community sehr, sehr populär, weil eben Bibliotheken existieren. die es erlauben, sehr schnell, sehr produktiv, sehr schnell Dinge auszuprobieren, sehr viel Number Crunching zu betreiben. Es eignet sich aber auch für Web-Development. Das ist wirklich eine fantastische Sprache. Ja, kann man gar nicht so viel sagen. Es ist sehr, sehr populär, sehr einfach zu lernen, es ist sehr schön lesbar, es ist wirklich einfach zu lernen, das muss man wirklich sagen.
Joel Kaczmarek: Ist das deswegen so ein bisschen einer der wichtigsten auch, wenn man irgendwie im Web-Entwicklung machen will, dass man nach sowas schaut? Ist das dann irgendwie relevant?
Johannes Schaback: Es kommt wirklich drauf an. Also wenn du, letztendlich willst du ja Code lesbar haben und den Code, den Das Programm, was du schreibst, muss, wenn es sehr, sehr, sehr komplex ist, auch immer noch für Menschen lesbar sein. Und häufig hast du einen Trade-off zwischen Einfachheit der Sprache und wie einfach ist es dann noch, diesen Code zu maintainen, wenn das Programm mal wirklich sehr, sehr, sehr, sehr komplex wird oder Anforderungen hat, wie zum Beispiel auf Geschwindigkeit, dass bestimmte Operationen nicht länger dürfen. laufen würden als Millisekunden. Dann hast du häufig Schwierigkeiten oder du merkst plötzlich, dir fehlt eine bestimmte Bibliothek oder du hast wirklich eben ein Security-Thema oder so. Es ist nicht der einzige Grund, aber als Einsteigersprache super.
Joel Kaczmarek: Wir hatten es schon öfters erwähnt, Ruby bzw. Ruby on Rails wäre die Langform davon.
Johannes Schaback: Ja, Ruby on Rails, also Ruby ist erstmal eine Sprache. Ruby
Joel Kaczmarek: Das ist gar nicht die Abkürzung, dass man sagt, ich kann Ruby, ich dachte immer, dass die Leute dann meinen, ich kann Ruby on Rails, dass das die Kurzform, die gesprochen wird.
Johannes Schaback: Ja, das ist genau, also Ruby ist populär geworden durch Ruby on Rails, aber Ruby ist erstmal quasi eine Sprache, die glaube ich um 94 erdacht wurde und letztendlich sich vieler Ideen bedient aus anderen Sprachen. Zu dem Zeitpunkt aber wirklich sehr innovativ war, weil es eben in der Form so in der Zusammensetzung dieser vielen guten Ideen noch nicht existierte. Ruby on Rails ist das Web-Framework, also eine Bibliothek wieder, wenn du so willst, was das Bauen von Web-Services sehr schnell und sehr einfach und sehr consistent, sehr coherent, also sehr, sehr Kohärent. Kohärent, genau, ermöglicht in der Sprache und eben diese wunderbaren Vorteile von der Ruby-Sprache ausnutzt. Und dadurch ist es populär geworden und dadurch ist es, also sehr, sehr viele, sehr große Web-Services oder auch Websites sind in Ruby on Rails programmiert.
Joel Kaczmarek: Also das ist schon eine der wichtigeren Sprachen im Absolut, absolut.
Johannes Schaback: Es ist eine sehr schöne Sprache. Genau, es ist auch ziemlich schnell und es eignet sich wirklich wunderbar, insbesondere eben durch diese Ruby on Rails Framework. Man muss der Fairness halber aber auch eben sagen, dass viele andere Sprachen, wie eben halt auch im PHP oder mit Scalar oder Java, in den Bereichen auch viel von diesem populären Ruby on Rails Framework nicht wieder abgeschaut wurde, sodass so ein bisschen dieses Alleinstellungsmerkmal wieder verloren gegangen ist.
Joel Kaczmarek: Wo du es gerade sagst, PHP wäre so der nächste Case, den ich mal thematisieren würde.
Johannes Schaback: Genau. PHP steht für Hypertext Preprocessor, glaube ich. Also es ist ein lustiges Akronym und ist eben auch ursprünglich mal erdacht worden, um Template Engines zu bauen. Also wirklich damals große Leute, die sozusagen aus Perl, von einer ganz alten Programmiersprache kamen und sozusagen dynamische Web-Anwendungen programmieren wollten. Also Web 1.0, wenn man so will, damals. Wir waren eben frustriert davon, wie komplex es war und mit PHP konnte man eben sehr schön, sehr, sehr früh HTML schreiben und mischen mit eigentlichem Code. Und es wurde dann übersetzt zur Laufzeit in PHP-Code und das hat eben die Leute sehr, sehr schnell sehr produktiv gemacht, tolle Websites zu bauen. Facebook etc. wurden auch in frühen Zeiten in PHP programmiert.
Joel Kaczmarek: Das hat geswitcht dann irgendwann, ne?
Johannes Schaback: Ich glaube, dass große Teile immer, also meines Wissens nach sind immer noch große Teile im PHP, aber es macht natürlich Sinn, dass du in manchen Bereichen, gerade in Backend-Bereichen, wo eben dieser Vorteil von PHP nicht so zum Tragen kommt und du eben halt auch immer noch in einem interpretierten, also PHP wird interpretiert, das heißt, du brauchst irgendeine Laufzeitumgebung und wenn es wirklich auf Performance ankommt oder auf Speichermanagement, dann Nachzusehen, dass du switchst. Aber grundsätzlich auch PHP ist sehr, sehr mächtig. Du kannst sehr, sehr viel mit PHP machen. Es gibt auch kein richtig und kein falsch. Es gibt einfach nur ein schneller oder nicht schneller oder mehr geeignet oder weniger geeignet. Aber es ist jetzt kein komplett schwarz-weiß-Entscheidung. Ja, und das ist nach wie vor Also wenn du Webseiten hast, die die Funktionalität sehr viel nicht so komplex sind in ihrer Funktionalität, dann bist du im PHP einfach sehr schnell. Und wenn du wenig vom Frontend unabhängige Prozesse hast, die du betreiben musst, wählen viele Leute auch PHP. Und das war ein bisschen verschrien, das hat ein bisschen schlechten Ruf, weil der PHP-Code insbesondere so 2000 häufig nicht unbedingt immer der allerschönste war. Aber das liegt eben an den Entwicklern. Du kannst halt auch sehr guten PHP-Code schreiben. Und durch Frameworks wie jetzt die Zen-Frameworks ist das auch sehr stark standardisiert und es gibt jetzt auch einen Standardisierungsprozess innerhalb von PHP, also absolut etablierte Sprache.
Joel Kaczmarek: HTML, das kenne ich ja sogar noch aus dem Informatikunterricht. Hypertext Markup Language war, glaube ich, die Abkürzung. Sag da doch auch mal ein, zwei Sätze zu.
Johannes Schaback: Genau, ist eine deklarative Sprache. Das heißt, ich beschreibe nur ein Ergebnis. Also ich beschreibe das Layout einer Website. Mit HTML5 natürlich sehr stark erweitert worden um etliche Dinge. Auch immer in der Ehe mit JavaScript. JavaScript ist ja wiederum imperativ. Das heißt, ich sage, ich kann Schleifen bauen, ich kann Zahlen hochzählen, ich kann Bedingungen programmieren, Abläufe programmieren und kann damit dieses HTML modifizieren. HTML ist, genau, es ist sozusagen ein XML-Derivat, also für diesen eckigen Klammern, was man immer sieht, das ist eben sozusagen nur eine spezielle Form. Und genau, es ist eine Marker-Language, also ich beschreibe etwas. Ja, beschreibe in dem Fall Websites.
Joel Kaczmarek: Dann sollten wir doch als nächstes mal JavaScript ansprechen. Java hatten wir schon, bei HTML hast du es gerade aufgeschrieben. Was ist JavaScript?
Johannes Schaback: JavaScript ist auch eine interpretierte Sprache. Das heißt, sie läuft im Browser, wird interpretiert. Das heißt, es wird nicht in speziellen Hardware-Code übersetzt und dient dazu, Inhalte, in HTML-Seiten insbesondere, dynamisch zu machen. Es gibt dadurch, dass viele Leute eben mit JavaScript angefangen haben, sich mit Programmierung zu beschäftigen, gibt es eine große, große Bewegung, dass auch JavaScript auf der Server-Seite läuft, also außerhalb des Browsers. Und dass sozusagen auch die eigentlichen Backend-Anwendungen in JavaScript programmiert werden, häufig auch in Microservice-Umgebungen. Das liegt eben daran, dass viele Leute sich mit JavaScript auseinandergesetzt haben und dann eben es nahe lag, okay, ich will jetzt auch mein Backend-Verwaltung in JavaScript programmieren. Aber letztendlich kommt es daher, JavaScript hat nichts mit, also man muss jetzt auffassen, JavaScript hat Stand heute sehr, sehr wenig mit Java zu tun, eigentlich nichts. Die Syntax, also die Wörter, die verwendet werden, sind ähnlich, ist aber darüber hinaus fast eigentlich nicht zu vergleichen. Witzigerweise gibt es jetzt Bestrebungen, dass JavaScript sich sehr nah mit ECMA an Java angleicht, von der Syntax auch her, und sich beide Welten zusammenführen.
Joel Kaczmarek: SQL wäre so ein Faktor, den ich nochmal thematisieren würde. Das ist sogar bis zu mir durchgedrungen, ist so im Datenmarktbereich angesiedelt.
Johannes Schaback: Genau, SQL ist Standardized Query Language und dient dazu, Abfragen oder eben Änderungen in Tabellen durchzuführen. Und es ist auch eine deklarative Sprache. Also ich sage nicht, laufe über die Tabelle, gucke in Zelle 3. Wenn jetzt in Zelle 3 der Wert 9 steht, dann speichere diese, gib diese Zeile aus. Sondern ich schreibe im Grunde eine Abfrage. Und wie das genau implementiert wird, das ist dann Sache der Datenbank. Und das ermöglicht es eben, diese Sprache zu portieren, auch auf unterschiedlichen, desselben SQL-Standard oder dieselben SQL-Syntax und Semantik zu portieren auf unterschiedliche Datenbanksysteme, also Postgres, MySQL etc. Ja, sehr, sehr populär. Absolutes Muss für jeden Entwickler. Das ist einfach der de facto Standard für Abfragen. Es gibt sehr, sehr viele unterschiedliche Varianten mittlerweile von SQL. Ganze Doktorarbeiten darüber. Aber im Großen und Ganzen das Abfragen und Updaten und Einfügen und Löschen, das ist im Grunde ein Standard. Ganz ähnlich wie REST, absoluter Standard.
Joel Kaczmarek: R ist eine Programmiersprache, die mir jetzt nicht so oft unterkommt, aber anscheinend irgendwie eine zunehmende Bedeutung spielt. Also R wie der Buchstabe R.
Johannes Schaback: R, MATLAB. Ja, das ist auch eine interpretierte Sprache, wobei ich glaube, dass sie auch just-in-time-compiled werden kann. Übrigens, das muss man der Fernsehsache auch nochmal sagen, das ist jetzt für den Hörer wahrscheinlich nicht entscheidend, aber für die Entwickler ist es wichtig zu wissen, ist diese Sprache, wie schnell ist diese Sprache letztendlich? Und auch wenn es augenscheinlich eigentlich gerade bei Web-Services nicht so super wichtig ist, dass es total schnell ist, wenn du ein Mobile-Game entwickelst, dann ist es schon sehr wichtig, dass deine Programmierung sehr hardware-nah ist und dass du sehr schnelle, sehr effiziente Programme programmieren kannst. Und dann musst du also sagen, irgendwann diese Sprachen übersetzen und in Kompilieren, wie es so schön heißt, also quasi von einer menschenverständlichen Variante in eine nur noch der Maschine verständliche, aber dafür sehr schnelle Variante übersetzen. Und deswegen ist immer dieses interpretiert, nicht interpretiert oder kompiliert entscheidend. Und beispielsweise Java wird just in time compiled, das heißt also die Laufzeit einer Laufzeitumgebung wird also interpretiert, aber kann zur Laufzeit kompiliert werden und ist deswegen dann halt auch sehr schnell und durchaus vergleichbar von der Performance her wie C oder eben andere kompilierte Sprachen. Genau, also R ist eine Sprache, die im wissenschaftlichen Rechnen eingesetzt wird. Es ist eine Sprache, die es sehr einfach macht, mit Vektoren, Matrizen oder im Grunde mit diesen linearen Algebra-Datenstrukturen zu hantieren. Also wenn ich eine Matrix definieren möchte, eine 3x3 Matrix und ich muss die transponieren oder eine Inverse berechnen oder ich möchte ein Matrix-Matrix-Produkt ausrechnen oder ein Matrix mal Vektor, dann kann ich das eben sehr, sehr effizient machen, während ich in anderen Sprachen mir da eben einen Wolf programmieren müsste, um so eine Matrix-Matrix-Multiplikation oder ich müsste irgendeine Bibliothek benutzen, das sähe aber nicht so schön aus. R liest sich eben gerade für solche wissenschaftlichen Anwendungen sehr, sehr gut und hat eben gerade für den Data Science Bereich sehr viele Vorteile. Es gibt noch Matlab. Python wird häufig auch in einer ähnlichen Domain eingesetzt, ist aber von der Lesbarkeit her nicht ganz so groß. R kommt eben sehr stark von den Statistikern.
Joel Kaczmarek: Abschließend, vielleicht noch mal so ein paar Crazy-Shit-Sprachen nenne ich sie jetzt mal. Also ich glaube, es gibt welche, die so ein bisschen abgefahrener sind. Scaler ist eine, die mir da irgendwie unterkam. Und du hast Brainfuck gerade schon, das hört sich auch so ein bisschen an. Und Erlang, glaube ich, ist noch so ein Faktor, der da kommt oder am Kommen ist. Sag doch da auch mal einen Satz zu.
Johannes Schaback: Ja, das sind wirklich drei sehr unterschiedliche Sprachen. Vielleicht Brainfuck ist wirklich eine crazy Sprache. Das ist eine Sprache, die besteht aus acht Kommandos. Im Grunde sind das so Pointer Arithmating. Also es ist ganz abgefahren. Es ist de facto nicht lesbar. Und es ist eigentlich, nach welchem Prinzip das entwickelt wird, weiß ich nicht. Es ist eher ein Scherz, diese Programmiersprache. Einfach nur um Hallo Welt auszugeben, bedarf es, ich schätze mal 50, 60 Zeilen Code. Es ist unglaublich komplex und du musst dir vorstellen, es besteht nur aus Klammern und aus Punkten und Plussen und Minussen und es gibt nur acht Kommandos. und es ist halt total minimalistisch und absolut nicht lesbar für den Menschen und es dreht wirklich dein Gehirn um. Erlang ist eine funktionale Programmiersprache, sehr, sehr effizient, kommt ursprünglich von Ericsson aus dem Telekommunikationsbereich, ist eben gerade auch in der Community der funktionalen Programmiersprachen sehr populär. und es lässt sich in funktionalen Programmiersprachen sehr schön Algorithmen programmieren, es lässt sich sehr sauber programmieren, es lässt sich sehr schön programmieren. beschreibend programmieren, wie jetzt mit sehr viel Rekursion und sehr, sehr schönem Code. Es ist eben nicht Rezeptform, kommt wirklich auf den Use Case an. Habe ich manchmal ehrlich gesagt so ein bisschen, das ist aber meiner Meinung nach das Gefühl, ist so ein bisschen so ein akademisches Kräftemessen, wenn Erlang eingesetzt wird. Es sei denn, du hast wirklich das Problem, dass du highly concurrent, also sehr, sehr stark parallelisierte Programme hast, wo es wirklich Sinn macht, das einzusetzen und du sonst wirklich aus Komplexitätsgründen es nicht hinbekämpfst, wenn du nicht eben Erlang einsetzt. bei diesem vielen parallelen Verarbeiten zu verwenden. Scalar ist eine Programmiersprache, die in der Java Virtual Machine läuft. Viele Programmiersprachen in Groovy auch. Und wird so ein bisschen als die Weiterentwicklung von Java verstanden, bedient sie viele Elemente von Java selbst. aber auch aus funktionalen Programmiersprachen, Haskell, teilweise Lisp. Es hat sehr, sehr viele moderne Ideen eingebaut, wird sehr stark auch weiterentwickelt und ist aber nicht ganz trivial zu lernen. Also in der Regel springen die Leute von einer, von C oder von Java in Scalar. Grundsätzlich kannst du mit weniger Zeilen Code mehr erreichen und die das Paradigmen ein bisschen dadurch, dass du weniger Platz brauchst, kannst du weniger Fehler machen, brauchst weniger Zeichen, hast weniger, sozusagen mehr erfassen als Mensch und bist sozusagen effizienter in einem Code. Aber der Code liest sich halt auch sehr viel dichter und du musst mehr nachdenken sozusagen pro Zeichen, wenn du so willst, ne? Aber klar, wenn du ein erfahrener Entwickler bist, dann macht das schon einen Unterschied. Und ja, es ist eine sehr, sehr schöne, sehr tolle Sprache. Und ja, manchmal in der Kritik, weil es nicht unbedingt so schnell ist wie Java. Ich glaube, es ist mittlerweile gelöst. Aber genau, ich denke, da Scalar wird man auch noch sehr viel von sehen.
Joel Kaczmarek: Ja, spannend. Ich finde das ja faszinierend, wie du mit irgendwie, wie so ein wandelndes Lexikon zu jeder Sprache was sagen kannst. Und ich glaube, wir haben alle auch sehr viel gelernt darüber, was das überhaupt ist, eine Programmiersprache, worauf man achten sollte, wo es wichtig ist. Von daher danke ich dir ganz herzlich für diesen Roundup, der wirklich, glaube ich, sehr informativ war. Hervorragend. Danke euch auch fürs Zuhören und bis zum nächsten Mal. Ciao.
