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

Ob so etwas wie die genannte Anwendung leichter zu realisieren ist, hängt vor allem am verwendeten Framework, weniger an der Sprache.

Wenn man moderne Programmierung lernen will, kann man es sich mit C++ ganz schön versauen. Es hat mit den neuen Versionen auch alle Features moderner Sprache, aber die ganzen alten, schlimmen Sachen gibt es halt auch immer noch. C++ kann aber auch sehr performant sein, wenn man es richtig gut kann. Wenn Du natürlich C++ kannst, dann kann das natürlich helfen, wenn man es jemanden zeigen will.
Bei C++ müsste man erst mal darüber nachdenken, mit welchem Framework man so eine App schreiben könnte, vielleicht Qt?

Swift ist vom Sprachdesign her viel moderner und du hast die Apple-Frameworks und gute Einstiegshilfen.

Objective C könnte ein guter Kompromiss sein.

Konkret gibt es bei der Anwendung auch verschiedene Möglichkeiten das zu realisieren. Das eine ist Motion Capturing, das andere, was mir einfällt ist eine Videoanalyse.

C++ ist auf der Apple-Plattform ein (geduldeter) Fremdkörper. Das also ganz sicher nicht.

Objective-C oder Swift. Ich bin ein großer Objective-C-Fan, aber viele finden Swift „moderner“. Es benutzt mehr der heute gängigen Syntax, ich finde es aber schwerer zu lesen. Dafür kann man keine Speicherfehler machen, was für Anfänger vielleicht hilfreich ist.

Für Anfänger ist Euer Vorhaben allerdings ausgesprochen anspruchsvoll. Ich müsste da auch erstmal recherchieren, wie man sowas macht.

Daher ein vielleicht entscheidendes Auswahlkriterium: Schaut mal, ob und was für Codebeispiele Ihr für Eure Aufgabenstellung im Netz findet. Ihr müsst die gar noch nicht im Detail verstehen, es geht nur um die verwendete Sprache:

Ist das C oder C++, dann nehmt als Basis Objective-C, das sich leicht mit C und relativ leicht mit C++ verbinden lässt. Swift hingegen ist eine Insel. Ist das Problem in Swift komplett lösbar, prima. Aber falls nicht, wird es unnötig schwierig. (Die Idee hinter Swift war zunächst, eine möglichst narrensichere Sprache mit der heute üblichen Syntax für kleine iOS-Programme anzubieten, die programmtechnisch gesehen meist trivial sind und nicht in tiefe Tiefen hinabsteigen müssen so wie Ihr vielleicht bei dem Video-Code.)

Jedenfalls Respekt für und viel Erfolg bei Eurem Vorhaben! Ist Deine Tochter technisch angehauchte Künstlerin?

Unter diesem Kriterium ist Swift so sehr Insel, wie Objective-C, C++ oder meinetwegen Rust. In all diesen Sprachen lassen sich C-Bibliotheken (und damit auch C++ Bibliotheken) einfach und problemlos einbinden.
Und sorry, aber das ist völliger Quatsch. Die Idee hinter Swift war von Anfang an, Programmierer anzulocken, die von der steilen Lernkurve Objective-Cs abgeschreckt wurden. Mit der Größe oder „Tiefe“ der Anwendungen hat das nun wirklich gar nichts zu tun.

@Holger1111
Das angesprochene „kleine“ Programm ist ein deutlich ambitioniertes Vorhaben, insbesondere für einen Programmieranfänger. Daher zwei Anmerkungen von mir:
1. Ein Programmierer wählt die genutzte Sprache nach dem Problem (gerade bei so komplexen Problemen), nicht umgekehrt. Und ich bin mir nicht sicher, ob C++ oder Swift für das genannte Problem die richtige Wahl sind.

2. So sehr ich C++ schätze: das ist keine Sprache um Programmieren zu lernen. Das ist eine Sprache für Leute, die C gut kennen und mit dem objektorientierten Paradigma vertraut sind. Die Lernkurve ist einfach extrem steil. Mit Swift werdet ihr deutlich schneller (motivierende?) Erfolge verzeichnen.

Ihr müsst euch in jedem Fall klar darüber sein, dass ihr - als Anfänger - sehr viel Zeit (abhängig davon wieviel Zeit ihr täglich erübrigen könnt) mit den Grundlagen verbringen werdet (und das meine ich wörtlich), bevor ihr an solche komplexen Sachen denken könnt. Das wird ein Marathon, kein Sprint!

Es geht aber nicht um das Einbinden von Bibliotheken, sondern von Code.
Welche steile Lernkurve? Aufgrund seiner Nähe zu natürlicher Sprache ist Objective-C ja wohl mit die am einfachsten zu erlernende Sprache der Welt. Jeder des Englischen mächtige Laie kann bei vielen Objective-C-Programmen ziemlich problemlos verstehen, worum es geht. Versuche das mal mit dem unter semantischen Inkonsistenzen, Perl-ähnlichem Regelwust und AbKüFi leidenden Swift …
Aber selbstverständlich hat es das. Als Sprache für kleine Progrämmchen mit ein paar Standeard-GUI-Elementen wurde es gegenüber Tim Cook gepitcht. Für wissenschaftliche Anwendungen, die auf dem großen Reservoir von C-Code aufbauen müssen, und für systemnahe Unix-Programmierung ist Swift ziemlich ungeeignet.

