Auch heute noch höre ich ab und zu Aussagen, dass Apps keine echten Programme seien und sich hier der falsche Begriff etabliert habe, wenn am MS Word eine App nennt.

In diesem interessanten Mittschnitt von 1992 nutzt Steve Jobs den Begriff bereits wie selbstverständlich und ohne weitere Erklärungen. Hat mich doch überrascht, weil ich ebenfalls dachte, das kam erst mit dem iPhone.


Interessant ist auch der Rest des Beitrags. Steve hat echt früh erkannt, wie wichtig es ist, das man möglichst schnell Anwendungen entwickeln kann.

App ist kurz für Application Software oder Anwendungssoftware. Wenn Du bei Wiki die Fußnote 7 anschaust, da gab es 1989 sogar schon den Begriff "killer app" (und vermutlich schon viel früher).
Natürlich muss eine Anwendung schnell entwickelt werden. Dass Entwickler Geld kosten, dürfte lange bekannt sein.

In den Fußnoten findet sich sogar eine Historie des Begriffs "App".

Klar, aber Next waren offenbar die ersten, die das ganze System um diese Erkenntnis zu bauen. Bei allen anderen Systemen war die Entwicklung von Software viel aufwendiger. Behauptet zumindest Jobs in dem Video. Die anderen System waren ja nicht objektorientiert – von OS/2 mal angesehen.

Auch im geläufigen „Internet-Slang“ der frühen Nullerjahre wurden Programme eigentlich schon immer mit „apps“ abgekürzt.

Eine App war schon immer eine Programm. Es gab da einige Leute, die den Leuten versucht haben den Leuten einzureden, eine "App" sie kein richtiges Programm.

Dabei gab es schon immer ganz kleine Apps und ganz Große.

Was mich eher stört, dass offenbar immer mehr Mulitplattform-Müll zum Einsatz kommt. Das nervt extrem. Erst gestern konnte ich in einer App den Passwortmamanger nicht starten, weil das Eingabe-Feld irgend so ein Nachbau war. Vielen Dank auch.

Ich habe zwar nie auf Consumerprodukten entwickelt, sonder auf Mittel- und Grosssysteme. Und da wurden schon 1984 Applikation und Programm gleichwertig benutzt. Kam halt immer auf den Kontext drauf an. Bei Consumerprodukten war eher Programm geläufig, bei den Mittel- und Grossystemen (IBM, NCR, Burroughs, DEC usw.) sprach man eher von Applikationen. Und kam zusätzlich auch noch auf die sprachliche Herkunft des Entwicklers an.

Ich habe zwar erst seit 2007 einen Mac, Programme waren doch schon zu dieser Zeit Apps, bzw. mit Endung .app (im hinkenden Vergleich zu .exe bei DOS/Windows)

Das war mehr oder minder eine Lüge von Jobs zu Marketingzwecken. Der GUI Designer von NeXTSTEP war etwas Neues und hat die Produktivität erhöht. Allerdings nur sehr kurz, da es schnell Vergleichbares von anderen Firmen gab. Dann sollte man nicht vergessen, dass Jobs etliche Jahre vorher Xerox PARC besucht hatte und dort eine Vorführung der Xerox Alto bekam, und diese nicht nur ein GUI hatte, sondern auch schon über objektorientierte Frameworks auf Basis von Smalltalk verfügte.

1988 als der NeXTcomputer auf den Markt kam, gab es aber auch andere GUI-Systeme auf dem Markt, die OO-Techniken nutzten. Hier sei besonders auf SUN verwiesen, weil es da ein Video von NeXT gab, bei dem die Produktivität eines Entwicklers unter NeXTSTEP mit einem Entwickler mit Solaris verglichen wurde. Die Art und Weise des Vergleichs favorisiert enorm den NeXTSTEP Entwickler, und man darf sich davon nicht blenden lassen, da es meist sehr viel mehr Arbeit gibt als das GUI mit Rapid Prototyping zusammen zu setzen.
Das ist falsch: Apples MacApp, SUNs TNT for NeWS, SGIs ViewKit, … sind nur einige OO-Beispiele.

