How to Avoid Plagiarism?

The purpose of any scientific activity is to gain insight, to understand something, to advance knowledge in a field, to make some theory applicable etc. In any case, your are standing on someone else shoulders – a statement attributed to Isaac Newton (1642-1726), who revolutionized physics. Even a genius like Newton rarely creates something from scratch. There is always a basis, a foundation, work done by other people, we built our research upon.

The issue is: Give credit where credit is due!

In science, you do so by referencing the work (books, papers, articles and – in rare cases – web sites) of others your scientific outcome (books, papers, articles and – in rare cases – web sites) relies and is built on. It is a way to say “Thank you for letting me stand on your shoulders that helped me do my work.” This might include referencing private communication. Here, I don't mean any sort of assistance you received while you were stuck, but personal contacts, which decisively influenced your research by having research-related conversations, orally, by email etc. Give credit where credit is due!

The other issue is: Be honest about your contribution, no matter how tiny it is.

Most scientific work does not create a sort of Big Bang of insights, understandings etc. Mostly, science advances in very small, more baby-like steps. That's ok and there is nothing wrong with this. Do not feel bad about your tiny contribution to science. The point is: Make absolutely clear what the state-of-the-art in your field regarding your topic is and what your contribution is no one else did before. It is about making a difference, literally speaking.

You do so by summarizing and referencing the work of others relevant to your field. For that you need to carefully revise and inspect the current state-of-the-art. Sometimes that's not easy and requires you to do a lot of work, usually systematically searching databases covering the vast knowledge of your field and reading a lot of papers. Nonetheless, it is important work. To make a difference you need to show the difference no matter how small the difference is.

Not giving credit and letting your contribution appear more impressive than it actually is is regarded as an academic fraud. It is called plagiarism.

I hope you got the point: This one-pager is not about the technicalities to reference and quote other peoples work correctly. On this topic, there are tons of resources available elsewhere. “How to avoid plagiarism?” is about creating a mindset. It is a mindset of showing respect to others and being honest about your contribution. Make a difference – but without plagiarism.

Having immersed the mindset, you might understand why academia reacts quite drastic to uncovered cases of plagiarism. Students might get exmatriculated, researchers might loose academic titles and their jobs or positions. Plagiarism is not so much about a code of ethics but putting the scientific method at risk:

We cannot advance science by cheating on each other.

Das Kanban-Board des Steve Jobs

War Steve Jobs ein Anhänger der Kanban-Methode? Ja, ich glaube schon. Er hat Kanban gewissermaßen praktiziert. Anders zwar, auf seine Weise, aber es hat ihm einen Überblick über den aktuellen Arbeitsstand bei Apple samt einem Blick in die Zukunft ermöglicht.

Doch zunächst: Was ist Kanban?

Kanban ist eine der jüngsten agilen Methoden der Software-Entwicklung. Eine zentrale Stellung nimmt dabei das sogenannte „Kanban-Board“ ein. Als Kanban-Board dient z.B. eine (magnetische) Tafel oder eine Pin-Wand. Darauf finden sich Karten angeheftet. Die Karten repräsentieren Arbeitspakete; sie weisen einen Titel für das Arbeitspaket aus, den Namen der Person, die mit dem Arbeitspaket befasst ist, das Datum der Deadline etc. Das Kanban-Board ist in Bereiche unterteilt, die ein Spiegelbild des Entwicklungsprozesses sind. So gibt es Bereiche die beispielsweise "Inkubation", "Analyse", "Entwicklung", "Test" und "Abnahme" heißen. Die Verteilung der Karten in den Bereichen gibt die aktuelle Situation der Arbeitspakete in den einzelnen Arbeitsschritten wider. Das Kanban-Board ist nicht nur eine Dokumentation des Status quo, sondern dient auch als Steuerinstrument, um sicher und ohne Überlastung den Entwicklungsprozess zu durchlaufen -- und fordert dabei die stete Auseinandersetzung mit der Frage heraus "Was können wir besser machen?".

Kanban-Boards verfehlen leicht ihren Sinn und Zweck, wenn sie ein virtuelles Leben führen. Den Kanban-Vertreter(inne)n ist ein physisches Board sehr wichtig. Da soll was an der Wand hängen und für alle Beteiligten unübersehbar sein. Jeder soll über den aktuelle Arbeitsstand im Bilde sein. Das Kanban-Board soll auch Treffpunkt sein für kurze Treffen zur Abstimmung über die zu erledigende Arbeit, für den Austausch über Probleme, Rückstände oder Fortschritte.

Das Kanban-Board des Steve Jobs lag in einem Gebäudeteil auf dem Apple-Campus, im Design-Studio von Jonathan ("Jony") Ive, dem Chefdesigner von Apple. Es war weniger ein Board, als denn eine Reihe von langen Stahltischen, die in einem großen Raum aufgestellt waren. Auf den Tischen lagen echt aussehende Design-Modelle der laufenden Arbeiten. -- Das ist nachzulesen in Kapitel 25 der nach dem Tode von Jobs erschienenen Biographie "Steve Jobs" von Walter Isaacson, auf Deutsch veröffentlicht im C. Bertelsmann-Verlag. Die nachfolgenden Seitenangabe beziehen sich auf diese Ausgabe.

Jobs kam praktisch täglich in das Design-Studio von Ive und hatte dabei seine "Kanban-Tische" direkt im Blick. Er sah dort alle in Planung befindlichen Produkte und "konnte direkt erspüren, ob und wie sie in die Strategie von Apple hineinpassten. Er konnte mit seinen Fingern das in Entwicklung befindliche Design befühlen und begreifen." (S.405) Oder, um Ive sprechen zu lassen: "Dieser große Raum ist der einzige Ort in der ganzen Firma, wo man sich einfach nur umzuschauen braucht und alles sieht, was wir gerade in Arbeit haben." (S. 406)