Swift ist prima für simple Programme von schreibfaulen Skript-Kiddies, die es nicht mal schaffen, Speicherfehler zu vermeiden, und so ist auch das intellektuelle Niveau dieser Sprache. Eine der verheerendsten Fehlentscheidungen der Cook-Ära.

Weia
Komm schon, willst Du hier ernsthaft abstreiten, dass Objective-C eine ziemlich steile Lernkurve hat? Das kann ich nicht ernst nehmen.

Und das nicht jede Sprache für jeden Anwendungsfall geeignet ist ist ja wohl ne Binse. Ich würde auch keine großen Datenverwaltung in PROLOG schreiben (zumindest nicht freiwillig), trotzdem ist das eine - für ihren Zweck: logische Kalküle - ziemlich gute Sprache.

Abgesehen davon: Selbst wenn 100% des vorhandenen Codes auf C oder C++ aufbauen, kann (wohlgemerkt „kann“, nicht „muss“) es trotzdem sinnvoll sein, neue Module in einer anderen Sprache zu schreiben. Wobei ich bei wissenschaftlichen Anwendungen tatsächlich eher Go (Stichwort Nebenläufigkeit) oder Rust (wegen des starken Typsystems und der Performance) sehen würde.

Aber der OP wollte weder systemnah noch wissenschaftlich programmieren. Er bezeichnet sich selbst als Anfänger und da gibt es deutlich geeignetere Sprachen als C++ oder Objective-C, und eine davon ist eben Swift.

Das das ein ziemlich arroganter Kommentar ist, habe ich Dir ja bereits mehrfach dargelegt. Und ganz ehrlich: Jeder C/C++/Objective-C Programmierer, der behauptet in einem nicht trivialen Programm keine der klassischen Speicherfehler einzubauen (egal wie erfahren er ist), lügt. Entweder weil sein Code noch nie auf Herz und Nieren geprüft wurde, oder weil er es sich (oder anderen) nicht eingestehen will.

Es ist praktisch unmöglich in C/C++/Objective-C keine Speicherfehler einzubauen, wenn es komplexer als „Hello World“ ist. Beispiele?
Stringverarbeitung C. Referenzhandling in C++. Das (von C geerbte und verschlimmbesserte) unterirdisch schlechte Typsystem von Objective-C.

Warum wohl kämpfen von Apple über Google bis Microsoft bis heute alle großen Entwicklerfirmen mit derartigen Altlasten? Weil die alle unfähig sind?

Das Problem mit C++ und anderen älteren Sprachen ist doch schlicht, dass sie nicht funktional „by design“ sind. Man kann damit funktional programmieren, aber man wird nicht wirklich in die richtige Richtung „geschoben“.

Bei Swift ist halt echt die Frage, ob die gewählte Aufgabe mit den Apple-Frameworks leistbar ist. Wenn nicht, ist guter Rat möglicherweise teuer.

Woran ich bei der Aufgabe gedacht habe, ist die Homecourt-App, die mal in einer Apple Keynote gezeigt wurde und die Fähigkeiten des damals aktuellen iPhones zeigen sollte.

Ja, das will ich. Ich kann mir keine noch einfacher zu erlernende Sprache vorstellen. Ich habe als jemand, der von Mathematik und Philosophie kam und noch nie in seinem Leben zuvor eine Zeile Programmcode gesehen hatte, Objective-C an einem Wochenende so gut gelernt, das ich mit dem Programmieren beginnen konnte. (Ich rede nicht von den Cocoa-Frameworks – das ist eine Aufgabe für viele Jahre …  – und C, um das man natürlich am Ende nicht herumkommt bei Objective-C, dauert auch länger …)

Wo zum Teufel gibt es irgendetwas Schwieriges in Objective-C?
Dann lässt Du’s halt bleiben.
Binsen haben aber halt die Eigenschaft, wahr zu sein. Insofern ist der Hinweis hier doch angebracht.
Wenn sich herausstellen sollte (was ich jetzt nicht überblicke), dass sich die Aufgabenstellung nur lösen lässt mit tiefem Eintauchen in Video-Code wie z.B. den von ffmpeg, dann ist man aber in einer sehr ähnlichen Situation.
Wenn es aber in Swift keine vorgefertigten Funktionalitäten für die gestellte Aufgabe gibt, dann stimmt das eben nicht. Ich bin mir sehr sicher, dass es kein in Swift geschriebenes Video-Framework gibt, in dem sich die gewünschte Funktionalität hinzufügen ließe.

Du kannst mir das gerne auch noch mehrfach darlegen, ich werde meine Auffassung dennoch nicht revidieren.

