Früher mal dachte ich, dass das ja in den Universitäten sein muss. Schließlich ist da alles auf einem fleck. Forscher und Lehrer und Schüler.

Optimale Bedingungen eigentlich - nur dass dort an der Lehre überhaupt nicht geforscht wurde. Schließlich war das ja nur ein Anhängsel das Zeit kostet. Kein Forschungsgebiet.

In der Schule natürlich sowieso nicht und danach?

Im Beruf?

Ich bin natürlich mein eigenes Forschungssubjekt, weil ich weiter lerne und das beobachte. Und für mich selber ist es natürlich so dass ich ständig mit Innovationen habe, durch meine Möglichkeit das Netz zu verwenden.

Aber ab und an trifft man auf etwas großartiges. In einem  Interview von John Udell bin ich auf die  Khan Academy gestoßen.

Das ist ein Mensch der seine Erfüllung darin findet dass er kurze Videos (~10 Minuten lang) aufnimmt in denen er eine Sache - ein Konzept aus Mathematik, Physik, Chemie, Finanzen und vielen weiteren Themen.

Und die sind gut!

Ausserdem hat er  eine Software online gestellt die ein sehr spannendes Konzept verfolgt: Wissen ist dort als Graph aufgestellt - von einfachster Addition bis zu relativ komplexen Themen. (Aber viel weniger als als Video verfügbar ist).

Der Clou: Man fängt bei einfacher Addition an und kriegt die nächst-Schwierigeren Aufgaben erst wenn man 10 Aufgaben aus einem Wissensgebiet erfolgreich direkt hintereinander gelöst hat.

Dazu gibt es jeweils den ganzen Lösungsweg plus einen Link auf das dazugehörige Video wenn man es noch mal im Detail braucht.

Das führt dazu dass Kinder gerade bei Mathe ihre Lücken auffüllen können die sie irgendwo im Verständnis haben. Und das finde ich Großartig - denn das ist eines der größten Probleme von Großgruppen-Lernen. Wenn ein Thema vorbei ist, dann ist es vorbei - egal ob man es verstanden hat oder nicht.

Verdammt schade dass es noch soo lange dauern wird bis solche Konzepte auch in der "Offiziellen" Lehre angekommen sind.

Klima-Veränderung ist ein schwer zugängliches Thema.

Aber auch Sau-Wichtig. Und daher finde ich es grandios was James Balog für eine Arbeit gemacht hat um den Gletscher-Rückzug zu dokumentieren. Mit knapp 30 Zeitraffer-Kammeras macht er über Jahre Hinweg jede Stunde ein Bild von vielen Gletschern und daraus dann einen Film.

Wow.

• Gibts bei  TED als Video
• Oder auf  der Homepage des Projekts
• Mein  Lieblingsvideo dort bisher

:) Einer meiner Lieblingspodcasts hat es jetzt auf die 100. Ausgabe gebracht.

Und da muss ich doch mal gratulieren. Vor allem weil ich bei der Quiz-Show über Programmiersprachen und deren Verbreitung absolut herzhaft gelacht habe. :-)

Hörenswert! Immer wieder großartige Interviews mit Machern von Open Source Projekten.

