5 Gedanken zu „WMR142 – Autos Raus!“

1. Woll ihr euch nicht in Verbotspodcast umbennen, fands ehrlich gruselig (Auto- u. Vegandiskussion)

   Antworten ↓

   • Gruselig ist das Gegenteil: Beliebig viel Auto-Fahren, Fleisch-Essen, etc. und das auch noch als normal & richtig darzustellen. Das ist, was im Effekt uns allen eine lebenswerte Zukunft verbietet.

     Zur Antibiotika sei noch eine feine, zynische Ironie aufgezeigt: die zerstoeren die ja die Darmflora, sodass die nicht mehr mitisst, also die Tiere mehr/alle Kalorien aus’m Futter selbst aufnehmen. Effizienz, YOLO!

     Kaputte Darmflore ist an sich ungesund, Massentierhaltung ist aus sonst eher elend und die mutliresistenten Erreger raffen dann menschliche Patienten dahin. Lose, lose at it’s worst, obwohl die Antibiotika ja gerade uns selbst helfen sollten.

     Wie solche Fleischproduzenten mit Antibiotika umgehen ist, als ob die Polizei am Feierabend ihre Dienstwaffen beim Waffennarren abgibt, weil der sich ja dafuer interessiert!

     So eine Situation sollte selbt bei Fleischessern einen gerechten ‚Solchen Produzenten gebe ich mein Geld nicht!‘-Zorn erzeugen.

     Antworten ↓

2. Die Erklärung von SwiftUI vs. UIKit war so derart schlecht, dass man sich ernsthaft Fragen muss ob Max eigentlich jemals ernsthafte iOS Entwicklung betrieben hat.

   Beispiele:
   – SwiftUI ist Objektorientierung in Hochpotenz. Genauso wie UIKit. Der Unterschied ist die imperative Programmierung mit UIKit vs. dem deklarativen Stil in SwiftUI. Das ganze Framework ist trotzdem hochgradig generisch objektorientiert.
   – was das Layout betrifft ist es bei iOS schon seit Jahren die Realität deklarativ zu arbeiten. Wer in den letzten Jahren immer noch Frames geschubst hat statt Autolayout zu verwenden hat entweder nur mit sehr altem Legazy Code zu tun gehabt, oder den Anschluss verloren.
   – SwiftUI wird selbstverständlich nicht immer neu gezeichnet. Stattdessen wird auch hier der deklarierte Tree mit dem aktuellen Stand gedifft und nur das neu gezeichnet was sich wirklich geändert hat. Die aktive UI, bzw. das darunterliegende Constraint System hat also selbstverständlich einen sich verändernden State.

   Tatsächlich habe ich auch durch sowas immer weniger Spaß an diesem Podcast…

   Sicher kann man jetzt einfach sagen „dann hör doch was anderes“. Aber es war ja mal anders und dann kann man ja zumindest mal sein Bedauern zum Ausdruck bringen.

   Antworten ↓

   • Hallo Torben! Ich glaube du hast missverstanden was ich gesagt habe und nicht so genau verstanden wie swiftUI funktioniert.

     SwiftUI ist nicht objektorientiert, was zum Beispiel daran klar wird, das es keine Objekte und Klassen verwendet – alle views sind structs und keine Klassen, also auch keine Objekte. Auch fehlen jegliche Lifecycles wie bei Objekten – swiftUI views werden nicht verändert, sondern einmal erzeugt, gezeichnet und dann verworfen. Das passt ja auch sehr gut zu Swift, was ja auch den Stellenwert von Objekten gegenüber Valuetypes massiv nach unten geschraubt hat. Du deutest das ja selbst an, als du erwähnst das der alte Tree gegen den neuen gedifft wird – in einer objektorientierten Implementierung gäbe es ja nichts zu diffen, da man ja lediglich sich ändernde Objekte hat, die man also gar keinen vorher/nachher Zustand vergleichen kann.

     Das nicht immer alles neu gezeichnet wird ist mit klar, ist aber lediglich eine interne Optimierung, ein Implementation detail von swiftUI die mich als Entwickler (und die Hörer unseres Podcasts) nicht zu interessieren braucht – swiftUI Würde exakt so weiter funktionieren wie es heute funktioniert wenn es immer alles neu zeichnen würde, es wäre eben nur nicht so effizient.

     Zu Autolayout: mir ist klar was das ist und ich setze es durchaus auch für kleinere Projekte ein, wo Performance, Wartbarkeit und Erweiterbarkeit nicht so wichtig sind und es z.B. wichtiger ist auch unerfahrene Entwickler oder Grafiker schnell mal eine Änderung durchführen müssen. Für die Erklärung im Podcast war das aber egal, weshalb ich da abgekürzt habe. In Projekten mit vielen Entwicklern wird man autolayout aber eher vermeiden, weil man ohne Interface Builder einfach zu viel Boilerplate Code schreiben muss und sich Interface Builder Dateien nur sehr schlecht versionieren lassen – wenn man in einem Pull Request oder Diff ein storyboard oder xib sieht ist es nich mehr wirklich nachvollziehbar was sich jetzt eigentlich geändert hat, was Code Reviews zu einem Glücksspiel macht. So kannte ich bei Facebook nicht ein einziges Projekt das Xibs oder Storyboards verwendet, bei Google ist deren Einsatz explizit verboten (u.a. auch wegen deren Buildsystem) und alle Entwickler die ich von Apple kenne lehnen den Einsatz von Interface Builder explizit ab. Wenn man aber Interface Builder nicht nutzt ist der Nutzen von Autolayout noch fraglicher – es ist relativ langsam, man hat keine Kontrolle wann Layoutet wird, man kann ins Layouting nicht manuell eingreifen (ich musste neulich in einen View an eine Stelle Zeichnen, an die ein anderer View autolayoutet wurde – es gibt keinen Weg informiert zu werden wann ein Autolayout Durchgang abgeschlossen ist. Es ist nicht mal möglich IB autolayout constraints beim Laden des views zu disablen.

     Wie gesagt: bei kleineren, überschaubaren Projekten mit wenigen Entwicklern kann man durchaus Interface Builder und Autolayout einsetzen. Sobald dein Projekt aber etwas größer wird oder die Anforderungen anspruchsvoller würde ich dir raten die heißen Teile der Codebase zu refactoren bevor du zu viele Probleme damit bekommst.

     Antworten ↓

3. Hallo 🙂

   ich mach mir schon länger Gedanken über Verhältnissmäßigkeit. Grundgedanke ist folgender:
   Unverhältnissmäßige Dinge sind unverhältnissmäßig und sollten entweder
   a) nach gesundem Menschenverstand und pragmatischen Aspekent nicht exisitieren
   oder
   b) dennoch exisitierende unverhältnissmäßige Dinge gesetzlich verboten werden.

   Es gibt das Verhältnissmässigkeitsprinzip als rechtsstatliches Prinzip ->
   https://de.wikipedia.org/wiki/Verh%C3%A4ltnism%C3%A4%C3%9Figkeitsprinzip_(Deutschland)die

   Gerade am Beispiel von Blech overflow in Innenstädten müsste das doch jurisitsch durchsetzbar sein. Autos auf’m Land sind verhältnissmässig. In Ballungszentren aber nicht, weil man keins braucht und alle darunter leiden.

   sry für den formlosen Beitrag.

   jetzt noch Blumen:
   wmr hat war vor 4 Jahren meine erste Podcast Erfahrung, und ich bin Fan. Keep it rolling 🙂

   cheers
   sash

   Antworten ↓