Zen of Python: Grundprinzipien (nicht nur) der Softwareentwicklung (2 von 2) #24 - podcast episode cover

Zen of Python: Grundprinzipien (nicht nur) der Softwareentwicklung (2 von 2) #24

Jun 20, 202344 minEp. 24
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Das Zen of Python von Tim Peters enthält wichtige Grundprinzipien der Softwareentwicklung. Diese Prinzipien und Leitlinien darf man zum Teil mit einem Augenzwinkern verstehen. Viele Softwareentwicklerinnen und -entwickler leiten die Prinzipien in Ihrer täglichen Arbeit mit Python, aber auch mit anderen Programmiersprachen. Einige der Prinzipien lassen sich sogar auf andere Lebensbereiche übertragen. Diese Folge gibt Denkanstöße und vermittelt ein in Ansätzen philosophisches Bild der Softwareentwicklung.

Das Zen of Python findet ihr hier: https://peps.python.org/pep-0020/

---

Einfach Komplex ist ein Podcast von Heisenware. Alle Infos und Kontakte findest du im Linktree:

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://linktr.ee/heisenware⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

---

Dr. Burkhard Heisen (linkedin.com/in/burkhard-heisen/) und Gerrit Meyer (linkedin.com/in/gerrit-meyer/) sprechen heute über:

(00:00) Bedeutung Zen of Python

(06:45) Beautiful is better than ugly.

(08:00) Explicit is better than implicit.

(10:30) Simple is better than complex.

(11:20) Complex is better than complicated.

(13:30) Flat is better than nested.

(15:30) Sparse is better than dense.

(16:30) Readability counts.

(18:00) Special cases aren't special enough to break the rules. Although practicality beats purity.

(20:00) Errors should never pass silently. Unless explicitly silenced.

(25:00) In the face of ambiguity, refuse the temptation to guess.

(28:30) There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.

(33:30) Now is better than never. Although never is often better than *right* now.

(37:30) If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.

(40:30) Namespaces are one honking great idea -- let's do more of those!

(42:00) Zen of Python

Transcript

Bedeutung Zen of Python

Moin und herzlich Willkommen zu einfach komplex Hi Burkhard, Moin Moin. So und Hallo Liebe können heute ist Teil 2 der großen Grundprinzipien der Softwareentwicklung. Diesmal wollen wir dann wirklich über die Sam of Python sprechen, die 20 beziehungsweise 19 Guiding Principles, die dort aufgestellt wurden und warum die nicht nur für die Entwicklung mit Python oder für die Softwareentwicklung allgemein zuständig sind.

Als kleine Wiederholung würde ich das Board einfach zusammenfassen und falls nicht, vielleicht erst nochmal die vorherige Folge, aber dieses Teil 2. Burkhard, Warum ist das so entscheidend und wichtig, dass wir darüber sprechen? Ja, ich meine in der letzten Folge haben wir glaube ich noch auf höherer Flughäfen, Flughöhe, Weisheiten irgendwie bekannt gegeben.

Diesmal ist es noch ein bisschen niedriger Flughöhe, aber es sind einfach so, man muss sich, vielleicht kommt das eigentlich, dass Python, also Python ist ja ne Programmiersprache, total relevant ist. Auch heute noch existiert schon ein bisschen länger, heute ist sie so relevant, weil wir das ganze AIKI Thema in Python abgeriegelt wird durch 2 sehr bekannte Frameworks die das erlauben, ich nenne die kurz mal Tensor Flow von Google und Pytorch glaube ich von.

Jetzt muss ich nachdenken, Meter vielleicht nochmal schneiden. Gerät das Quatsch was ich erzählt hab? Und bei einer Programmiersprache? Da werden bestimmte Sachen festgelegt, wie funktioniert ja und was sie kann und so weiter und sofort und dann gibt es.

Da gibt es natürlich Leute, die Lieben das dann so wie das funktioniert mit der Programmiersprache und es gibt auch ganz viele Leute, die kritisieren das, weil sie irgendwie andere mögen und so weiter da stehen ja auch immer Leute hinter dir entwickelt haben ne das man auch sagen Python wurde von Guido von Rossum, ein Holländer quasi gebaut, der Erschaffer der Sprache Python wurde auch liebevoll Dictator of Life getauft, also freundlicher

Diktator, wohlwollender Diktator auf Lebenszeit, was die Entwicklung dieser Sprache angeht und so ein armer Mensch, der muss natürlich schwerwiegende Entscheidungen treffen, ja. Nämlich wie diese Sprache auszusehen hat und welche Features sie bekommt. Ja, und vielleicht irgendwie auch mal wieder. Was in der nächsten Version nicht mehr gibt und so weiter das ist, das ist furchtbar, furchtbar schlimm, glaube ich, weil das ist so, als würdest du eine Firma führen.

Management muss Entscheidungen treffen, die jetzt aber nicht nur für 2000 Mitarbeiter, sondern für 20000000 oder Irgendsowas wichtig sind. Ja, und jeder von diesen 20000000 sind Nutzer dieser Programmiersprache Entwickler und das sind meistens clevere Leute und die haben auch ziemlich krasse Meinungen zu allem. Und die sind auch manchmal gar nicht so zurückhaltend mit ihrer Meinung. Und da kriegst du beides.

Ja, da kriegst du natürlich Support und Wohlwollen, aber du kriegst auch viel Kritik rein so.

Aus dieser Not heraus war wieder gerade, dass irgendwie Python in der Kritik stand wegen des technischen, nervigen, wegen, dem Aufräumen von Memory Garbage Collection nennt man das also Müllbereinigung weißt schön, muss nicht aktiv darum kümmern, die wie Müll, den ich angesammelt habe mit Objekten und so weiter also quasi Datenmüll, ja wie ich den bereinigt, das macht das schon alleine und darüber gab es im Detail ne. Ja, eine, ein Streitgespräch und

viele Nutzer waren da irgendwie wohl ja sehr kritisch unterwegs und haben mal wieder irgendwie gesagt, es muss sich alles

ändern. Wir müssen alles neu machen, ja die ganzen Konzepte sind Mist. So man Ruckelte an den Designgrundlagen so ja aus dieser Zeit kommt das ja und da gab es n Chancen gibt es immer noch fest im Netz verankert kann man nachlesen so. Und jetzt kommt der Tim Peters ins Spiel, der auch einfach ein Urgestein der Python Entwicklung war, dass auch viele grundsätzliche Beiträge Python hat er gemacht und so weiter der hat sich darauf eingelassen zu

sagen, OK lass uns doch mal die Grundfesten, die Philosophie, denke oder sowas von Python hinschreiben, damit wir diese ganzen Kritiker ein für alle Male irgendwie mal einordnen können, so denn man kann ja nicht ein System machen was

