[Allegro] Getrennte Listefür Entwickler sinnvoll?

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

>>> Dazu kann ich nur meinen, daß das alles noch da ist, und man sich
>>> nach wie vor darauf beschränken kann. Wir haben eine ungebrochene
>>> Rückwärtskompatibilität, *und* V12 tut's auch immer noch ohne jede
>>> Neuerung, nur eben unter Win'64 nicht mehr.
>>
>> not true bzw. es kommt darauf an, welche V12: Ein damals unentdeckt
>> gebliebener BUG(!) in index.exe von V12.1 erzeugt eine Division durch 0,
>> wenn weniger als 1 Sekunde benoetigt wird, um 100 Datensaetze zu verarbeiten
>> (es war halt mindestens 10 Jahre nicht reindexiert worden, warum auch).
>>
> Seufz, ja, stimmt.
> Aber hacken Sie nicht auf der V12 noch rum, es war eher nicht so
> spezifisch gemeint. Und die Klage von Herrn Mentzel-Reuters bezog sich

worauf ich mit dem Beispiel hinaus wollte, ist folgendes:
Aufwaerts- und Abwaerts-"Kompatibilitaet" duerfte sich gar nicht so einfach
streng definieren lassen. Alte Parameterdateien funktionieren auch heute
noch - mit den alten Daten. Oder auch nicht: Evtl. sind da subtile Syntaxfehler
drin, die bei neueren Versionen eine Bedeutung haben. Oder es sind
Programmierfehler oder Abhaengigkeiten von Bugs der alten Versionen drin,
sind die im Kernsystem behoben, funktioniert die Parameterdatei ploetzlich
auch nicht mehr. Neue .api's produzieren mehr Schluessel und bringen
alte index.exe's zur Fehlfunktion. Und wenn ich neue Daten einarbeite,
die etwa auf neue eingefuehrten Kategorien (#8e) beruhen oder in denen
sich neue Funktionalitaeten niederschlagen (v14-Verknuepfungen), dann
funktionieren meine alten Parameterdateien auch nicht mehr wie frueher,
produzieren "Schmutz" oder lassen Information aus. (Im konkreten Beispiel
hatte ich meinen Rechner so unter Last gesetzt, dass der Division-durch-0-
Fehler bei der Indexierung nicht mehr auftauchte nur um festzustellen,
dass im Laufe der Jahrzehnte Datensaetze erfolgreich eingegeben worden
waren, die die maximale Schluesselzahl des INDEX.EXE von V12.1 ueberschritten,
nicht jedoch die von V12.2: Da war wohl der Anwender nicht kompatibel
mit allegro 8-<<< ??? [Die geschilderte Kette von Problemen hatte uebrigens
nur mit "geanderten Daten" zu tun: Nach 18 Jahren ist die xxx_1.cLD
voll geworden und ein Bug (noch einer!) in PRESTO v12.1 hat verhindert,
dass es mit der xxx_2.cLD automatisch weiter ging]) Und Anwender haben evtl.
sogar die noch weitergehende Anforderung, dass sich ihr Benutzerinterface
nicht veraendert und dass sie eine Anwendung so wie sie ist auf die
uebernaechste Version des Betriebssystems umtopfen koennen.

"Kompatibilitaet" heisst bei allegro also, dass es eigentlich nie
einen konkreten Zwang zum Einsatz einer neuen Version gibt, oder
zum Umarbeiten von Parameterdateien, oder zur Umsetzung von Daten.
Man kann auch Parameterdateien, Executables und Daten aus verschiedenen
Versionen irgendwie kombinieren und meistens geht es gut. Aber man
muss konstatieren, dass es Installationen gibt, die nicht nur alt
sind sondern ganz eindeutig zu alt und dass dort "punktuelles" Aktualisieren
meist scheitert und es auch keine Garantie gibt, dass komplettes
Aktualisieren plus Beibehalten der einzelnen eigenen Parameterdatei
als punktuelle Altkomponente ueberhaupt kein Problem ist (real viel
wichtiger ist sowieso das Problem, dass niemand weiss, wo ueberhaupt
Anpassungen vorgenommen worden sind bzw. wenn man die identifiziert,
ist das Problem nicht mehr unbedingt rekonstruierbar, das damit
geloest wurde. Was nicht bedeuten muss, dass es sich aufgeloest hat, es
ist nur nicht mehr praesent).

Es bleibt die Frage, warum nicht mehr Anwender mit (ziemlich) aktuellen
Versionen arbeiten und ob nicht sogar falsche Erwartungen oder Versprechen
an "Kompatibilitaet" dazu beitragen, dass Anwendungen zu alt werden
und ihre Aktualisierung riskant.


> ja nun nicht auf solche Dinge, sondern es ging ihm darum, daß fast
> alles verloren sei, was er damals so geschätzt habe. Wie Sie auch
> vorhin schon anmerkten, hätten wir das gerne genauer gewußt: Was ist
> verloren, und was ist andersrum von allem Neuen so überflüssig oder so
> anders geworden, daß wir's nicht erst so hätten machen sollen, sondern
> das Alte mehr pflegen oder anders weiterentwickeln oder so?

Ich hatte Herrn Menzel-Reuters Bemerkung so verstanden, dass ihm
der Nutzen von allegro als Werkzeug (Schweizer Taschenmesser?) fuer
eigene Loesungen abhanden gekommen ist und schrieb in dem Zusammenhang
von sich als "Bastler".

Ich kann mir in dem Zusammenhang allerhand konkrete Kritikpunkte
vorstellen (weil ich sie hoffentlich auch schon bedacht und geaeussert
habe), z.B. Featuritis, der Zoo von Mikrosprachen, Ideen und Experimente,
die als Loesungen angepriesen werden und jahrelang herumduempeln, bis
jemandem ein Problem dazu einfaellt und er feststellen muss, dass die
Loesung nicht greift, da zu kurz gedacht. Oder insgesamt ein barockiger
Eindruck mit wenig klaren Linien der Entwicklung.

Allerdings sehe ich auch, dass es in Bibliotheken immer weniger Platz
fuer "Bastler" gibt. Genauer: Grosse Bibliotheken oder Verbuende beschaeftigen
u.U. ganze Kohorten von Softwareingenieuren etc., in mittleren und
kleineren Bibliotheken hingegen hat sich die Arbeit so verdichtet, dass
wenig Gelegenheit bleibt, sich intensiv mit irgend etwas auseinanderzusetzen,
insbesondere - und da ist noch ein Unterschied zu den 1990ern - da man
fuer fast alles auf Kooperation mit anderen Abteilungen und gfls. deren
oder den eigenen outgesourcten Dienstleistern angewiesen ist. Bleibt noch
das oft bemuehte "eigene Listenformat", aber das reisst einen nach dem
dritten Mal auch nicht mehr vom Hocker. Man kann das als Professionalisierung
oder als Buerokratisierung sehen, vermutlich ist beides nicht falsch.

In anderen Zusammenhaengen ist erkannt worden, dass etwa RAK- (oder RDA-)
Kenntnis heutzutage eigentlich gar keinen Wert mehr hat: Wichtig sind
die konkreten Verbundregelwerke und dass sind im Prinzip bibliothekarisch
grundierte Erfassungsregeln fuer das konkrete, i.A. ziemlich abgespeckte,
Datenformat im jeweiligen Bibliothekssystem. Loesungen fuer kompliziertere
Faelle muessen ohnehin mit allen Beteiligten dort abgestimmt werden, dafuer
gibt es dann einige wenige Spezialisten in den Redaktionen, die koennen
die Loesungen dann auch direkt selbst entwickeln.

Aber auch im eigenen, kleinen Bereich, und selbst dann, wenn man sich
Freiraeume dazu erhalten hat, ist "Basteln" fragwuerdiger geworden:
Anders als 1990 gibt es viele andere Werkzeuge und man kann sich schnell
verzetteln, wenn man sich darauf kapriziert, nur eines zu benutzen.
Bloss, wo hatte man die Gelegenheit, mehrere Werkzeuge immerhin so gut
kennen zu lernen, dass man beurteilen kann, ob sich der Einsatz und
die notwendige Einarbeitung langfristig lohnt? Und "interessantes"
spielt sich heutzutage seltenst innerhalb der eigenen Daten ab, es
geht viel haeufiger um "Integration" vorhandener "Dienste" (natuerlich
alles im Web), und selbst bei genuin bibliothekarischen Angeboten ist
da im Laufe der Zeit einiges zusammengekommen, wird immer mehr und
veraendert sich auch staendig. D.h. selbst ohne die konkreten "Techniken"
ist es schon sehr aufwendig, auch nur orientiert zu bleiben, welche
Datenbanken und Dienste es im "globalisierten" Umfeld ist, wie die
einzuschaetzen sind und ob man sie in Bezug auf das eigene irgendwie
nutzbar machen koennen will...

Hier also die ernste Frage, ob allegro als "Programm" nicht schon vor
laengerer Zeit die Zielgruppe abhanden gekommen ist (mein Standpunkt:
Bibliotheken brauchen diese Leute, egal ob sie allegro als /Software/
einsetzen oder nicht. Sie kommen moeglicherweise aber dem Bibliothekswesen
insgesamt abhanden)

viele Gruesse
Thomas Berger