[linux-l] Das NIH-Syndrom (was: Grammar Design)

Mi Sep 21 17:18:08 CEST 2005

Zunächst ein paar allgemeine Bemerkungen zum NIH-Syndrom:

Eine interessante nicht-IT-spezifische Sichtweise auf das NIH-Syndrom
findet sich hier:

	http://www.innovation-aktuell.de/kl0111.htm

Da wird NIH etwa so beschrieben:

Das heißt, DSL sind tatsächlich schon rein prinzipiell sehr anfällig
für das NIH-Syndrom.

Eine Unix-spezifische Sicht auf das NIH-Problem befindet sich hier
(Abschnitt 6):

	http://sites.inka.de/mips/unix/unixphil.html

On Mon, Sep 19, 2005 at 09:51:39PM +0200, Oliver Bandel wrote:
> Was das Steuersystem angeht, da meinte ich etwas, das
> die gestzliche Struktur nachbildet.
> Man gibt Kenndaten an und der Steuersatz oder die Steuerlast
> wird ausgegeben.

Das gibt es auf jeden Fall .. in Form von der Software, die bei den
Finanzämtern läuft. :-)

Wahrscheinlich sind, aufgrund der vielen Gesetze und Gesetzesänderungen,
die Programme dort ohnehin sehr flexibel. Vielleicht gibt es sogar
dadurch eine DSL dafür. Oder was ich eher glaube: Ein gutes Framework,
sodass man die Gesetze nur noch durch sehr einfachen Programmcode
beschreibt.

So zumindest würde ich das machen. Nehmen wir mal nicht Python :),
sondern Ruby. Man hätte dann ein Framework, das einem schon so viel
Trivialzeug abnimmt. Dann gäbe es ein Ruby-Programm mit relativ
einfachem Code, das die Gesetze abbildet. Der Vorteil wäre,
dass du keinen Parser etc. brauchst, und dass du auch kompliziertere
Gesetze gleich hinschreiben kannst.

Eine extra Sprache für diesen Zweck wäre dann höchstwahrscheinlich
auch nicht einfacher als dieser Ruby-Code, hätte aber Beschränkungen,
d.h. du müsstest ihn syntaktisch ständig erweitern, und kriegt am
Ende vermutlich doch wieder eine Programmiersprache dabei heraus,
die unübersichtlicher ist und weniger kann als Ruby.

Übrigens vermute ich, dass für solche Gesetze eine funktionale Sprache
besser wäre. Vielleicht könnten die Gesetze auch in einem Haskell-
oder Ocaml-Modul recht einfach dargestellt werden.

Ich glaube nicht, dass man zum Abbilden von Gesetzen irgendein
Sprachfeature braucht, das keine Programmiersprache besitzt.
Im Gegenteil, ich würde eher sagen, eine extra Sprache würde die
Sache nur nochmal unnötig verkomplizieren.

> Das ganze dann mit diversen Inputs gefüttert und man kann sich
> als Ergebnis eine Grafik ausgeben lassen (gnuplot-Output oder so),
> die anzeigt, wie der Steuersatz/die Steuerlast über den Parametern
> variiert.

Klar, das sollte es wiegesagt schon geben. Zumindest die Berechnung
wird in den Finanzämtern ja irgendwie erfolgen. Dass diese Sachen
nicht längst in Form von Libraries der Öffentlichkeit zur Verfügung
stehen, finde ich nicht ganz okay.

Eine solche Auswertung wäre natürlich cool. Aber schon allein die
Möglichkeit, seinen eigenen Steuerbescheid damit zu überprüfen wäre
genial.

> Ggf. mit genetischen Algorithmen optimierung der Belastung auf Minimum. :)

Klar, auch cool.

Für all das braucht man aber keine DSL, bzw. ich wüsste keinen echten
Nutzen davon. IMHO sind gerade Gesetze ein herrliches Beispiel für
etwas, das man in praktisch jeder Programmiersprache gut umsetzen kann.
(Ob funktionale Sprache da besser geeignet sind als andere, müsste man
 einfach austesten)