Genau das ist die Funktion eines Kanban-Boards! Steve Jobs hatte von Software-Entwicklung und Hardware-Bau kaum Ahnung -- ganz im Gegensatz zu Bill Gates. Bei ihm war das Design, das Aussehen, die Formgebung seiner Produkte derart zentral, dass er alles dem Design unterwarf und das alles mit dem Design verwoben war. Mit dem Design began und endete alles. Insofern ist es nur konsequent, "Kanban-Tische" im Fall von Jobs zu haben. Für einen Außenstehenden standen dort "nur" Design-Modelle. Für ihn manifestierte sich in den Design-Modelle der gesamte Entwicklungsstand seiner Produkte. Auf einen Blick! Was für ein großartiges Management-Tool!

Über den Wolken muss die Freiheit wohl grenzenlos sein ...

In einer Wolke kann man sich der schönen Illusion hingeben, man habe so etwas wie Privatsphäre. Ein paar Meter weit kann man sehen, gerade genug, um sich selbst nicht aus dem Auge zu verlieren. Einem Außenstehenden versperrt der Dunst den Blick.

Welch wunderbare Illusion!

Ich nutze z.B. Google Docs. Ein paar Texte und Tabellen sind unter meinem Account abgelegt -- irgendwo in der Datenwolke, der Cloud von Google. Gerne gebe ich mich dem Glauben hin, meine Daten seien dort "privat" und "sicher". Vielleicht liegen Ihre Daten gleich nebenan, nur ein kleines winziges Bisschen entfernt auf der Festplatte im Google-Rechenzentrum. Wir sehen einander nur nicht, im Nebel der Cloud.

Machen wir uns nichts vor: natürlich ist der Nebel eine Illusion. Google sieht alles. Man analysiert dort fleißig alle nur verfügbaren Daten. Meine Daten ebenso wie Ihre Daten. Für Google gibt es keinen Nebel. Google sieht alle Daten in der Wolke, die Spannendes an Informationen herzugeben weiß. Und sollte irgendwo, irgendwann eine Panne passieren, so lichtet sich möglicherweise der Nebelschleier für einen Moment -- und Ihre und meine Daten bieten sich der Welt feil, und wir müssen uns der Peinlichkeit der Offenbarung des Privaten stellen.

Wissen Sie, was ich gerne möchte? Über den Wolken fliegen. Auch wenn es in diesen luftigen Höhen eiskalt ist, der Blick auf sonnengeflutete Wolkenlandschaften entschädigt alles. Durch eine Wolke fliegen ist uninteressant. Aber über den Wolken, da ist die Freiheit grenzenlos ...

Grenzlose Freiheit ist, wenn jeder in der Cloud prinzipiell meine Daten sehen könnte -- aber nichts davon hätte, weil alles verschlüsselt ist. Grenzenlose Freiheit ist, wenn Google (oder welcher Clouddienst auch immer) meine Daten nicht zu interpretieren wüsste. Verschlüsselt eben. Auf dem Client, im Browser, in der App, dort würde ent- und verschlüsselt werden. Niemals jedoch würde auch nur ein einziges privates Bit meine Rechner oder mein Smartphone verlassen, ohne vor den neugierigen Blicken Dritter wirklich geschützt zu sein.

Warum sollte uns irgendjemand diese Freiheit schenken? Wohl kaum einer! Die Freiheit über den Wolken, die Freiheit über der Cloud ist wirtschaftlich uninteressant. Grenzenlose Freiheit hat nur der, der in der Cloud keine Privatsphäre kennt oder will. Grenzenlos frei ist auch der, der unter der Wolke lebt -- und ohne den Datenrummel in der Cloud auskommt.

Von der Leichtigkeit, ein Startup zu gründen

Am vergangenen Wochenende fand der Entrepreneuship Summit in Berlin statt. Etwa 1200 Teilnehmer füllten den Henry-Ford-Bau der Freien Universität Berlin. Vorträge wechselten sich ab mit Impulsgruppen. Ging es am Samstag noch etwas zaghaft zu, kam am Sonntag mehr Bewegung und Stimmung auf. Man hatte sich am Vortag zaghaft beschnuppert, orientiert und allmählich in ein Gefühl gemeinschaftlicher Absichten eingefunden. So "störte" eine kleine Gruppe den Programmablauf am Sonntagmorgen und rief zum "Funky Business" auf; man wolle sich in Berlin-Tempelhof zusammentun und ein kleines Silicon Valley aufbauen -- nur besser. Sowas, so mein spontaner Gedanke, ist eben nur in einer Großstadt möglich. Und vielleicht sind die Berliner sogar experimentierfreudiger als andere Großstädter; vielleicht eben auch williger, das Scheitern mit in Kauf zu nehmen.

Veranstaltet hat den Summit die Stiftung Entrepreneurship. Dahinter steht als treibende Kraft Prof. Dr. Günter Faltin. Er hat mit seinen Studierenden das Unternehmertum real in der freien Wildbahn des Marktes ausprobiert. Herausgekommen ist dabei die sogenannte Teekampagne, die sich rühmen darf, den Teemarkt neu aufgemischt zu haben. Günter Faltin hat das und seine Gedanken zum Unternehmertum festgehalten in dem Buch "Kopf schlägt Kapital". Ein absolut lesenswertes Buch! Seine Art des "Entrepreneurship Design" prägte die Veranstaltung durch und durch. Es ist die neue "Leichtigkeit des Unternehmertums", mit der man von einer Idee zu einer Unternehmensgründung kommt. Heute lässt sich eine Vielzahl von Komponenten "einkaufen". Es ist nicht mehr nötig ein Büro zu haben, die Buchhaltung zu führen, selbst Produktionsanlagen zu betreiben, Bestellung und Versand in die Hand zu nehmen. Es genügt, sich aus diesen Komponenten das eigene Unternehmen masszuschneidern. Man muss nicht mehr Alleskönner sein. Man kann sich ganz auf das konzentrieren, was den Kern eines Unternehmens ausmacht: Die Geschäftsidee, die Konzeption der Idee und ihre Ausrichtung am Markt.

