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:

• Blindbacken
  
• Hohl auslösen
• Klären
• Trockenschleudern
• Trockenschwenken
• Verschütteln
• Plattieren
• Mazerieren
• Abbröseln
• Abschwaden

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"

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?

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...