gfhfkgfhfk, Du musst ca. Anfang der 90ger irgendwo anders als ich gewesen sein. Die Programmierung von Anwendungen für NeXTStep war damals IMHO allem anderen sowas von Lichtjahren voraus. Hast Du damals Java mit Swing programmiert? Oder Win32 für Windows? Nichts davon war auch nur annähernd mit NeXTSteps Interface-/Project-Builder vergleichbar.

Diese Leute (wie Du sagst) gab es nicht nur. Sie gibt es immer noch.

Der von allen hier hoch geschätzte Marcel Bresink weist bei seinen Produkten auf diesen Unterschied hin. Wobei die Erklärung weniger auf wirklich technisch bedingte Unterschiede als viel mehr auf nicht vorhandene gegenüber vorhandenen Einschränkungen bei der Nutzung der Software eingeht.

Das hat alles rein gar nichts mit der App zu tun.
Und Ausserdem gibt es gerade für Firmem sowas wie ein MDM. Da lässt sich alles ruck-Zuck verteilen.

Für mich sind das keinerlei Gründe. Es geht im wesentlichen darum, nicht den App-Store verwenden zu müssen.

Das ist aber eine sehr idiosynkratische Verwendung des Begriffs, die darauf aufbaut, dass der Begriff App im deutschsprachigen Raum erst mit Apples App Stores mitsamt ihren Nutzungsbeschränkungen populär wurde. Vergleiche den (lokalisierten) Ordner /Programme, der in der englischsprachigen GUI seit jeher /Applications heißt. Und von Application zu App ist es ja kein großer Schritt, das ist einfach eine joviale Abkürzung.

Kommen hier noch jemanden die Tränen, wenn er Steve Jobs reden (und denken) hört und dann an die vorgefertigten „Keynotes“ des gegenwärtigen Apple-Personals denkt?

Sind das denn eigenständige und vollwertige Betriebssysteme, die von Grund auf auf OO konzipiert sind? Zumindest bei MacApp weiß ich, dass das nicht der Fall ist. Auch für die Lisa gab's schon ein OO-Framework für die App-Entwicklung, damit war das System selbst aber noch nicht objektorientiert.

Steve Jobs hört man 32 Jahre nach diesem MIT-Vortrag noch gerne zu und misst den Gedanken Bedeutung bei.
Bei den heutigen Verlautbarungen von Apple fühle ich mich nur noch veräppelt. Phil Schiller sagte, er wisse nicht, was Apple mit dem App Store verdiene. So etwas ärgert mich enorm.

NeXTSTEP/MacOS X/macOS ist kein von Grund auf OO-Betriebssystem, sondern ein BSD UNIX mit einem Microkernel und reinen C APIs, die den UNIX Standard mehr oder minder umsetzen. (Über die Feinheiten zwischen BSD und System V müssen wir uns in einem Mac Forum wohl nicht austauschen.) Alle NeXT/Apple Frameworks bauen auf den C APIs der UNIX Basis auf. So kommt es auch, dass es Openstep for Solaris gab, dass eine 100% kompatible Umgebung unter Solaris mit X11/DPS als Grafikbackend zur Verfügung stellte. SUN hatte eine längere Zeit sehr aktiv den Plan verfolgt Openstep (d.h. die OO-Frameworks von NeXTSTEP) unter Solaris als neue Bais für die Applikationsentwicklung unter Solaris zu nutzen. Daher wurde auch die Firma Lighthouse Design gekauft. Später wurde dann die Strategie geändert und es wurde auf Java gesetzt.
Ich schrieb ja explizit von ViewKit (RapidApp war der dazu gehörendes GUI-Editor), und das unterschied sich von der Art und Weise der Programmierung nicht allzu sehr von Openstep for Mach. Der Funktionsumfang bei SGI war größer, da es z.B. schon Frameworks für 3D gab, die es bei NeXT noch nicht gab.