> > > Bitte erköär mal, was "NIH" meint.
> > 
> > NIH heißt "Not Invented Here". Das NIH-Syndrom beschreibt eine
> > allgemeine Krankheit, an der viele Software-Projekte (vorallem im
> > kommerziellen Bereich) erkrankt sind. Es geht darum, dass Dinge
> > gebaut werden, die es schon lange gibt.
> 
> Klingt eher anders herum: NIH wäre erstrebenswert, denn man greift
> auf Libs zurück, die not here invented wurden.

Falsch, da hast du den Begriff verdreht, obwohl ich ihn IMHO richtig
erklärt habe.

Lass und bitte zwischen Problem, Lösungsweg und Implementierung
unterscheiden.

Bei NIH geht darum, dass du ein Problem hast, und "dein" Lösungweg
für das Problem "not invented here" wurde, d.h. dass schon andere
vor dir diesen Lösungsweg kannten und implementiert haben. Wenn du
die bestehende Implementierung /nicht/ anschaust, sondern nochmal
selbst, von Null auf, diesen Lösungsweg implementierst, dann redet
man vom NIH-Syndrom.

> [...]
> > Die "Nachbauer" haben damit die gleichen Vor- und Nachteile wie die
> > ursprünglichen Entwickler, mit folgenden zusätzlichen Nachteilen:
> > 
> > 1) Sie haben alles nochmal implementiert, obwohl sich im Nachhinein
> >    herausstellt, dass sie ja doch den Kram der ursprünglichen Autoren
> >    direkten verwenden könnten.
> 
> Hat aber evtl. andere Vorteile.
> 
> Etwas in OCaml zu implementieren, was es in C schon gibt
> hat den Vorteil, daß man da keine probleme mit Segfaults kriegt,
> sondern einem sattdessen Exceptions gegeben werden.

Klar, aber dann nimmst du dir ja nicht nur den Lösungsweg, sondern
eine ganze Implementierung als Vorlage. Und das ist gut! Weil deine
Implementierung nämlich auch in den Details mit der Erst-Implementierung
übereinstimmen wird, d.h. kompatibel ist. Außerdem nutzt du bei den
zahlreichen Implementierungs-Details die Erfahrung der
Erst-Implementierung, d.h. deren frühere Fehler, die sie mittlerweile
gelöst haben, wirst du auch nicht wiederholen, weil du ja schon ihre
verbesserte Version gleich als Vorlage nimmst. Vielleicht fällt dir
dabei sogar noch das eine oder andere auf, sodass auch sie wieder von
dir profitieren.

Das ist gut! Das ist Fortschritt. Du nimmst das bisherige Ergebnis und
verbesserst es.

Das NIH-Syndrom wäre, wenn du deren Implementierung missachten würdest,
wenn du eine geringfügig andere API hättest, andere Dateiformate, etc..
Wenn du es bloß anders machst, ohne dabei wirklich etwas Neues zu machen.
Und das ist schädlich.

Verfolgst du hingegen einen ganz anderen Lösungsweg, dann ist das
natürlich was anderes. Aber dass dein Lösungsweg bisher noch von
niemandem durchdacht, analysiert oder implementiert wurde, ist
i.A. sehr unwahrscheinlich. Vielleicht wurde dieser Weg aus guten
Gründen sogar schon lange verworfen.

> Neu bauen macht ggf. also durchaus Sinn.

Ja klar, dem habe ich nicht widersprochen. Etwas vorhandenes hernehmen,
und zu verbessern, vereinfachen, reimplementieren, was auch immer, ist
gut!

Aber etwas völlig neu, aus dem Nichts heraus, zu implementieren, obwohl
es das schon gibt, /das/ ist i.A. sehr schädlich, wenn da nicht wirklich
irgendeine bahnbrechende Innovation dahintersteht.

> Wozu soll man ein Unix nachbauen, wenn es sowas schon gibt?
> Und was ist draus geworden? Linux.
> Wozu denn so einen Blödsinn veranstalten?

Das GNU-Projekt hat sich sehr viel Mühe gegen, dass das gesamte System
POSIX-konform wird, wo immer das möglich und sinnvoll ist.

Auch Linus Torwalds hatte ein konkretes Vorbild, den Unix-Kernel,
das er neu implementierte. Die System-Calls sind bei den Unix-Systemen
sehr ähnlich.

Das gehört in die Kategorie "Reimplementierung", das hat nichts mit
dem NIH-Syndrom zu tun.