Den einen oder anderen mag das erinnern an die "4-Hour Workweek" ("Die 4-Stunden Arbeitswoche") von Tim Ferriss. Er vertritt eine ähnlich autonome, komponentenbasierte Unternehmensarchitektur, in Teilen sogar radikaler als Prof. Faltin. So war es denn kein Zufalls, dass ein Vortrag eine Videoeinspielung war, in der Prof. Faltin Tim Ferriss interviewte. Bedauerlicherweise war die noch am Samstagmorgen angekündigte Video-Liveschaltung mit Ferriss nicht zustande gekommen.

Ich kann nicht aus eigener Erfahrung mitreden. Aber es hat in der Tat den Anschein, als sei es nie zuvor so leicht und risikoarm gewesen, ein Unternehmen zu gründen. Manch junger Unternehmer setzt sein Unternehmenskonzept so konsequent auf, dass Kosten erst entstehen, wenn Kunden das Produkt bestellen oder die Dienstleistung nutzen. Das ist ein faszinierendes Extrem. Der Gründer der Laktasekampagne (der Name deutet es an, die Teekampagne war das Vorbild) Martin Lipsdorf sagte, er habe sein Unternehmen mit 700€ an den Start gebracht. Hui! Das hat was, oder?

Sascha Lobo -- wer ihn nicht kennt: eine auffallend unauffällige Erscheinung, wäre da nicht die rote Irokesen-Frisur -- berichtete als selbsternannter "Scheiterexperte" vom Scheitern. Auch das war also Thema. So leicht es heutzutage sein mag, ein Startup zu gründen, so leicht ist auch das Scheitern geworden. Es ist ja nicht gleichzeitig leichter geworden, sich auf dem Markt zu behaupten und in einer Nische einzunisten. "Fail often and adapt", das könnte man als Botschaft da raushören. (Ein Buchtipp am Rande: "Adapt: Why Success Always Starts with Failure" von Tim Harford.) Die Lernzyklen sind kürzer geworden. Man kann sich allmählich "warmgründen", bis es klappt! Und man sollte sich ohnehin darauf einstellen, die Geschäftsidee immer wieder anzupassen und zu tunen. Das berichteten einige Gründer in einer Impulsgruppe.

Wer sich Mut holen möchte zum Gründen: Ich bin sicher, im Oktober 2012 findet wieder ein Entrepreneurship Summit in Berlin statt. Einfach hinfahren und Erfahrungen austauschen. Ich habe 75€ Teilnahmegebühr bezahlt, der Betrag sollte für künftige Entrepreneure erschwinglich sein.

P.S.: An meine Zunft der Softwareschrauber: Die "School of Design Thinking" des Hasso Plattner Instituts (HPI) aus Potsdam war mit einem Vortrag zu "Enabling Innovation with Design Thinking" vertreten. Da geht es zwar nicht nur um Innovationen mit Software. Aber wenn Software eine Rolle spielt, dann macht es kaum einen Unterschied. Da werden "Prototypen" mit Stift und Papier, Knete, Playmobil und Lego realisiert. Anders lässt sich die prototypische Entwicklung eines Produkts an einem Tag gar nicht durchziehen. Dahinter steckt Methode. Kurze Zyklen, das Scheitern inbegriffen, sollen eine Innovation zu einem nützlichen, marktfähigen Produkt reifen lassen. Das Ganze hat mich sehr neugierig gemacht. Eine "School of Design Thinking" an der Hochschule Heilbronn, das wäre mal was ... fehlt uns doch nur ein kapitalkräftiger Förderer! Das "Design Thinking" ist sehr personalintensiv in der Betreuung der studentischen Gruppen.

Ein Blick in die Zukunft

Was hat einem ein Zukunftsforscher zu erzählen? Am Dienstag, den 25. Oktober, hielt Lars Thomsen an der Hochschule Heilbronn einen Vortrag über die Zukunft. 520 Wochen, sprich 10 Jahre, ließ er uns in die Zukunft schauen. Thomsen hatte aufmerksame Zuhörer. Die Aula war voll. Etwas mehr als eine Stunde hörten alle gebannt einem Vortrag zu, der ohne eine einzige Folie auskam. Ohne Zweifel ist Thomsen ein geübter Redner, der sein Thema ausgezeichnet zu vermitteln und zu verpacken weiß!

Worüber er sprach? Sie hätten dabei sein sollen. Ich versuche eine grobe Zusammenfassung von vier "Megatrends", wie Thomsen sie nennt:

Die Rechenleistung von Computern wird sich weiterhin jährlich verdoppeln. In 10 Jahren sind die Desktops, Laptops, Netbooks, Tabs und Smartphones 1000x leistungsfähiger als die heutigen Geräte. Es wird das "Ende der Dummheit" einläuten. Computer werden uns ganz neue Helferlein sein, da sie beginnen, uns zu verstehen. Sie werden EMails mitlesen, eingehende Nachrichten geeignet sortieren, Anfragen teils selbstständig beantworten. Das brauchen wir dringend. Jedes Jahr steigt der Mailverkehr um 18%. Wir Menschen sind schon jetzt mit der Datenflut überfordert. Es wird mehr und mehr Programme geben, die ein primitives Verständnis haben von dem, was wir tun, was unsere Gewohnheiten und Wünsche sind. Und die werden dieses Verständnis nutzen, uns zu helfen.