Ich kann gar nicht so arrogant sein, wie ich es an dieser Stelle gerne wäre.
strncpy?
C++ zu verteidigen mache ich mich nicht anheischig.
Nicht alle. Es würde ja einer reichen. Und den gibt es. Wenn ich mir die macOS-Versionen der Cook-Ära anschaue, gibt es bei Apple sogar deutlich mehr als einen davon.

Gut, so betrachtet wäre das dann doch wieder ein Argument für eine Skript-Kiddie-Sprache, in der man keine Fehler machen kann.

OK, Blocks können pfrimelig sein, aber soooo schlimm finde ich sie nun auch wieder nicht. Bei Swift scheitere ich ja schon an der Typisierung …
Eben.
Guter Gedanke! Müsste man nur noch wissen, in welcher Sprache und mit welchen Frameworks die App erstellt wurde.

Ich will euch den Spaß nicht nehmen, aber vermutlich ist das Idee zu ambitioniert. Die o.g. App verlangt mindestens ein iPhone XR, was darauf deutet, dass die Neural Engine der CPU benutzt wird.

Ihr müsst nicht nur eine Sprache lernen, sonder auch etwas über Mustererkennung, ML usw...

Allgemein gilt, wenn man etwas für MacOS/iOS programmieren will, sollte man Swift oder Objective-C nehmen, wobei Swift einfacher und moderner sein soll.

Swift !

Sorry, aber was für ein Blödsinn...

Solch überheblicher, polemischer Unsinn ist für die Beantwortung der eigentlichen Frage nicht hilfreich. Und ich traue dir, lieber Weia, auch zu, dass du das weißt und nur stänkern willst.

Ich bin Informatiker, habe im Studium C und Java und dann danach iOS-Entwicklung mit ObjC gelernt, und weiß deshalb: Das ist nicht leicht. Swift ist meiner bescheidenen Meinung nach für Programmieranfänger sehr viel leichter zu lernen und zu debuggen als (Obj)C, solange man die Finger von den neuen Sprachfeatures der letzten zwei, drei Jahre lässt, die meiner Meinung nach den Programmcode komplett unlesbar machen können. Auch um Combine und SwiftUI sollte jeder Anfänger einen weiten Bogen machen, denn das ist weder lesbar noch mit vertretbarem Aufwand für einen Anfänger zu debuggen, wenn mal was schief geht.

Das Argument, man sei auf Apple-Frameworks beschränkt, wenn man sich für Swift entscheidet, ist (natürlich) Unfug, ein kleiner Ausflug nach GitHub sollte da Klarheit schaffen. Im Jahre 2021 dürfte nur noch für die allerhärtesten Spezialfälle die Verwendung von C-Frameworks nötig sein, damit werden (und sollten) Programmieranfänger kaum in Berührung kommen.

Würde mich freuen, wenn die Diskussion hier mehr auf die Belange des Fragestellers zielen würde statt die (lächerliche) Fehde zwischen ObjC und Swift weiter zu befeuern. Ich kann beide, benutze mittlerweile ausschließlich Swift, mag ObjC trotzdem gerne und kann nicht verstehen, warum manche Programmierer so wenig offen für neue Sprachen sind, dass sie sie mit solchen "Argumenten" wie oben zu lesen runtermachen müssen.

Wenn _das_ Deine Antwort auf die massiven Probleme der C-Strings sein soll (angefangen bei der String-Ende-Kennzeichnung bis hin zu Multibyte-Zeichensätzen), dann bin ich aus der Diskussion raus. strncpy() löst genau ein Problem von unzähligen, und das nicht mal sonderlich gut (siehe Multibyte-Zeichensätze).

Vielleicht sollte man noch mal die Frage in den Raum stellen, ob es sich bei dem Projekt der Tochter zwangsläufig um eine Echtzeitumsetzung während einer Aufführung handelt (so interpretiere ich und alle anderen hier offensichtlich auch die Beschreibung), oder vielleicht doch um die Ergänzung von bereits aufgezeichnetem Bildmaterial. In letzterem Fall ergäben sich über Spezialsoftwares ganz andere und sicherlich wesentlich leichter umzusetzende Möglichkeiten.

Und mal so am Rande: Eure Grundsatzdiskussion ist ja tatsächlich interessant, aber vielleicht solltet ihr mal etwas Rücksicht auf den Fragesteller nehmen, dem als Anfänger mit diesen Details und einer teils ideologisch geführten Diskussion bei seiner Frage nicht sonderlich weitergeholfen wird.

C++ würde ich vermeiden. Zu complex und "historisch gewachsen", damit viel zu anspruchsvoll für Einsteiger.

Objective-C: Ohne vorherige C-Kenntnisse auch nicht besonders einfach. Hat man sich aber einen Unterbau an C Wissen angeeignet, dann ganz OK.

Swift: Wahrscheinlich die Sprache der Wahl auf Apple-Plattformen für Newcomer. Kann man das Benutzerinterface auch gleich mit SwiftUI machen. Zwar moderner als C++, aber durch die Vielzahl der verbauten Sprach-Features nicht so einfach, wie Apple PR es suggeriert.

Klare Sache: Swift.