> > 2) Sie sind in Sachen Dateiformat/Protokolle etc. inkompatibel zu dem,
> >    was die ursprünglichen Entwickler gemacht haben.
> 
> Wenn  man ein freies Format haben will, ist das ein Problem.
> Aber vielleicht ist das ja auch gewollt...

Sicher. Und deshalb habe ich ja auch gesagt, dass bei vorrangig bei
kommerziellen Produkten das NIH-Syndrom vorfindet. Die Leute sehen
darin anfangs sogar einen "Vorteil", merken aber nicht, dass sie sich
auf Dauer damit selbst schädigen, wenn sie es übertreiben.

> > Aus diesen Gründen ist das NIH-Syndrom als fortschrittsfeindlich
> > anzusehen.
> 
> Aber nicht immer das schlechteste für den Geldbeutel. ;-)

Ich habe nirgends behauptet, dass Innovation gut für den Geldbeutel
ist, obwohl das natürlich idealerweise so sein sollte. Dass dies aber
in der Praxis, gerade in der Informatik, leider überhaupt nicht
zutrifft, sieht man am besten am wirtschaftlichen Erfolg von Microsoft.

Als freier Entwickler hingegen kann man die Ideale "Innovation",
"Wiederverwendung" und "Fortschritt" viel leichter hochhalten,
vorausgesetzt, man kann von was anderem leben ..

> Neubauen kann auch Spaß machen und man was dabei lernen.
> Auch ein Grund.

Klar, keine Frage.

> > Was du hier heruntermachst, sind genau die Werkzeuge, die es dir
> > ermöglichen, dass du eben nicht mehr im Urschleim (Sprachdesign,
> > lex/yacc, ...) anfangen braucht, sondern dich gleich voll auf die
> > Struktur und die Struktur-Manipulation stürzen kannst.
> 
> naja, to be honest, macht es mir auch Spaß, lex/yacc genauer zu kennen
> und damit was zu implementieren. :)

Klar.

> Es war also mehr als nur der Wunch, schnell mal was Labansymbol-mäßiges
> zu bauen. :)

Ja, das ist alles richtig. Es soll ja auch Spaß machen.

Aber wenn es nicht mehr für dich allein ist, sondern auch für andere, oder
wenn es größer werden wird, dann sollte Sauberkeit erstmal den höchsten
Stellenwert haben, sonst halst du dir nämlich zu viel Arbeit auf, bzw.
machst Leute von einem Produkt abhängig, das zu nichts kompatibel ist,
keine Synergie-Effekte zu anderen Sprachen aufbaut, und das du auf
Dauer nicht pflegen kannst, weil du dich irgendwann mit Detail-Problemen
befassen musst, die überhaupt nicht zur Aufgabe gehören, und die schon
längst gelöst sind, aber die du trotzdem nicht verwenden kannst.

Ich habe dir stets aus der Perspektive geantwortet, dass du was
Ordentliches bauen willst. Anderenfalls wäre jede Diskussion darüber
witzlos.

Für dich, allein, zum Spaß, ne Sprache entwerfen, zu lexen und zu
yaccen, zu transformieren und per Hand PostScript zu erzeugen, das
ist alles gut und schön. Hab ich öfter übrigens genauso gemacht.

Aber sobald es mehr als nur Spaß wird, sollten Eleganz und gutes Design
vorherrschen.

> Und was den Websieve angeht, da war nervig, daß die Regexp-Syntax es extrem
> erschwert hatte, z.B. "*" zu matchen. Da musste dann ein aufwändiges
> Konstrukt zusammen gebaut werden.
> 
> Da habe ich dann übrigens gedacht: Sch...., warum nutzen die nicht Perl-regexps
> und Perl's eval?! :)

Siehste! So gefällst du mir. Okay, die eval()-Funktion in Perl ist wohl
etwas zu riskant. Aber der Wunsch, dass vorhandene Regex-Sprache
wiederverwendet wird, ist sehr fortschrittlich. Genau auf sowas will ich
hinaus. Nimm das, was da ist, statt es inkompatibel und womöglich
schlechter nachzubauen.