Unser Umgang mit Energie wird sich vollkommen verändern -- schon aus reiner Notwendigkeit. Die fossilen Rohstoffe sind begrenzt. Schon immer hat es auf unserem Planeten ein Einlagern und Freigeben von Kohlenstoff gegeben. Das, was der Mensch jedoch an CO2 in kürzester Zeit auf dem Planeten freigesetzt hat, ist wohl einmalig in der Geschichte der Erde. Klimatische Grenzen werden sich verschieben, neue Vegetationsgebiete kommen auf. Der Umstieg auf alternative Formen der Energiegewinnung und -speicherung ist unausweichlich. In China werden Solarmodule produziert, die Preise für Photovoltaik sind dadurch allein in der Zeit von Januar bis September um 22% gefallen -- ein sich fortsetzender Trend. Gut möglich: Künftig mögen die Solarzellen billiger sein als Dachziegel. Die Speicherung von Energie wird in Form eines Smartgrids gelöst werden. Die intelligente, dezentrale Organisation von Energiezu- und abflüssen im Energienetz wird die zentrale Energieversorgung ablösen.

2016 wird ein Elektroauto so viel kosten wie ein Benziner. Elektroautos sind dem Treibstoffwagen in vielerlei Hinsicht überlegen. Ein Blick unter die Motorhaube offenbart eine Boardelektronik, die kaum mehr als drei Coladosen einnimmt. Die Bodenplatte wird mit Akkus aufgefüllt, was zudem den Schwerpunkt extrem tief legt und exzellente Fahreigenschaften garantiert. Schon jetzt sieht ein Porsche alt aus im Sprint gegen moderne Elektroautos. Das derzeit kostentreibende Element im Elektroauto sind die Akkus. Doch hier macht sich ein Preisverfall von 12% pro Jahr bemerkbar. Noch in diesem Jahrzehnt wird das Auto mit Verbrennungsmotor nur noch etwas für Enthusiasten sein. Wer das Röhren in seinen Ohren höhren will, wer das Zittern eines aufdrehendes Motors spüren möchte, der muss sich als Nostalgiker einen teuren Benziner oder Diesel leisten -- vermutlich als Zweit- oder Drittwagen.

Die Medizin hat längst nicht ihr Potenzial ausgereizt. Sie lässt sich reduzieren auf das "Schneiden und Zusammenflicken" und den Einsatz von Chemie. Es kommen derzeit im Wesentlichen 37 Grundsubstanzen in Medikamenten zum Einsatz. Der Rest ist Hoffnung. Die "Medizin 2.0" baut auf den Selbstheilungskräften des Genoms auf. Die Menschen haben es gelernt, die 770MB Erbinformation, die jede Zelle mit sich herumträgt, auszulesen. Nun geht es darum, die darüber kodierten Eigenschaften und Aubläufe gezielt zu nutzen. Ein Beispiel: Eine Firma schenkt schwerhörigen Menschen ihr Gehör zurück. Nicht durch ein Hörgerät! Die feinen Häarchen im Ohr, die für das Hören gebraucht werden, werden wieder zum Wachstum stimuliert. Dazu wird ein Stopp-Gen, das unbegrenztes Haarwachstum verhindert, gezielt ausgeschalter und später wieder eingeschaltet. Mit den nachgewachsenen Harchen hört es sich prima. Viele von uns durfen auf solche medizinischen Fortschritte hoffen. Die Lebenserwartung unter den lebenden Menschen (nicht also erst in einer späteren Generation), steigt pro Jahr um 3-4 Monaten. Wer künftig steinalt wird, wird sich gerne von der Medizin "frisch" halten lassen.

Spannend, nicht wahr?! Thomsen hat noch eine Menge mehr erzählt. Er sprach vom Versagen des Geldes, aber auch von dem, was uns Menschen auszeichnet: Wir sind soziale Wesen, das wird sich nicht ändern. Vermutlich werden wir neue Wirtschafts- und Arbeitsformen ausprobieren. Und was Studenten gerne hören mögen: Man wird sich später auf dem Berufsmarkt um sie reißen. Es wird einen Mangel an (aus)gebildeten Menschen geben. Selbst Länder wie China werden aggressiv Fachkräfte aus dem Ausland anheuern, um ihren Hunger nach wirtschaftlichen Wachstum zu stillen.

Ich habe keine Ahnung, ob sich die Zukunft so entwickeln wird. Vieles, was Thomsen erzählt, wirkt erschreckend plausibel. Wenn Sie diesen Blogbeitrag in 10 Jahren, also im Jahr 2021 lesen, dann werden Sie wissen, ob Thomsen nicht nur ein hervorragender Redner, sondern auch ein wirklich guter Zukunftsforscher ist.

Clojure per Kommandozeile in Windows: CLASSPATH-Setting

Möchte man die Clojure-REPL interaktiv unter Windows nutzen, helfen gut gesetzte Umgebungsvariablen und ein einzeiliges Batch-File ungemein. Schmerzfrei wird der Dialog mit Clojure aber erst dann, wenn der CLASSPATH der JVM auf die nötigen jar-Files gesetzt ist. Ist auch das Verzeichnis der interaktiven Konsolen-Session dabei, funktioniert auch z.B. ein load-Aufruf aus Clojure heraus, um die dort befindlichen clj-Dateien zu laden.

Der folgende Einzeiler ruft die Clojure-REPL auf. Die Umgebungsvariable PATH muss das Verzeichnis mit java.exe beinhalten, die Umgebungsvariable CLOJURE sei auf das aktuelle Clojure-Verzeichnis gesetzt:

java -cp %CLOJURE%\*;*; clojure.main %1 %2 %3 %4 %5 %6 %7 %8