Und auf YouTube nach den Seminaren von Prof. Paul Hegarty von der Stanford Uni suchen. Die sind echt top.

Ganz andere Richtung: Das beschriebene Problem lässt sich sicherlich auch filmtechnisch lösen.

Jetzt mal nur beispielhaft: Der Schauspieler steht vor einer Wand und hat einen Laserpointer im Ärmel. Alle Laser-Lichtpunkte auf der Wand werden nach dem Dreh (in der Postproduction) zu einer schwarzen Linie, die dann scheinbar vom Schauspieler im fertigen Film in dem Moment durch die Bewegung an die Wand gezeichnet wird.

Du merkst aber schon, dass Du Dir gerade selbst widersprichst, oder?

Aber bevor ich weiterschreibe, stelle ich gleich mal klar, dass ich ObjC liebe und, wenn ich die Wahl hätte*, dann würde ich ObjC jederzeit Swift vorziehen.

Warum sollte es das sein?
Es ist eher anders herum! Menschen, die schon einer bestimmten Syntax folgenden Sprachen (C, Java, PHP) beherrschen, haben Schwierigkeiten sich die scheinbar unorthodoxe Syntax von ObjC zu gewöhnen. (Eigentlich werden immer nur die eckigen Klammern als Argument angeführt).
Menschen, die ObjC als ihre erste Sprache wählen, haben diese Probleme nicht und für sie ist das an die natürliche Sprache angelehnte Sprach-Paradigma (kann kann ObjC-Code auch durchaus hässlich schreiben!) eine große Hilfe.
Und warum sollte sich Swift leichter debuggen lassen als ObjC? Unter bestimmten Umständen gibt Swift kryptische und oder unsinnge Debug-Meldungen (besonders im Zusammenhang mit SwiftUI!)

Wie? Du empfiehlst Einsteigern, dass sie mit Swift 3 anfangen obwohl wir schon bei Swift 5.3 sind? Ernsthaft?
Und welche neuen Sprachfeatures sollten Einsteiger vermeiden? Weiter würde ich, wenn ich schon Menschen zu Swift als Einstieg empfehle, ihnen dringend raten, sich mit SwiftUI die ersten UIs zu bauen, denn Einsteiger müssen eben nicht von imperative nach declarative umdenken. Und gerade für kleine Einsteigerprojekte ist SwiftUI super, denn da will man sich eher auf den Code als auf die UI-Gestaltung konzentrieren. Bei Combine gebe ich Dir recht, allerdings kommen Einsteiger damit überhaupt nicht in Berührung.

Interessant finde ich an dieser Stelle, dass Du behauptest, dass Swift (in Verbindung mit neuen Sprachfeatures) komplett unlesbar sei. Swift ist, wie oben schon erklärt, von der Syntax für Einsteiger her schwerer lesbar als ObjC.

Ich habe bis vor ein paar Jahren auch Schulungen für die Programmierung iOS/macOS gegeben und ich muss sagen, dass Programmierneulinge wesentlich weniger Schwierigkeiten (was die Sprache an sich an geht) hatten, als Umsteiger von anderen Sprachen.

Und zu was würde ich nun einem Einsteiger raten?
Swift! Der Hauptgrund hat aber mit meinem * weiter oben zu tun.
Aktuell forciert Apple Swift dermaßen, dass ich in meiner beruflichen Laufbahn, wohl noch das ende von ObjC in macOS und iOS miterleben werde …

Dürfte ich mir aber aussuchen, in welcher Umgebung ich arbeiten wollte, dann wäre es wohl in den Zeiten von NextStep oder von mir aus auch den pre-iOS Mac-Zeiten, aber das hat mehr mit meiner "Wohlfühlkuschelecke" zu tun.

Das stimmt nicht, für ObjC braucht man keine C-Kenntnisse … und man kann sehr lange mit ObjC arbeiten ohne auch nur C zu streifen.

Warum streitet ihr ich über Programmiersprachen? Genau ein Post hat einen guten Tipp zur Lösung des gestellten Problems gegeben.
Selbst wenn ich gut programmieren könnte wüßte ich zB garnicht, wie ich dieses Problem, egal in welcher Sprache, angehen sollte. Daher sollte zuerst mal die Aufgabenstellung genauer definiert werden. Dann kann man sehen, wie und womit man das lösen kann. Und wenn sich dabei rausstellt, das man das am Besten manuell erledigt, dann ist das halt so und ihr streitet euch bisher nur um des Kaisers Bart.

Das Problem ist doch defniert:
Dass das für den Anfang ziemlich ambitioniert ist, steht auf einem anderen Blatt, ich sehe sowas aber nicht als Grund nicht damit anzufangen, im Gegenteil.
Wer sich vornimmt Alpe d'Huez oder den Mont Ventoux mit dem Rad hochzufahren, muss vorher auch erstmal das Radfahren lernen. Manche fahren 30 Jahre Rad und trauen sich das dann, andere fahren 1 Jahr und fahren da locker hoch und wieder andere merken, dass sie doch lieber schwimmen wollen. Und genauso ist es beim Programmieren, man sollte ein Ziel haben und loslegen. Man merkt dann schnell, wo die eigenen Grenzen sind und wie stark man bereit ist, an diese zu kommen und sie gar nach oben zu verschieben.

