ruby, MRI, wiederverwendbare Software, NIH, ...

Mir scheint da in Ruby überhaupt so ein generelles NIH-Problem zu existieren. Könnte letztendlich eines der Argumente gegen Ruby sein. Aber wie geht der Spruch mit dem Fisch und dem Kopf? Habe jüngst die Erfahrung gemacht, dass man bei MRI auch in Sache POSIX locale nicht auf (GNU) libc setzt sondern lieber auf re-inventing the wheel. Sei's drum!
In den 80-er sprach man nicht nur von re-usable software, sondern man verfolgte den Ansatz auch, und man hat Software schließlich auch re-used. Software muss nicht nur re-usable sein, sie muss auch re-used werden, sonst hat das Ganz ja wohl kaum einen Sinn.
Heute entsteht so manche Software halt im Rahmen von Hochschul-Projekten zur Übung und mehr oder weniger als proof of concept, und dann besinnt sich niemand eigentlich besserer Lösungen. Sehr bedauerlich. Nein, richtig loben kann ich niemanden dafür, dass er für Sprache x die n+erste regular expression engine baut und verbreitet. Schön, dass er das kann, und wenn man 10 Studenten-Gruppen und ihre Lösungen zu einem Standard-Problem vergleichen kann, dann mag's ja noch angehen, aber auch die beste dieser Lösungen muss deswegen noch nicht für Sprache x die Standard-Lösung werden. Mir graut davor. Echt.
MRI ist in C geschrieben, und wird wohl in der Regel mit gcc übersetzt, und im Umfeld des gcc gibt es passender, performante, ressourcen-schonend und reife Lösungen, die schon so manchen Sturm überlebt haben und dabei Qualität bekamen. Nicht dass meine heile Nacht-Ruhe davon abhängt, dass mein Ratschlag befolgt wird, aber MRI sollte soweit möglich auf performante reife Middleware setzen (niemand würde ernsthaft die echt großen Middlewaren in Ruby nachbauen, aber so studienarbeitsgroße Teile wohl immer wieder) und NIH und Reinventing_the_wheel sind Mist.
Ja, ich habe auch schon mitbekommen, das JRuby auch nicht in C geschrieben ist, und dass man auch im JRuby-Umfeld eine gangbare Lösung braucht. Ja. Ist aber nicht mein Problem. JRuby ist ja eigentlich nicht schlecht vom Ansatz her - vielleicht, aber wenn einen eine Parallel-/Alternativ-Implementierung zu heftig sub-optimalen Lösung drängt, dann ist eine Nötigung, der ich mich nicht aussetzen will. Aber / und muss man jetzt wegen JRuby auch im MRI- / CRuby-Umfeld alles in Ruby schreiben, was nicht unbedingt in Ruby geschrieben werden muss, nicht wahr?
So genug für heute ;-)