Kleinste gemeinsame Obermengen

Heute hatte ich bei der Arbeit ein interessantes Problem.
Es fing ganz harmlos mit "Business Logik" an und reduzierte sich je mehr ich darüber nachdachte auf schlichte Mengenlehre.

Das Kernproblem ist folgendes und sei dem geneigten Leser zur Implementierung überlassen:

Man hat eine Gesamtmenge A von Mengen B.
Diese Mengen B enthalten eventuell gleiche Elemente.
Aufgabe ist es nun "kleinste gemeinsame Obermengen" zu finden. D.h. wenn zwei Mengen gleiche Elemente enthalten, müssen sie vereinigt werden.

Beispiel:
a: [1]
b: [2, 3]
c: [4, 5, 6]
d: [7, 8]
e: [9]
f: [1, 3, 4, 5]

=>
[1, 2, 3, 4, 5, 6], [7, 8], [9]
d.h. a, b, c und f werden vereint. d und e bleiben separat.

Ich habe das ganze mit Maps, Sets und einer Rekursion gelöst. Und irgendwie habe ich das Gefühl, dass es eine einfachere Lösung geben muss.
Vor allem ist mir auf dem Nachhauseweg aufgefallen, dass ich die ganze Aktion vermutlich auch noch für eine andere Gruppierungsebene machen muss...

Ruby

Ich habe jetzt angefangen mir die Programmiersprache Ruby anzusehen.
Koryphäen wie Martin Fowler schwärmen davon. Und das will etwas heißen, denn er hat ein paar wunderbare Bücher über Programmierung geschrieben. Vor allem den Klassiker "Refactoring: Improving the Design of Existing Code".
Außerdem ist es die Modesprache des Tages.

Und mein erster Eindruck ist: furchtbare Hackersprache. Javascript reloaded.

* Man kann abkürzen wo man will. D.h. Methodenaufrufe brauchen nicht einmal die sonst üblichen Klammern, wenn man keine Parameter hat.
* Membervariabelen werden nicht zwingend deklariert. Sie entstehen quasi bei Benutzung.
* Methodendeklarationen sind arschhäßlich und erinnern mich an 70er Jahre Sprachen. Anstelle von Klammern wird mit "end" gearbeitet. *schauder*
* Überhaupt scheinen die Entwickler eine Allergie gegen Klammern gehabt zu haben, was bei if und ähnlichen Kontrollstrukturen eher zur Verwirrung beiträgt.

Viele Blogs, in denen Ruby gelobt wird, pochen darauf, dass andere Sprachen viel zu unflexibel seien, zu viel Tipparbeit erfordern und den Blick auf das Wesentliche durch zu viel Ballast ("boiler plate code") verschleiern.

Man kann den Code in Ruby zwar durch diverse Umdefinitionen klein halten, aber m.E. leidet die Lesbarkeit sehr darunter. Vermutlich soll der Name von einer gewissen Verwandtschaft mit Perl zeugen. Sozusagen Perl x C++ mit syntaktischen Anlehnungen an Pascal.
Und ich kann mir wirklich nicht vorstellen, wie man da bei einem größeren Projekt noch durchblicken soll. Sobald die ersten Umstrukturierungen kommen, verliert man den Durchblick.

Ich finde Ruby noch unleserlich und verwirrend, aber so ging es mir mit Java 1.1 anfangs auch.
Mal sehen ob sich der Eindruck ändert, wenn ich erst mal etwas damit gemacht habe.