Hi, ich will in den Streit um die richtige oder falsche Sprache gar nicht einsteigen

Ich halte das Vorhaben für ziemlich ambitioniert, weil es unabhängig von der Programmiersprache eine Reihe recht komplexer Probleme lösen muss. Wenn du da ohne Vorwissen und die Vorarbeit anderer anfängst, wirst du ziemlich sicher bald frustriert aufhören.

Aber, vielleicht ist das folgende Tutorial für OpenCV ein guter Einstieg (in das zugegeben riesige Universum der Computer Vision ): https://learnopencv.com/deep-learning-based-human-pose-estimation-using-opencv-cpp-python/

Unabhängig von der "richtigen" Sprache -- aus der Diskussion ziehe ich mich zurück -- sollte Holger vielleicht sagen, welcher der Teile seiner Anfrage für die Tochter und ihn wichtiger ist: Programmieren (wieder) zu lernen oder möglichst schnell Apps wie die Beschriebene zu entwickeln. Die Wahl der Waffen ist in beiden Fällen wahrscheinlich unterschiedlich.

Moin,
wichtiger wäre, möglichst schnell die Apps entwickeln.

Informiert: Holger

Java

Naja, im Apple/Xcode Universum ist es eigentlich fast wichtiger die Frameworks zu kennen/verstehen, als welche Programmiersprache man benutzt. Für schnelle Ergebnisse würde ich aber definitiv Swift mit SwiftUI empfehlen.

Zum Problem selbst: So etwas kann man schön mit Core ML umsetzen. Es gibt sogar ein fertiges Model das man für den Einstieg benutzen könnte PoseNet. Der Beispielcode dazu ist hier: . Die Leistung des Rechners muss halt ausreichen um Videos statt Standbilder auswerten zu können.

Hm ich befürchte die Programmiersprachendiskussion werden wir nicht beenden, meine Ansicht: die Sprache ist fast egal, am Ende brauchst du eine Bibliothek die dir aus einem Bild recht schnell extrahiert ob da ein Mensch ist und wenn ja in welcher Pose.

Das macht man heute oft mit Hilfe neuronaler Netze - die man sich fertig trainiert von irgendwo besorgt - und denen man ein paar Input-Pixel aus einem Video oder Bild füttert und als Antwort sagen sie dir zB die Koordinaten für: hier ein Kopf, da ein Bein, hier eine Hand, hier ziemlich sicher ein Fuß

