Also, ich bin jetzt seit 20 Jahren in der Softwareentwicklung tätig und habe schon an vielen Konferenzen und Vorträgen teilgenommen. Ich muss jetzt mal an dieser stelle ein wirklich großes Lob aussprechen. Super ausführlich ohne auszuschweifen, direkt auf den Punkt erklärt. Obwohl ich wohl unbewusst vieles weiß und beim zuhören häufig mit dem Kopf nicke, habe ich auch viele aha Momente und lerne doch noch was dazu;) Also wirklich super erklärt, schön anzuhören!
@thenativeweb
2 жыл бұрын
[gr] Vielen, vielen Dank 😊
@MrRiesable
2 жыл бұрын
Kurz und knackig - super erklärt! 👏
@thenativeweb
2 жыл бұрын
[gr] Vielen Dank 😊
@jeyt436
2 жыл бұрын
Hä? (Das war mein erster Gedanke)
@thenativeweb
2 жыл бұрын
[gr] 🦆😉
@kyrospace
2 жыл бұрын
Ich mache viel mit NodeJS also Javascript oder Typescript. Im Falle von Javascript habe ich Duck Typing also angewedet ohne zu wissen, dass es so heißt. Viel mehr hab ich es immer indirekt bemerkt, nämlich weil ich es schrecklich unkonfortable finde - besonders in größeren Projekten - nicht zu wissen von welchem Typ ein Objekt ist oder zu sein hat. Deswegen hab ich bei Zeiten Typescript gelernt, um bei den Typen den überblick zu behalten. Bei Java war das wie beschrieben ja eh kein Thema.
@ThomasJunkOS
2 жыл бұрын
Ein sehr nettes Video. Allerdings scheinen mir drei Punkte ergänzenswert: 1) SOLID ist ein Prinzip, das orthogonal zur Typisierung steht. "Single Responsibility" etwa hat etwas mit dem Umfang von Klassen zu tun - unabhängig, ob und wie die Sprache typisiert ist. Und "Interface" meint nicht unbedingt das, was Java- oder C#-Entwickler meinen, wenn sie das Wort lesen. Es geht darum, dass - analog zum "S" in SOLID - Einfachheit und Wiederverwertung leitende Designprinzipien sein sollen. Während ich in Java bspw. explizite Interfaces definieren kann, die dann eine Klasse implementiert, kann ich in anderen Sprachen "Mixins". Es sind Prinzipien, die man beherzen kann, wenn das gewählte Paradigma "Objektorientierung" heißt - egal ob die genutzte Sprache dynamisch oder statisch typisiert ist. 2) Über Vor- und Nachteile von Typisierung werden Menschen vermutlich noch so lange streiten, bis AIs sich selbst Sprachen ausdenken und alles selbst implementieren. Ob generell das eine oder das andere besser ist, läßt sich definitiv nicht beantworten. Man sollte sich nur bewusst sein, dass beides eben unterschiedliche Herangehensweisen brauchen: Während Typfehler vom Compiler abgefangen werden, muss man derartiges in dynamischen Sprachen über Tests erledigen. Mit Tests wird ein zum Status quo gewünschtes Verhalten festgelegt und kann wiederholbar überprüft werden. Wenn man also an einer Stelle einen Typfehler hatte, lässt sich der in einem Test festhalten und die Codestelle fixen. Wenn man vorwiegend Typfehler produziert sollte man seinen Programmierstil und die Wahl der Sprache überdenken. Ich finde es etwas schnoddrig, zu behaupten, dass "Typescript so viel besser ist für komplexe Anwendungen". Ich finde medium.com/javascript-scene/the-typescript-tax-132ff4cb175b zu dem Thema sehr aufschlussreich. Wie gesagt, wenn man in einem Umfeld arbeitet, wo Fehler mit Typen überproportional häufig sind, ist Typescript eine gute Wahl. Oder wenn Entwickler es so gewohnt sind, ist es ebenfalls eine gute Idee. Eine schlechte Idee ist es, Typescript mit einem Team einzusetzen, die keine Erfahrung mit Typisierung haben und das Wort "any" etwas zu häufig benutzt wird. 3) Die Entwicklung einiger Sprachen zu Konstrukten wie "var" oder "auto" (Typinferenz), wo man das Arbeiten mit Typen bei der Deklaration dem Kompiler überlässt - der es zur Not eh besser weiß. So wird die Syntax weniger verbose.
@BenjaminBuch
2 жыл бұрын
Bei C++ gibt's ducktyping zur Compilezeit, nennt sich Template Argument ;-) Während man bei Runtime ducktyping in nicht stark typisierten Sprachen cryptische Fehlermeldungen zur Laufzeit bekommt, sind es bei C++ Templates oft cryptische Fehlermeldungen zur Compilezeit. Um das zu umgehen, kann man natürlich am Anfang einer Funktion die Argumente auf bestimmte Eigenschaften testen und so lesbare Fehlermeldungen generieren. C++20 hat das für Template Argumente nach laaaanger Entwicklungszeit in Form von Concepts auch endlich eingeführt. Ducktyping ist Fluch und Segen, aber mit ein paar zusätzlichen Preconditions für die Werte, wird der Fluch gebändigt. In modern C++ sogar ohne Laufzeit Overhead ^^ Ich möchte auch noch Mal anmerken, das C++ OOP zwar unterstützt, es aber keineswegs eine reine OOP Sprache ist, sondern eine Multiparadigmensprache. Man kann in C++ genauso gut auch rein funktional oder prozedural programmieren.
@xVirtualMagicx
2 жыл бұрын
Nuja. Ich schreibe jetzt seit über 30 Jahren Software. Ich habe inzwischen unzählige Basic Dialekte und Sprachen kennengelernt. Unter allen Sprachen die ich im Laufe der Zeit gelernt habe, ist JScript die fürchterlichste von allen. Eben weil es alles zulässt. Es erfordert extrem viel Disziplin "vernünftigen" JScript Code zu schreiben, wenn die Anwendungsfälle komplexer werden. Da war Type Script schon ein extremer Fortschritt. Aber für komplexe Projekte würde ich immer eine streng typisierte Sprache verwenden, weil es die Zuverlässigkeit und Lesbarkeit von Code extrem erhöht. Ich folge keinen "Prinzipien"... Ich folge nur zwei grundlegenden Dingen: Lesbarkeit und Wartbarkeit. Keine Theorie, und das gilt auch für SOLID, hält der Realität stand. Aber für Anfänger stellen sie hervorragende Leitplanken dar. Also sollte sich jeder zumindest mal damit beschäftigt haben.
@momstopflashing
2 жыл бұрын
09:44 in der zu testenden Klasse: 'es wird naemlich an der Stelle keine Ente erwartet, an der das Schild "Ente" klebt, es genuegt wenn ein Onjekt uebergeben wird, dass so aussieht wie eine Ente und sich so Verhaelt wie ein Ente [...] ob dieses Objekt nun darueber hinaus auch watscheln und schwimmen kann [...] ist zumindest an der Stelle ziemlich irrelevant". Da eingangs das Gedicht mit allen Eigenschaften der Ente genannt wurde, waere hier ggf zur Verdeutlichung ein Hinweis gut, dass aus "Sicht" der zu testenden Klasse, die Ente nur dieses eine Merkmal hat? Anyways, imo super erklaert und dickes +1 fuer die SOLID-Referenz. "Composition over inheritance" als Ansatz koennte imo noch verlinkt werden. Da ich ab und zu feststelle, dass "Dependency Inversion Principle" mit "Dependency Injection" gelegentlich verwechselt/gleichgesetzt wird (und ja, fuer mein denglish deserve ich einen falcon-punch): "Dependency Injection": Abhängigkeiten werden nicht von Funktionen oder Klassen selbst erzeugt, sondern per injection bereitgestellt. Im Video die Ente der Logger-Klasse. Das "Dependency Inversion Principle" empfiehlt, sich bei Abhängigkeiten immer auf Abstraktionen zu verlassen, nicht aber auf Implementierungen (oder: auf Interfaces).
@marcotroster8247
2 жыл бұрын
Python Protocols, baby! Beste Erfindung ever 😄
@madmanX1314
2 жыл бұрын
Schon fies von euch! Jetzt klick ich schon zum zweiten Mal auf eins eurer Videos, weil das Thema (wieder mal) genial ist und mich brennend interessiert, und dann ist es noch gar nicht verfügbar. Immerhin sind es diesmal nur 15 Minuten bis zur Premiere 😂
@thenativeweb
2 жыл бұрын
[gr] Viel Spaß gleich 😊
@michaelmueller9635
2 жыл бұрын
The one and only ...Tori Amos - Winter ❤️ ....quack quack Winter (Live) kzitem.info/news/bejne/y6OhlnWMh4RzfI4
@thenativeweb
2 жыл бұрын
[gr] „Winter“ - ich liebe dieses Lied 🥰
@argamon2025
2 жыл бұрын
Wie immer sehr schön erklärt. Ich bin aber nach wie vor kein Fan dieser "freien" Sprachen. Fehler erst zur Laufzeit zu finden... hatte das lange genug mit Visual Basic ;) Das einzige was ich nicht verstanden habe ist das mit dem "willst kein Mocking Framework" einsetzen. Also zumindest im C# Umfeld sehe ich das quasi als Standard an. Die Einarbeitungszeit in NSubstitute, Moq & Co hält sich in Grenzen. Ich will ja nicht behaupten, dass es keine Ausnahmen gibt, aber um Deine Frage zu beanworten, das ideale Interface hat genau eine Methode. Natürlich kann man das als Defizit ansehen zu jeder Klasse einen Interface Zwilling zu haben. Vielleicht fällt einem das nach 20 Jahren .NET auch nicht mehr auf ;)
@argamon2025
2 жыл бұрын
@@sven2529 Da bin ich ganz bei Dir. Golo hat in dem Video nur mehrmals betont, wieviel Aufwand es in streng typisierten Umgebungen eine Attrappe fürs Testen zu erzögen. Also konkret, wenn ein Interface 42 Methoden hat, meine zu testende Methode davon aber nur eine benutzt. Dann muss meine Attrappe trotzdem alle 42 Methoden implementieren. Dafür gibt es eben Frameworks, womit sich der Aufwand auf ein "Mache Attrappe und das ist der Code für die eine Methode" reduziert. Dieses Konzept gibt es in all diesen Platformen und man sollte da schon von Kenntnis haben, bevor man sinnlos Zeit in unnützen Code steckt. Selbstverständlich hat er auch recht damit, dass es ein Problem ist, dass man in loser typsierten Sprachen erst gar nicht hat. Hier ist es eben persönliche Präferenz, was man dann einsetzt. Ich lebe lieber mit diesem Problem als mit anderen Problemen. Aber es ist natürlich auch wichtig ab und an mal über seinen Tellerrand zu schauen
@StefaNoneD
2 жыл бұрын
Also die Vorteile von Ducktyping halte ich alle für kurzfristig, denn spätestens bei Wartung, Refactoring, Fehlerbehandlung (ich mag die meisten Fehler zur Compilezeit sehen und nicht zur Laufzeit, wie bei dynamisch typisierten Sprachen), werden einem die ganzen Nachteile ins Gesicht geklatscht. Je größer ein Projekt ist, desto heftiger die Nachteile von dynamisch typisierten Sprachen. Übrigens hat C# einen Standard-Logger-Interface ILogger. Wenn das eine Sprache nicht bietet, dann kann man selbst ein Interface schreiben und die Implementierungen können bspw. Wrapper-Klasse sein. Man braucht dafür auch keine Vererbung, weil Komposition und Delegation vollkommen ausreichen. Man muss Interfaces übrigens nicht zwingend komplett implementieren, wenn sie eine Basis-Implementierung haben. Ich bin kein Fan von Basis-Implementierungen, aber das würde dein Problem, dass alles implementiert werden muss, umgehen. C++ hat über Templates übrigens eine Art "Duck Typing", nur ist das immer noch statisch typisiert.
@thenativeweb
2 жыл бұрын
[gr] Dass rein dynamische Sprachen bei größer werdenden Projekten zunehmend dynamisch werden, da bin ich bei Dir. Deshalb finde ich ein optional-statisches, strukturelles Typsystem (so wie TypeScript das macht) eigentlich schon ziemlich ideal. Man hat mehr Flexibilität als mit einem rein statischen, hat aber durch das strukturelle bei Bedarf einen Großteil der Unterstützung, die man haben will. Das mit ILogger in C# kannte ich noch nicht - das ist allerdings kein Bestandteil direkt von .NET (und schon gar nicht von C#), sondern ist Bestandteil der .NET Extensions (was aber nichts daran ändert, dass das natürlich sehr praktisch ist). Ich vermute, dass es das zu der Zeit, in der ich noch C# und .NET gemacht habe, noch nicht gab, und ich es daher nicht kenne.
@pixelwurmi4406
2 жыл бұрын
Und wenn einer die Webtechnologien gut erklären kann, wird es wohl ein Golo Roden sein :)
@thenativeweb
2 жыл бұрын
[gr] Danke schön 🥰
@bibamann
2 жыл бұрын
Ich kenne den Begriff "Ente" im IT Bereich ganz anders. 😂 Und zwar gab es in den 90ern mal das Schachprogramm "battle chess", wo die Figuren alle herrlich animiert waren (Der Turm fraß glaube ich immer die gegnerischen Figuren, wenn er sie schlug, usw.). Und die Entwickler fanden ihr Spiel perfekt, aber wussten, dass ihr Projectmanager (oder product owner) immer was zu meckern hatte, weil sonst wäre sein Job ja nicht mehr relevant. Also bauten sie eine Ente ein, die der Königin immer hinterher watschelte, was wohl auch (absichtlich) ziemlich bescheuert aussah. Und der PM / PO meinte dann "ist ja alles super - aber bitte entfernt die Ente". Und das Prinzip verfolgt man angeblich (selber noch nicht erlebt) teilweise heute noch - die Software ist super, aber man weiss, man wird wen vor sich haben, der aus Prinzip was bemängelt, darum baut man eine "Ente" ein.
@thenativeweb
2 жыл бұрын
[gr] YMMD (You Made My Duck ^^) 🦆🤣
@boothtml9069
2 жыл бұрын
Hay wieder super Video vielen Dank👍 Wenn es schon um Enten geht kannst du Mal ein Video zur Gherkin Language machen? Passt finde ich gut zu deinen Themen.
@thenativeweb
2 жыл бұрын
[gr] Danke! 😊 Programmieren mit Enten und Gurken? Nehmen wir noch Toast.js dazu, und es wird was … 🤣
@fredheine8650
2 жыл бұрын
Den kann ich nur zustimmen mach bitte mal ein Video zur Gherkin Language (Cucumber) wenn es passt, würde mich sehr darüber freuen.
@ettoreatalan8303
2 жыл бұрын
Schön erklärt. Die 2 Enten im Hintergrund wurden hoffentlich nicht aus einem Badezimmer entführt.😏
@thenativeweb
2 жыл бұрын
[gr] Danke schön 😊 Und was die Enten angeht: Die wurden für das Video gekauft. 🦆
@lordasterios1137
2 жыл бұрын
Ein Daumen hoch alleiin für Kapitel 2. Das ist echt starrk erklärt.
@thenativeweb
2 жыл бұрын
[gr] Vielen, vielen Dank 😊
@orange-vlcybpd2
2 жыл бұрын
Wie immer kurz und verständlich erklärt! Vielen Dank!
@thenativeweb
2 жыл бұрын
[gr] Danke schön 😊
@qui-gonkenobi4574
2 жыл бұрын
falls einer es nicht findet: Tori Amos: Yes, Anastasia kzitem.info/news/bejne/q4OeyoCpqaalnXo 😂
@thenativeweb
2 жыл бұрын
[gr] 😊
@dagogilein
Жыл бұрын
Abonniert!! Sehr sympathisch und der Content ist Top!!
@thenativeweb
Жыл бұрын
[gr] Vielen, vielen Dank 😊
@FIIRdesu
Жыл бұрын
Was das Typsystem angeht ganz klar: strukturell > nominell Seit ich mit TypeScript arbeite erscheinen mir Java/C# geradezu archaisch und beklemmend. Einen Wermutstropfen gibt es leider: Da bei TypeScripts graduellem Typsystem die Angabe von Typen optional ist, lädt dies zu mangelhafter Typisierung ein, die man insbesondere bei Code von Drittanbietern antreffen kann.
@VeryBlackMan
2 жыл бұрын
Finde ich sehr gut erklärt warum JavaScript gut ist, wo man damit an seine Grenzen stößt und womit es gelöst werden kann.
@thenativeweb
2 жыл бұрын
[gr] Danke schön 😊
@VeryBlackMan
2 жыл бұрын
@@thenativeweb durch das Fehlen der Interfaces wird der Code nicht unnötig beim Duck Typing aufgebläht, wie in anderen Sprachen. Typescript nimmt diesen Vorteil wieder weg. Schön wäre es in Vscode ein Plugin zu haben, der jedes Objekt statisch analysiert, welche Objekte als Parameter hier passen könnten und schlägt es als Autocomplete vor. Dann könnte man sich JsDoc und Typescript sparen.
@XrEmoZz
2 жыл бұрын
Also für die verstaubte Programmiersprache Abap von SAP kann ich sagen, das wir über interfaces ein fake Objekt bauen. Wir haben auch ein statisches Typsystem, müssen also das interface in einer globalen Klasse definieren. Funktioniert dann aber auch ganz gut, wenn wir testen wollen. Wir haben an vielen komplexen Klassen interfaces, womit dann fake Klassen gebaut werden können.
2 жыл бұрын
Hallo schöne Übersicht - die Definitionen sind zwar ein bisschen wackelig (Nominal kommt AFAIK davon das Typen erstmal durch den "Namen" also durch den Bezeichner den ich beim Programmieren wähle identifiziert werden - aber egal). Die Übergänge sind aber nicht so eng wie man vielleicht denkt (schönes Beispiel: Records in PureScript) und je nachdem was Du mit Deinen Typsystem machen willst können nominale Typsysteme unter Umständen mehr. Vielleicht willst Du ja auf Typebene ausdrücken können, das zwei Typen, auch wenn sie gleich aufgebaut sind eben nicht gleich sind (Beispiele: newtypes/typeclasses in Haskell, Dependency Injection in OO-Sprachen, ...) In der IT scheint es im Allgemeinen einfach keine "silver bulltest" zu geben ... ich finde das ist auch gut so ;) (Wäre doch schade wenn wir alle nur auf die EINE Art und Weise entwickeln würden ... ich finde es schön, dass da immer was kreatives/subjektives dabei ist).
Пікірлер: 53