Hallo allerseits,
Heute kam meine Tochter (37, Programmiererfahrung = 0) mit der Idee auf mich zu, dass wir zusammen C++ lernen könnten. (Meine Programmiererfahrung liegt ca. 40 Jahre zurück ). Sie möchte die ein oder andere App für ihr MacBook Pro basteln. Sie möchte zum Beispiel, dass eine Kamera einen Schauspieler aufnimmt und dass dann passend zu dessen Bewegung eine Linie an die Wand projiziert wird. (Geht sowas überhaupt?)
Was wäre eurer Meinung nach einfacher: Ihre Ideen als Anfängerin mit C++ oder Swift zu realisieren?

Fragt: Holger

OK, da Du ja vermutlich für Dich in Anspruch nimmst, dass Du mit Swift klarkommst, erkläre mir doch mal, wofür let und var stehen. (Damit meine ich nicht, welchen Variablentyp sie bezeichnen, sondern warum sie das mit den Buchstaben tun, mit denen sie es tun.)

Ihr helft dem Fragesteller mit eurem Kleinkrieg kein bisschen btw.

Ich würde denken, dem Fragesteller sei mit dem Verweis auf das Vision-Framework geholfen.

Keine Ahnung, warum die so heißen, wie sie heißen. Weißte, ich habe mir die Bezeichner einfach gemerkt und verwende sie für verschiedene Variablentypen. So mache ich das mit allen Sprachen, die ich lerne. (Sogar bei meiner Muttersprache ist es mir meistens egal, warum die Wörter so sind, wie sie sind.)

Da ich ahne, in welche Richtung sich das hier entwickelt, bin ich dann mal hier raus. Dem Holger ist vielleicht ein kleines bisschen geholfen, und für alles weitere bin ich zu alt.

Weia, ich muß Dir da widersprechen. Objective-C ist nur einfach, wenn man die C-Hölle darunter schon als verstanden voraussetzen kann. Dann ist das Buch zu Objective C tatsächlich nur wenige Seiten dick. Zudem kommen in moderneren Obj-C APIs diverse sehr subtile Fehler, die man sich über die Blocks-API (ungewollte starke Referenzen und Zyklen) einhandelt.

Ich würde jedem Anfänger, der unbedingt eine App schreiben will, Swift ans Herz legen. Geht es nur einfach ums Programmieren an sich, würde ich von allen C-artigen Sprachen Abstand nehmen und eher sowas wie Python oder OCaml raten.

Also Objective-C ohne C und ohne Cocoa-Frameworks. Das klingt fast nach "sei Epsilon kleiner 0".

Siehst Du, Du scheiterst also auch bereits an der Typisierung, genauso wie ich. Denn in meinem Verständnis scheitert man, wenn man nicht versteht, warum man tut, was man tut, sondern es aus Pragmatismus tut, „weil es nun einmal so ist“. Und Swift nötigt einen dazu, so zu agieren, ohne dass sich irgendein Sinn dahinter erkennen ließe. Das ist das, was ich mit „intellektueller Bankrotterklärung“ meine.

Ich bin ein sehr friedfertiger Mensch mit einem geringen Agressionspotential, aber wenn jemand, obwohl er es besser könnte, eine solche intellektuelle Bankrotterklärung abliefert und dabei bleibt, dann ist das etwas, was ich aus allertiefstem Herzen verachte. Jede Faser meines Körpers sträubt sich dagegen, damit in Berührung zu kommen.

But that’s just me. (Stimmt nicht, Steve Jobs hätte haargenauso gedacht.)

Öhm, die Einschätzung habe ich doch aber gar nicht geäußert?

(Und habe sie auch nicht. Auch ich denke, dass jedenfalls nichts dergleichen passieren wird, solange Tim Cook am Ruder sitzt. Sollte danach Craig Federighi (oder ein Gleichgesinnter) seine Stelle einnehmen, könnten sich meiner Einschätzung nach die Dinge verändern, aber auch dann wohl kaum zurück zum „alten“ Objective-C, wie es war.)

Was für C-Hölle? Ich kenne nur ein muckelig beheiztes C-Zimmer.

Kann man ernsthaft von sich behaupten, man sei Programmierer, wenn man kein C kann, die „Mutter aller Sprachen“?
Ich bin der Letzte, der behauptet, man könne Objective-C nicht noch deutlich verbessern.
Für den Zweck dieses Threads sollte das ja auch geklärt sein.