jedem und allem gerecht ist. Ja das stimmt ja genauso wie in der Politik. Ja es gibt, deswegen gibt es verschiedene Parteien, jeder hat, jeder hat irgendwo seine seine Sache, ja es gibt ja nicht eine Partei die jedem gefällt so. Das funktioniert nicht so mit der Programmiersprache auch und dann muss ich noch ein Paar, dann muss ich so ein paar Weisheiten runter schreiben oder so ein paar Leitlinien so n Paar soll ich sagen, ja ja, so wie

das Programm einer Wahlprogramm oder irgendwas vielleicht noch die Parteiprogramme einer Partei, ja. Und das ist passiert. Ja, und das haben Sie senden Python genannt, und das hat eigentlich tituliert 19. Geschrieben und hat die 20. Eigentlich aufgehoben für für Chefin Self Guido von Rossum, der sollte eigentlich die unterschreiben, hat er nie gemacht so, deswegen sind 19 geblieben. Und ich finds halt deswegen so

spannend, weil sich hier jemand. Der sehr viel Ahnung hat vom System, der der, der auch genau so weitreichende Entscheidungen treffen muss. Ja, der wurde gezwungen quasi sich mal zu committen und ein paar Leitlinien herauszugeben, jetzt für Python, ja wie Python funktioniert, was sie entschieden haben, das Python soll und nicht soll, ja.

Das finde ich total wertvoll. Wenn das mal jemand tut, weil wir stellen uns halt selber andauernd diese Fragen, ja, wie entscheide ich was und ob jetzt eine Programmiersprache selber natürlich das niedrigste Fluglevel so ja, aber es ist genauso schlimm für Softwareentwickler jetzt ein großes Software machen ja auch so für uns, ja wir machen ja große Software, wir müssen ziemlich viele Entscheidungen

treffen. Und wenn ich mir dann aber zum Beispiel so ein paar Leitplanken hinlege, wenn ich nämlich in Frage komme, mache ich das ja. Wo ich mich dann einfach orientiere, ich mich immer gleich orientiere. Dann komme ich einfacher durchs Leben, sag ich mal.

Ja, und diese Leitplanken selber hinzudichten ist nicht gar nicht so einfach und es gibt halt sehr clevere Leute in der Historie, das schon mal gemacht haben und deswegen wollen wir den angucken, weil langes Vorwort, aber ich will n bisschen die ne, es gibt ja auch, es gibt ja Kurse für Management und Entscheidungstreffen und so weiter noch und Löcher sind ja voll damit, so ja und was machen die versuchen ja auch mal Art Leitlinien Punkte so ne wie führe ich was ist dir wichtig

und so weiter das musst du dir nicht selber denken. Zusammen mit Hilfe und so weiter für mich sind das auch Leitplanken, die nicht nur das Programmieren wichtig sind. Manchmal nehme ich halt auch, um Entscheidungen zu treffen. Als Chef einer Firma, denn da ist es genauso kompliziert. Ja, und da will ich aber kohärent irgendwie eigentlich agieren, ja, und ich musste mir selber einen Satz hinlegen, woran ich glaube. Das ist gut, was du jetzt sagst.

Und wenn wir gleich die die Leitprinzipien einmal durchgehen, wird es auch den Zuhörern klarer, warum die zum Großteil auch für andere Bereiche Relevanz haben. Vielleicht schaffen wir 2 bis 3 Minuten pro Leitlinie oder sowas durchzukommen. Ja genau, war nicht vorhanden ist, haben wir noch philosophische Folgen hier, ja

Beautiful is better than ugly.

OK, prima dann wie gesagt 90 Stück hat schon gesagt 20. Ist noch von Guido Schaffer von Python zu füllen, hat also bis heute nicht weiß, vielleicht kommt ja irgendwann mal also Nummer 1 beautiful is better dann ugly schön ist besser als

hässlich oder? Ja, auf jeden Fall, es ist so wahr, aber ich finde das ist es wert einfach nochmal unterschreiben ne bezieht sich hier garantiert auf den auf den Code ja. Denn man kann schon sagen, es gibt schönen Code einer lesbaren Code Eleganz im im im hinschreiben auch schöne Texte, die du lesen kannst. Da manche finden zum Beispiel Thomas Mann sehr angenehm und schön als Text zu lesen, weiß ich nicht.

Auf jeden Fall ist es ist ein wahrer Richtlinie, ja schreib halt gleich schön kurz ja passt super zusammen mit der neuesten Folge da wo man sich gut überlegen sollte braucht man hier einen Kommentar und wenn man einen Kommentar braucht ist dann der Code nicht vielleicht noch zu kompliziert schrägstrich hässlich? Ja genau genau genau ist glaube ich sogar weiter als nur jetzt den Text aber schön.

Es geht ne. Also es gibt halt einfach schöne Lösungen, schöne elegante Konzepte und so weiter das ist glaube ich sehr allgemein, deswegen auch der also einfach Versuch einfach schön zu machen. Man muss diese ganzen Dinge so einen Augenzwinkern nehmen, wie beißen, sich selber nimmt ja die, also die Autoren sind auch lustige Leute, so ja die sind

Explicit is better than implicit.

immer ein bisschen Spaß dabei gehabt, ja das ist jetzt hier nicht akademischer Zack zack, ja, ich glaube, dass wir ein bisschen lustig und Spaß reinzubringen. Explicit ist better dann implicit. Das hattest du in der letzten Folge schon mal kurz, das ist gar nicht so einfach. Punkt auch gleich an zweiter Stelle, das heißt, hier versucht das nicht zu verstecken, dass das Verhalten von der Sprache, sondern drückt explizit aus, was

du wirklich willst. Da steht so ein bisschen im Konkurrenzkampf zu Convention over Configuration, wo man genau das eigentlich das Gegenteil will, wo man sagt, OK, ich will nicht alles explizit schreiben müssen, ich möchte, dass wenn ich nix schreibe, die richtigen Defaults angewendet werden. Ich weiß nicht, ob es wirklich im Widerspruch steht.

Ich glaube, man muss jetzt auf der Flughöhe gucken, wenn ich ne Programmiersprache habe, wo ich ja wirklich auf der niedrigsten Abstraktionsebene unterwegs bin um Sachen auszudrücken, da will ich vielleicht tatsächlich nicht irgendwie zu viele Sachen dem Zufall überlassen. Ja und irgendwelche impliziten Sachen passieren, die irgendwie raus kriege, wenn ich die 40. Dokumentationsseite lese, ja. Da will ich doch schon relativ explizit sagen können, was genau jetzt passiert.

So, ja, ich glaube, das ist hiermit gemeint und ich würde auch nicht meinen, dass jetzt irgendwie Peters oder g. Von Rom oder irgendwas absprechen würde, dass Convention over Configuration, was auf einer höheren Flugebene stattfinden muss, also auf Framework Ebene und so weiter, dass das ne gute Idee ist, ja, dass das finden die auch ne gute Idee. Hier geht es darum, dass eine Sprache explizit genug sein kann, um es auszudrücken. Ja, ich nehme noch mal das Jura Beispiel vom letzten Mal.

