Tuesday, May 29, 2007

Kochjargon

Eigentlich wollte ich einen kurzen Blogeintrag darüber schreiben, wie man den Sachverhalt des "Reduzierens" (beim Kochen) sinnbildlich auf das Programmieren übertragen könnte. Dazu vielleicht mehr später, zunächst mal ist mir, neben Reduzieren, eine ganze Reihe so schöner und bemerkenswerter Begriffe aufgefallen wie:
Wunderbar, oder? Da fällt mir erstmal nur noch Loriot ein:
"Man musste die Silben in die richtige Reihenfolge bringen. Es musste heissen
"Brat fettlos mit Salamo-Bratfett-ohne", aber es stand dort... Oh-mo-ne-la-sa-mit-brat-brat-fett-fett"

Thursday, May 17, 2007

Ruby, creating classes dynamically

Eine Klasse "Klass" mit einer Methode "meth" würde man ja normalerweise so definieren und instanzieren:

class Klass
def meth
"soso"
end
end

Klass.new.meth # => "soso"

Angenommen, man hätte den Inhalt der Klasse als String vorliegen, könnte man das Gleiche so machen:

s = <<eos
def meth()
"soso"
end
eos

Klass = Class.new() # neue leere Klasse erzeugen und der Konstante "Klass" zuweisen
Klass.class_eval s # "Evaluate" String (mit der Methodendefinition) im Kontext der Klasse

Klass.new.meth # => "soso"

Angenommen, man hätte auch den Namen, den die Klasse erhalten soll, als String vorliegen, so:

s = <<eos
def meth()
"soso"
end
eos

Kernel.const_set("Klass", Class.new())
Klass.class_eval s

Klass.new.meth # => "soso"

Angenommen, der Name, den die Klasse erhalten soll, wäre auch in dem String mit dem Inhalt der Klasse als Konstante definiert:

s = <<eos
NAME = 'Klass' # <= so soll die Klasse später mal heißen
def meth(); 'soso'; end
eos

c = Class.new
c.class_eval s
Kernel.const_set(c::NAME, c)

Klass.new.meth # => "soso"

Schon erstaunlich, oder?

Tuesday, May 08, 2007

Design Challenges

Ich bin schon mal über das online verfügbare Kapitel 5 aus dem Buch Code Complete 2nd Edition von Steve McConnel gestolpert (siehe Managing Complexity). Heute fiel mir folgende Liste an "Design Challenges" aus dem gleichen Kapitel auf:
  • Design is a wicked problem
    Wicked scheint sowas wie "teuflisch" zu heißen, also: Design ist ein teuflisches Problem. Warum? Man muss das Problem oft erst gelöst haben, um klar zu erkennen, was das Problem eigentlich ist. In der Regel muss man ein Problem zunächst lösen, um es klar definieren zu können, und dann erneut "lösen", indem man eine funktionsfähige Lösung schafft.
  • Design is a sloppy process
    Das Endergebnis mag ordentlich und organisiert sein, der Weg dahin ist es nicht. Der Weg dahin ist voll von Fehlern, Missverständnissen und Irrwegen, was auch völlig ok ist. Design lebt von Fehlern, die dazu beitragen das Design zu verbessern.
  • Design is about Tradeoffs and Priorities
    Abwägen, Kompromisse finden, Prioritäten setzen. Irgendwas bleibt immer auf der Strecke.
  • Design Involves Restrictions
    Anything goes? Nein, eher Möglichkeiten einschränken.
  • Design Is Nondeterministic
    Das Endergebnis ist nicht festgelegt. Man kann auf vielen verschiedenen Wegen ans Ziel kommen.
  • Design Is a Heuristic Process
    Designtechniken, die wiederholbar ein vorhersehbares Ergebnis erzielen? Gibt es nicht. Eher eine Frage von Faustformeln, Versuch und Irrtum. Kein Werkzeug ist für alles geeignet.
  • Design Is Emergent
    Ein Design "entspringt nicht fertig aus irgendjemandes Kopf", sondern entsteht graduell beim Entwickeln der Lösung, durch Design Reviews, Diskussionen, Erfahrungen beim Programmieren selber, usw..
Ja, hochinteressant, oder? Vielleicht sollte man sich das Buch anschaffen...