Generell konditioniert einen Swift gerade als Anfänger aber leider dazu, Dinge einfach hinzunehmen statt zu verstehen, wie am obigen let/var-Beispiel exemplifiziert.

Grmbl, es ging um den Vergleich von Swift und Objective-C. Bei beiden muss man gleichermaßen Cocoa lernen, wenn man für das Apple-Universum programmieren will, also kann man das für den Vergleich als Konstante rauskürzen.

Und wie man ohne C-Kenntnisse in der Welt des Programmierens dauerhaft zurechtkommen will, erschließt sich mir auch nicht. Das ist einfach die lingua franca für Algorithmen, elementare Codebeispiele und Bibliotheken.

Hier vielleicht noch ein interessantes Video zu Swift Playgrounds. Damit man mal eine Vorstellung bekommt, was man mit wenig Code auf dem iPad schon machen kann. So ab Minute 36.

WWDC 2019 Swift Playgrounds

Entschuldigung, aber das ist kompletter Unsinn! Wenn man plain Objective-C macht, womit man im Apple Universum sehr sehr weit kommt, braucht man absolut keine C-Kenntnisse.

Es gibt zwar Zeiger und Referenzen, aber die kann man völlig unabhängig und losgelöst von C und mehr als Teil von Objective-C selbst betrachten. Ich kann nicht mehr die Anzahl der ObjC-Apps sagen, die ich für Kunden entwickelt und in den Store gebracht habe, aber C habe ich bei max. 1% verwenden müssen.

Kurrioserweise hatte eine der ersten Apps ich ich mit Swift (1.0!) in den Store gebracht habe, mit den höchsten C-Anteil … was aber der Tatsache geschuldet war, dass da eine bestimmte Verschlüsslung implementiert werden musste und zu Zeiten von Swift 1.0 sah es da ja noch sehr mau aus.

Fun Fact: Ich hatte mich damals mit dem Kunden auf Swift geeinigt, weil die App eine sehr lange Lebensdauer haben und einfach zu pflegen sein sollte … damit, dass Swift bis zur Version 5 nie abwärtskompatibel sein wird, hatte ich nicht gerechnet … und so kommt es, dass das erste Update der App auch gut 5 Jahre brauchte.

Aber ich wäre Dir dankbar, wenn Du mir darlegst, wo man im normalen ObjC-Alltag so massive C-Kenntnisse benötigt.

Wen interessiert das? Ganz ehrlich? Let steht für konstante Eigenschaften und var eben nicht. Die IDE hilft einem sogar dabei, wenn die merkt, daß eine Variable auch als Konstante gesetzt werden kann. Jede Sprache, die ich bis jetzt gesehen habe hat so ihre Eigenheiten. Deal with it!

Dich müsste ja PowerShell-Scripting z.B. in die Pure Verzweiflung bringen. Denn da ist so einiges Inkonsistent. Aber soll ich deswegen bei meine Job keine Powershell verwenden? Dann müsste ich mir einen anderen Job suchen.

Ich glaube, das siehst nur du so. Genau das ist doch ich den verschiedensten Sprachen ohnehin anders. Programmieren heißt für mich auch, sich auch die verschiednen Sprachumgebungen einzulassen.

Nicht hier, aber hier* habe ich das schon so aufgefasst.

*Bei mir springt MTN beim klicken des Links nicht zum entsprechenden Kommentar, darum noch mal als quote:

Ist eigentlich recht einfach: "let" wurde zuerst in BASIC genutzt und leitet sich tatsächlich aus dem englischen Wort "to let" (im Sinne von etwas stehen lassen) ab. "var" ist hingegen einfach die gängige Abkürzung für "variable". Für einen Native Speaker ist die Bedeutung also relativ selbsterklärend.

Und noch eine persönliche Meinung: Objective-C ist Vergangenheit. Wenn alle Frameworks auf Swift umgestellt sind wird Apple den Zopf abschneiden. Spätestens wenn die letzte iOS Version, die kein Swift UI kann veraltet ist, wird Apple den Umstieg forcieren.

Damit hör es jetzt für mich endgültig auf...

Ich weiß nicht mehr genau wo ich das mal gehört/gelesen habe, aber mir wurde das mal so erklärt:
let wird als "lass es so sein, belasse es so" (frei übersetzt)
var ist ganz offensichtlich: variable

also deshalb die Wortwahl.