Wenn ich zu wenig Wörter habe in meiner Grammatik, einer Sprache, um wirklich festzulegen, was exakt ich meine und für Jura ist das total wichtig, ja, weil es geht ja um Strafen und strafen, was ich dann hab ich auch ein Problem ne also ich muss schon in der Lage sein mit meiner Sprache sehr explizit sehr eineindeutig auszudrücken was hier Phase ist.

So das meint das hier für ne Programmiersprache, ich glaube das ist für Kommunikation auch unter Menschen ganz allgemein total relevant, also jedes Gespräch, jede Beziehung profitiert davon, wenn man explizit. Und offen, transparent kommuniziert, anstatt Dinge implizit auszudrücken. Und das dann immer von der Interpretation des gegenüber abhängig ist. Ja, was denn tatsächlich nachkommt?

Ja, ich glaube, es gibt es gibt, hier gibt es auch wieder cases, ne, ich glaube es ist auch gesund, dass man, wenn du beim Bier zusammensitzen und schnacken irgendwie abends im Urlaub am Tisch, da wirst du auch ein Paar weglassen und dann geht es darum, dass die das richtig verstehen, was du da gerade sagst. Falls du es noch gerade sagen

Simple is better than complex.

kannst. Es gibt aber, wie gesagt, es gibt also die anderen Sachen, wo du irgendwie vielleicht einen Vertrag irgendwie verhandelt oder irgendwas, wo du es brauchst, du explizit bist du ja prima, der nächste ist auch. Irgendwie schön, einfach stimmig. Es simple is better den komplex also einfach ist besser als komplex. Genau so einfache Leitlinien, ne. Also das erinnert quasi jemand nochmal daran, Probleme nicht zu komplex werden zu lassen.

Ja find nimm doch erst mal die simpelste und naheliegendste Lösung. Ja viele, viele Softwareentwickler wünschen sich selber auch erwischt und dabei an sich simple Nutzer umsetzungsprobleme zu komplex zu denken, ja weil man vielleicht schon weiterdenkt wo der Nutzer, also man muss ja nicht alles mit und weiterdenken, so machst dann einfach erstmal simpel, ja. Könnt ihr Untertitel werden? Jetzt wo ich gerade gesprochen habe, einfach komplex, ja oder

Complex is better than complicated.

wir werden das auch ganz schön, also OK gut der Vierte jetzt, der setzt an am dritten also komplex ist Better denn complicated, also komplex ist dann doch wieder besser als kompliziert, dafür müssen wir vielleicht nochmal kurz auseinanderdividieren, was denn jetzt eigentlich komplex oder kompliziert jeweils bedeutet, weil ich glaube das wird ja ganz häufig in einen Topf geschmissen und man überhaupt nicht, das sind ganz verschiedene Vokabeln für mich auch so, ja, also.

Also total wichtig, wenn man unseren Podcast verstehen will an sich, der heißt der heißt einfach komplex und nicht einfach kompliziert, ja. Also wenn was kompliziert ist, dann habe ich es schlecht gemacht. Wenn was komplex ist, dann kann ich nichts dagegen tun. Ne, das ist das ist eine Urgewalt. Ja, es gibt halt einfach Sachen, die sind komplex, ja so wie

Software und und und also. Diesen deswegen komplex, weil sie, weil sie vielschichtig ist, weil sie, weil sie abstrakte Probleme lösen, E zum Beispiel die Biologie unseres Körpers ist komplex, ja, ist aber nicht kompliziert. Ja, es ist komplex, weil weil ganz viele ineinandergreifen muss, damit wir atmen sehen und leben können, ne. Kompliziert wird es dann, wenn ich schreibe. So, und deswegen haben wir diesen Podcast einfach komplex.

Also wir versuchen die Komplexität, die nehmen wir an, die ist so, da kann man nichts machen, wir versuchen sie ganz einfach darzustellen, ne, ich kann immer irgendwas kompliziert machen, ne, aber das ist dann halt schlecht so.

Also im besten Fall ist es nicht komplex, sondern ist so glasklar, schlechtesten falle ist aber komplex, weil das Problem komplex ist, aber es darf nie kompliziert sein und wenn ich irgendwas kompliziert mache, dann habe ich selber verbockt so das meint das so ja also schreib wenn du komplexe Probleme hast, schreib das so einfach hin, dass maximal komplex bleibt, aber nie kompliziert wird.

Sau gute Zusammenfassung. Und wenn jemand beim zuhören hier das Gefühl hat, dass wir das dann doch zu kompliziert ist, dann lass uns wissen, dann versuchen wir es aufzulösen, ja. Du, ich hab noch einen Nachtrag, hab ich ganz vergessen von Picard. Völlig richtig ist n Facebook damit noch Facebook heute meta Entwicklungsthemen was pytorch also dieses KI Framework entwickelt hat ja prima genau prima Nummer 5. Ja da ist mir nicht klar direkt

Flat is better than nested.

zum Lesen was das genau bedeutet. Flat is better than also flach ist besser als verschachtelt oder sowas. Ja genau hier haben wir das Thema, hier können wir auch beim letzten Mal aufgreifen, da ging es um die Datenstrukturen also denke die Datenstrukturen erst und dann denkt über den Code nach so. Also die Daten sind wichtig. Bei Datenstrukturen hatten wir auch eine Folge, haben wir die Möglichkeit auch wieder

verschiedene auszudrücken. Ja, wir können, wir können Sachen ja ineinander schachteln, wir haben gelernt, es gibt Objekte mit Key Value und dann kann ich auch Objekte in Objekte Schachteln, also wenn zu meinem Key Value wieder ein Objekt ist, dann hab ich wieder ebene Key values und dann kann ich wieder

ne Values machen und so weiter. Ähm, das kann ich beliebig fortführen in der Software, da gibt es keine Grenzen, eigentlich ja und und und dieser dieser Lebensspruch, der ist krass so, ja weil der hilft sich weiter. Ja ich, ich kann einfach Daten verschiedene Organisieren und entweder organisiere ich sie mehr auf einem auf einem Level, dann sind meine Kennwörter schon länger und drücken mehr aus oder ich organisiere sie in, ich organisiere hierarchisch.

Man kann sich vorstellen wie der Strukturen ne hat, jeder hat das Problem ja Google Drive, onedrive oder irgendwas, ich muss ordnerstrukturen anlegen ja mach ich jetzt also ganz viele Ordner die immer tiefer werden habe ich. Habe ich ein riesiges Hierarchiesystem, wo ich nach dem 15. Ordner finde. Hier ist das Customer PDF was ich suche ja oder bin ich eher flach unterwegs und hab wenig Hierarchien?

Ne und hier sagt ganz klar fürs Coding für Datenstrukturen bleibt flach ja geht nicht so tief runter in den Hierarchien des Macht kriegst Kopfschmerzen ne. Und total war. Ich kann nicht, ich kann nicht sagen warum. Es ergibt sich einfach, dass sich einfach viel Arbeit viel einfacher nachdenken und arbeiten lässt. Wenn ich meine Hierarchiestrukturen flacher lasse, als dass ich sie zutiefst