[Hier gehts zur 100-sten Show  http://twit.tv/floss100]

Das ist ein steinalter  Vortrag von Alistair Cockburn (gesprochen Co-Burn) in dem er darlegt wieso er findet das das eine sehr gute Sichtweise auf Softwareprojekte ist.

Der Vortrag ist schon 10 Jahre alt - und trotzdem finde ich ihn sehr Aktuell.

Lesenswert!

a = b = list()
a = a + ['foo']
print b # => []

a = b = list()
a += ['foo']
print b # => ['foo']

Doh. Wie kann das sein? Kommt man von C ist das erst mal sehr verblüffend - und auch die meisten anderen Programmiersprachen die ich kenne verwenden a += b als equivalent für a = a + b.

Well, nicht so Python. Weil  da gab es offenbar mal Programmierer die fanden dass man Code der mit Matrizen rechnet lieber mit Operatoren schreiben möchte weil sich das besser ließt. Natürlich nicht mit den normalen operatoren wie */+-, weil, da kann man ja den empfänger nicht in place modifizieren, und wie jeder weiß sind Matrizen ja so groß dass die dann nicht mehr in den Ram passen.

Also haben sie die <op>= operatoren in Python so spezifiziert, dass sie ihre left-hand-variable in place modifizieren wenn diese mutable sind.

:-(

Klassenobjekte sind special - daher hat man im boddy einer klasse keinen Zugriff auf das klassenobjekt.

Weil, self ist ja auch nicht automatisch und man muss es in Methoden immer als explizites Argument hinschreiben, und so etwas gibt es ja bei Klassen nicht, denn das sind ja keine Methoden und daher kann man halt das Klassenobjekt nicht referenzieren im body.

Doh.

Und das nervt natürlich total bei der meta-programmierung.

Hier mal ein Beispiel von etwas SQL-Alchemy Code wo mir das wieder aufgefallen ist:

class Poll(Base):
    proposal = relation(proposal.Proposal, backref=backref('polls', cascade='all',
                           lazy=False, order_by=Poll.begin_time.desc()))

Das geht nicht, weil ich auf Poll nicht zugreifen kann und damit nicht auf andere attribute der Klasse. Der Workaround den SQLAlchemy dafür macht ist das man einen String hineinreicht und die den dann aufwendig parsen. Total gar nicht toll.

:-(

Das höchste Ziel in der Physik ist alle Kräfte durch eine Formel auszudrücken bzw. sie in Beziehung zueinander zu setzen. Maxwell zum Beispiel gelang das für elektrische und magnetische Felder - und dafür ist er noch heute berühmt.

In der Software-Entwicklung gibt es so etwas bisher nicht. Klar, es gibt Daumenregeln, so wie:

• Keep it  DRY
•  Keep your Methods Small **
• Work  SOLID
• Obay the  Law of Demeter
• und so weiter…

Aber, und das ist der wichtige Teil: diese Daumenregeln sind keine Unifikation die die verschiedenen Probleme beim Programmieren abwägen und in Beziehung setzen.

Daher finde ich  Jim Weirichs Vortrag  The Building Blocks of Modularity sehr spannend - denn da stellt er den Ansatz der  Connascence vor (ab Folie 35).

Das ist letztlich eine Klassifizierung welche Art von Abhängigkeit man sich durch welche Programmiertechnik einfängt - und damit kann man 'normales' Refactoring anwenden um von problematischeren Connascence's (?) zu weniger problematischen zu kommen.

Ach ja, ursprünglich kommt das aus dem Buch  What every Programmer should know about Object Oriented Design. Davon kann man aber Getrost nur noch den dritten Teil lesen (über Connascence) - der rest ist nach 15 Jahren einfach veraltet. :)

** Niemand sagt das so gut wie Kent Beck: "Lots of little pieces - Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the “once and only once” rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces."

Eine Sache die mich bei Python immer wieder ärgert ist die Tatsache dass Standardwerte für Methodenargumente zur Parsezeit festgelegt werden anstatt zur Aufrufzeit.

Das ist total doof, denn dadurch teilen sich alle aufrufe der Funktion den gleichen default-wert - was zwar schön schnell sein mag, aber trotzdem in fast allen Fällen nur bei nicht veränderbaren Objekten (so wie Integer und Strings) Sinn ergibt.

So führt das dazu dass man in Python eine ganze Menge Workarounds braucht um mit default-argumenten zu arbeiten.

Das wichtigste dabei ist der default typ None. Das ist der workaround für alle mutable-objekte, da man die in fast keinem Fall zwischen verschiedenen Methodenaufrufen teilen möchte. So sieht das aus:

def end_poll(self, end_time=None):
    if end_time is None:
        end_time = datetime.utcnow()
    # work with end_time...

Der Punkt hier ist dass man datetime.utcnow() nicht in das standard Argument hineinschreiben kann, da man sonst bei jedem Aufruf der Methode den gleichen Wert hätte: Die Parsezeit. Nicht sonderlich nützlich.

Das hat zur Folge dass man:

• aus der Signatur nicht sehen was das Standardargument ist (utc/gmt oder vielleicht ewas ganz anderes?). Immerhin gibt es inzwischen immer mehr IDEs die diese Signatur beim aufrufen für autocompletion nutzen oder sie wenigstens anzeigen können.
• Man beim verwenden von Standardargumenten immer überlegen muss ob man dieses Argument jetzt in die Methodendefinition oder in den Body aufnehmen muss.
• für jedes Standardargument noch mal zwei extra Zeilen braucht. Das nervt vor allem deswegen weil man sich mit den standard Argumenten ja Zeilen sparen möchte. Das heißt die Kosten für Standard-Argumente steigen und man benutzt sie seltener.
• die default argumente noch mal separat dokumentieren muss, da ein dokumentations-extraktions-Werkzeug ja den Code nicht sieht, der das tatsächliche Standardargument setzt. Und natürlich hat man dann noch mal DRY verletzt da die Information jetzt zwei mal da steht.
• richtig fiese Bugs kriegt, weil viele Leute diese Probleme nicht kennen oder sie ab und an vergessen und mal ein list(), dict() oder set() als Standardwert nehmen was dan für viel Freude beim Debuggen sorgt.

Also, know your Python und vorsicht mit Standardargumenten!

Vielleicht kriegen wir ja irgendwann von unserem BDFL ein from __future__ import runtime_standard_argument_evaluation.

Ein Vortrag von der  GORUCO - sehr zu empfehlen.

Besonders gefallen hat mir ihr Fazit dass man mehr als nur  DRY als Prinzip beim Refactoring anwenden soll um bei gutem Code anzukommen.

Sandy Metz empfiehlt das man sich an den 'Grünen' Stellen des Red/Green/Refactor Zyklus für jedes Objekt diese Fragen stellt:

• Is it DRY?
• Does it have one responsibility?
• Does everything in it change at the same time?
• Does it depend (only) on things that change less often than it does?

Und bringt das auch an einem ordentlichen Beispiel auf den Punkt.

Alles in allem: Ein Vortrag der zum Nachdenken über den eigenen Code-Stil einlädt. Empfehlenswert!

Ich vertrete ja schon länger den Punkt dass ein Grundeinkommen eine Notwendigkeit sein wird in einer Gesellschaft in der Maschinen uns alle physischen Arbeiten abnehmen können.

Well, jetzt habe ich endlich jemanden gefunden der dieses Argument auch vertritt.

Auf dem 26C3 im Vortrag  Here be electric dragons

Sehr sehenswert!

Schon seit einigen Wochen bin ich am grübeln, nach welcher Regel ich in Python meine variablen für Methoden-Argumente benennen soll. Das ist erstaunlicherweise gar nicht so klar.

Hier mal das Problem: In Objective-C ist alles sehr klar und einfach (von Smalltalk kommend). Jede Methoden-Deklaration besteht abwechselnd aus einem Teil Methodennamen und dann einer Variablen. Hier mal ein Beispiel:

- (void) setValue:(id)aValue forKey:(id)aKey

Das hat den großen Vorteil dass man den Methodennamen benutzen kann um Stück für Stück die Argumente zu dokumentieren. Verwendet wird das so, dass das Stück Methodennamen das vor einem Argument kommt die Rolle beschreibt die das Argument spielen wird, während der Name der Variablen eher generisch ist und sich eher am Typ orientiert. Dazu kommt natürlich das man die Typen auch explizit auszeichnen kann, was die notwendigkeit für die Typ-Annotation im Namen der Variablen im vergleich zu Smalltalk oder Python noch mal vermindert und man kann ihn ganz der Rolle hingeben die die Variable in der Methode spielen wird - versehen mit dem a/an/some/etc. prefix der Argumente (als generische Instanzen von etwas) von den lokalen und instanz-variablen unterscheidet.

In Python geht das so nicht. Man kann versuchen das auf zwei wegen anzunähern:

def set_value_for_key(a_value, a_key): pass
# benutze als: some_dict.set_value_for_key('value', 'key')

Das hat den Vorteil das man die Argumente mehr oder weniger benennen kann wie man möchte, aber den Nachteil das die Dokumentation der argumente nicht mit diesen zusammen ist. Das hat schon mal den unangenehmen seiteneffekt das es sehr viel schlechter auf mehrere Argumente skaliert und damit sehr fix mehr extra-dokumentation nötig macht.

Der andere Weg wäre so:

def set(value, for_key): pass
#benutze als: some_dict.set(value='value', for_key='key')

Das hat den Vorteil dass der MethodenNamen von der Dokumentationshürde befreit ist - und damit Kurz wird. Auf der anderen Seite sind die Argument-Namen jetzt effektiv teil des Methoden-Namens und damit kann man sie nicht mehr so gut benutzen um den Typ der Argumente zu dokumentieren.

:-(

Das ist der Grund wieso ich die Objective-C / Smalltalk Syntax so gerne mag, weil es darin so einfach ist selbstdokumentierenden Code von hoher qualität zu schreiben.

Viele standard-funktionen und module in python haben zu kurze namen.

Das ist deshalb ein Problem weil, man diese Namen nicht für lokale Variablen verwenden kann bzw. ungewollt eine Standardfunktion überschreibt.

id zum Beispiel. Oder dict, list.

Module sind dabei aber auch Problemkandidaten - vor allem wenn man sie häufig wie ein Objekt benutzt. Das json Modul macht mir immer wieder probleme, weil ich eine lokale Variable die json enthält nun mal gerne json nennen würde. json_serialization wäre vielleicht ein besserer Name für das Modul.

Die Standard-Bibliothek ist leider voll von solchen Beispielen und der Include-Mechanismus von Python der die Module quasi als Objekt im namespace des Empfängers verfügbar macht hilft da nicht wirklich weiter. Das ist zwar IMO eine bessere Idee als der C-Präprozessor #include (was Ruby ja zum Beispiel nachbaut) aber gerade bei so kurzen Namen kann das wirklich nerven.

Wenn man aus einem Modul ein Objekt importiert ist das interessanterweise kein Problem, da Objekte in Python (wenn sie sich an die Namenskonvention halten - leider auch oft nicht der Fall in der Standardbibliothek) immer mit einem Großbuchstaben anfangen und dadurch diese Namenskollision nicht auftritt.

Für mich ist da das Problem dass die Python Programmierer leider so eine Obsession damit haben alles möglichst kurz machen zu wollen - und dabei aber dem Programmierer der mit der (Standard-) Bibliothek arbeiten möchte gerade wieder Steine in den Weg legen dass kurz zu machen was für Ihn am meisten sinn macht - lokale Variablen.

Das ist leider Premature Optimisation in Reinstkultur - und es stört mich beim Entwickeln von meiner Software. :-(

Well, it's all too easy apparently. We stumbled upon the problem when suddenly our web application crashed left and right on us in IE 7.

I've since reduced the code involved and created a plugin to jQuery to make it easier to reproduce this.

Well, maybe perhaps sometimes somebody even discovers a use for the crashIE7 jQuery plugin. :)

In any event - it was fun creating this. :)

See the blog post page for the attached source and how to use this.

Endlich mal hab ich einen überblick gefunden wo die Entwicklung momentan hingeht.

 http://mail.python.org/pipermail/python-dev/2009-October/092754.html

Kurz zusammengefasst:

• easy_install, ez_setup und Konsorten wird sterben.  distribute ist die Zukunft
• easy_install wird sterben ->  pip ist die Zukunft
• Metadata wird aus dem setup.py script herauswandern und stattdessen in einem ini file zur Verfügung gestellt (Da ist mir noch nicht ganz klar wie das funktionieren soll - aber gut).
• Deinstallieren wird auch mit den distutils gehen - man braucht also nicht mehr pip um das zu machen

Und noch mehr. Aber das find ich schon mal am wichtigsten. :)

 via

Meine Mutter hat diesen lesenswerten Text dazu geschrieben - und den möchte ich gerne (mit ihrer Erlaubnis) noch mehr Leuten zugänglich machen. Grund dafür ist diese Email die gerade mit diversen gut klingenden Arzt-Namen als Absender auch durch meine Inbox wandert

Für alle, die überlegen sich impfen zu lassen :

Die beiden Impfstoffe gegen die so genannte Schweinegrippe *Pandemrix® Und Focetria®,* enthalten als Adjuvans (Impfverstärker ) *Squalen*. Beim Menschen ist Squalen bei den US-Soldaten des ersten Golfkriegs als Impfverstärker eingesetzt worden.

23-27% (also jeder Vierte, auch solche, die zu Hause blieben) bekamen Die Golfkriegskrankheit, Mit chronischer Müdigkeit, Fibromyalgie (Muskelrheuma), neben Gedächtnis-und Konzentrationsproblemen, persistierenden Kopfschmerzen, Erschöpfung und ausgedehnten Schmerzen charakterisiert. Die Krankheit Kann auch chronische Verdauungsprobleme und Hautausschlag einschließen.

Die Erkrankung hat sich seit 1991 also seit 18 Jahren nicht gebessert. Bei 95 % der Geimpften mit Golfkriegssyndrom wurden Squalen-Antikörper Gefunden.

Erst nach mehr als 10 Jahren wurden die Schäden vom US-Verteidigungsministerium anerkannt.

Wenn die Bundesregierung ihren Willen durchsetzt und 35 Millionen Menschen geimpft werden, ist damit zu rechnen, dass 8-9 Millionen Bundesbürger für die nächsten Jahrzehnte unter chronischer Müdigkeit und Fibromyalgie etc. leiden werden.

Unterschrieben von: $GUT_KLINGENDER_ARZT_NAME

Dazu hat sie diese gute Antwort geschrieben:

Ja, es stimmt. Pandemrix + Focetria enthalten Squalen, das injiziert zum Imunogen wird. Das ist seine wirkstoffverstärkende Ebene. Es wird auch in unserer Leber produziert, aber liegt natürlicherweise in öliger Form vor. Im Impfstoff aber als Emulsion, was einen Unterschied für die Verstoffwechselung im Körper macht. Der Verdacht, dass es etwas mit dem Golfkriegsyndrom zu tun hat, ist nicht erhärtet. Neuere Studien mit größeren Teilnehmergruppen zeigen keinen Zusammenhang zwischen Squalen-Antikörpern und chron. Symptomen.- Dennoch wird unabhängig von diesem Aspekt der Debatte um diese Impfstoffe ihre Sicherheit als ungenügend geprüft eingeschätzt. Er wird schlechter vertragen als ein Spaltimpfstoff ohne Wirkverstärker. Das ist sicher. ER wurde noch nicht an Schwangeren und Kindern erprobt und die jetzt eingesetzte Wirkstoffverstärkerdosis ist viel höher als in bisher eingesetzten Impfungen. Nebenwirkungen wurden noch nicht systematisch erfaßt. Auch seine Wirksamkeit ist noch nicht hinreichend erforscht, da eine verringerte Dosierung gegenüber der Zulassungsphase jetzt vermarktet wird.

Da die Grippe gutartig abläuft und kein höheres Risiko darstellt, als die bisherigen Herbstgrippen, ist davon bei sonst gesunden Menschen abzuraten, ebenso bei Schwangeren und Kindern. Hier herum impfen nur wenige Ärzte und auch die Kinderärzte sind sehr zurückhaltend. Jürgen hat herausgefunden, dass 1974 dieser Virus schon mal "um die Welt lief", so dass alle, die damals schon sich anstecken konnten, wahrscheinlich immun sind.

Mein Rat an alle, die sich schützen wollen und dazu beitragen möchten, das sich die Viren nicht ausbreiten:

1. Bei ersten Symptomen ca 25 mg Zink einnehmen (gibt es als Tabletten) an zwei aufeinanderfolgenden Tagen. Parallel dazu Vitamin C Stoß mit heißer Zitrone o.ä. 2x täglich.
2. Cystus 052 Infektblocker Tabl. lutschen (pflanzlicher Virenblocker).
3. Wenn Fieber kommt, dieses auf über 39°C steigen lassen und abwarten. Viren werden durch Temperaturen über 39°C abgetötet. Es ist der effektivste Abwehrmechanismus. Die Nebenwirkungen des Fieberanstiegs ertragen sich am besten im Bett mit viel trinken und schlafen. Sobald die Viren keine Bedrohung mehr darstellen, geht das Fieber wieder runter (bei normalem Verlauf).
4. Auch ohne Fieber soll sich jeder im Stadium des Niesen und Hustens von seinen Mitmenschen fernhalten, da er wie eine lebende Viren-Schleuder wirkt. Am besten freiwillig daheim bleiben und viel Zeit auf Pflege der Gesundheit verwenden (Nasenspülung, Inhalieren, Tee trinken, ausruhen, an die frische Luft gehen wenn möglich, Basenbäder nehmen, bei Bedarf Brustwickel, Atemübungen, viel frisches Obst).

Ich hoffe dass das auch für viele anderen Leute einiges an Fragen beantwortet und die Pharmaindustrie hoffentlich deutlich einnahmen kostet.

Ich weiß ich bin etwas spät mich dazu auch zu äussern - aber jetzt wo die  Wikipedia wieder zu Spenden aufruft möchte ich was dazu sagen wieso ich nicht spende.

Das ist doch alles Kindergarten was in der Wikipedia gerade läuft.

Also gut, "embrace your enemy" oder wie es heißt, da können wir etwas tun.

Lasst uns einen Kindergarten eröffnen. Jeder neue Wikipedia-Artikel ist zuerst im Kindergarten und wenn er Groß und Stark geworden ist kann er irgendwann ins Erwachsenen-Artikel-Leben übertreten.

Das hätte folgenden Vorteil: Alle Exkludisten und die die nur die beste Qualität haben wollen legen einen Schalter um und sehen diese Einträge erst mal nicht.

Alle anderen verlieren nicht sofort die Lust an der Mitarbeit wenn einer Ihrer Artikel gelöscht wurde - weil er nicht gelöscht wurde.

Wenn jemand auf eine Seite kommt die unterhalb seines Qualitätslevels liegt, kann er ja einen Hinweis kriegen dass sie existiert, damit er sie mit einem Klick zu sehen bekommt bzw. er seine Einstellung ändern kann.

Alle sind Glücklich!

• Jeder Artikel kann jederzeit in den Kindergarten geschickt werden bis er groß wird.
• Jeder Artikel kann jederzeit aus dem Kindergarten "graduieren"
• Wer nur Inhalte von größtmöglicher geprüfter Qualität sehen möchte kann diese ausschließen
• Alle Anderen kriegen einen deutlichen Hinweis dass der Artikel noch im "Kindergarten" ist
• Man könnte Kindergarten Artikel generell anders Rendern damit der Unterschied ganz klar ist

Ich persönlich würde es vorziehen wenn die Standardeinstellung "Alles anzeigen" ist - aber auch wenn der Standard wäre "nur die geprüften Artikel anzeigen" und man jederzeit sieht wenn man an einer Stelle ist die im Kindergarten noch mehr Inhalt enthällt und man die nach bedarf zeigen kann wäre ich zufrieden.

Platz ist in der Wikipedia ja kein Problem - nur von Admins und regelmäßigen Mitarbeitern gepflegter Platz ist knapp.

Was ich will, ist das die User entscheiden können was sie lieber wollen. Mehr Artikel, oder besser geflegte - und nicht die die die meiste Zeit in das Projekt stecken. Das halte ich für absolut wichtig.

Ach ja, und falls das innerhalb der Wikipedia nicht funktioniert, müsste man so etwas als eigene Applikation davor setzen wikinursery.de / kindergarten.wikipedia.de oder per greasemonkey oder als iPhone App oder eben als "vollständige Wikipedia" irgendwo anders.

Nur innerhalb der Wikipedia wäre natürlich am besten - wobei zweifelhaft ist ob die macher des Projekts dafür bereit sind.

Ja, die Idee wurde schon von ein paar anderen Leuten geäussert - ich wollte sie auch noch einmal aufschreiben weil ich sie so wichtig finde.

 Ahhhhhhhhhh

Im vergleich zum Irak-Krieg? Oder alle Kinder dieser Welt für 5 Jahre zu ernähren?

 Hier wunderschön visualisiert.

So viel ist klar - man sieht was wichtig ist im Staat und was nicht. Leider.

 via

Zu  "Ergie" von Rainer von Vielen

In meiner Freizeit beschäftige ich mich gerade viel mit Ruby - sowohl  The Ruby Way, als auch  The Ruby Programming Language sind dafür gute Bücher.

Und ich muss sagen, das Ruby ist nicht unspannend. Zwar gibt es auch einiges dass ich ganz schön eklig finde (z.B. das Flip-Flop Statement, oder dass so viel mit globalen Variablen gearbeitet wird, oder dass viele Sachen so komplex sind.

Aber darum gehts hier gar nicht. Mir geht es hier um die Erkenntnis wieso und unter welchen umständen man Blöcke als etwas anderes sehen möchte als anonyme Funktionen.

Das dauert nämlich bis man das merkt.

Zuerst einmal die Konfusion: Ruby hat eine Syntax für Methoden

def method(positional_argument, *all_other_arguments)
  # some body
end

und eine für Blöcke

10.times do |positonal_argument, *all_other_arguments|
  # some body
end

Wieso der Unterschied? Wieso macht man Blöcke nicht einfach zu normalen Funktionen die man dann auch gleich mit () aufrufen kann anstatt immer ein a_block.call() verwenden zu müssen?

Echte Lambdas gibt es ja noch zusätzlich in Ruby.

Well, den Unterschied in der Syntax verstehe ich immer noch nicht. Aber dahinter steht der Grund dass Blöcke eine andere Aufgabe haben als Methoden - der Punkt ist nämlich dass man sie gerne als Teil der sie lexikalisch umgebenden Methode betrachten möchte damit man sie nutzen kann um mit ihnen Kontrollstrukturen zu implementieren. Hier mal ein Beispiel:

def find(needle, haystack)
  haystack.each.with_index do |index, element|
    if element == needle
      return index
    end
  end
  return nil
end

(Also als Python Programmierer muss ich ja sagen dass die end statements ganz schön auf die Nerven gehen. Doppelte Zeilenanzahl für null zusätzliche Information oder Nützlichkeit. But I digress.)

Das spannende daran ist die Zeile return index. Seht ihr was daran besonders ist? Ich Puzzle es mal auseinander als wäre der Block eine funktion, dann wird es klar.

find ruft einen iterator auf dem haystack auf, d.h. übergibt ihm eine Funktion die das richtige Element findet. Diese Funktion erhällt ein Element aus dem haystack und einen index und gibt diesen index zurück wenn das element das gesuchte ist.

Und da ist das Problem: Damit find funktioniert muss return index find verlassen und nicht nur die iterator-funktion.

Das ist der Grund wieso man Blöcke als etwas anderes als Funktionen/Methoden betrachten muss wenn man sie nutzen will um damit Kontrollstrukturen implementieren zu können und ihre volle Nützlichkeit für Abstraktionen verwenden zu können.