Ruby, Fanboys und Anwendungsfälle

04/08/2012 - 11:07 von Oliver Sch | Report spam
Heyho,

ich möchte mal mit einem etwas ketzerischem Betreff eine Debatte
eröffnen. Seit ich Ruby kenne (etwa 6 Jahre würde ich schàtzen), habe
ich diese Sprache immer sehr gemocht.

Gemocht habe ich vor allem, weil einige wenige Konzepte recht konsequent
durchgesetzt wurden und somit es aus meiner Sicht recht einfach ist die
Sprache zu verstehen.

Ruby ist aber am Ende für mich ein Werkzeug, um Probleme zu lösen, d.h.
vom meinem àstethischen Empfinden her komplett unabhàngig. Somit gibt es
auch für mich eine Differenzierung zwischen den beiden. Ich schaue mir
an, was ich damit gut erreichen kann und was nicht.

Ich hab jetzt einige Leute kennengelernt, die absolute Ruby-Fans sind
oder sogar schlimmer Fanboys sind, die diese Differenzierung nicht mehr
hinkriegen.

Ruby wird zu quasi-religiös betrachtet und somit wird gerade die
Funktion des Werkzeugs auch quasi verleugnet. Ein Werkzeug nutzt man,
eine Religion hat man.

Meine Auffassung ist, dass gerade, wenn man ein Werkzeug sehr gut kennt,
seine Schwàchen auch gut kennt. Schwàchen sind dabei keine absoluten
Schwàchen, sondern je nach Problemlage ist ein Verhalten/Fàhigkeit eine
Schwàche, in einer anderen Lage durchaus auch eine Stàrke.

Ich mag an Ruby, dass es recht wenig Spielregeln gibt, man kann vieles
formen, wie man will. Das widerspricht vielen Konzepten, Java war früher
für mich beinahe ein Kontrapunkt dazu, Statik war das Ziel.

Dieses Verhalten wird aber unter anderen Umstànden zum Problem: in
größeren Projekten mit vielen Personen, Organisationseinheiten und
Organisationen sehe ich, dass die organisatorischen Regeln und Aufwànde,
die man trifft und anfallen, einen immer größeren Teil ausmachen,
unabhàngig davon, was man erreichen will und womit.

Dies gilt für mich umso mehr, je flexibler/dynamischer eine Sprache ist,
denn um fehlende technische Regeln zu kompensieren, muss man
organisatorisch tàtig werden, Vereinbarungen treffen. Z.B. Monkey-
Patching kann schonmal cool sein, ist aber der Verlàsslichkeit sehr
abtràglich. Wenn man weder weiß, woher ein Verhalten kommt, noch wie man
den Code dazu findet, steht man vor einer echten Herausforderung.
Organisatorisch macht es also Sinn zu vereinbaren, dass man Monkey-
Patching unterlàsst, damit Code lokalisierbar ist und Verhalten
garantiert werden kann.

Meine Perspektive wàre, dass Ruby in großen Strukturen schwierig wird,
wenn man sich nicht ganz streng an gewisse Spielregeln hàlt. Tendenziell
aber ist es sowieso in großen Strukturen schon schwierig Spielregeln
durchzusetzen, daher würde ich auch da sagen, lieber technische
Durchsetzung der Spielregeln, anstatt organisatorische.

Da wàre dann für mich Ruby, was praktisch keine Spielregeln durchsetzen
kann eher außen vor.

Wie seht ihr das?
Wie erlebt ihr die Community?
Für welche Strukturgrößen seht ihr Ruby?
Gibt es Aspekte, die man zudem noch dringend mitbetrachten sollte beim
Einsatz?

mfg
Oli

Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
 

Lesen sie die antworten

#1 Robert Klemme
04/08/2012 - 12:58 | Warnen spam
On 08/04/2012 11:07 AM, Oliver wrote:

Für welche Strukturgrößen seht ihr Ruby?



Ich habe keine Erfahrungen mit großen Ruby-Projekten aber eine gewisse
Skepsis gegenüber der Bedeutung statischer Typisierung und anderer
Dinge, die es z.B. in Java gibt und in Ruby nicht. Ich habe schon zu
viel schlechten Java-Code gesehen, der auch durch die größere Striktheit
nicht verhindert wurde. Wenn man Software mal betrachtet, stellt das
Schreiben von Programmcode nur einen kleinen Teil der Arbeit dar (da
wàren noch: Anforderungsanalyse, Design, Tests, Dokumentationen...).
Und wenn es in diesem eher kleinen Teil eine Erleichterung gibt, dann
muss das für das gesamte Projekt gar nichts bedeuten.

Gibt es Aspekte, die man zudem noch dringend mitbetrachten sollte beim
Einsatz?



Ja. Im Ernst: so allgemein kann man das schwer beantworten.

Ciao

robert

Ähnliche fragen