Ob du diese Pixel jetzt mit C++ (siehe OpenCV Tutorial weiter oben) oder mit Python, Java, JavaScript oder mit Swift ( [url] https://developer.apple.com/documentation/coreml/detecting_human_body_poses_in_an_image[/url]) aus dem Video extrahierst und dann in das Netz fütterst ist gar nicht so entscheidend.

Wenn du dir die Syntax von Swift ansiehst, ein bisschen mit Swift UI rumspielst und dir das gleich taugt, ist doch super. Swift bietet dir alles um dein Problem zu lösen, das Beispiel von Apple ist ja so schon quasi lauffaehig

Wenn du sagst c++ find ich aber toller, ich verwalte meinen Speicher gerne selbst und bin potentiell auch gerne lowlevel unterwegs, nur zu.

Dass du als Wiedereinstieg aber from scratch so eine Bilderkennung selbst programmierst, ich denke das kannst du, egal welche Sprache, eher vergessen.

Dass du so ein Werkzeug aber anbindest, das soll bekommst du sicher mit jeder der verfügbaren Sprachen hin

Edit: ich schließe mich one two an

Wollen wir wetten, dass, wenn sich Apples Aktienkurs dereinst mehr als halbiert haben wird und man anfängt, die Fehlentscheidungen der Cook-Ära aufzuarbeiten, Swift ganz oben auf der Liste stehen wird?

Wenn Swift nicht auftaucht und ich dann noch lebe, spendier’ ich Dir ’ne Cola, sonst umgekehrt.

Ich halte meine ursprüngliche Formulierung – falls die Aufgabenstellung den Rückgriff auf C-/C++-Code erfordern sollte (weil sich Code-Fragmente zur Lösung der gestellten Aufgabe im Netz nur in diesen Sprachen finden ließen), dann Objective-C, sonst auch Swift – nach wie vor für korrekt und zur Beantwortung der Frage beitragend.

Die erläuternde Klammerbemerkung über Apples ursprüngliche Motivation für Swift diente nur Veranschaulichung. Die hat Perdiste puesto primero als „Quatsch“ abgetan. Ich weiß aber nunmal aus erster Hand, dass das die ursprüngliche Motivation von Apple war. In Folge hat sich viel zu viel leider nur noch um diese Frage gedreht, das war nicht hilfreich, da hast Du Recht.
Hängt davon ab, was Du unter Stänkern verstehst.

Es gibt Fälle intellektueller Minderwertigkeit, für die ich genau 0 Toleranz habe, wenn sie aus einer hochkarätigen Quelle kommen, die es ganz sicher auch besser könnte. Swift ist dafür ein Paradebeispiel. Und dazu werde ich auch nicht aufhören, klar und deutlich Stellung zu beziehen. Mit neuen Programmiersprachen im allgemeinen habe ich keinerlei Probleme. Nur mit Swift von Apple.
Ich kann, ohne mich diesbezüglich einzuarbeiten, eben nicht beurteilen, ob das geplante Vorhaben nicht genau zu diesen allerhärtesten Spezialfällen gehört.

Aber mittlerweile habe ja dankenswerterweise micheee und One Two mehrere hilfreiche Links gepostet, die nahelegen, dass das Ganze auch ohne Rückgriff auf C-Code und in Swift zu lösen ist. Wenn das geht (ich hatte jetzt keine Zeit, das im Detail nachzuprüfen), wunderbar. Dann kann man natürlich auch Swift nehmen, wenn man mag.
Stimmt, und werde dazu hier auch nix mehr schreiben.

LOL. Der Zug ist doch schon längst abgefahren. Nur eben ohne dich.

Und in welcher seltsamen Logik folgt daraus, dass man das daher später nicht als Fehlentscheidung wird erkennen können?
Das macht nichts. Ich fühle mich ausgesprochen wohl hier und hatte gar nicht vor zu verreisen.

Das geht recht einfach auch für Anfänger mit Unity und Kinect . Als Grundlage, den Rest muss man natürlich selbst programmieren. Wobei der härteste Teil mit so einer Kinect-Lösung erledigt ist.

Wobei die meisten Optionen dann mangels Kinect-Treiber Bootcamp benötigen werden (die Treiber laufen nicht in virtualisierten Umgebungen), zumindest früher gab es Assets für macOS die auf Scanect und OpeKinect alsTreiber gesetzt haben, bin in dem Kinect-Thema aber nicht mehr drin, also keine Ahnung, ob es die noch gibt. Eine Kinekt bekommt man günstig auf eBay.

Das wäre dann allerdings C# was ihr lernen müsstet, wobei das generell cross-plattform ist, also z. B. mit Xamarin auch für alles mögliche eingesetzt werden kann. Zudem ist es recht einfach zu lernen.

Da deine Tochter wohl offensichtlich sehr viel Visuelles machen möchte, sollte sie sowieso auf Unity setzen. Unity und Unreal werden heutzutage auch in der Filmindustrie eingesetzt, als Ersatz für die Blue/Green-Screens, z. B. bei The Mandalorian:


Ergibt keinen Sinn, das Rad zum tausendsten Mal neu erfinden zu wollen, vor allem als Anfänger.

Um kurz zu zeigen, wie simpel das innerhalb von Minuten ist:

Irgendeine Kinect-Lösung für Unity nehmen, die Personenbewegungen komplett trackt und das ganze in Echtzeit darstellt. Siehe hier:


2D Position des gewünschten Körperteils über dessen 3D Position ermitteln, also Transform des Körperteils über Camera.WorldToScreenPoint

Die Visualisierung des Körpers ausschalten.

Eine Linie an der 2D Positon malen. Wie so was get, zeigt dieses Video, hier wird die Mouseposition genommen.


Das Projekt sollten Anfänger wirklich sehr schnell umsetzen können.

Soll die Linie hingegen nur irgendwie die Bewegungen des GESAMTEN Körpers abbilden, dann den Durchschnittswert der 3D-Postion aller Körperteile nehmen. (Oder deren Veränderungen gegenüber der Position des Frames davor)

Hallo allerseits,
Vielleicht sollte sich meine Tochter mal Unity und Kinect ansehen. Ich denke, diese Anwendung mit C++ oder Swift zu realisiere, bedarf doch einer seeeehr langen Lernkurve.
Aber vielen Dank für eure zahlreichen Anregungen.

Meint: Holger

Neu mit etwas zu starten, was auf Hardware setzt, die es schon gar nicht mehr gibt, ist halt so eine Sache. Und wenn ich Deine Ausgangsfrage richtig verstanden habe, ging es doch eher um reine Software-Lösungen für ihr MacBook Pro.

Läuft auf dem MacBook Pro Deiner Tochter denn Big Sur? Falls ja, lies bitte weiter.
Ja, das hatte ich ja eingangs als jemand, der selbst gar nicht in dieser Ecke arbeitet, auch gedacht. Ich habe mich jetzt aber noch ein bisschen bei Apple umgesehen und bin vollkommen überrascht, wie viel sich in dieser Richtung jüngst getan hat: So gibt es von Apple ein eigenes Framework namens Vision, das seit Big Sur auch explizit das Verfolgen von Händen und Körperposen erlaubt.

Ein einführendes Video hierzu von der Apple-Entwicklerkonferenz WWDC 2020 gibt es auf (samt Transkript und englischen Untertiteln für diejenigen, die gesprochenes Englisch nicht ganz problemlos verstehen können).

Ab 1:08 Minuten geht es spezifisch um Hände. Als Beispiel wird u.a. ein Video gezeigt, wie eine Emoji-Hand der realen Hand überlagert ist und all ihre Gesten mitverfolgt. Von dort zu einer an den Händen „befestigten“ Linie sollte der Weg nur sehr kurz sein. Entsprechendes mit Körperposen; das beginnt bei 12:56 Minuten.

Es gibt auch Sample Code wie z.B. für Hände Detecting Hand Poses with Vision oder für Körperposen Building a Feature-Rich App for Sports Analysis .

Da alle Code-Beispiele in Swift geschrieben sind, dürfte die Frage mit der Programmiersprache auch geklärt sein. (C++ ist für die Apple-Plattformen, das kann ich nur wiederholen, eine unsinnige Idee, da das einfach ein Fremdkörper im Apple-Universum ist.)

Ich revidiere daher meine Einschätzung der Schwierigkeit Eures Vorhabens um 180°: Im Rahmen des Schwierigkeitsgrades, den der Einstieg ins Programmieren immer hat, sollte Eure Aufgabe mit Vision zu lösen eher ein Kinderspiel sein.

Dann erkläre mal, warum das so sein sollte.
Weil du(und vielleicht ein paar andere ewig gestrige) mit Swift nicht klarkommst und lieber in der alten Welt lebst?

Würde sogar auf einen Kasten erhöhen, allerdings keine Cola...

Wenn es ausreichend ist, dass die fertige Anwendung unter iOS und Android läuft, dann könnte folgendes Trio etwas sein:

• Dart
• Flutter
• ML Kit

Beantwortet zwar nicht zu 100% die Ausgangsfrage, ist m.E. aber auf jeden Fall einen Blick wert.

So...und jetzt schlagt auf mich ein...

Ich persönlich verstehe den Flutter Hype nicht.
Für mansche Apps kann das ja passen, aber für mich sind die Nachteile größer als die Vorteile...

Und ja, ich habe schon eine App mit Futter entwickelt...

Dann nenn sie doch bitte auch, sonst hilft es ja auch niemanden. Vielleicht sehen andere das nämlich nicht als Nachteile.

Eine iOS App sieht nicht nur anders aus als eine Android App (unterschiedliche UI Elements), sondern funktioniert und verhält sich auch anders.
Z.B.
- AppBar != NavigationBar
- TabBar != BottomNavigation

Und genau diese Unterschiede werden per Default nicht beachtet.
Die meisten nutzen einfach "material.dart" und gut ist. Und schon hast du eine Android App auf iOS.
Und wenn du dann alles das beachten möchtest, also überall "material.dart" und "Cupertino.dart" verwenden möchtest, ist der große Vorteil (einmal entwickeln für beide Plattformen) auch schon weg.

Gibt aber noch mehr...

Wie ich schon geschrieben habe, will ich diese Diskussion hier nicht fortführen. Da sämtliche Codebeispiele, die ich jetzt für das Vision-Framework gefunden habe, in Swift geschrieben sind, erachte ich die Sprachenfrage im hiesigen Kontext als ausreichend geklärt und alles weitere gehört nicht mehr hierher.
Das ist eine reine Unterstellung Deinerseits. Wer sagt Dir, dass ich mit Swift nicht klarkomme? Meinst Du, wer etwas kritisiert, tut das stets deswegen, weil er damit nicht klarkommt? Könnte die Kritik nicht auch einem besonders gründlichen Verständnis der kritisierten Sache entspringen? Oder einem anderen Wertesystem? Würdest Du behaupten, dass jemand, der Rechtsextremismus kritisiert, das deshalb tut, weil er damit nicht klarkommt?

Verräterisch ist allerdings Deine Rede von ewig gestrig und alter Welt. Das legt nahe, dass Du zu denjenigen gehörst, die jede neue Entwicklung schon deswegen gut finden, weil sie neu ist. Und da unterscheiden wir uns allerdings gründlich; mein Kriterienkatalog ist ein gänzlich anderer. Dass jemand mit diesem Mindset ein Zeitgeistphänomen wie Swift gut findet, egal wie unausgegoren es ist, ist aber natürlich konsistent.
Das nützt mir nix; ich trinke nur Cola. Aber Du darfst Dir gerne ein anderes Getränk Deiner Wahl aussuchen, Holundersirup oder was auch immer.

Mir ging es nicht um die Diskussion, sondern um die Erklärung, warum die Einführung von Swift den Aktienkurz von Apple "massgeblich" zum Einsturz bringen sollte...

Zum Rest sage ich nichts... Besser ist das...

Du solltest nicht unbedingt das Wort "ewig gestrige" verwenden, weil das ist in mehrfacher Hinsicht die falsche Wortwahl!
Ich teile mit Weia die Liebe zu Objective C und ich halte es immer noch für die schönere und wesentlich elegantere Sprache besonders im Vergleich zu Swift. Ich gebe auch Weia mit der Einschätzung recht, dass die Entscheidung für Swift bei Apple aus … Marketinggründen fiel. Den einzigen "Vorteil" den Swift zu Objective C hat ist/war(?), dass es sich von der Syntax her an Ruby & Co orientierte und Entwickler:innen, die von da kamen, einen leichteren Einstieg bot. Ansonsten? Swift ist, in Version 5, in einigen Teilen auf der Performance von ObjC, teilweise noch dahinter. Bis mindestens Version 4 wurden bei Swift unter anderem Sachen ausgemerzt, die auf ein schlechtes Design (Syntax) der Sprache hindeutete … wer erinnert sich nicht gern an die Optional-Chain-Orgien früher Swift-Versionen. Und noch ein Merkmal von Swift: Es ist eine der wenigen Sprachen, bei denen der Compiler in einer anderen Sprache geschrieben ist.

Und dann ist da noch die Sache mit "Swift ist sicherer": Das ganze steht und fällt mit den Entwicklern und wie oft sich Dinge wie:

oder


Dann nutzt mir auch die "Sicherheit" von Swift nichts. Und wenn man nun mit dem Argument kommen mag: Das liegt an den Entwickler:innen. Ja … aber wenn man bei Objective C sorgfältig arbeitet, dann minimiert das auch die Fehlerrate.
Und wenn ich meiner subjektiven Einschätzung glauben will, dann habe ich mehr Probleme in Swift-Code fixen dürfen als in Objective-C … wobei ich aber auch sagen würden, dass die ObjC-Zeit einfach auch eine andere Zeit war.
Das klingt jetzt sehr böse und arrogant, aber es ist zumindest ein kleines Stück wirklich so:
In der Vor-iOS-Zeit, da hat man sich sehr bewusst für den Mac und damit für Objective-C als Plattform entschieden. Man hat sich intensiv mit Plattform und Sprache beschäftigt und jede WWDC bzw. die Mitgliedschaft beim ADC war ein Fest. Die Plattform selbst hat sich "verständlich" weiterentwickelt und nachvollziehbar weiterentwickelt. Wenn mich meine Erinnerung nicht täuscht hat sich in den letzten 4 Jahren die von Apple vorgeschlagene Art, wie man in CoreData NSFetchedResultsController bzw. NSFetchResult verwendet 3 mal geändert vorher war das Rezept dafür jahrelang stabil.
iOS hat das Apple-Entwickler-Universum massiv durcheinander geschüttelt. Vor iOS-Zeiten war es z.B. so, dass man sich solange es ging an Apples Frameworks hielt. Mit iOS begann etwas, das ich gern als "Javaisierung" (Ich habe in vor OS X-Zeiten hauptsächlich Java programmiert) bezeichne: Bei Java fing es irgendwann an, dass jeder sein eigenes Framework entwickelte, selbst wenn es schon zig-Lösungen für ein und das selbe Problem gab, es wurde einfach noch eines entwickelt. Jetzt möchte ich niemanden die Freiheit nehmen ein Framework zu entwickeln, es ist aber durchaus kontraproduktiv den 42. JSON-Parser zu bauen, denn mit jedem neuen Framework fehlen einem anderen die Maintainer und vormals oft genutzte Projekte sterben dann … und der uralt-Code lebt in vielen Apps einfach weiter … mit allen potentielen Sicherheitslücken!
Das andere extrem der "Javaisierung" ist, das "ich mach es besser als Apple", mein Paradebeispiel ist da immer noch three20. iOS war damals ja noch sehr strickt MVC und ich finde es ist in iOS immer noch sehr gut umgesetzt und gut benutzbar … bei three20 (dahinter stand Facebook) meinte man aber, man müsse das alles auf den Kopf stellen und kräftig durchrühren.
Ich kenne einige Apps, die das nutzen … und nicht zuletzt deswegen eingingen.
Und mit Swift wurde das alles noch mal massiver und vielleicht verstehst man jetzt ein bisschen, warum die angeblich gestrigen, etwas angepisst sind und in Swift keine Verbesserung sehen.
Oder wie es ein anderer, recht bekannter, macOS/iOS-Entwickler mal gesagt hat:
"Swift und Kotlin sind seelenlose Hipster-Sprachen"

Was ich aber nicht mit Weia teile ist die Einschätzung, dass Objective-C Swift wieder verdrängt, der Zug ist leider abgefahren

Du schreibst doch selber weiter oben: "Bei Swift scheitere ich ja schon an der Typisierung … ". Da das ein grundlegendes Feature der Sprache ist, darf wohl davon ausgegangen werden, dass du mit Swift nicht klarkommst. Oder nicht klarkommen willst. Alles an sich keine Schande, aber dann stehe doch auch dazu.

Eine Kursrückgang um mehr als die Hälfte ist kein „Einsturz“, sondern eine völlig normale Schwankung über die Jahrzehnte, aber dann eben auch Anlass zur Rückschau. Dass Swift den Rückgang massgeblich verursacht, habe ich nirgendwo geschrieben. Die Sprache ist eher Ausdruck eines internen Wandels bei Apple, der das Unternehmen zum Schlechteren verändert (was dann zu besagter Kursentwicklung beitragen wird).
Vermutlich.