Zur Erläuterung: Das Wildcardzeichen "*" sorgt dafür, dass alle jar-Files im CLOJURE-Verzeichnis in den CLASSPATH aufgenommen werden, ebenso wie mit dem zweiten Wildcard "*" alle jar-Files im aktuellen Verzeichnis. Hinweis: Ohne das Semikolon als abschließendes Trennzeichen funktioniert das Wildcard-Zeichen nicht.

Complexity, Size and Focus

Why is it so hard to understand software? Or to put it more to the point: What makes it so hard to write understandable software? This question is the driving theme of this article: the quest to uncover techniques of complexitiy management that go beyond established principles of software engineering such as information hiding and modularization and which are unbound to specific paradigms like object-orientation or functional programming.

For that reason I studied two kinds of software systems in depth: telecommunication systems, modeling and programming languages. I did so for two reasons: First, telecommunication systems are among the oldest, largest and most successful systems. They are highly reliable, roboust and scalable. What are their key design principles that make them stand such demanding requirements? Second, each modeling and programming language is its creators attempt to provide a set of language conceptions to address and manage complexity. A language – be it a programming or modeling language – is, so to speak, the destillate of another persons opinion, experience and expert knowledge about how to write „better“ programs or how to design „better“ software.

My observation and claim is that two factors are most responsible for what I capture under the term „complexity“: size and focus. Size refers to number of lines of code and number of features, focus refers to intellectual comprehensibility.

The code basis of todays operating systems goes into million lines of code. Recently, Linux was reported to reach 10 million lines of code. Windows 7 is estimated to be of the same size. These numbers do not include application software typically shipped with these operating systems. Applications such as OpenOffice also count some ten million lines of code. The latest release of the Eclipse IDE (Integrated Development Environment), version 3.6, counts 33 million lines of codes. Since there is a relation between code size and the number of faults to be expected per 1000 lines of code (numbers vary from 25 to about 1 error per 1000 lines of code), such huge-sized software is highly interspersed with faults.

Another dimension of size is number of features: Todays software is extremely feature-rich. A whole industry of education and consulting is build around teaching and configuring the use of software, which is too feature-rich to use out of the box. Office applications and SAP R5 come into mind. This observation also refers to programming languages used to build these systems. The most spreaded languages are C, C++, C# and Java. Java, for instance, is such feature-rich that it requires a programmer to learn and understand a language specification of almost 700 pages of text. It is no exaggeration that most Java programmers only master a personalized subset of these 700 pages.

The sheer size of code of todays software makes it impossible for a software developer to understand software systems in its entirety. The sheer volume of code is overwhelming und impossible to master. It is a valid question whether this size complexitiy is inherent to the problem domain or a symptom of a certain design philosophy that has become main stream and is manifested in lanaguages like C(++), C# and Java. Alternative approaches indicate the latter: TeX, a typesetting system designed in the 1980s by Donald E. Knuth, is still top-class in its typesetting quality and widely spread in academia and among textbook authors; many publishers prefer manuscripts produced in TeX. TeX is based on a language kernel with primitives for typesetting and it can be easily extended via a powerful macro system. Besides bug fixes, the TeX kernel has been kept stable for almost 30 years now. Nonetheless, the system adapted constantly via its macro system with grwoing demands and new technologies coming up. Another example is Postscript.

There are also alternatives to feature-rich languages like C(++), C# and Java. Kernel-based languages like Lisp/Scheme, Prolog, Forth and Smalltalk are easy to understand. Their implementations fit on some few pages of code. They easily incorporated new paradigms and trends (e.g. object-orientation and aspect-orientation) due to their extensibility.

Another aspect of complexitiy management is focus. From a cognitive viewpoint, complexity is a human beings incapability to intellectually manage information which is (a) too much and (b) spread in time and space. It is a combination of information overload and a lack of recognizing temporal and/or spacial patterns. Two techniques address these issues: one is condensation, the other is localization. Condensation comes in two forms: abstraction building and modeling. Abstraction building can be reversed by refinement without loss of information; modeling condenses at the price of loosing information thereby simplifying things. A simplification introduces faults and errors; an oversimplification overstresses the acceptance of incorrectness. Localization is a technique to bring together (to bring in focus), what was spread and distributed before and thus appeared to be unrelated and unconnected. To concentrate on a problem (domain) means to put it in focus, to dissolve and localize relevant parts and highlight their relations, which might be spatial (i.e. structural) and/or temporal (behavioral). The act of localization establishes a new context, a new perspective or point of view, a new universe of discourse, a new domain.

In software engineering, several techniques have been developed for abstraction and localization. Among many other ideas we just would like to mention abstract data types, object-orientation and meta-object protocols, aspect-orientation, meta-programming and macro systems. All these approaches have one thing in common: they try to rearrange parts in a software description, they try to bring in focus, they localize. We call the flexibility of a language to adapt to different localization needs its expressiveness.

Interestingly, the other aspect of condensation, modeling, is rarely used in a systematic manner in software engineering with a clear understanding of the degree of incorrection and impreciseness introduced with a model. This understanding of modeling differs significantly from the common interpretation of the term. Typically, modeling is more meant to be a form of visual programming or a means to visually create code templates.

The assumption is that small size systems are a natural consequence of systems designed with extremely expressive languages. Empirical data point into this direction: Systems developed in expressive languages like Lisp/Scheme, Prolog, Python or Ruby argue with code size reduction compared to languages like C, C++, C# and Java. These languages (Lisp etc.) are quite expressive, whereas C and others strictly separate the language from the problem domain. If a certain localization need is not covered by language features, frameworks need to be designed and implemented to simulate expressiveness.

I think that software engineering has yet underestimated the use and the value of highly expressive languages and highly extensible kernel-based systems.

Superhacker