Wen interessiert das? Ganz ehrlich?
[/quote]
Mich. Und jeden anderen Menschen, der ein ähnliches Arbeitsethos wie ich und ein ähnliches Verständnis eines aufgeklärten, von Vernunft geleiteten Individuums wie ich hat.

In einer Vernachlässigung dieser Aspekte kommt ein minderer Qualitätsanspruch zum Ausdruck, den ich niemals akzeptieren würde. Und Apple unter Steve Jobs war eines der wenigen kommerziellen Unternehmen, das von diesem Arbeitsethos durchdrungen war. Jobs selbst war es jedenfalls.

Deswegen empfinde ich Swift bei Apple ja regelrecht als Tragödie.Sorry, aber Marsmenschen sind mir zugänglicher als diese pragmatische Geisteshaltung. Damit werde ich mich niemals abfinden.Ja.Ja.

Swift-Weg wieder verlassen ≠ zurück zum alten Objective-C

Siehst Du, bei mir fängt es da an.

Dann mach mach mal.

Wenn es für dich da aufhört, dann mag das ok sein, aber dann solltest Du auch aufhören Menschen, die Objective-C u.a. wegen der Syntax sowohl klarer als auch besser als Swift finden, zu beleidigen.

Es ist nun mal ein Vorteil von ObjC, dass man den Code fast schon wie menschliche Sprache lesen kann und er sich dadurch zu grossen Teilen selbstdokumentiert. Und gerade die Selbstdokumentation wurde mit Swift ziemlich zerstört.

Das wird nicht passieren. Warum auch?

Wann habe ich jemanden beleidigt?
Weil ich gesagt habe, das jemand zu den "ewig gestrigen" gehört?
Ist das schon eine Beleidigung? Wenn dem so ist, sage ich offiziell "Entschuldigung"

Ich bin nicht sicher, ob ich die Frage richtig verstehe, aber das "let" hat man aus ML-artigen Funktionalsprachen übernommen (Haskell hat es auch). Es dient dazu, ein neues Binding für einen Ausdruck zu erzeugen. Da Swift aber nunmal noch "richtige" Variablen braucht, hat man mit "var" noch ein gleich langes Keyword dafür gesucht.

Wer sich erinnert: In Swift 1.0 war auch noch eine ans Currying angelehnte Syntax noch verbreitet, bevor sie entfernt wurde. Man hatte anfangs noch mehr Funktionalsprachen im Sinn als Swift designt wurde.

Wenn Du SwiftUI als Maßstab nimmst und dich dabei an der Historie von Swift orientierst, dann sind wir noch sehr sehr weit davon entfernt.
Ich habe im letzten Jahr sehr viel mit SwiftUI gemacht und kann Dir sagen, dass es für einfach bis mittelkomplexe UIs gut bis so naja Nutzbar ist. Aber es kommt der Punkt, an dem wird SwiftUI absolut unbrauchbar bzw. da ist die Mängelliste von SwiftUI sehr sehr lange! Und nicht umsonst heißt es SwiftUI, denn z.B. Drucken oder andere Farbräume als sRGB mag SwiftUI garnicht.

Ja, schon klar, dass man so zu verstehen versucht. Das let kommt vom biblischen Let there be light!, das kulturgeschichtlich in der Folge in mathematischen Beweisen zu Let 𝑆 be the set of integers > 1 … wird.

Das Problem ist, dass let ein Verb ist und variable ein (zudem noch ohne Not abgekürztes) Nomen. Es gibt aber keinerlei sachlichen Grund, hier zwei verschiedene Wortarten zu nutzen. Wenn überhaupt, würde ein Verb Prozessualität, also einer veränderbaren Variablen, zuzuordnen sein und ein statisches Substantiv der unveränderlichen Variablen. Es ist bei Swift aber genau umgekehrt.

Wie man es dreht und wendet, die Verwendung von let und var in Swift ist inkonsistent. Wenn aber selbst an den elementarsten Grundfesten einer Sprache bereits Gedankenlosigkeit herrscht, will ich eigentlich gar nicht mehr wissen, wie dann erst der Rest aussieht …

Und ich hatte dich auch schon weiter oben darauf hingewiesen:

Genauso gut kann auch fragen, ob jemand ernsthaft programmieren kann, wenn er die Konzepte hinter Haskell oder Prolog noch nicht verstanden hat.

Wieso ich? Mich zwingt ja keiner zu PowerShell-Scripting. Und zu Swift auch nicht.
Ich stelle eine Ungleichung auf und Du sagst, sie wird nicht passieren. Wenn Du mich jetzt noch aufklären könntest, was es heißt, dass eine Ungleichung passiert …

Siehst Du, das ist so das Maß an gedanklicher Klarheit, das einem noch bleibt, wenn man zu lange Swift goutiert hat.

Hallo allerseits,
Meine Tochter würde sich auch gerne an der Diskussion beteiligen, aber sie konnte sich mit ihrer E-Mail Adresse (info@xyzabc.de) nicht beim Forum anmelden: Daher kopiere ich ihren Text - natürlich unzensiert - :

Der Prof an meiner Uni meinte dass Game Engines wie Unity bei Echtzeitperformances nicht so perfekt funzen. Gerade überlege ich, TouchDesigner mal auszuprobieren. Evtl lässt sich das sogar mit Modul8 oder MadMapper kombinieren, da letztere schon alles enthalten ausser der Bewegungsreaktivität. Bei der kinect bin ich auch schon gelandet, da gibt's wohl ne neue Version von, Kinect Azure. Wenn ich die mit TouchDesigner nutzen könnte, wäre ich vllt schon weiter. Ich denke auch dass ich das Rad nicht neu erfinden muss, das macht ja wenig Sinn. Um dem Forum noch einmal spezifischer meine Aufgabenstellung nahezulegen, für deren Erfüllung ich definitiv eine Everestbesteigung auf mich nehmen würde: ich suche nach Tools, gerne schon vorgefertigt, mit denen ich folgendes tun kann

- Videos auf dreidimensionale Objekte mappen
- Diese Videos sollen sound- und bewegungssreaktiv sein
- Im besten Fall soll die Footage aus Malerei bestehen, dh dass ich möchte, dass meine malerei durch Bewegung und Sound beeinflusst wird a la: wenn Person xy die Hand hebt, bewegen sich alle roten Pixel nach oben.
- Es soll sich um live-performances handeln

Ich bin bereit, dieses Ziel auch mit viel Gehirnanstrengung umzusetzen, jedoch steht das erreichen des Ziels vor dem Wie. Wenn es Shortcuts gibt, gerne. Über Tipps freue ich mich, Diskussionen über die Qualität von Programmiersprachen sind an dieser Stelle für mich inzwischen irrelevant.

Danke für die rege Diskussion!
Inga

Oooops, wie das? Was passiert? Ist info der tatsächliche Wert und xyzabc ein Platzhalter?

Falls Du nicht weiterkommst, schicke doch mal eine kurze Mail an bug@mactechnews.de.

Was mir noch nicht klar ist: Wo sind diese Videos denn dann zu sehen? Sollen die auf die sich bewegenden Personen projiziert werden? Oder sollen die Zuschauer an irgendeinem statischen Ort ein projiziertes Video sehen, in dem Bewegungsabläufe stattfinden, die denen sich zugleich an anderer Stelle bewegender Personen entsprechen?
Hast Du in die von mir verlinkten WWDC-Videos mit dem Vision-Framework schonmal reinschauen können? Geht das in die richtige Richtung?
Klar, das wurde zu einer Nerd-Diskussion. Wenn überhaupt „richtiges“ selbstgeschriebenes Programm auf dem Mac, dann vermutlich mit Vision-Framework und damit eben Swift. Ansonsten je nach anderer Lösung, für sowas wie TouchDesigner braucht man ja keine Programmiersprache.

Mit let (lass Pi den Wert 3,14 haben) definiert man eine Konstante, mit var reserviert man den Platz für eine Variable. Das weißt Du doch sicher ganz genau. Deine Antwort auf Weia's Frage ist auch nicht viel gescheiter als die Frage selbst. (Es gibt keinen Variablentyp, für den Du let verwenden kannst.)

... Tut mir leid: Jetzt bist Du wieder drin.

Es geht aber schlicht drum, warum die var oder let heißen, nicht was sie tun

Ich rate dringend, dieses Forum bezüglich dieser Frage zu velassen und sich in den einschlägen Foren zu informieren, in denen Threads nicht von techreligiösen Eiferern gekapert werden, was hier mehr als offensichtlich auf zum fremdschämen ignorante Weise geschehen ist. Noch schlimmer ist aber, dass sich hier anscheinend niemand zu Wort gemeldet hat, der auch nur irgendwas in der gewünschten Richtung jemals gemacht hat, der Thread daür aber inzwischen lächerlich lang ist.