zueinander. Wenn ich auch totaler Fan beim Dateisystem und sowas wie Google Drive einfach die Suche zu nutzen aber alles Thema ist jetzt nicht so viel mit dem zu

Sparse is better than dense.

tun, aber OK hab ich verstanden dann nochmal 6 spars ist better Dance also weiter ist besser als enger oder dichter so in der freien Übersetzung wieder genau ich also also Spaß und dann muss ich immer also hier muss ich auch interpretiert ja gerade sowieso alles wie ich denke ja keine Ahnung ob ich jetzt hier den richtigen Ton treffen sich Peter irgendwie überlebt hat also bei Spaß und denk ich an Mathematik. Vielleicht die nicht an Matrizen.

Es gibt es gibt sogenannte Base Matrizen und Dennis Matrizen, also entweder sind die. Übrigens das von der Mathematik. Ich Hülle ja und entweder fühle ich voll oder ich lass ein bisschen dünner und drücke n bisschen dünner aus. Hier ist gesagt, so versuchs halt irgendwie dünner oder einfacher auszudrücken und macht die Informationen nicht so dicht. Muss sagen, habe ich so ein bisschen Schwierigkeiten zu interpretieren. Ich würde, sagen wir schnell zum nächsten.

Gerade freue ich mich über Kopf und Kragen, reden hier völlig

Readability counts.

fair, hat total gut readability Counts ist die Nummer 7, Lesbarkeit zählt ja. Stimmt nix da, also geht im Code wieder darum, dass ich einfach das ganze, wenn nicht der Experte laut deiner Meinung für die entsprechende Programmiersprache oder die Expertin, dann muss ich in oder dann bin ich in der Lage diese zu lesen, ohne dass ich noch Erklärungen für Kommentare nicht richtig ich kurz bevor du den nächsten vorliest gleich die 2 nächsten bitte vor ich sag doch

auswendig nein Spaß. Muss ich lernen, um Bayer zu

starten? Ne OK genau 10 Gebote, da ist ne die neuen 10 Gebote gut nochmal 8 special cases and special love to break the Rules und all Dow practically Beats Purity also soll ich es zusammen fassen wir zusammen ich glaube es ist auch ein bisschen Lyrik oder also jetzt nicht gedacht so das ganze Ding, wir machen es ja auch so ein bisschen jetzt One by One es liest sich glaube ich wenn alles durch ist aber ich versuche es mal also Spezialfälle sind nicht speziell genug um die Regeln zu

brechen. Dennoch, also Praktikabilität, schlägt die Einfachheit ja oder die Reinheit, Reinheit, Purity Reinheit richtig, ja, OK. Ja, voll gut. Also ich mag, ich mag das, weil. Hier hat es wieder was mit der, mit der auch mit einer Weisheit zu tun, die wir das letzte Mal hatten, mit Consistency. Ja, also ich hab mir ein gewisses Regelwerk angewöhnt, wie ich was mache.

Special cases aren't special enough to break the rules. Although practicality beats purity.

Mal ganz abstrakt gesprochen und es sollte nicht so viele Ausnahmen von der Regel geben. Ja oder von den Regeln ne. Allerdings ist wieder was zu tun mit fertigwerden und 100% und so weiter ich glaube hier geht es um 100%. Ja, also klar kann ich mir irgendwie überlegen und dann sollte ich auch keine Ausnahmen dazu machen, ne? Aber das Regelwerk wird nicht perfekt sein und Ausnahmen müssen halt dann passieren, wenn ich nicht schnell genug im Gehirn bin, um mir was auszudenken, was die Regeln

nicht bricht. Trotzdem Stability ist also das baut aufeinander auf, ne alle die alle die Sätze die vorher schon gesprochen werden sind ja auch wahr ja also wenn ich nicht schaffe in Counts und beautiful und so weiter was auszudrücken. Was nicht die Regeln bricht, dann brechen sie lieber ja.

Denn Practically ja, das ist wichtig, ja, wollen wir machen das ja nicht darum, dass wir uns selbst beweihräuchern und irgendwie tolles Stück Software. Also es gibt, das könnte man machen, ja, es gibt Leute, die lesen Partituren von Mozart und brauchen gar nicht hören und haben Spaß daran, dass zu sehen, wie toll das aussieht, so, ja, ich habe auch Spaß daran, sehr, sehr clean Code zu lesen, einfach zu lesen habe ich brauche, ist mir scheiß egal, was macht so, ja, ich freue mich

ja, dass man. Dass man einfach so elegantes lesen darf, so hast wie Buch H is ja nich so, aber was das hier sagt ist es geht ja schon um eine Anwendung für den Nutzer am Ende des Tages. So, ja dann bleib bitte bei 80% machst, dann machst du halt eine Ausnahme und dafür wirst du aber

fertig. Ja und es wird nicht erst in 10 Jahren fertig und ist dann total beautiful, aber nur für dich, ja. Ich finde es faszinierend, dass es diese Art, ja die soll diesen jetzt hier für Python, oder es gibt ja auch so Manifesto s für verschiedene Themen oder sowas in der Softwareentwicklung, dass sich da so eine Art und Weise philosophische Gedanken macht, Beyrich vielleicht Dinge

abschaut et cetera. Ich glaube, das hast du immer bei diesen Themen, wo so ein bisschen nerdig, ich glaube, die Physiker sind ja auch so ne Partei, die da, die machen ja

Errors should never pass silently. Unless explicitly silenced.

auch so krasse Sachen, Mathematik und so weiter, und dann stoßen an Grenzen und müssen ständig irgendwas

entscheiden, nachdenken. Die haben das ja auch so ne, die haben sich ja auch sehr gerne sehr philosophisch unterwegs coole Bücher von den von den Physikern, die sehr philosophisch sind, ja auch gut so, ich denke mal 11 und schuldigung, 10 und 11 sollte ich wieder zusammenbringen, die gehören wieder zusammen und ich hatte auch schon Interpretationen, also 10 Aros, shout never pass silently und 11 unless explicitly silenced, also Fehler sollten niemals still,

vorübergehend oder oder auftreten, ohne sich bemerkbar zu machen. Es sei denn, man möchte das explizit, dass diese nicht laut geben, sag ich jetzt mal. Ich muss zuerst dran denken beim 10. Eine offene Fehlerkultur, ja. Also die ja auch irgendwie ich Management geprägt wird. Also lieber viele ansprechen, Fingerpointing und aus den Fehlern lernen und beim nächsten Mal besser machen. Aber ich hab das Gefühl, es geht eher darum, dass man irgendwie ne, dass man mitbekommt, wenn