Es gibt dieses wunderbare Bild der Hacker! Ich meine die Geeks, nicht die Kriminellen. Hacker leben mit dem Computer, sie scheinen eins mit ihm zu sein. Computer und Hacker gehen eine Symbiose ein. Hacken ist Leben, Leben ist Hacken. Menschen und soziale Kontakte sind eine wunderbare Sache -- sofern man mit ihnen im Chat oder in anderen virtuellen Welten kommuniziert und sie dort trifft. Hacker sind mindestens 10x produktiver als normal sterbliche Programmierer. Und Hacker sind nicht nur produktiver, ihr Code scheint nicht von dieser Welt zu sein. Kein Mensch versteht die Kryptik und die Gedankengänge im Code eines Hackers.

Kurzum, wir bewundern die Hacker. Ein bissel hätten wir gerne von ihnen "vererbt" bekommen, wir, denen das Programmieren nicht ganz so locker von der Hand geht.

Gibt es die Hacker überhaupt? Oder sind sie ein Mythos? Ja und nein.

Es gibt Menschen, die das Bedienen ihrer Maschinen gründlich erlernt haben. Die 1000 Tastenkürzel kennen, mit Emacs arbeiten, alle Unix-Befehle kennen und im 10 Finger-System schreiben. Die Arbeit geht rasend von statten, wenn man diesen Tastaturakrobaten zuschaut. Fenster wechseln so schnell, das man glauben könnte, der Monitor habe einen Wackelkontakt. Das so ziemlich überflüssigste Interface für sie ist die Maus.

Dann gibt es welche, die mit den vielen kleinen Helferlein und Tools umzugehen wissen. Da wird Windows rasch gescripted, ein Makro programmiert, ein Makefile konfiguriert, im Hintergrund laufen inkrementelle Backups. Das sind die Automatisierer. Denn wozu von Hand machen, was eine Maschine besser, alleine und vor allem viel schneller erledigen kann. Für sie ist Linux die Idealwelt. Aber sie ziehen auch eine Freude daraus, dass sie dieselbe Magie auch mit Windows hinkriegen. Und mache von ihnen haben sich auf die Zauberkunst mit Excel spezialisiert.

Und es gibt die, die das Programmieren als Handwerk gelernt und verinnerlicht haben. Design Patterns sind für diese Menschen ein Klacks. Standardalgorithmen und -probleme können auf Zuruf während eines Telefonats runtergezimmert werden. Die Handwerker kennen ihre Bibliotheken und APIs in- und auswendig. Für sie ist Eclipse eine mächtige Schaltzentrale und die vielen offenen Fenster sind auf mindestens zwei Riesenmonitore verteilt. Sie haben mindestens genauso viel im Blick wie Börsenmarkler.

Kennen Sie die Sammler? Sie sammeln Programmiersprachen und konzentrieren sich natürlich auf die exotischen Exemplare. Java und C# hat schließlich jeder. Sie Sammler sind oft auch liebenswerte Spinner. Sie können einem stundenlang begeisterte Vorträge über ihre neueste Entdeckung halten. Die neueste Sprache ist immer eine Steigerung zu dem, was letzten Monat noch aktuell war. Sie schreiben immerzu kleine Programme, manchmal auch etwas größere, und zwar in Sprachen, die keiner versteht. Aber sie kennen sich aus. Im Grunde gibt es für sie keine Probleme, sondern nur falsche Programmiersprachen.

Tastaturakrobaten, Automatisierer, Programmierhandwerker, Sammler -- sie alle können etwas, was der Otto Normal-Programmierer nicht kann. Es sind Künstler, Handwerker, Besessene. Sie sind zweifelsohne jeweils auf ihre Art produktiver. Sie lösen Probleme geschickter, schneller und überzeugender als Andere. Manchmal nennen wir sie Hacker, besonders dann, wenn sie mehrere dieser Fähigkeiten vereinen. Aber sind das wirklich die Hacker?

Ich habe ein ganz anderes Bild vom Hacker; ich will sie mal "Superhacker" nennen. Manche von ihnen sind Tastaturakrobaten, manche Automatisierer, alle beherrschen das Programmierhandwerk eher besser als schlecht, und einige sammeln Programmiersprachen. Aber keines dieser Talente ist entscheidend. Superhacker denken! Das ist ihr eigentliches Talent, ihre eigentliche Stärke. Superhacker durchleuchten Probleme von verschiedenen Perspektiven. Sie skizzieren mögliche Lösungen. Diskutieren Ansätze und Vorgehensweisen. Sie brauchen dafür ihre Zeit. Manchmal findet sich eine elegante Problemlösung in einer exotischen Sprache begründet. Aber von Sprachen sind diese Menschen im Prinzip unabhängig. Sie kombinieren für eine Lösung Altbekanntes und Neues.

Und das Ergebnis: Brillant kurzer Code. Code, der verständlich ist. Code, der verblüfft ob seiner Offensichtlichkeit. Code, dessen Genialität seine Einfachkeit ist. Code, der wartbar ist und andere Designer und Software-Entwickler inspiriert. Code, der Zukunft hat und klare Entscheidungen für ein Design trifft.

Die Superhacker sind in der Regel nicht mehr produktiv in ihrem Tagesoutput als andere Software-Entwickler auch -- auch wenn es solche Wunder-Hacker geben mag. Das Geheimnis ihrer Produktivität schlägt sich nieder im Einfluss, den sie auf andere Entwickler ausüben. Das Geheimnis ihrer Produktivität zeigt sich in der überdurchschnittlichen Qualitätssteigerung der durch sie beeinflussten Produkte. Sie sichern Märkte. Sie sichern Zukunft.