Wie der Prof darauf kommt, das Engines, deren ursprünglicher Hauptzweck Echtzeitanwendungen sind, etwas anderes sind Spiele nicht, ausgerechnet in ihrer Kernkompetenz nicht so perfekt funzen sollen, das ist mir ein Rätsel. Wie in meiner ersten Antwort erwähnt, werden die Engines heute im Filmbereich eingesetzt um die Bluescreens durch rundum Displays zu ersetzen, die in ECHTZEIT die SFX und Hintergründe und somit eine realitische dynamische Umgebungsbeleuchtung und Reflektionen auf Schauspielern und Kulissen zu erzeugen. Wahrscheinlich hat der Prof es bisher einfach nur auf zu schwacher Hardware einfach übertrieben? Anders kann ich mir das nicht erklären.

Die Augabe schreit förmlich nach Unity.

Es is schön, was Apple da mit dem Vision-Framework anbietet. Aber es ist immer noch wesentlich aufwendiger als mit Unity und du bist bei Swift, ObjC und Apple-Frameworks an eine Plattform gebunden, ohne jegliche Möglichkeit der Portierung deines erworbenen Wissens. Obald du in Zukunft bei deinen Projekten ein Feature benötigst, das Apple nicht anbietet, kotzt du im Strahl! In Unity kannst du, wenn du auf dem Niveau angelangt bist, das dem entspricht, das notwendig ist um dein Projekt mit Swift zu erledigen, ausnahmslos alles einbinden, da du dann auch eigene PlugIns für schreiben könntest. Gleichzeitig hast du dann mit C# eine Sprache gelernt, die universell auf allen Platformen auch ohne Unity einsetzbar ist.

Videos auf dreidimensionale Objekte zu mappen ist ein Kinderspiel in Unity. 1, 2, 3, fertig! Schafft jeder, der copy/paste beherrscht.
Panoamavideos? Auch kinderleicht

Objekttracking ist bei Unity plattformübergreifend über die AR Foundation möglich.
Die Kinec-Lösung erschien mir nur am naheliegendsten.

Die Strategie von Unity ist seit Jahren auch Dinge anzubieten, die überhaupt nichts mit Spielen zu haben. Siehe:

Hi Weil,willst du jetzt allen Ernstes die Qualität eine Programmiersprache daran festmachen, wie die Namen der Schlüsselwörter gewählt wurden?
Falls ja, dann müssten die Sprachen wie Kolin (da verwendet man fun bei der Definition einer Funktion, egal ob es einem Spaß macht oder nicht) oder Lisp mit dem Schlüsselwort car (was definitiv nichts mit Autos zu tun hat) ja schon fast körperlichen Unbehagen bereiten.

Oder drehen wir mal den Spieß rum! Was hätte man bei Swift anstelle von let und var verwenden sollen damit es dir besser gefällt?

Hi,

Dass das Wort variable ein Nomen ist, ist durchaus diskussionswürdig. Laut dem Cambridge Dictionary ist es ein Adjektiv, das Oxford Dictionary und Merriam-Webster führen es in 2 Kategorien, wobei in beiden Werke jeweils die erste Kategorie Adjektiv ist und Nomen erst die zweite ...

Interessanterweise wird im Oxford Dictionary das let auch als zweites in der Kategorie Nomen geführt, wobei als Bedeutung A period during which a room or property is rented. aufgeführt wird.

Man liest sich
Peter

Wir sollten das Thema wirklich langsam mal abschließen, sonst zeigt uns MacKaltschale noch mehr seine kalte Schulter, als er es eh schon tut, aber: Jein.

Wäre Swift eine ansonsten durch und durch gelungen Programmiersprache, dann könnte man darüber sicher hinwegsehen, auch wenn ich es selbst dann als einen Makel betrachten würde.

Aber so ist es halt gleich ein erster, bezeichnender Hinweis auf die gedankliche Verwahrlosung, die einen in dieser Sprache erwartet.