was schief gelaufen ist. Perfekt, genau, du hast ja fast ja. Ja, das ist das ist, ich weiß nicht, ob unsere Zuhörer wissen, aber es kann ja total viel schiefgehen. Software wenn also wir haben ja immer, wir coden, ja, das nennt man dann ja Coding Times, aber wenn die Software läuft, Runtime. Das sind ja ziemlich viele Unbekannte.

Ja, also irgendein Nutzer eröffneten File System sollen File hochladen, ja in dem Fall ist nur Kauderwelsch kaputt von innen drin das PDF oder irgendwas ja und dann sollte ich hoffe dass einlesen und kommt völlig durcheinander und dann passieren Fehler. Da gibt es 1000, Beispiele, das und was das hier sagt, ist, wenn was schief geht und das kann 2 Sachen liegen. Entweder du hast halt einfach verkackt und nicht geplant und eine Software ist Buggy.

Oder du kriegst ja was rein, was völlig unerwartet ist.

So, ich erinnere mich gerade an das Beispiel von, wir hatten mal ne Folge über Sicherheit mit Klima, Timo genau und der hatte gesagt, so hier eben wenn auf der Autobahn ein Nummernschild Detektor ist so ja und jemand hat sich irgendwie n krasses Nummernschild selber geschrieben, QR Code drauf steht so ja dann ist das auf jeden Fall irgendwie n Fehler wahrscheinlich produziert in der Software und im schlimmsten Falle und jetzt kommt ja im schlimmsten Falle gibt es gar

keinen Fehler sondern wird Silently eingebaut und damit ist ein Sicherheitsprobleme. Was hier sagt ist, sieht zu, dass wenn etwas Unerwartetes passiert, es auch wirklich ein Fehler triggert. Ja, denn in der Software gibt es ein eigenes System, fast banal, Programmiersprache, Exceptions. Also es gibt wirklich das Objekt Fehler ja und jetzt kann auch durchgereicht werden und so weiter und sofort und dann

behandeln oder auch nicht. Ja man kann sagen Shop da ich ja weiß ich du einer den erwarte ich hier den du brauchst hier nicht ich behandle dich extra ja.

Es zum Beispiel jetzt nochmal das der Fall Nummernschilder eingelesen ja und ich erkenne Text der kein Nummernschild ist und fange diesen Fehler ja und sage OK den zählst du mal als hier markierst du mal dieses Auto, dann nimmst du die Farbe auf oder was weiß ich kann ein Fahrer der will dich irgendwie hier stimmt was nicht so ja. Und wenn man schlecht programmiert oder ein bisschen fahrig ist, dann kann es schon sein, dass ein Fehler entsteht. Nirgendwo.

Der löst sich irgendwo Nirvana auf und kriegst nie. Es wird nur gelobt und nichts so. Und dann habe ich ein Problem haben Sicherheitsproblem und auch n ein Anwendungsproblem, weil das funktioniert nicht so wie man denkt und keiner weiß wie man's debuggen soll, ja nichts aufgetaucht ist. Also auch sehr wichtig.

Ja stehst du deinen Fehlern könnte man auch sagen auf dem Großen auf dem großen Platz und lass dich bloß immer alle Hochpoppen und mal irgendwo hin soll auch als Nutzer oder jetzt auch im Vertrieb von Surface ist das Nervigste für Anwender und Anwenderinnen wenn die halt irgendwas nicht funktioniert und man hat aber gar keine Ahnung warum das denn jetzt nicht funktioniert. Wie man das erwartet hätte?

Ja, das ist immer besser, da dann Transparenz auch in der Software zu haben und sagen, hier ging jetzt was schief, dann kann man darüber sprechen, ich wollte einfach etwas ins Leere laufen zu lassen, ne du musst die n bisschen die verständlich sind, aber zum Beispiel ein ganz einfacher Klassiker ne wenn du sagst Anwendung h die Internetverbindung braucht ja und du hast halt der Nutzer ist halt irgendwo und hat kein Internet und macht die auf und es geht einfach nicht das ist

halt nicht schön so für den wer weiß nicht was los ist.

Ja dabei ist total trivialer Fehler hat kein Internet also dann hilft es auch wenn die Anwendung einfach dann so n. Mindestens OP so Hey du bist offline so ja ich brauche Internet sonst kann ich nicht funktionieren als wir neulich diese diese andere aufnahmeplattform für den Podcast hier benutzt haben waren wir beide total genervt weil es hat gehakt das Video und es gab eine Latenz und wir wussten aber nicht ist das jetzt beeinträchtigt das auch die die

die die die aufnehmen ganz genau völlig Banane ja also wir hatten einfach keine Ahnung und dann haben wir halt wieder ausgestellt weil das Programm gesagt hier Video ist beeinträchtigt Aufnahme läuft hätte vielleicht weitergemacht so ja also wenn dieser Fehler nicht einfach silently irgendwie. Nicht behandelt werden, aber wir wurden halt einfach nicht in Kenntnis gesetzt. So, ja dann wirst du kennst. Ja, es gibt hier ein Fehler, dein Video ist Mist, aber Aufnahme läuft.

In the face of ambiguity, refuse the temptation to guess.

Kannst du anfangen? Hast recht. Dann kommen wir zur Nummer 12 von von 19 also geht gut voran in the Face of ambiguity Review, the Temptation to gets also im Angesicht von von Mehrdeutigkeit, Widerstehe der Versuchung zu raten, lass das Bauchgefühl weg oder was könnte man daraus ziehen? Nee, das heißt, das glaub ich nicht. Das passt so explizit und implizit. Ja, im Code willst du explizite Wege haben, wir die Software sich bewegt.

Ja, Mehrdeutigkeit ist ganz furchtbar im Code, ja wenn irgendwas wenn irgendwas nicht ganz glasklar ist und es könnte 2 Wege gehen wie du jetzt weiter gehst, dann dann versucht das nicht zu verraten vom User ja weil jetzt muss nicht passen so ja versucht das System so zu designen, dass es gar nicht erst zu mehrdeutigen Würdigkeiten kommt. Ja, das heißt, das heißt also, wenn das nicht ganz klar ist, klar ist im Software ein bisschen ja.

Wenn die einen, wenn die Eingabe des Felder nicht so designt sind, dass du jetzt nicht ganz genau weißt, ist es der oder der nicht oder irgendsowas. Dann sagen das Eingabefeld neu Apparat nicht rum, dann nicht irgendwie den ersten A oder irgendsowas und denke ja könnte schon passen. So, das ist jetzt Zuhörern einer Software ist so ja ich noch ein Beispiel, das immer so vorkommt. Du hast zum Beispiel.

Du hast ein Datenbank und basteln Abfrage und erwartet eigentlich, dass nur genau einen Eintrag in der Datenbank existiert. Zu dieser Abfrage, zum Beispiel zu einem User. Ja du erwartest ich quasi einen finden sollten nur einen geben, ne. Es könnte aber sein, es gibt irgendeinen Fehler oder so. Und dann gibt es noch zweimal. Also du machst eine Abfrage und kommt 2. Zeilen zurück aus der Datenbank, nicht eine ja, und wenn das so ist, ja dann nicht einfach den

ersten. So wird schon der Richtige sein, so ja, denn da 2 zurückkommen und erwartest aber nur einen, dann Rat nicht rum wenn ich das richtige ist, dann musst du nochmal gucken warum kommen jetzt zurück, das sollte nicht so sein, ne. Also hör auf, dass also fix das so ja heißt das irgendwie, es darf nicht mehr deutlich werden in deinem Codes und bist du irgendwie so von gilt das jetzt mehr für die Coding Time hast du gesagt oder für die Runtime?

Also muss ich in der Runtime eines Programms dann auch dafür sorgen, dass wenn der Fall auftritt, dass dann da irgendwo ne Lösung würde ich sagen ganz klar Coding Timecoding Time macht, dann macht das ordentlich so dein Ding und mit den Tests dann gemeinsam, dass man dann rausfindet und übrigens auch wieder so ein Satz, den kannst du ja auch in anderen Bereichen ist der war ja also. Also ich will auch mit

Menschlichkeit oder irgendwas. Ja, wenn du zum Beispiel haben mitarbeitergespräche irgendwas der Mitarbeiter sagt mir irgendwie sagt mir irgendwas ja und ich habe vielleicht nicht verstanden und so, das könnt ihr jetzt so meinen, ne trau mich aber nicht noch mal nachzufragen was da wirklich meint ja dann speichere ich mir irgendeine Interpretation von dem was vielleicht hab in meinem Kopf war als Chef, das ist ziemlich schlecht, vielleicht ja doch nicht so, ja.

Also wenn was wichtig ist und ich habe es nicht verstanden, dann frag halt. Hakt es ab. So ja frag halt nochmal nach so ja so wenn ich glaube ganz viel Kommunikationsprobleme sind dadurch, dass man zu schüchtern ist oder sowas, weil es einfach nicht macht, ja man redet halt was der andere gemeint haben könnte, ja. Aber raten ist vielleicht das Richtige. So an also. Bisher ist nicht an jeder Stelle, wenn es drauf ankommt, dann will ich nicht raten.

Ja dann frag ich nochmal nach, dann explizit so und dann hat es wirklich wirklich richtig oder falsch zu tun, während ein

There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch.

Bauchgefühl was ich anfangs sagte oftmals also es oftmals mehrere richtige Weg einfacher. Ich muss mich dann entscheiden, dass das nicht glaube ich verstanden ja prima. Gut, ich denke mal nochmal 13 und 14 gehören auch wieder zusammen. Bitte jetzt wirds schwierig ja hier wieder auf Englisch OK bisschen Musik anmachen, das ist so ein bisschen Hintergrund ist machen wir Sousa haben ja wenn ich das nicht machen muss. Gut Nummer 13 und 14 gehören auch wieder zusammen. So wie es aussieht.

Und ich versuche es mal ohne den Dreher, sonst korrigiere mich gerne. Burkhard ja, one and probably only one way to do it in 14 all so that way may not be the first unless your dutch so übersetzt jetzt nicht frei übersetzt. Ja, wir haben tatsächlich auch Übersetzung, die ich vorher nicht benutzt, es sollte einen und vorzugsweise nur einen offensichtlichen Weg geben, es zu tun. Auch wenn dieser Weg anfangs vielleicht nicht offensichtlich ist, es sei denn, man ist Niederländer.

OK, ich, ich vermute irgendwo zu tun. Ja du hast richtig vermutet, ich hab ja gesagt, du musst machen, angucken ist natürlich hier, ist natürlich ein Augenzwinkern so genau Guido Voss nieder und kommt als Autor der Frage ist für ihn natürlich am offensichtlichsten wie es zu sein hat und seinen Schein soll deswegen das ne also auch wenn dieser vielleicht sie ist, dann sei immer wieder ein Teil dann nochmal kurz ich hab zwar gelesen aber nicht komplett erfasst habe. Ja, pass auf.

Genau das hat natürlich noch mehr Tiefgang als nur über diesen als nur den Guido von Rossum hier irgendwie aufs Korn zu nehmen. Ich glaube, es heißt so viel wie wenn du deinen, wenn du deine dein System, also hier, worum geht es hier eigentlich? Geht die Programmiersprache Python die in sich schlüssigen, schlüssiges Ding sein soll, benutzt werden, ne. Das ist ja auch wahr für Software, die benutzt werden soll von jemand anders. Also ein Framework baust oder irgendwas.

Ja also ich, ich nehme das für uns total wahr und bar weil wir irgendeine Local Plattform machen wollen. Mithilfe derer andere Leute Anwendungen schaffen. Genau das heißt, wir machen, wir machen, wir machen einen Werkzeugkasten, der von anderen benutzt werden müssen muss. Ja, und jetzt beim Werkzeugkasten sollte es offensichtlich sein, welches Werkzeug ich für welches Problem in die Hand nehme, aber das meint das so ja. Ähm, und wenn du schön designt hast.

Und alles wieder Bill ist und alles ne einen gewissen Sinn und Logik interne ergibt, dann wird das auch irgendwie in sich schlüssig. Ja und wenn du dann ein Problem lösen willst das nächste Problem, du hast schon 20 gelöst, sonst kommt das einzige Problem. Dann wird, wenn das System gut gemacht hast, ist total klar, wie du es zu tun hast. Auch mit den Werkzeugen, die du schon geschlafen hast. Ja, findest du halt.

Du Erfindest hat keine Werkzeuge, die immer wieder das Gleiche machen oder leicht anders sogar, denn erfindest du quasi eine Lösung, wo du den 2, die du schon gut designt 2

Werkzeuge nehmen kannst. Und das dritte Problem zu lösen so. Das heißt, das mehr oder weniger ja und wenn und wenn, wenn es zu, wenn es zu fragwürdig ist und wenn das Tool zu viel Mittel anbietet, um ein gleiches Problem lösen zu können und das total fragwürdig ist und nicht weißt welche soll ich nehmen, ist das besser oder das oder das ist nicht so gut, das lässt sich nie vermeiden, dass total schwierig, ja, es gibt immer mehrere Arten und weisen was zu

zu lösen, aber wenn wir quasi deinen. Ein Framework, irgendwie nen Klaren, so eine Art Denkanstoß schon gibt wie du es zu tun hast, wenn es in sich irgendwie schlüssig ist, dann hast du es gut gemacht, sogar das heißt das was ist denn was ist denn mit powerpoint oder Google Slides oder pitch.com was auch immer man verwendet. Du kannst immer textfelder machen. Und über eine Form legen, um irgendwas in eine Form reinzuschreiben. Oder du kannst aber direkt in

die Form reinschreiben. Ja nervt mich auch total, weiß ich aber nicht wollen ist ein Beispiel dafür, dass das nicht

gelungen ist. So, ja, es ist immer wieder in jeder, es gibt schlimme Probleme auf der Welt, schon klar, aber es ist es ist in jeder powerpoint meist wild gemischt, dazwischen textfeldern und Formen eingeschrieben, das gute Beispiel ja und das ist schlimm vielleicht unter die powerpoint Jungs Entwickler vielleicht deswegen Schmerzen weil sie jetzt irgendwas darauf aufbaut, wenn zum Beispiel was ich automatisch irgendwelche Widgets.

Der sortiert oder irgendwie schon ausrichten möchtest, kannst du nicht so einfach wieder gucken. Ist jetzt alleine oder n komischen drin, irgendwas macht überhaupt keinen Sinn, dass diese Möglichkeiten gibt. Und wenn es keinen Sinn macht, lass weg, ja. Wenn man jetzt aber der Guido wäre, dann hätte der eine klare Meinung, würde sagen, ja, das ist schief gelaufen, ist historisch gewachsen und muss immer in der Form drin sein. So ist natürlich gemeint, so, ja.

Aber das ist natürlich, wenn du nicht mit dem Auto von dem Tool sprichst und hast du nicht gerade am Ärmel und fragst du, was muss ich machen, dann ja. Die Weisheit ist natürlich,

Now is better than never. Although never is often better than *right* now.

vielleicht gibt es eine Weisheit dahinter und the way to do. Aber wenn du nicht, wenn du nicht da ist, dann ist es nicht abwärts, ja. 15 und 16 gehören wieder zusammen. Nummer 15 wäre now ist besser never und nummer 16 wäre also never is often better than right now. Also jetzt ist besser als nie, das hat man auch schon mal gehört, das wäre, obwohl niemals manchmal besser ist als jetzt sofort ja, also über haste nichts überhastetes wahrscheinlich das zweite und das Erste ist leg los, ja.

Ja, voll. Es ist auch das trifft ja auch so einen wunden Punkt, so ne für alles Projektmanagement mäßige. So du hast halt n zum Beispiel ein Feature Quest hast du lösen sollst. Und zwar du musst. Das bringt ja nichts anderes. Und dann implementierst du, merkst, verdammt ich das richtig gut lösen will, dann muss ich hier und hier auch noch mal L faktorisieren ich muss nicht anfassen, ja, macht auch Sinn so, ja. Hab ich jetzt aber keine Zeit zu, ja.

Und ich glaube hier hier sagt es aus so viel wie OK, du hast schon fast keine Zeit das Feature selber zu machen. Und ja, du hast erkannt, dass du jetzt hier eigentlich noch was holen müsstest und sauber einzubauen tuts nicht so ja, also weil wenn du das jetzt tust, dann wird es nur

schrecklich. Du hast die Tests dafür, nicht die Zeit die dafür zu schreiben und so weiter das geht halt irgendwie ja und die Gefahr besteht natürlich, dass wenn du es heute nicht tust, du wirst nie tun wirst, weil was passiert, wenn das fertig ist, der nächste, das nächste Feature, du bist ja im Hamsterrad so ja auch oft, ja nicht nur wenn wir im Leben oft, wenn wir gerade über Firmen sind, im Hamsterrad da sind, ständig etwas Neues, so, ja wann

hast du schon die Zeit sagen, so jetzt hab ich irgendwie 3 Stunden Zeit, mal gucken was mache ich denn jetzt lustiges so ja da kannst du hingehen und wenn ich dir aufgeschrieben hast kannst du nochmal das gerade schön fixen so ja wenn du noch auf dem Zettel hast ja aber das heißt das so ja also. Also bevor du das ganz kurz hin Donnerstag, lass es weg und wenn es dann halt gar nicht gibt, dann gibt es halt nicht so Pech

gehabt. Ja, es ist ein Stück weit auch ne priorisierungs Thema was da einfach angesprochen wird. Auf jeden Fall wird darüber aus was du machen willst.

Priorisierung und das ist dann halt wenn du wenn du Sachen machst die potenziell lange folgen nach sich ziehen können ne wenn du musst dir überlegen, also die Grundlage dessen was wir alles besprechen ist ist an was zu werkeln, was lange lebt ja es geht hier nicht um irgendein Wegwerfprodukt, sondern deswegen passt glaube ich die Analogie zu einem zu einer Betriebsführung, ja. Also wenn du betriebliche Entscheidungen machst und willst eigentlich den Betrieb noch

irgendwie 20 Jahre irgendwie in der Welt ist. Dann hat er jede Entscheidung eine Konsequenz. Ja, und hier geht es um die Konsequenzen, ja, also bevor du warst in Eile schnell machst, was eigentlich wichtig wäre zu tun und richtig wäre zu tun, was du dann aber gar nicht umsetzen kannst. Die Konsequenzen sind schlimmer als wenn, dann lieber doch nicht so, ja weil vorher lief ja auch irgendwie schon ne. Das hilft mir halt ganz oft zu Lebensweisheiten. Ja manchmal.

Man kennt das ja selber, du bist irgendwie, du hast schon das P im Auge, hast du am besten nicht, ja, lernt man ja auch das nicht zu bekommen, aber du bist halt irgendwie schon gestresst, weil du weil einfach viel auf dem Tisch ist und du musst fertig machen, dann siehst du OK cool das wenn ich das jetzt hier noch ist, richtig elegant merkst, aber ich habe eigentlich keine Zeit und jetzt bist du innerlich in so einem Konflikt, was machst du denn jetzt entscheidest du dich ja, sagst

du jetzt dem Kunden auch nix oder wie? Ja und dann nochmal die durchlesen und dann weiß man eigentlich was machen muss aber sag mal welches P hat man da im Auge. Party des Panik P. Ach so, alles klar. Gut das Pause B im Auge haben, dann ganz cool wenn richtig Stress hast du Pause so viel besser als Panik zu haben das stimmt mal durchatmen, drüber

nachdenken genau. So 17 und 18 gehen wieder hand in Hand. Na, wobei nicht unbedingt, ja nicht so wie die anderen, aber ganz schön zusammen machen wir mal zusammen würde ich sagen, oder was würdest du sagen?

If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.

Du bist mir egal, mach du, entscheide f die Implementation des Hardware explain a bad idea. Und 18 wäre m implementation is easy to explain, it may be a good idea. Ja so also ich wieder auf meine Übersetzung, speziell wenn die Umsetzung schwer zu erklären ist. Oder die Implementierung würde ich sagen, die Implementierung schwer zu erklären ist, ist das eine schlechte Idee, wenn die Implementierung einfach zu erklären ist, kann sie eine gute

Idee sein. Ja, ja, ich liebe, ich liebe auch diese 2 Punkte und das habe ich schon oft gehört. Das ist ja auch ein bisschen die im Podcast hier haben. Es kann ja was Komplexes sein, aber wenn ich nicht in der Lage bin ist dir zu erklären, relativ einfach. Dann ist irgendwie, dann ist eine schlechte Idee. Also ganz oft haben wir ein neues Feature und ich will dir das erklären, Gerrit und wenn du das sofort verstanden hast, was er gemacht hat und wie ich es gemacht hab.

Dann könnte es sein, dass es tatsächlich n Maya könnte sein. Das ist vielleicht eine gute Idee ist. So muss man nicht nur wenn erklären kann und erstmal auf den ersten Blick total offensichtlich erscheint, heißt es noch nicht, dass man vielleicht alle Randbedingungen, alle Nebenwirkungen und Risiken davon gedacht hat, darf auch nicht so schnell sein, dass alles gut zu bestellen und sofort Release zu knallen, ja, das heißt das Maybe.

Aber wenn ich dir schon gar nicht erklären kann, was ich da gemacht hab, ja ich schon selber mich verhaspel, indem beim beim Erkläre versuch dessen was ich da getan habe ist auf jeden Fall auf jeden Fall wert wieder zu löschen. So dann hab ich irgendwie nichts gemacht oder irgendwas am nächsten morgen ich s gelöst aber es war 11:30 Uhr, also nicht 11:30 Uhr morgens sondern PM.

Ja dann muss man dazu stehen sagen kommt das nochmal erst gar nichts oder jetzt hast du jetzt hast du mich als Beispiel genommen im überhaupt jetzt hab ich schon groben Plan von von unserer Software zumindest was die tut was sie kann. Vielleicht auch zum Teil, wie Dinge implementiert sind. Ja, aber sehr begrenzt sollte man dann aber jemanden wie mir erklären können oder dann doch lieber jemanden, der vom Fach

ist. Nee, auch v hier tatsächlich das Beispiel hakt n bisschen an der Stelle genau, es geht hier, es geht hier um die Erklärung unter gleichen ja, also ich würde auch das, also hier geht es natürlich Implementation Software, also wenn ich im anderen Softwareentwickler nicht erklären kann, was gab es auf jeden Fall misst ich glaube, dass man das auch ein Level höher ziehen kann, egal ne wenn ich wenn ich irgendwas jemandem nicht erklären kann als wenn

sich Wissenschaftler unterhalten und ich kann den. Die Untersuchungen oder die das Experiment, was ich da gemacht habe, dem anderen nicht erklären und das versteht, dann war es ein mistiges Experiment. Der andere müsste das potenziell verstehen können. Ja, die müssen schon sein, sag ich mal, was den Inhalt der Erklärung angeht, so das ist,

das heißt schon. Es geht auch um Produkte und sollte auf dieses, vielleicht kann man vielleicht auch ein Stück weit übertragen, ne total Wahl für alle möglichen Bereiche. Genau nicht, kriegst dein Produkt oder den den Nutzen eines Produkts prägnant und gut zu erklären, dann muss vielleicht mal ein Produkt arbeiten, ne genau krasser Weise ist wieviel Startups gibt, sie

Namespaces are one honking great idea -- let's do more of those!

schaffen es nicht irgendwie ihr Produkt zu erklären, man sogenannten Elevator Pitch ja also du sagst du hast 3 Sätze, sag mal machst du ja und es nicht schaffst, dann hast du irgendwie, dann musst du dich nochmal machen, dann ist es nicht so gut so last but not least und 19 sind schon angelangt. Namesspaces A One hunting great idea, let's do more of those also Namensräume sind eine großartige Idee, lasst uns mehr davon machen.

Ja, ja, das ist jetzt ja, das ist total nervig, und das ist als letztes Ding noch mal so, ich glaube, das war es, glaube ich, Tim Peters mit Mitgabe an an an dem, was er gerne hätte. Namensräume Namespaces ist ein Konzept der Software.

In vielen Programmiersprachen gibt es das sehr ausgeprägt, zum Beispiel E Plus. Und das führt dazu, dass du, wenn du Namen vergibst, es geht ja auch alles viel um Benamung in der Software variablennamen Funktionen haben und so weiter und die Namen lesbar machen wieder ja und und kurz ja wenn es zu lang ist auch nicht lesbar und so weiter und dann gibt es das Konzept der Namensräume, dann kannst du ganz oben, das ist der Namensraum, Users oder irgendsowas ja und darunter gibt

es Variablen und Funktionen, die kannst du dann irgendwie nennen, die sind alle quasi im Kontext users. Ja da musst du nicht immer schreiben. User unterstrich Authenticate oder User was weiß ich. Ja, was du müsstest, wenn du nicht diesen Kontext gibst. Und ist das nicht so ausgeprägt mit dem Namen? Jetzt nicht gerade, was der aktuelle Stand ist so, aber es ist aber eine gute Idee, wenn du, wenn du wenn du lesbaren Q

Zen of Python

schreiben willst, dann ist es nicht schlimm irgendwie Namen festzulegen, oben und unten in dieser Bubble bewegst du dich dann halt in Sams Bilder, die kannst du auch wieder verschachteln. Übrigens wir namentlicher flach, ja vielleicht besser geht wir sind durch darf ich eine Sache machen weil es mir irgendwie herzlichen darf ich einmal komplett vorlesen im August irgendwie wirklich schön ne ja absolut ich will dich nicht aufhalten o cool dann mach ich

das. Und dann vielleicht auch ich weiß gar nicht, wieviel Minuten wieder gequatscht haben wir von mir aus den Sack zu, es sei denn du hast noch fragen, irgendwie, aber nee, dann sollen das die letzten Worte sein, ich sage schon mal Tschüss und Burkhard wird euch nochmal die. 19 Grundprinzipien der Softwareentwicklung unter diesen auf Python vortragen. Ja, ich sag dann auch schon mal vielen Dank fürs Zuhören und wir spielen dann unser Auto da rein,

während ich vorlese. Ich stelle mir gerade sehr cool vor, ich nehme mal schwarzer weg. Wir haben eine morgendliche Aufnahme, dass meine Stimme nicht nächstes mal abends erst wird. OK, aber egal, es geht los. Beautiful ist better than ugly, explicit is better than implicit. Simple ist besser dann complex complex is better dann complicated. Flat ist bei dir ned spars is better dance rehability counts. Special Cases and Special love break the rules all so practically Beats Purity.

Aros Schütz Never Pass silently unless explicitly silenced. In the face of ambiguity Review tentation Tues. Dash one and only one obvious way to do it all that way not p obvious at first unless your dutch now is better than never. Olson never is often better than right now. Ist der Implementation is hard explained the bad idea if the implementation is easy to explain, it may be a good idea namespaces one hundred idea it's two of those.

Vielen Dank fürs Zuhören dieser Folge von einfach komplex. Die Folge gefallen? Dann lass uns doch ne gute Bewertung da oder Teile die Folge mit jemanden aus seinem Netzwerk für Kritik zufolge Anregungen und Fragen für neue Folgen freuen wir uns auf deine Email an Podcast datei.com Abonniere jetzt unseren Podcast und keine Folge mehr zu verpassen bis zum nächsten Mal. Tschüss aus Hamburg h.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android
Open in Metacast