Die Superhacker, die Denker, sind Menschen, deren Produktivität deshalb hochgradig skaliert. Über den Umweg des Einflusses auf andere steigern sie die Produktivität in einem Unternehmen vielleicht um ein, zwei, drei oder vielleicht sogar einmal fünf Prozentpunkte, im Glücksfall um 10 Prozent. Ähnliches mag für die Qualitätssicherung gelten. Darüber tragen Sie zum Umsatz und Gewinn eines Unternehmens in einem Ausmaß bei, der keinen Vergleich findet zum Einfluss eines "Normalprogrammierers". Die normalen Hacker steigern ihre Produktivität -- nicht die der anderen!

Übrigens gibt es eine etwas seriösere Bezeichnung für Superhacker: Man nennt sie auch Softwarearchitekten.

Factor @ Heilbronn University

It was an experiment -- and it went much better than I had imagined: I used Factor (a concatenative programming language) as the subject of study in a project week at Heilbronn University in a course called "Software Engineering of Complex Systems" (SECS). Maybe we are the first university in the world, where concatenative languages in general and Factor in specific are used and studied. Factor is the most mature concatenative programming language around. Its creator, Slava Pestov, and some few developers have done an excellent job.

Why concatenative programming? Why Factor?

Over the years I experimented with a lot of different languages and approaches. I ran experiments using Python, Scheme and also Prolog in my course. It turned out that I found myself mainly teaching how to program in Python, Scheme or Prolog (which still is something valuable for the students) instead of covering my main issue of concern: mastering complexity. In another approach I used XML as a tool for lightweight modeling to explore and study some techniques. The approach is innovative and still worth to be developed further but I wasn't satisfied.

My goal in the course "Software Engineering of Complex Systems" is to present and discuss practical techniques to conquer complexity in software systems. I did and still do a lot of research in this area. To make a long story short, I have come to the conclusion that Language-Driven Software Engineering (LDSE) is a very powerful and promising approach to conquer complexity. It's more than creating and using Domain Specific Languages (DSLs). It's consistently designing and creating languages throughout all levels and layers of a software implementation.

During my research I stumbled across Joy and Factor and learned about the concatenative paradigm. A series of excellent articles written by Manfred von Thun, creator of Joy, taught me the theory and fundamentals of concatenative languages. Factor, Slava Pestov's implementation of a practical concatenative language, turned out to be the best showcase I could think of: Factor is almost self-contained and extends itself by creating vocabularies of words using other vocabularies of words. Programs in Factor are written the very same style. Factor is seeing LDSE in action. I realized that it's the concatenative paradigm which enforces you to design software from a language-driven point of view.

How did the course go?

First I discussed the issue of complexity in software systems. Before I used Factor in the project week, I introduced the concatenative paradigm in the course. I presented it's mathematical foundation and used a pattern-driven approach to define the semantics of concatenative words as syntactic transformations. Finally, we defined a simplified grammar of Factor which we extended to cover pattern matching and template instantiation. All this served the purpose to smoothly prepare the ground for Factor. We also reflected and discussed a lot about what complexity is about and how it can be managed.

During the project week, my students (about 30 persons) worked with Factor four out of five days almost 8 hours per day. For my students it was full contact combat with an almost unknown programming paradigm and an exotic language. But they did really well. On day 1, the students worked through the introductory material supplied with Factor. On day 2, we studied types and object-orientation in Factor. On day 3, parsing and macros were studied in Factor. For these two days, the students worked with tutorials and worked their way through a number of exercise, which required them to write tiny programs in Factor to pass unit tests. On day 4, we worked on a topic unrelated to Factor. On day 5, two students thoroughly presented their project work, a real-world application in Factor, they had done in another course in the previous semester. We concluded the week with discussing and reflecting Factor's capabilities and the power of the concatenative paradigm in general.

Before I forget to mentioned it: Tim, research assistant in the software engineering department and PhD student, created the tutorials and the exercises and helped out a lot in class. Without him, the course wouldn't have been possible!

The students enjoyed the week very much. The evaluation of the course shows that they liked getting a new and different viewpoint on software development, object-orientation, parsing etc. They definitely realized and experienced that Factor helps them becoming better software engineers although Java is their main language.

Isn't Facor, aren't concatenative languages too esoteric to be useful?

Yes and no. There is no question that Factor is a niche language no one in industry shows interest for (besides Google, so far ;-). There might be some companies out there which use Forth and might be open for "concatenative thinking". However, even though the concatenative paradigm is almost unknown, concatenative languages are functional languages and functional languages are gaining in popularity. There's little doubt that learning functional programming broadens your scope and complements a student's skill set.

The fun part is that the concatenative approach to functional programming is much more simpler than the lambda calculus, which is traditionally taught. The math is simple and no intellectual barrier and formal transformations are easy to understand since there are no variable bindings and nesting scopes. Key concepts are stripped to their bare minimum. Did you ever try to explain the idea of continuations in Scheme? You might spend a good amount of time explaining continuations and running exercises. It's not unlikely that some students still don't get it. Continuations seem to be an extremely complex thing and appear to be somewhat mystical. In Factor, and in concatenative languages in general, continuations are a triviality! In principle, it's a snapshot of the data and the call stack. No big deal, since you juggle around with both stacks all the time. Are generic functions a specialty of CLOS. They come out naturally in a pattern-based approach to define concatenative words.

But my point goes beyond that. The way you create abstractions and refactor your programs in a concatenative language enforces you to continuously reflect about your design decisions. You have an enormous freedom of how you shape and constrain the design space of options at hand. It lets you think about words and vocabularies of words. It is thinking about creating and using languages. It combines software engineering and software programming in a way I haven't experienced in any other paradigm. That's why I introduced Factor in my course: You will start to engineer software, you'll explore new ways of creating abstractions and design frameworks.