> Und man könnte es aber mit anderen Sprachmöglichkeiten auch
> versimplifizieren, indem man z.B. ein Keyword einführt, das andeutet,
> daß das nachfolgende Regexp-Konstrukt oder Einzel-Symbol literal
> zu nehmen ist und nicht als Wildcard.
> 
> Da haben die am falschen Platz gespart und hätten so eine Möglichkeit mit
> rein nehmen sollen.

So, wie du es beschreibst, leidet auch Websieve an diesem Syndrom, durch
ihre Ignoranz gegenüber dem Stand der Technik. Und *du*, als etwas
anspruchsvollerer User, leidest darunter.

Genau davor wollte ich dein Labannotation-Projekt bewahren.

[ XML-Format ]
> Allerdings hätte ich den Tag-Parsser selbst gebaut.
> Ist übrigens auch nicht sonderlich schwer.

Mag sein, aber dann kommt ein User vielleicht auf die Idee:
Hey, das ist XML, und zieht alle Register von XML, und du
bist dann nur noch damit beschäftigt, alle weiteren XML-
Syntaxmerkmale zu erlauben. Statt einfach direkt einen 1000x
getesteten, stabilen, gut gereiften XML-Parser zu nehmen.

> Und interessant, das mal implementiert zu haben.

Wiegesagt: Für dich, zum Spaß, völlig okay. Mach ich auch nicht anders.
Aber für alles andere ist dieser Ansatz IMHO ungeeignet.

> > Nein? Aber die
> > Eingabe-Sprache, die muss unbedingt zu 100% selbstgestrickt sein.
> Wenn das Stricken Spaß macht, was spricht dagegen?

Die Qualitätssicherung, die armen User, dein Aufwandt, die schlechte
Wiederverwendbarkeit, die drohende Inkompatibilität.

Übrigens macht das Verwenden von anderen Parsern auch Spaß, vielleicht
nicht ganz so viel, aber dafür hält *dieser* Spaß länger an. Sonst wird
dir und den Usern der Spaß schnell vergehen, wenn das Projekt wächst und
gedeiht.

> Hatte mir aber gedacht: lieber erst mal iregdnwas funktionierendes ins Netz
> legen und feedback einholen, als das Perfekte niemals fertig ztu kiegen.

Ja, das war völlig okay.

> Wie man sieht, hat es mindestens eine Diskussion angezettelt.
> Das war also schon mal sinnvoll so.

Richtig. Hauptsache, du nimmst die Kritik dann auch an. :)  Wenn du es
tust, kannst du auf meine Hilfe jedenfalls zählen. Das Labannotation-
Projekt klingt sehr interessant. Zumal ich im Bereich Textsatz schon
einiges gemacht habe, daher kommt ja auch das Wikidok-Projekt
letztendlich.

> > Denn ab einem bestimmten Grad an Ansprüchen, der gar nicht so
> > weit oben liegt, hätte das Erlernen von LaTeX mehr Nutzen als Aufwandt
> > gehabt. Außerdem kannst du ja ConTeXt oder Lout nehmen, die sind
> > anfängerfreundlicher als LaTeX.
> 
> Naja, es hat eben auch noch andere Vorteile, wenn man was spezielles baut.

Aber sehr viele Nachteile. Eine spezielles Anwendungsgebiet gezielt zu
fördern ist die eine Sache, da bin auch dafür. Aber für diesen Zweck
jede Schraube neu zu erfinden, ist unnütz und schädlich.

> > Ja und? Du willst doch, dass der User sowieso eine neue Sprache lernen
> > soll (nämlich deine selbstdefinierte). Da macht es für den Anfänger
> > keinen großen Unterschied,
> 
> Na gut. Die Syntax ist sehr ähnlich.
> So gesehen kann man das eigentlich übernehmen, da geb' ich Dir recht.
> 
> Den Lerneffekt "Implementierung eigener Sprache mit lex und yacc"
> hingegen habe ich dann nicht. Naja, egal, das ist ja jetzt schon erledigt. ;-)

Eben!

Und der Vorteil wäre, dass besonders interessierte User dann auch
"weiter" gehen können, und ihr Gelerntes auch für andere Sachen
verwenden können. Synergie-Effekte sind wichtig ... aus
wissenschaftlicher Sicht, also aus Sicht des Fortschritts.

Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR