Montag, Dezember 17, 2012

Softwarebau und Storytelling

Wenn Software-Entwickler über Software reden, dann übertragen sie die Welt der Klassen, Objekte, der Methoden in die Welt der Geschichten. Wir Menschen können nicht anders. Wir erzählen Geschichten, wenn wir uns erklären, was diese Klasse oder jenes Framework tut. Wir betreiben Storytelling, um uns die formale Welt eines Rechners erklärbar und beschreibbar zu machen. Wir müssen es in den Worten unserer Welt tun.

Das Problem? Die Welt eines Rechners ist eine formale Welt, ähnlich der Mathematik. Die Welt des Storytellings, des Geschichtenerzählens könnte nicht gegensätzlicher sein: Geschichten müssen nicht logisch sein, sie müssen nicht einmal stimmig sein, solange sie unsere Phantasie nicht überstrapazieren. Praktisch jedes Buch und jeder Film ist ein Beleg dafür, wie sehr wir bereit sind, uns auf selbst abstruse Geschichten einzulassen.

Und so versagen wir oft kläglich, unsere Stories zurück zu übertragen auf die strenge Welt eines Rechners. Die Inkonsistenzen unserer Vorstellungen straft die Software mit Fehlermeldungen ab. Das ist der Urgrund dessen, warum das Testing so notwendig und dringende Pflicht ist: Es geht um den Abgleich unserer Stories mit dem, was eine Software wirklich macht. Das hat erst einmal nichts mit Qualitätssicherung zu tun. Warum wir uns trotzdem so schwer mit dem Testen tun, ist psychologisch einfach erklärt: Wir sind auf einen Erhalt unserer Selbstbilder und Vorstellungswelten aus. Wir sind Wesen, die nur bedingt auf Empirie setzen, denen aber die Bewahrung der lieb gewordenen Meinungen, Ansichten und Stories so viel wert ist, dass wir sie ungern erschüttern lassen.

Das Drama des Software Engineering spitzt sich noch um einen weiteren Aspekt zu: Zwar arbeitet ein Rechner nach formalen Prinzipien, aber das Prinzip basiert letztlich auf einem sehr einfachen Gesetz: Dem Gesetz des nächsten Befehls! Die nächste Anweisung im Rechner wird kommen. Und sie wird tun, was sie tun muss. Ob darüber hinaus das Tun des Rechners sinnhaft, schlüssig und logisch ist, ist nicht im geringsten gewährleistet.

Und so prallen zwei Welten aufeinander -- die Welt des Rechners als formale, die Welt des Menschen mit seinem Storytelling als informale --, die eines eint: beide Welten erlauben das absolute Chaos. Rechner müssen außer dem Gesetz des nächsten Befehls keine Physik und keine Logik beachten, keine Plausibilitäten und keine Konsistenzen -- genauso wenig wie jede Story.

Daraus gibt es einiges zu lernen:

Erstens: Software Entwickler müssen es lernen, ihre informelle Ausdrucksformen in eine formale Form zu bringen -- und sie sollten diese Übertragungen stets auf Fehlannahmen etc. hin testen. Dafür gilt es psychologische Barrieren zu durchbrechen.

Zweitens: Da weder die Software noch die Story konsistent, plausibel und logisch sein muss, tun sich Menschen einen Gefallen, die formale Welt im Rechner auch zur Konstruktion formal-logischer Welten zu nutzen, die mehr einfordern, als nur das Gesetz des nächsten Befehls. Das kann zum Beispiel in Grenzen geschehen durch domänenspezifische Sprachen (DSLs), Kernel-Ansätze und ein konsequentes Schichtenmodell, durch den Einsatz logischer Sprachen wie Prolog etc. Oder, und das ist ein großes, sehr großes Korrektiv, die Software interagiert mit der physikalischen Welt (wie embedded Systems) und muss die dort vorzufinden Gesetze und Eigenschaften strengstens berücksichtigen.

Erst wenn das gegeben ist, bauen wir Software von der Qualität mit der auch Ingenieure ihre Werke erschaffen: Ingenieure werden von den Gesetzen der Natur optimiert. Das Gesetz des nächsten Befehls allein optimiert nichts. Und unsere Stories auch nicht.

Montag, Dezember 10, 2012

Brauchbare Klassendiagramme

Mich überrascht immer wieder, wie sehr Klassendiagramme in einer undefinierten Grauzone schweben zwischen Modellbeschreibung einer Problemdomäne und Dokumentation der Implementierung. Das ist nicht nur ein "Problem" von Studierenden, sondern auch von Profis.

Ein Klassendiagramm kann zwei Zwecken dienen, die sich an zwei Fragen festmachen lassen:

Dient das Klassendiagramm zur Erfassung einer gedanklichen, logischen Zerlegung einer fachlichen Problemdomäne (Modellierung)? Oder dient es zur Dokumentation der Klassenbezüge im Code einer Implementierungssprache (Realisierung).

Meist "hängt" ein Klassendiagramm genau zwischen diesen Welten und ist am Ende weder ein ausdrucksstarkes Modell (da es Ausdrucksmittel der UML ungenutzt lässt), noch eine korrekte Beschreibung der Realisierung, die in aller Regel das Klassendiagramm nicht einmal sauber umsetzt.

Um es konkreter zu machen:

Oftmals wird in Klassendiagrammen keine Mehrfachvererbung verwendet, obwohl sie bisweilen sehr elegante Zerlegungen und Wiederverwendungen von Modellanteilen erlaubt. Warum? Weil die Implementierungssprache (z.B. Java, C#) Mehrfachvererbung nicht kennt. -- Das sollte zwar kein Grund sein, sich in den Ausdrucksmöglichkeiten zurück zu halten, ist es aber faktisch immer wieder! Interessanterweise eben genau bei dem Thema "Mehrfachvererbung".

Andererseits sehe ich sehr oft, wie die Komposition und bisweilen auch die Aggregation in Klassendiagrammen verwendet wird. Dabei bietet keine mir geläufige OO-Sprache ein Sprachkonstrukt für die Komposition/Aggregation an -- vom Hörensagen ist eventuell Eiffel die große Ausnahme. Merkwürdigerweise scheint das Fehlen von Komposition und Aggregation in der Zielsprache den wenigsten Modellierer(inne)n Sorgen zu machen, ganz im Gegensatz zur Mehrfachvererbung. Dabei habe ich -- und das ist das Kuriose daran -- (fast) noch nie Implementierungscode gesehen, der die Komposition oder Aggregation korrekt umsetzt. Die wenigsten Programmierer(innen) wissen, wie Komposition in Code geht, und auch die gängigen Modellierungswerkzeuge versagen mit ihren Code-Generatoren an dieser Stelle oftmals kläglich.

Damit sind Klassendiagramme merkwürdige Artefakte: Sie sind oft halbherzige Modellbeschreibungen mit einem sehr implementierungszentrischen Blick. Und gleichzeitig versagen sie als Dokumentation des Programmcodes, der die vom Klassendiagramm geforderten Strukturbeziehungen nicht wirklich einlöst.

Darum halte ich es für sinnvoll, sauber und klar in zwei Klassendiagrammen zu denken, die den Unterschied zwischen fachlichem Modell und Implementierungsdokumentation offen legen und bewusst machen, statt ein Klassendiagramm mit unklarem Bezug und fraglichem Nutzen zu erstellen. Da viele IDEs wie z.B. Eclipe immerhin einfache Klassendiagramme aus der Implementierung abzuleiten vermögen, sollte der Fokus auf zwei Punkten liegen:

  1. Gute Klassendiagramme zu entwerfen, die die Problemdomäne versuchen ausdrucksstark zu modellieren -- ohne auf die Implementierungssprache zu schielen.
  2. Zu dokumentieren, wie das Klassendiagramm in die Zielsprache übertragen wird, so dass deutlich ist, wo Programmierdisziplin mit Blick auf das Modell eingefordert werden muss, und wo der Programmcode das Modell sauber umsetzt.


Donnerstag, Dezember 06, 2012

Denkspuren auf Google+ und Facebook

Seit wenigen Wochen gibt es mich auch unter Google+ und Facebook. Ich will verstehen lernen, wie sich die sozialen Medien anfühlen, ob sie für mich eine Bereicherung sind oder nicht, ob ich sie als wertschöpfend erlebe oder nicht. Tatsächlich hat mich der Vortrag von Lars Lehne motiviert, mich auf diese Welt einzulassen. Auch geht es mir darum mitzubekommen, was meine Studierenden mit diesen Welten verbinden.

Eines habe ich bislang festgestellt: Facebook scheint nichts für mich zu sein, ganz anders als für meine Studierenden. Vielleicht liegt es daran, dass ich nicht wirklich einen Bedarf habe, die Kontaktpflege mit "Freunden" über Facebook zu betreiben. Google+ hingegen spricht mich an. Das Format ist niederschwellig genug, so dass ich angefangen habe, öfter etwas zu posten. Und dass ich nicht gleich mit jedem Freund sein muss, sondern nur Kontakt-Kreise aufbaue, das scheint auch mehr zu mir zu passen.

Darum: Wenn Sie Lust haben, "besuchen" Sie mich auf Google+. Auf meiner Facebook-Seite passiert dagegen kaum etwas.


Sonntag, November 18, 2012

"if" in statisch und in dynamisch typisierten Sprachen


Ein "if" realisiert eine binäre Entscheidung. Bei statisch typisierten Sprachen wird abhängig von einem Booleschen Wert im "true"-Fall entweder das eine oder im "false"-Fall das andere gemacht. Auch wenn eine dynamisch typisierte Sprache die Booleschen Werte "true" und "false" kennt, ist das Verhalten für ein "if" meist anders definiert: Für jeden beliebigen Wert außer "false" tue dieses, für den Wert "false" jenes. Manchmal heißt es sogar: Für jeden Wert außer "false" und "nil" tue dieses, sonst jenes. Wissen Sie, warum statisch und dynamisch typisierte Sprachen sich so unterschiedlich verhalten?

Statisch typisierte Sprachen nutzen die Typüberprüfung vor der Ausführung des Codes, um festzustellen, ob die "if"-Entscheidung tatsächlich binär ist. Das ist durch den Booleschen Datentypen garantiert, wenn die Typüberprüfung erfolgreich ist.

Dynamisch typisierte Sprachen überprüfen die Typen zur Laufzeit. Wenn bei einem "if" kein Boolescher Datenwert genutzt wird, könnte eine Ausnahme (Exception) geworfen werden -- dann würde ein "if" jedoch eine ternäre und keine binäre Entscheidung mehr treffen: Mache dieses im "true"-Fall, jenes im "false"-Fall und was gänzlich anderes, wenn ein sonstiger Wert vorliegt. Um das binäre Entscheidungsverhalten aufrecht zu erhalten, muss man ein, zwei Werte wie ein logisches "false" und alle anderen Werte wie logisch "true" interpretieren.

Dass "nil" oft ebenfalls als "false" zählt, hat einen Grund: Vielfach hat "nil" bei dynamisch typisierten Sprachen die Sonderfunktion, "Nichts" als Wert zurückzugeben, wenn es keine andere Lösung gibt, statt einen Fehler per Exception zu werfen. Dynamisch typisierte Sprachen halten so die Ausführung eines Programms so lange wie möglich aufrecht, ohne durch Exceptions aus dem Ausführungsfluss geworfen zu werden.

Donnerstag, November 08, 2012

Google-Director Lars Lehne in Heilbronn


Eines ist Lars Lehne, Google Director bei Google Deutschland, wirklich gelungen. Sein Vortrag hat mich mitgerissen und begeistert. Dabei war es, wenn man ehrlich ist, eine einzige Werbeveranstaltung für Google. Aber das muss man Lehne wirklich lassen: Er ist sehr gut darin, sein Unternehmen "zu verkaufen". Nett, charmant und humorvoll ist er. Und er weiß, dass man ihm zuhört -- zuhören muss.

Warum der Vortrag "Die digitale Zukunft ist bereits Realität" heißt, bleibt bis zum Schluss ein ungelöstes Rätsel. Egal. Die Einladung von Lars Lehne ist Grund genug für deutlich über 200 Gäste, am Mittwoch, 6. November 2012, den Saal der IHK Heilbronn-Franken zu füllen. Lehne, übrigens FH-Absolvent -- er hat BWL in Düsseldorf studiert --, ist seit 2009 bei Google. Er startet seinen Rechner, alle sehen über die Projektionswand seinen Desktop ... ich bin verblüfft: Ist das wirklich wahr?

Der Google Director hat doch tatsächlich ein iBook mit Mac-OS laufen. Später wird er auf Nachfrage des Moderators das Publikum aufklären, dass viele Googler einen Apple-Rechner haben, aus Sicherheitsgründen. Apple-Rechner gelten bei Google als sicherer als Windows-Rechner. Sein Smartphone ist aber kein iPhone -- das wäre ein echter Skandal gewesen ;-) Sicher ist es ein Nexus, auf die Ferne ist es nicht klar zu erkennen.

Lehne hält dankenswerter Weise keinen Powerpoint-Vortrag. Er macht einen Streifzug durch die fast 15jährige Geschichte von Google, wobei er sich weitgehend auf die Google-Suche beschränkt. Und so füllt Lehne 60 Minuten lang den Abend mit kurzen Youtube-Videos und live durchgeführten Google-Suchen. Er erzählt viele nette Anekdoten, die das Publikum begierig aufsaugt. Das alles bringt Lehne so unaufgeregt rüber, dass es die Bedeutung von Google nur unterstreicht.

Ich möchte den Vortrag von Lehne nicht zusammenfassen, sondern mit ein paar Schlaglichtern ein wenig nachzeichnen, wovon er gesprochen hat.

  • Wussten Sie, dass Google rund 35.000 Angestellte (ohne Motorola) hat? Mehr als 50% sind Ingenieure. 3.000 bis 8.000 Menschen werden pro Jahr bei Google eingestellt, bei 2 Mio. Initiativbewerbungen. (Ich hoffe, ich habe mich nicht verhört, die Zahl ist so unglaublich.) Am aussichtsreichsten ist es, wenn Sie ein Googler (ein Google-Mitarbeiter) empfiehlt.
  • Larry Page und Sergey Brin (die Gründer von Google) sind hochintelligente Schnelldenker, so Lehne -- er habe des öfteren mit ihnen Kontakt. Das Credo von Page ist: "Jedes Problem kann mit Mathematik gelöst werden." Und er leistet sich einen "Streichelzoo" (so Lehne) von 50 Ingenieuren, die tun dürfen, was immer sie wollen.
  • "Jedes Problem kann mit Mathematik gelöst werden", so zitiert Lehne Larry Page. Was ist das für ein Geek! Und nun dürfte Ihnen auch klar sein, warum man sich besser um Mathematik kümmert -- auch wenn man "nur" Informatik studiert. Ohne Mathematik keine Algorithmen für die Indizierung und Suche von Webseiten, und ohne Mathematik kein autonom fahrendes Auto. 
  • Noch so eine Frage für Neugierige: Woher kommen die bunten Farben im Google-Logo? In den Anfangstagen haben sich die Googler die Racks für Ihre Server aus Legosteinen gebaut! Die bunten Farben sind eine Erinnerung an die Lego-Zeit!
  • Google verarbeitet jeden Tag 4 Milliarden Suchanfragen, Tendenz steigend. Deutschland ist daran mit 350 Millionen Anfragen beteiligt. Große Unternehmen haben Google schon dreistellige Millionenbeträge angeboten, um auf der "weißen" Seite mit der Suchmaske Werbung zu schalten. Google lehnt das ab.
  • Google verdient sein Geld mit den Clicks auf eingeblendete Anzeigen zur Suche. Verbleiben Sie mehr als 3 Sekunden auf der angebotenen Werbeseite, dann klingelt der Geldbeutel bei Google. Die Preise für einen Click reichen von 10 Cent bis 50-70€ (z.B. bei Versicherungen oder Winterreifen, wo eine sehr hohe Abschlusswahrscheinlichkeit für ein Geschäft besteht). In Deutschland verdient Google im Schnitt 12,7 Cent an Clicks auf Links von Werbeanzeigen. Lehne stellt die einfache Rechenaufgabe: Wenn es 1 Mio. solcher Clicks gibt bei 365 Tagen im Jahr, dann kommt da einiges zusammen. (Es sind übrigens etwas mehr als 46 Mio. Euro. Wenn dieser Wert für Deutschland gilt, dann sollte der weltweite Umsatz bei 500 Mio. Euro liegen. Das liegt weit unter den 9,7 Mrd. US-Dollar Reingewinn, die Google 2011 erzielt hat.)
  • "Suchanfragen sind komplex, Maschinen sind saudoof", so Lehne. Wenn er von komplexen Suchanfragen spricht, meint er aber auch die saudoofen Anfragen, die Google verstehen muss und will. Google erkennt 860 falsche Schreibweisen des Namens "Britney Spears"! Das Schlagwort, das Lehne mehrfach erwähnt, lautet "Datenaggregation". Google muss die Suche und die tatsächlich angeklickten Seiten zusammenführen, um herauszufinden, was der Nutzer will. Wenn ein Nutzer das Wetter abfragt, dann will er in 99,99% der Fälle das Wetter an seinem Standort erfahren. Auch hier aggregiert Google Daten, um Ihnen das vermutlich gewünschte Ergebnis zu liefern.
  • "Youtube ist die zweitgrößte Suchmaschine der Welt." Von diesem Blickwinkel aus, sagt Lehne, war die Aquisition von Youtube für Google nur folgerichtig. Gleichzeitig sei Youtube auch ein soziales Netz
  • Lehne: "Brauchen wir ein zweites Facebook? Nein! Das wollen wir auch gar nicht sein." Für Google hat Google+ (kurz G+) eine ganz andere Bedeutung: Das soziale Miteinander, die "Freunde" und der (mit)geteilte Inhalt gehen in die Suche mit ein und sollen helfen, die Suchergebnisse zu verbessern. Google geht davon aus, dass unser soziales Treiben in G+ eine Relevanz hat bei dem, was wir suchen. So werden Inhalte aus unserem sozialen Netzwerk mit durchsucht und angezeigt. Die Logik scheint mir nachvollziehbar: Facebook hat eine Wand im Internet aufgezogen, Facebookler(innen) bleiben unter sich. Alles außerhalb dieser Wand, will Google auffindbar machen und dabei die sozialen Aspekte berücksichtigen. Übrigens: Laut Lehne wird Google niemals Werbung in G+ schalten!
  • Warum heißt Google eigentlich "Google"? Der Name kommt von "googol", was eine riesengroße Zahl bezeichnet: 1E100 (einmal Zehn hoch Hundert, sprich, eine Eins mit 100 Nullen). Eine Anspielung auf die unglaublichen Datenmengen, die Google verarbeitet. Das muss den Gründern Page und Brin schon vor rund 15 Jahren bewusst gewesen sein.
  • Für Google hat die Sprachübersetzung eine immense Bedeutung: Was, wenn die Antwort meiner Frage in einer Fremdsprache vorliegt? Google vermag Webseiten sofort zu übersetzen, fast in Echtzeit. Lehne betont es immer wieder an dem Abend: Alles werde getan, um den Endbenutzern bessere Suchergebnisse zu liefern. Eine Strategie dahin ist, den Suchraum auf fremdsprachliche Webseiten zu erweitern.
  • "Wir wollen Fragen beantworten bevor sie gestellt werden." Das hat, laut Lehne, Larry Page gesagt. Was ist damit gemeint? Herr Lehne bringt ein Beispiel: In seinem Google-Kalender ist der Rückflug eingetragen samt Flughafen und Flugnummer. Nun kann Google die Daten aggregieren und eine Frage beantworten, die noch nicht gestellt ist: Google weiß dank GPS, wo man ist, aus dem Kalender wo man wann sein möchte und wann der Flug geht (da im Netz nachgeschaut). Daraus ergeben sich Fragen wie: Wie ist die Verkehrslage, um zum Flughafen zu kommen? Wie ist die Route? Geht mein Flieger pünktlich oder hat er eine Verspätung? All das nimmt Google vorweg und erinnert den Nutzer rechtzeitig: "Pass auf, Du solltest Dich innerhalb der nächsten 15 Minuten ins Auto setzen, die Verkehrslage ist kritisch. Anbei die Route samt Umleitung, der Stau kann umfahren werden. Dein Flieger geht 10 Minuten später als geplant." Das ist die Antwort auf eine Frage, bevor der Anwender sie stellt.

Interessant, nicht wahr?! Die anschließende Podiumsdiskussion war ebenfalls sehr erhellend. Ein Beitrag von Lehne aus der Diskussion: Social Media funktioniert nicht in hierarchisch geführten Unternehmen. "Soziale Führung" verlangt und fordert Transparenz ein. -- Die junge Generation wird das einfordern, so ergänzen auch die anderen Teilnehmer der Runde, da sie nicht verstehen und einsehen werden, warum Social Media innerhalb der Mauern eines Unternehmens tabu ist. Es wird die Unternehmen und die Führungsstile verändern.

Montag, August 27, 2012

Die etwas andere Konferenz: FrOSCon 2012

Die diesjährige "Free and Open Source Software Conference" (FrOSCon) in St. Augustin (25./26. August) war eine ganz neue Erfahrung für mich: Bislang habe ich nur akademische Konferenzen rund um das Thema Software bzw. Informatik besucht. Die FrOSCon ist keine akademische Konferenz und ist, ganz im Sinne von freier und offener Software, für jeden Interessierten zugänglich. Ein symbolisch zu nennender Eintritt von 5€ (für beide Tage!) grenzt sich wohltuend ab von den horrenden Preisen bei Akademikern, 300-500€ Teilnahmegebühr sind da keine Seltenheit. Dabei steht die FrOSCon in Organisation und Programm professionellen Konferenzen in nichts nach. Ein Heer von Freiwilligen organisiert die FrOSCon. Es geht also auch ganz anders!

Und noch etwas ist ganz anders. Die Vorträge auf der FrOSCon sind nützlich und pragmatisch. Das kann man leider von vielen akademischen Konferenzen nicht uneingeschränkt behaupten. Man erfährt spannende Dinge, lernt etwas und wird tatsächlich "angefixt", das eine oder andere Thema einmal anzugehen. Tim Becker und Matthias Krauß hielten am Samstag einen hinreißenden Vortrag "How to build your own computer from scratch" zu Open Hardware. Am liebsten hätte ich gleich mit dem Lötkolben losgelegt. Die beiden haben wunderbar erklärt, warum ein paar Widerstände und Kondensatoren die Anschlussleitungen eines Microprozessor zieren müssen. Aber auch Uwe Ziegenhagen konnte mit seinem Vortrag zum Arduino begeistern. Ob ich nicht doch den Lötkolben erst einmal beiseite lege und mein Programmierglück mit dem Arduino versuche?

Am Sonntag hörte ich von Judith Andresen und Heiko Harthun einen sehr gelungen Vortrag zur effizienten Gestaltung von Arbeitstreffen: "Nur keine Langeweile!". Ich hätte den beiden noch stundenlang zuhören können. Selena Deckelmann forderte in ihrer halbstündigen Keynote alle eindringlich auf, dass sich jeder dazu verpflichten möge, anderen irgendetwas zum Umgang mit einem Computer beizubringen. Computer sind zu wichtig in unserem Leben geworden.

Mein ursprünglicher Anlass, die FrOSCon zu besuchen, war allerdings eine einzige Person: Andy Wingo. Etwa eineinhalb Wochen vor der Konferenz las ich auf seinem Blog, den ich seit einiger Zeit verfolge, dass er auf der FrOSCon gleich drei Vorträge halten wolle: zu Guile, einer Scheme-Implementierung, die Wingo als Hauptentwickler pflegt; zu JavaScript, an dessen Implementierung er hauptberuflich mitarbeitet; und zu Delimited Continuations. Alles drei Themen, die mich sehr interessieren. Und ich wurde nicht enttäuscht. Wingo hat einen lockeren und sehr netten Vortragsstil, weiß eine Menge zu erzählen, und hat Breite und Tiefe anzubieten in seinem Wissen, etwas, was man selbst auf akademischen Konferenzen selten bekommt. Kurzum, ich bin glücklich mit vielen Stimuli abgefüllt nach Hause gefahren. Die Delimited Continuations haben es mir besonders angetan.

Was mich am meisten überrascht hat, ist das Altersspektrum. Anfangs glaubte ich noch, ich wäre auf einer Konferenz etwas schräger Geeks und Nerds gelandet in der Altersgruppe der 20-30-Jährigen. Dieser Eindruck stammte aus dem ersten Vortrag, den ich im Lisp-Track der FrOSCon hörte. Meinen Eindruck musste ich spätestens beim Arduino-Vortrag korrigieren. Plötzlich saß da auffällig gut vertreten meine Altersgruppe der 40-50-Jährigen, auch waren noch deutlich ältere Menschen dabei. Man interessierte sich durch alle Altersgruppen hinweg für diese kleinen Mikroprozessoren. Faszinierend! Der Vortrag zur Gestaltung von Arbeitstreffen war wiederum von den 30-40-Jährigen dominiert. Offenbar vereint die FrOSCon viele Menschen unterschiedlichen Alters und unterschiedlicher Hintergründe beim gemeinsamen Thema: Allen geht es um freie und offene Software -- und den Durst um frei vermitteltes Wissen.

Die FrOSCon hat noch einen besonderen Aspekt, den ich noch nie auf einer akademischen Konferenz gesehen habe: ein Kinderprogramm! Kinder der 5.-10. Schulklassen konnten Minecraft spielen, Vorträge zu Linux und zur Programmierung in Python hören, Geo-Caching über den Campus machen und noch einiges mehr. Vorbildlich!

Ich wünschte, es gäbe mehr solcher Konferenzen!

Donnerstag, Juni 21, 2012

eLBa 2012: Vom Lernen und Lehren in der Zukunft

Rostock, eLBa 2012, die fünfte Konferenz der eLearning-Baltics. Keynote-Speaker Sven Gabor Janszky. Er bezeichnet sich als Trendforscher -- und redet über die Zukunft in 10 Jahren. Er riskiert damit einen ebenso weiten Blick in die Zeit wie es Lars Thomson im Oktober 2011 bei seiner Rede an der Hochschule Heilbronn tat.

Mich fürchtet's vor den "Trends", die Janszky mit kleinen Filmeinspielern vorzeichnet: Im Bad begegnet mir der "Smart Mirror", im Wohnzimmer die "Screentapete", im Wohnzimmer der "Intelligente Couchtisch". Alles Geräte, die großformatige Projektionsflächen für Informationen sind und weitgehend berührungslos mit uns kommunizieren. Die unsichtbaren "Helferlein" geben sich intelligenter denn je. Sie wissen, was wir wollen, wünschen, brauchen -- sie vernetzen uns, sie lernen aus unseren (Persönlichkeits-)Profilen, wiederholen "dumme" Vorschläge und Angebote kein zweites Mal und brauchen von uns nicht mehr direkt konfiguriert zu werden. Dahinter winkt immer der Kommerz, manchmal zugunsten unserer Bedürfnisse, wohl öfter zur Bedürfnisweckung. Und so bleibt mir das sehr ungute Gefühl, wie wir in diesen Visionen den Maschinen die gesamte Verwaltung und Gestaltung unseres Lebens überlassen. Dagegen mutet die Datenschutzkritik z.B. an Facebook lächerlich an. Die Maschinen der Zukunft erschaffen individualisierte Realitätsprojektionen nach irgendwelchen verborgenen Kriterien wirtschaftlicher Nutzbringung. Brrr.

Nach Janszky verlagert sich die Wirtschaft von einer Aufmerksamkeitsökonomie zur einer Anerkennungsökonomie. Man braucht Aufmerksamkeit auf Massenmärkten, und man arbeitet mit Anerkennung, um 1:1-Beziehungen zu erhalten. Die Assistenten der Zukunft haben nur eine Chance, wenn sie sich um diese 1:1-Beziehung kümmern, ihren Partner, den Menschen, in seinen Anliegen und Bedürfnissen verstehen und nicht belehren oder bevormunden. Nach Janszky heißt Anerkennung geben, immer ansprechbar zu sein, mit dem anderen Leid und Freud zu teilen und sie oder ihn hin und wieder zu überraschen.

Immer wieder fordert Janszky die Übertragung auf eLearning und das Bildungswesen ein. Der Frontalunterricht basiert auf Aufmerksamkeit (wohl wahr!), was Lernende aber suchen, ist Anerkennung (oh ja!). Und hierbei kann Technologie helfen -- und da überlässt es Janszky jedem selbst herauszufinden, wie das aussehen könnte. Das macht mich nachdenklich. Denn er hat recht: Das Einfordern von Aufmerksamkeit ist vielleicht eine Voraussetzung für das Lernen, aber es reicht nicht. Die Anerkennung für Erlerntes hingegen ist ein starkes Antriebsmoment. Vielleicht kann man es so aufschlüsseln: Aufmerksamkeit ist eine Voraussetzung für das Lernen, Anerkennung das "Ziel" des Lernens (wenn man es mal so ausdrücken möchte). Es gilt freilich außerdem, zwischen diesen Pfeilern vom Beginn des Lernprozesses (Aufmerksamkeit) bis zum Ende (Anerkennung) einen Bogen zu spannen.

Janszky sagt, der Arbeitsmarkt der Zukunft interessiere sich weniger für formale Bildungsabschlüsse als denn für ein Portfolio an Qualifikationen. Zumal die meisten Menschen in der Zukunft so etwas wie "Jobnomaden" sein werden und ihr Berufsleben in wechselnden Projekten verbringen. Die Konsequenz, die ich daraus ableite: Jede Studentin, jeder Student sollte individuelle Studienpfade durchlaufen und jederzeit Prüfungen ablegen können, und am Ende einen "Bachelor" oder einen "Master" haben, der nicht programmhaft standardisiert, sondern ganz eigenwillig und individuell ist. Warum eigentlich nicht? Es gibt viel mehr Gründe, eLearning-Systeme und Lern-Assistenzsysteme zu bauen, als bei dem alten Modell standardisierter Massenausbildung zu bleiben. In unserem Bildungssystem, in der Lehre an den Hochschulen muss sich etwas ändern. In Zukunft wird es keinen Massenmarkt für z.B. Informatiker geben -- es gibt ihn eigentlich heute schon nicht mehr. In Zukunft bieten junge und ältere Menschen Qualifikations- und Kompetenzprofile an, die sie beständig erweitern, anpassen und ausbauen werden (müssen). Das mag zwar anstrengend sein -- aber vielleicht ist es auch der Schlüssel zu einem erfüllteren und sinnreicheren Arbeitsleben.

[Update: Wahrscheinlich hielt ich die Trends für so unglaublich, dass ich das Jahr 2022 für 20 Jahre entfernt hielt. Ein netter Kommentar hat mich darauf aufmerksam gemacht. Nun ist der Fehler korrigiert.]

Donnerstag, Mai 24, 2012

The root of polymorphism: The Anti-If Campaign

Ever heard about the Anti-If Campaign? The less if-statements there are in your code, the better -- argues Francesco Cirillo, the initiator of the Anti-If Campaign. There is a lot of truth behind his campaign. Too much if-statements in your code are evil, that's for sure. They'll make your code static, hard to maintain and no fun to read. It goes without saying that related concepts like switch-statements, conditionals and the like are subsumed under "if". They are just syntactic sugar for a certain arrangement of if-statements.

I asked myself: What if we abandon if-statements completely? What about being absolutely strict about the use of if and related concepts: No ifs in your code anywhere anyplace. You are not allowed to use if at all. It is like not having such a construct in your programming language.

Is it possible to write code without ifs? Yes, it is, as I'll show in this post. You'll end up with polymorphic functions instead -- and this is really cool stuff. Polymorphic functions are a result of having no ifs at your fingertips.

So let us proclaim the No-If Campaign for the sake of being extreme -- and see where it leads us to. In the following, I'll use Clojure for demonstration purposes. Clojure is a functional programming language and belongs to the family of Lisp languages. Don't worry if you don't know Clojure. The programs are simple to grasp and should let you follow the line of argumentation.

The Magic with Maps

A map, sometimes also called dictionary, associative array or hash map, is a data structure that stores pairs of key values and target values. A key value is uniquely associated with a target value. In Clojure, maps are written with curly braces. The example interaction at the console (called REPL in Clojure speak) associates so-called keywords with numbers; the ordering of the pairs is irrelevant.

user=> (def day {:mon 1 :tue 2 :wed 3 :thu 4 :fri 5})
#'user/day

It is a specialty of Lisp-like languages, that programs are written with parentheses. It's something one quickly gets used to. The above code defines day to be bound to a map with the given elements.

To query a map, the map and a key value must be given.

user=> (day :thu)
4
user=> (day :sat)
nil

If there is no target value associated with a key value, nil is returned. We can provide a default value as an extra argument to be returned instead.

user=> (day :thu 0)
4
user=> (day :sat 0)
0

The notion of equality is built into maps. Otherwise we couldn't query a map. That means: We can re-implement "equality" with the help of a map.

user=> (defn equal? [x y] ({y true} x false))
#'user/equal?

The code defines a function called equal? that expects two arguments, namely x and y. The body of the functions says: if x is not a key value in map {y true} return false; otherwise, if x equals y return true.

Let this use of a map sink in for a moment. Once you get the overall idea, it is easy to see how we can re-implement if.

How does if work in Clojure? In Clojure, if is a so-called special form. It expects at least two arguments, a third argument is optional. The evaluation of an if is as follows: If the evaluation of the first arguments results in false or nil, the third argument is evaluated and its result returned; if the third argument is missing, nil is returned. If the evaluation of the first argument is neither false nor nil, the second argument is evaluated and its result returned. It sounds more complicated than it actually is. Let us take an example

user=> (if (== 2 3) (+ 2 3) (- 2 3))
-1

Since the evaluation of (== 2 3) leads to false, the third argument to if is evaluated, which results in -1. Easy, isn't it?!

We could emulate this behavior with a map in the following way:

user=> (eval ({false '(- 2 3) nil '(- 2 3)} (== 2 3) '(+ 2 3)))
-1

In the map, there are key values for false and nil, which are both associated to the same expression. They are quoted (that's what the apostrophe is for) to suppress premature evaluation. The default expression '(+ 2 3) is quoted for the very same reason. Depending on the evaluation of the test-expression, here (== 2 3), either the default expression or the target value is taken. The resulting expression is evaluated by eval.

We can capture this use of a map as a coding pattern with the help of a macro. Let us call the macro IF -- for obvious reasons.

(defmacro IF
  ([test then]
    `(IF ~test ~then nil))
  ([test then else]
    `(eval ({false '~else, nil '~else} ~test '~then))))

Don't worry when you don't get all the details of macros and the special characters used inside. The point is that
  1. this macros behaves exactly like an if without using an if for its implementation. It is a proof-of-concept: We can live without if -- because we can re-built it from maps.
  2. this macro reads like a perfect specification of an if, which is a very interesting aspect of our approach.
user=> (IF (== 2 3) (+ 2 3) (- 2 3))
-1

(Note to experts: Because of eval, the macro does not respect lexical scope. Nothing to worry about in a proof-of-concept demonstration.)

To conclude: Yes, we don't need if as long as we have maps natively provided in our programming language. We can re-implement if.

This sounds ridiculous: We proclaim the No-If Campaign just in order to re-introduce if-statements? You are right, we need if-statements one way or the other. We can't seriously get rid of them. In programming, the concept of choice is essential and needs to be used. if-statements are just the most primitive binary choice construct you can think of -- and they have their meaning and use.

But there is another lesson to be learnt from re-implementing if with a map. With maps, we have a multiple choice construct, which can be instrumented for implementing polymorphic functions.

Polymorphism

Instead of choosing either something based on false/nil or choosing something else otherwise (binary choice), we generalize the idea of choice with maps. Based on any kind and any number of key values a map returns an associated target value (multiple choice). To get rid of the use of eval (see our IF macro), we demand that any value associated with a key value has to be a function.

Assumed we would like to calculate the area of a given geometric shape. The formulas are dependent on the type of shape. The area of a circle is computed in another way than the area of a rectangle. This knowledge can be encoded with a map.


(def shape2func
  {:circle    (fn [r]   (* r r Math/PI))
   :rectangle (fn [a b] (* a b))
   :triangle  (fn [a h] (* a h 0.5))})

Now, we define a function area which expects at least one argument. This very argument acts as a sort of identifier for choosing the right function from map shape2func. The function is applied on any further arguments supplied with function area.



(defn area [shape & args]
  (apply (shape2func shape) args))


Function area has become a polymorphic function! Based on the value of some argument -- here the very first argument identifying the kind or type of shape one refers to -- a proper implementation is chosen and called.

user=> (area :circle 2)
12.566370614359172
user=> (area :rectangle 2 3)
6

This kind of polymorphism is so much intriguing that it is worth being captured with a macro. The macro eases the definition of polymorphic functions. What we add to the macro is the idea of a dispatch function. The dispatch function determines the identifier used as a key value for looking up the function in the map. It gives us some additional flexibility.

(defmacro defnpoly
  ([name dispatch-fn map]
    `(defnpoly ~name ~dispatch-fn ~map nil))
  ([name dispatch-fn map default-fn]
    `(defn ~name [& args#]
      (apply
        (~map (apply ~dispatch-fn args#) ~default-fn)
        args#))))

Don't worry if you do not get the details of the macro. Using the macro is straight forward. It captures a pattern of a multiple choice construct -- and that is what we are after.

Using the macro, the definition of our polymorphic function area looks like this; note how the area for a square is implemented:

(defnpoly area (fn [shape & args] shape)
  {:circle (fn [self r] (* r r Math/PI))
   :rectangle (fn [self a b] (* a b))
   :square (fn [self a] (area :rectangle a a))
   :triangle (fn [self a b] (* a b 0.5))})

The dispatch function captures the previously mentioned strategy how a dispatch value is determined from a given set of arguments. It is the very first argument the dispatch is based on. Since the different functions implementing area are called with the very same arguments as the dispatch function is called with, we need to capture the first argument called self though it is ignored in the body of the functions. The use of self might trigger a revelation: object-orientation is nearby.

user=> (area :circle 2)
12.566370614359172
user=> (area :square 2)
4

As you can see, no if-statements are needed nor used in polymorphic functions. And that's exactly what the Anti-If Campaign is after: Use polymorphic functions, use the power of such a multiple choice construct whenever meaningful and possible. If-statements are no adequate means to emulate multiple choice. Beyond the need of binary choice, if-statements make code for multiple choice ugly, hard to maintain and less adaptable. As you can see, it is a breeze to add an implementation for :square to area -- no if is required.

One can do amazing things with polymorphic functions and a flexible dispatch mechanism. It embraces first argument type dispatch as is done in object-orientation. But there is more to it. Let us have a simple example for dispatching on the type of both arguments given to polymorphic function times

(defnpoly times (fn [x y] [(type x) (type y)])
  {[Long Long]   (fn [x y] (* x y))
   [Long String] (fn [n s] (reduce str (repeat n s)))
   [String Long] (fn [s n] (times n s))})

The program is clear and succinct -- because there are no ifs. Polymorphic functions have their own beauty!

user=> (times 4 3)
12
user=> (times 4 "hi")
"hihihihi"
user=> (times "hi" 0)
""

Polymorphic functions are so much useful that Clojure has them already included. In Clojure, polymorphic functions are called multimethods.

Multimethods in Clojure

Part of the fascination of Lisp-like languages such as Clojure is that they are extremely extensible. If you are missing polymorphic functions, you write yourself a short macro, and you have the feature and can use it. We demonstrated how easy that is.

Clojure follows the tradition of Lisp and favors a slightly different model of defining a polymorphic function in your code. The polymorphic function is declared with defmulti and its implementing functions are defined with defmethod. This way, Clojure abstracts away the use of a map for polymorphism. It adds a layer of abstraction and removes a little bit of syntactic overhead we had in our solution. Other than that, defmulti and defmethod behave exactly like defnpoly. See yourself, how close the definition of area is to our defnpoly approach.

(defmulti area (fn [shape & args] shape))
(defmethod area :circle [self r] (* r r Math/PI))
(defmethod area :rectangle [self a b] (* a b))
(defmethod area :square [self a] (area :rectangle a a))
(defmethod area :triangle [self a b] (* a b 0.5))

Multifunction area is used exactly like our polymorphic function definition of area.

user=> (area :circle 2)
12.566370614359172
user=> (area :square 2)
4

There is a lot more to say about multifunctions in Clojure, but I do not want to drift away from our starting point: the Anti-If Campaign.

Summary

In the data structure of a map the concepts of equality and choice are inherently included. The interesting part is that a map provides a mechanism for multiple choice. That means that binary choice (being another word for if, so to speak) is just a special case of multiple choice; that is why if can easily be re-implemented using maps. To have a binary choice construct like if at hand is useful and meaningful.

The fun part is to utilize and explore the power of multiple choice with maps. It takes a simple step and the introduction of a dispatch function and we have polymorphic functions. Polymorphic functions are a very powerful control construct. They are easy to use, make code highly readable and flexible to adapt. Same does object-orientation. But the flexibility given by a dispatch function goes beyond (single type-dispatch) object-orientation.

And that is the message of the Anti-If Campaign: Learn to think in and use multiple choice constructs -- be they provided in form of object-orientation or polymorphic functions (like in Clojure). If you use binary choice (i.e. if) for multiple choice, your code will be messy and ugly. So, don't use if to emulate multiple choice. Be the power of maps with you ;-)

Donnerstag, April 19, 2012

Werden Sie erfolgreich Informatik studieren? Testen Sie es!


Ich weiß etwas über Sie, das Sie nicht über sich wissen! Zum Beispiel, ob Sie zu einem Informatik-Studium geeignet sind. Ich habe einen Test entwickelt, der ist kurz und schmerzlos und ein Ergebnis jahrelanger Forschung. Nach der Auswertung der Daten von über 10.272 Studierenden kann ich Ihnen mit einer Sicherheit von 97,3% sagen, ob Sie ein Informatik-Studium abbrechen werden oder nicht – und zwar bevor Sie mit dem Studium anfangen. Der Test kann Ihnen die Fehlinvestition von ca. 17.400€ ersparen, sollten Sie zu den Abbrechern gehören. Im Mittel erfolgt der Abbruch nach 14,3 Monaten.

Hier meine Fragen, anhand derer ich Ihnen Ihre Eignung für die Informatik vorhersagen kann: (1) Ist Ihr rechter Zeigefinger so lang wie Ihr rechter Ringfinger? Falls nicht: Welcher ist größer? Sollten Sie Linkshänder sein, vergleichen Sie Zeige- und Ringfinger der linken Hand. (2) Wie lange können Sie die Luft anhalten? (3) Wie ist Ihre letzte Mathematik-Note aus der Schulzeit? (4) Wie lautet Ihr Vorname?
Das klingt absurd, nicht wahr? Und Sie werden sich innerlich nicht wohl damit fühlen: Ihre Zukunft hängt von Antworten auf diese Fragen ab, die so ohne jeden Bezug mit der Informatik zu sein scheinen? Ja, zugegeben, ich habe dieses Szenario erfunden. Ich weiß nicht, mit welchen Fragen ich Ihr Durchhaltevermögen für ein Informatik-Studium ermitteln kann. Aber so vollkommen wahnwitzig ist mein konstruiertes Beispiel nicht. Qualitativ unterscheidet sich der Test auf Eignung zum Informatik-Studium nicht von einem Erkenner von Schad-Software.

Am 4. April vermeldete heise online, dass Adobe an einem Erkenner für Schad-Software arbeite – die 30KB Python-Code zum Erkennerprogramm liefert Adobe gleich mit (http://heise.de/-1500180). Ein Erkenner für Schad-Software in 30KB? Neugierig geworden lud ich den Code runter – und war fasziniert und abgeschreckt zugleich. In dem Code ist für jeden offen zugänglich der Algorithmus kodiert, wie Adobe Schad-Software mit einer Trefferquote von über 90% erkennen will. Hier wird scheinbar Klartext geredet. Und dennoch ist der Code eine 753 Zeilen lange Ausgeburt an Hässlichkeit. Sowas produzieren in der Regel Code-Generatoren. Man liest den Code und versteht schlicht und ergreifend nichts. Wie kann das sein?

Als ich den verlinkten Artikel „Selecting Features to Classify Malware“ von Karthik Raman las (http://infosecsouthwest.com/lectures.html#sftcm), verstand ich, warum der Python-Code zwar nutzbringend aber unverständlich ist. Ausführbare EXE-Files folgen unter Microsoft Windows einem besonderen, sogenannten PE-Format (Portable Executable). Zu Beginn einer EXE-Datei kodiert das PE-Format einige Metainformationen. Und die sind bei Schadsoftware statistisch auffällig. Raman hat verschiedene Ansätze des maschinellen Lernen genutzt, um einen Satz an kritischen Metainformationen zu identifizieren. Er nutzt diese Informationen dann zur Vorhersage, ob es sich um Schadsoftware handelt. Dafür hat er 5193 „verseuchte“ Dateien und 3722 „saubere“ Dateien seinen Algorithmen vorgelegt. Im genügen letztlich 7 Metainformationen. Ist die Datei „verseucht“ erkennt Raman anhand dieser 7 Feature die Schad-Software zu 98,56% (true positives), „saubere“ Dateien stuft Ramans Erkenner zu 5.68% fälschlicherweise als schadhaft ein.

Obwohl Raman dieses Wissen als Python-Programm veröffentlicht hat, bleibt der Code vollkommen unverständlich. Solange man weder die untersuchten Ausgangsdaten noch die statistischen Verfahren und Algorithmen kennt, kann man mit dem Code nicht viel anfangen außer ihn einzusetzen. Es ist seltsamerweise eine Art der Preisgabe von Wissen, die nichts verrät. Ähnlich ist es mit meinem Eingangsbeispiel. Man könnte eine Reihe von objektiven Daten von Studierenden erheben und nach Klassifikatoren etc. untersuchen, die Studienabbrecher auszeichnet. Meine hypothetischen Testfragen wirken genauso sinnfrei und unverständlich wie der Python-Code, der Schad-Software identifiziert. Und trotzdem könnte ein solcher Test über Ihren Studienerfolg funktionieren mit genau solchen merkwürdigen Fragen.

Der Adobe-Ansatz begeistert mich. Aber sicher fühlen Sie sich unwohl, ihren Studienerfolg als Kondensat einer statistischer, maschineller Untersuchungen über Tausende Studierende hinweg eingeschätzt zu wissen. Sind Sie nicht ein Individuum? Kann der Test nicht auch irren? Und wo bitteschön sind die kausalen, die ursächlichen Zusammenhänge? Was spielt der Vorname für eine Rolle, ob ich ein Studium abbreche oder nicht?

Das ist die bittere Pille, die es zu schlucken gilt, wenn man nach statistischen Zusammenhängen in Daten sucht (Korrelationen), die aber nicht notwendigerweise etwas über Wirkungsbezüge (Kausalitäten) verraten. Und wenn Sie glauben, das sei schlimm, so irren Sie sich. Unsere Gehirne lernen Korrelationen, wenn sie sich in der Welt orientieren und überleben wollen. *Warum* man sich die Finger verbrennt, wenn man eine heiße Herdplatte anpackt, ist nicht unbedingt notwendig zu verstehen für das Überleben. Die Tatsache *dass* man sich die Finger verbrennt, das will im Zusammenhang mit einer Herdplatte gelernt, gespeichert und in Zukunft vermieden werden. Primitive Lebensformen könnten sich nicht entwickeln, wenn sie verstehen müssten, warum es links keine aber rechts eine Menge Nahrung zu finden gibt. Und seien Sie mal ehrlich: Verstehen Sie das Warum Ihrer Welt? Verstehen Sie, warum ein Fernseher funktioniert und warum es einen Klimawandel geben soll? Es ist erstaunlich, mit wie wenig an kausalem Wissen wir auskommen und uns dennoch wunderbar in der Welt zurecht finden.

Firmen wie Facebook, Google, Amazon, Twitter und viele andere sammeln sehr viele Daten von den Nutzern ihrer Dienste. Und erst seitdem es das Internet gibt, und erst seitdem so viele Menschen im Tausch für die Dienstleistung ihre Daten bei diesen Anbietern lassen, erst seit dieser Zeit ist die statistische Auswertung dieser Daten so interessant und wertschöpfend geworden. Diese Firmen suchen täglich nach statistischen Merkmalen und Auswertungen, die sich für verschiedenste Zwecke nutzen lassen. Google kann z.B. anhand von Suchanfragen die Ausbreitung von Grippe-Epidemien vorhersagen. Und Amazon schlägt Ihnen Buchtitel, die sie interessieren könnten, alles andere als zufällig vor.

Das Brisante daran ist, dass diese Firmen Ihr Wissen über uns Menschen als soziale, konsumierende Wesen ebenso Preis geben könnten, wie Adobe das Python-Programm – und dennoch hätten die Firmen kein Geheimnis über ihre Algorithmen und Verfahren verraten. Ich bin mir ziemlich sicher, dass Facebook – wenn das Unternehmen dies wollte – einen einfachen Fragekatalog erstellten könnte, der den Erfolg von jungen Menschen in Schule, Ausbildung und Studium vorhersagt; ähnlich wie ich Ihnen das eingangs vorgeführt habe.

Es gibt Firmen, die lassen Computer Twitter-Nachrichten lesen zur Beobachtung von Trends und Katastrophen-Meldungen, die dann z.B. einen Einfluss auf das Geschehen an der Börse haben. Auch hier lernen Maschinen nach Korrelationen zu suchen, die keinem Menschen jemals auffallen würden. Auch wenn wir lange nicht verstehen werden, wie diese Korrelationen zu erklären sind, Maschinen sind längst dabei ein neues, bislang ungekanntes Weltwissen zu generieren.

Ich habe einmal gelesen, dass die Suche nach in Kampfsituationen belastbaren Elite-Soldaten ein aufwendiger, sich über Wochen hinziehender Prozess ist. Amerikanische Wissenschaftler wollen festgestellt haben, dass ein einfacher Bluttest mit hoher Zuverlässigkeit geeignete Kandidaten herausfiltert und damit den teuren, langwierigen Auswahlprozess in Teilen überflüssig macht. Im Blut lassen sich Stoffe ausmachen, die Auskunft geben über die Fähigkeit, in Stresssituationen einen klaren Kopf zu behalten. Trotzdem setzt die Army diesen Bluttest nicht ein, weil es nicht mit der amerikanischen Wertekultur verträglich ist. Der Glaube an „Du kannst alles erreichen, wenn Du es nur willst“ passt nicht mit einem Bluttest zusammen.

Darum wird man wohl auch in Zukunft auf einen Test verzichten, der Ihre Eignung für ein Informatik-Studium voraussagt. Aber machen Sie sich nichts vor: In den Rechenzentren von Facebook, Google, Amazon und Co. analysiert man Ihre Daten und die anderer Menschen und sammelt Erkenntnisse über Sie, die Sie nicht verstehen – die aber wirken. Weil man erstaunliche Dinge über Sie als Wesen in der Masse Mensch aber auch als Individuum herausfindet. Sie wissen vielleicht noch nicht, was Sie studieren wollen. Aber Facebook oder Google wissen das möglicherweise schon und blenden Ihnen neuerdings Anzeigen ein, die Sie zum Studium der Informatik an der Hochschule Heilbronn auffordern. Das wird aus gutem Grund so sein. Tun Sie’s einfach ;-)