Ich würde den Punkt vielleicht auch nicht so stark machen, würde ich Swift mit einer anderen Sprache vergleichen. Aber Objective-C ist solch ein Leuchtturm an Lesbarkeit, dass sich dieser Aspekt aufdrängt.
Bei Kotlin finde ich das in der Tat schauderhaft, da ich mit der Sprache aber keine Erfahrungen habe und daher nicht weiß, ob das symptomatisch für den Rest der Sprache ist, halte ich mich mit einer Beurteilung zurück. Lisp ist eine andere Baustelle; das kommt aus einer völlig anderen Zeit mit winzigen Bildschirmen und ohne Auto-Vervollständigung, da war noch nachvollziehbar, mit Abkürzungen zu arbeiten. 2014 war es das nicht mehr.
Objective-C macht diesen Unterschied ja gar nicht, aber wenn man ihn denn machen wollte, hätte ich vermutlich auf die bewährte Cocoa-Terminologie mutable/immutable zurückgegriffen.
Ja, kann auch ein Adjektiv sein; ein Verb ist es aber in keinem Fall.
Dasjaabernu was vollkommen anderes …

Nachdem dieser Thread nun zur Diskussion über Swift ausgeartet ist, möchte ich meinen Senf auch noch dazu geben:

1. Die Beschreibung von Swift finde ich gut. Man kann sie verstehen, ohne daß man einen Doktor in Computer Sience hat. Der Playground ist für lernende eine reine Freude.
2. Gut finde ich auch, daß es nun endlich Optionals gibt. Jeder kennt das Problem der uninitialisierten Variablen. Apple geht das nun (mit ziemlichem Aufwand) per Software an, obwohl Sie doch auch die Hardware selbst gestalten. Kleiner Trost: Die Turing Maschine versagt hier auch.
3. Automatic reference counting ist auf den ersten Blick ein Fortschritt in punkto Speichersicherheit, setzt aber voraus, das der Programmierer über own und weak kräftig mithilft. „Automatic“ ist das nicht. Das schafft nur der Garbage Collector, und der kostet Zeit. Allerdings gibt es Techniken, mit denen der GC parallel zum Programmablauf arbeiten kann. Eine entsprechende Hardware-Unterstützung wäre hier zusätzlich sehr hilfreich. Leider auch hier Fehlanzeige
4. Lesbarkeit: Wenn man die type inference voll ausreizt, dann kann man den Programmtext bis zur Unleserlichkeit verstümmeln. Außerdem hat der Compiler nun keine Möglichkeit mehr, vor Unstimmigkeiten zu warnen. Schmunzeln mußte ich als ich in den ersten Versionen von Swift herausfand, daß Gleitkomma-Konstanten mit weniger als acht Ziffern per type inference der Typ float zugewiesen wurde. Nachdem Apple dann am Jahresende Probleme mit der Datumsrechnung bekam, wurde das schnell geändert.
5. Etwas verwundert bin ich auch, daß bei Enumerationen Gleitkommazahlen als raw value zugelassen sind. Bisher war ich hier nur diskrete Typen gewohnt. Überhaupt hat sich die Enumeration in Swift zu einem Super-Gala-Monster-Typ ausgeweitet.
6. Damit kommen wir zur Überschneidung der Typen: Enumerationen, Strukturen und Klassen zeigen in ihrer Semantik große Überschneidungen. Bei natürlichen Sprachen ist das schön, damit Literaten und Poeten aus dem Vollen Schöpfen können. Bei Programmiersprachen liebe (und erwarte) ich eher einen orthogonalen Entwurf. Statt dessen wuchert die Sprachdefinition immer weiter aus. Daß man fast alles über subsripts ansprechen kann, erzeugt bei mir keine Begeisterung sondern nur Kopfschütteln.
7. Gewünscht hätte ich mir eine Rückkehr zu den Block orientierten Sprachen, unter Einbezug des Threads als aller äußersten Block. So wandert der Thread wieder in die Bibliothek. Ja, ich weiß, daß das nicht einfach ist und daß dann der Speicherzugriff hier und da mehr Zeit kostet. Leider hat die Sprache C alles über Bord geworfen, was Zeit kostet. Dadurch und durch die Offenlegung der Pointer ist C die unsicherste Programmiersprache der Welt entstanden, mühsam gezähmt durch diverse Anbauten. C und seine Nachfolger, zu denen ich auch Swift zähle — trotz der gefälligeren Syntax, haben uns einen überbordenden und schwer zu verwaltenden Heap gebracht. Zur Zeit der Blockorientierten waren Speicherlecks für den Programmierer jedenfalls kein Thema.

Breche hier ab, nachdem ich mir einiges von der Seele geredet habe.