Heute ist im Übrigen sein Todestag.
Möge er in Frieden ruhen!

Im Video sagte Jobs, dass von NeXTStep nur 10 % Unix sind, das dürfte bei macOS also nochmals viel weniger sein. Ein NeXTStep ohne den OO-Kram wäre halt ein schnödes Unix gewesen. Ein Mac OS System 6 ohne MacApp wäre wohl ein Mac OS geblieben.

In der Tat war SGI NeXTStep in Sachen 3D mit OpenGL und OpenInventor voraus. Aber alles andere, ich bitte Dich. ViewKit basierte auf X11/Motif, wurde in c++ programmiert und die Anwendungen hatten meistens Pre-MacOS-Usability. Man hat eine SGI wirklich nur für 3D verwendet. NeXTStep bzw. dessen WindowServer basierte auf PostScript, die Anwendungen wurden in Objective-C entwickelt und die Kombi aus AppKit und dem Interface-Builder haben sehr häufig zu sehr guter Usability geführt. Damals beste Kombi aus MacOS und Unix.

war aber nicht gerade die Art der Objektorientieren Programmierung anderen sehr weit voraus und das Steckenpferd von NEXT und später auch OSX?

Die Art und Weise wie in Objective-C das Dispatching durchführt (es folgt dem Vorbild SmallTalks) ist erheblich langsamer als zum Beispiel bei C++. Dadurch erhält man zwar mehr Flexibilität (siehe Reflexion), aber bei der GUI Programmierung braucht man Reflexion gar nicht. Man nutzt das üblicherweise, wenn man Objektgraphen deserialisiert z.B. den internen Programmstatus eines OO-Programms in eine Datei speichert und anschließen laden will oder über eine Netzwerkverbindung übertragen will. In C++ ist dann viel Handarbeit notwendig, aber es geht auch da. Objective-C hingegen ist was die OO-Fähigkeiten betrifft keineswegs das Maß der Dinge, da wäre eine CLOS (Common Lisp Object System) zu nennen. Damals war das GoF Buch und die SmallTalk Companion Variante bahnbrechend für die Diskussion von Software Patterns. Falls das Thema nicht bekannt ist, wäre das sinnvolle Literatur.

Zurück zum Thema GUI und Performance: C++ war damals fürs GUI die bessere Wahl, weil die Systeme nicht so schnell waren und C++ in den 1990er schon RAII ermöglichte, so dass man weniger Probleme mit der Freigabe von Objekten hat, und in Folge erheblich weniger Ärger mit Zeiger die ins Nichts verweisen oder auf falsche Objekte. In Objective-C musste man die Zeiger manuell verwalten (d.h. händisch retain und release Messages schicken, autorelease kam sehr viel später), C++ räumt automatisch hinter einem auf, wenn man es richtig macht. Nur zur Erinnerung der NeXT Computer verfügte nur über einem 68030 mit 25MHz, d.h. Performance war damals extrem wichtig.

Sowohl der Desktop von NeXTSTEP wie auch der von IRIX waren damals eher spartanisch. Man sollte nicht den Fehler machen aktuelles macOS mit alten IRIX zu vergleichen. ViewKit hatte deutlich mehr GUI-Elemente als das zu Grunde liegende Motif 1.x, so dass der Funktionsumfang von ViewKit und NeXTSTEP Frameworks fürs GUI vergleichbar waren. Und natürlich hatte auch IRIX DisplayPostScript wie die meisten kommerziellen UNICES. SUNs NeWS war das erste System was DisplayPostScript hatte (das wurde in IRIX 3.x genutzt), NeXT kam als zweites und kurz darauf kam es für X11. Das war eine der Gründe warum spezielle Desktop Publishing Software wie etwa FrameMaker zuerst für SunOS erschien und erst später auf andere Plattformen portiert wurde.