Factor itself is an excellent case study for this approach. Factor starts from a relatively small kernel (which I -- admittedly -- haven't cleanly dissected, yet) and then consequently adds feature by feature with using Factor to extend Factor. A neat concatenative kernel turns itself into a powerful piece of software using a language-driven approach right from the start. Slava Pestov proves that this approach does result in a fast, interactive and highly reflective language. For me, Factor is a masterpiece of software engineering! It's definitely worth studying it!

Conclusion

What I experienced over the last two semesters is that some students become deeply attracted by Factor. Even if not, almost all students sense that there is a new world worth entering that takes them to a new level of understanding. It broadens their scope and skill set. Eventually, they'll leave the concatenative path for doing their Java/C# assignments in other courses or when they do some programming for a living. Still, I'm convinced that concatenative programming has an impact that lasts.

Do I sound too enthusiastic? Possibly, but I prefer to teach things I'm enthusiastic about! I'm still a student regarding the concatenative paradigm myself, I'm learning a lot each and every day about this paradigm. And one is for sure: I will continue to use Factor in the next semesters.

---
Update (2010-01-29) I received quite some requests to publish the Factor material we produced for the project week. The material is in German. Comments, ideas, corrections and improvements are welcome!

Day 1 - Intro: Getting started (Factor docu), Q&As

Day 2 - Object-Orientation: Intro, Tutorial, Q&As

Day 3 - Parsing and Macros: Intro, Tutorial, Q&As

Day 4 - Unrelated Topic:

Day 5 - Real-World Application in Factor: Presentation, Report, Sources (thanks to Andreas Maier and Marcel Steinle)

By the way, Daniel Ehrenberg indicated that Heilbronn University is not the first using Factor in a course. That's great to hear. Factor starts spreading!

In case you are interested in our research on concatenative languages, there is a paper available: "Concatenative Programming: An Overlooked Paradigm in Functional Programming".

Scripting Languages

Recently, I had an interesting discussion about "What's the distinguishing feature of so-called scripting languages?" We easily agreed on calling Python, Ruby, Groovy, Tcl, Perl etc. as scripting languages. But then the trouble started: What distinguishes Python, Ruby etc. from Java, C#, C++ and similar languages? Is it dynamic typing? Are they more introspective? Isn't it so that meta-programming is no difficulty at all with scripting languages?

Some whisper that a Python or Ruby programmer is as much as 2-5 times more productive than a Java/C# programmer. As a matter of fact, programs written in so-called scripting languages tend to be significantly shorter than their "unscripted" counterparts. Such a discussion typically moves over into an almost religious debate about static and dynamic typing. Programs in Python and Ruby might be shorter but they are unsafe because of dynamic typing. Static typing is the way to go for large programs being developed with many developers -- say the Java and C# advocates. And they have a point. Write unit tests, say the Pythoneers and Rubyists, which you are supposed to write anyhow. As a side-effect, your unit tests easily uncover all typing related bugs. You're not better off with a statically typed language, they say.

While such discussions are interesting our main question remains unanswered. What's the distinguishing feature of scripting languages? Most scripting languages are dynamically typed. But C# for example is catching up here. Are scripting languages interpreted languages? Python compiles to byte code internally, so does Java. Do they have unique reflective and introspective capabilities? To some extend, yes, but Java and C# are also quite powerful in this respect. Is programm size the only criteria? Regarding size, Haskell is a serious competitor. Haskell is statically typed (it requires a minimum of explicit type declarations) and quite dense in expressivity.

I think that the name "scripting language" is not very helpful these days anymore. It's historically motivated. In the early days of computing, users had to interact with their machines by typing in commands in a command line. Soon, the command line was embedded in a so-called shell. Famous shells under Unix are the bourne shell (bsh), csh, tcsh; another specialized automation tool for software developers is "make". The shell provided means to automate -- script -- repetitive tasks. This kind of "programming" inspired languages like Perl. These languages weren't regarded as "serious" languages like e.g. C/C++. They were typically interpreted and relatively slow in execution. However, these languages matured over time and inspired other designers to create "glue" languages like Python or Tcl/Tk. Because of their interpretative nature it was easy to add introspective features and meta-programming facilities. The idea of being a scripting or "glue" language vanished over time. They became full-fledged implementation languages on their own right and kept the philosophy of being flexible and easy to use to solve problems. I think it is not appropriate anymore to call them "scripting languages".

However, some of these "scripting languages" introduced a feature none of the compile-execute languages offered: The "programmable command line" languages introduced interactivity!

And that is the key point, it's the distinguishing feature: Interactivity requires to design a language in a certain way. To be interactive, relatively small chunks of text must represent syntactically valid program fragments in order to query or incrementally modify the run-time environment.

The way to interact with the run-tim environment in non-interactive compile-execute languages is via the debugger. A tool that is rarely taught in combination with a non-interactive programming language. It's quite much a different experience to work with a debugger or interactively via an interactive command-line. A debugger is built around a representation of the run-time model and usually establishes a bridge towards the language the original program is written in. Interactive languages connect your programming experience with the run-time model in a consistent language-related way but still might shield some implementation details from the programmer a debugger shamelessly unveils.

So the point is that interactive languages have a severe impact (a) on the syntactic language design and (b) they establish a certain way of how you perceive and experience the run-time environment of your language. This explains the shortness of interactive programs, it also explains the agility in the development process and its perceived prouctivity: quickly testing a program at the console results in immediate feedback to the programmer. This helps learning a language a lot and helps get a better run-time understanding. It's just fun and feels cool. There are only two languages I know of which have taken the implications of interactivity (small chunks of text represent valid syntactic programs and an incremental run-time experience) to an extreme: Forth and Factor!

This does not mean, that non-interactive languages are not useful and important! They just feel a bit different. Due to their lack of interactivity they feel less "handy", so to speak.