2007-Apr-25 VBA für Macintosh verschwindet

From The Joel on Software Translation Project

Revision as of 16:53, 5 May 2007 by Lutzw (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

VBA für Macintosh verschwindet

von Joel Spolsky,
25. April 2007.

Originaltext auf Joel on Software, VBA for Macintosh goes away

Aus dem Englischen von Lutz Weber

Die ersten paar Versionen von Excel (1.0 bis 4.0) waren ansatzweise Makro-programmierbar mit einer Sprache, die so peinlich war, dass sie niemals einen Namen erhalten hatte, obwohl sie manchmal nach ihrer Dateiendung XLM genannt wurde.

1991 war gerade das von den Kritikern hochgelobte Visual Basic auf den Markt gebracht worden. Durch die Kombination eines Baukastens für grafischen Benutzeroberflächen ähnlich NeXTSTEPs "Interface Builder" mit einem einfachen Basic, welches QuickBasic sehr ähnlich war, wurde es schnell die am meisten verkaufte Programmiersprache, solange bis sich Massen von Entwicklern auf die Web-Programmierung stürzten.

Wenn auch professionelle Programmierer über Basic die Nase rümpfen, die Marktforscher belegen eindeutig, dass ungefähr zwei Drittel der Leute, die "nebenbei" Makros schreiben, Basic anderen Sprachen bevorzugen und es "leicht" finden.

Also wurde selbstverständlich eine Art Visual Basic zu Excels neuer Makrosprache.

Es galt jedoch, eine Reihe komplizierter Voraussetzungen zu erfüllen. Excel war plattformübergreifend. Die Version für den Mac verkaufte sich sehr gut. Um sich mit den Macs gut zu vertragen, musste sich Microsoft Apples anwendungsübergreifender Skriptsprache "AppleEvents" anpassen. Um nicht zwei Objektmodelle einzuführen, entschloss sich das Excel-Team, das Excel-Objektmodell Apple-verträglich zu gestalten. Aus komplizierten Gründen war Visual Basic nicht objektorientiert "genug". Im Besonderen konnten Objekte zwar Eigenschaften haben, die aber nicht selbst Objekte sein durften. Visual Basic 1.0 konnte nicht "rows(1).cells(2).value" verarbeiten, weil das "rows"-Objekt nicht ein weiteres Objekt beinhalten durfte.

Die VB Mannschaft hat eine komplett neue Version geschaffen, sowohl für den Macintosh (System 7 mit Motorola68k) als auch für Windows (3.0 auf 16-bit-Rechnern). Diese wurde Visual Basic for Applications und bald folgte die selbstständige Variante, Visual Basic 4.0.

Das ganze hat ziemlich viel Arbeit bereitet, wurde aber als "strategisch" überaus wichtig eingestuft. Das bedeutete: Microsoft dachte, wenn die Kunden nur ganz, ganz viel VBA schreiben würden, wären sie auf Microsoft Office angewiesen. Wie sehr sich auch die Konkurrenz bemühen würde (damals waren das Borland, Lotus und mit Abstand noch Claris), sie könnte nie VBA und das riesige Excel Objektmodell nachbilden. Jedes Excel Makro würde bei den Konkurrenzprodukten irgendwann einmal abstürzen. Deshalb funktionieren übrigens Anwendungen unter Mono, Wine, usw. kaum beim ersten Aufruf so wie sie geschrieben wurden. Unter jeder API- oder Programm-Schnittstelle verbergen sich so viele Abhängigkeiten, von denen der Entwickler nicht einmal unbedingt etwas merkt, dass eine Nachbildung der Umgebung unvermeidlich unvollständig sein muss. In der spröden Welt der Programmierung sorgen diese Unsauberkeiten für einen schnellen Absturz der Programme, weit davon entfernt, ein nützliches Ergebnis zu liefern. Der bloße Versuch, eine API nachzubilden, zählt nichts.

Also hat Microsoft seinen Kunden nicht nur eine hübsche Programmiersprache verkauft, sondern auch eine Zugangsschranke errichtet und Excel-Nutzer an sich gebunden, besonders diejenigen, die in Konzernen und großen Firmen aufwändige Makro-basierte Projekte erstellt haben.

Schließlich wurden auch die übrigen Office Anwendungen einbezogen: Word, Project, Access, Outlook. Was als strategische Bindung für Excel begann, entwickelte sich zum strategischen Wert für das gesamte Office-Paket.

Im vergangenen August beschloss Microsoft, VBA in den Mac Versionen von Office nicht mehr mitzuliefern. Trotz komplizierter technischer Begründungen wird so eine strategische Entscheidung immer nach Kosten/Nutzen Erwägungen getroffen. Benutzer des Mac haben im Vergleich zu Windows-Nutzern wahrscheinlich keine geschäftswichtigen Makros geschrieben, einfach deshalb, weil Macs in großen Firmen kaum genutzt werden.

Aber total spannend ist an der Geschichte, wie sich Microsoft selbst ausgetrickst hat. Wenn man die Kunden an sich bindet und dann diese Bindung nicht mehr aufrecht erhält, machen sie es vielen Mac-Office-2004-Nutzer sehr schwer, auf Office 2008 umzusteigen. Die müssen sich dann zwangsläufig überlegen, welche Anwendungen sie in Zukunft benutzen. Das gleiche ist schon mit VB6 und VB.Net passiert und jetzt mit Windows XP und Vista. Als Microsoft sich von dem Dogma der Rückwärts-Verträglichkeit verabschiedete, das in der Vergangenheit so gewinnbringend war, haben sie drei ihrer wichtigsten Geschäftsfelder (Office, Windows und Basic) in Gefahr gebracht, Geschäftsfelder, deren Einnahmen vom Verkauf von Updates abhängig sind.

PS: Beim Recherchieren für diesen Artikel habe ich versucht, einige Aufzeichnungen zu lesen, die ich mit einer alten Word for Windows Version geschrieben hatte. Word 2007 hat sie "aus Sicherheitsgründen" nicht geöffnet und mich auf verschiedene Artikel der Knowledge Base verwiesen, denen zufolge ich obskure Einträge in der Registrierung ändern sollte, um die alten Dateien zu öffnen. Es ist außerordentlich frustrierend, wie sehr man bei der Nutzung von Microsoft Produkten nach jeder Versionsänderung im Hamsterrad laufen muss, um am gleichen Platz zu bleiben. Ich empfehle meinen Freunden neuerdings, bei Windows XP zu bleiben - auch bei der Anschaffung neuer Rechner, weil die paar neuen Eigenschaften von Vista nicht die Probleme mit der Kompatibilität aufwiegen.

PPS: Ich war von 1991-1993 Mitglied im Excel Program Management Team, wo ich die Leistungsbeschreibung von VBA für Excel verfasst habe.

Personal tools