bash & vim & screen als IDE

Da ich in Zukunft wieder in die Programmierung zurückkehre, habe ich mich auf der Suche nach komfortablen und mächtigen IDE's gemacht. Bisher habe ich immer auf der Console gearbeitet. Nachdem ich mich nun mal mehrere Tage gezwungen habe, mit NetBeans zu arbeiten, bin ich wieder zu meiner bash, meinem screen und dem vim zurück gekehrt. Einige Funktion habe ich in Netbeans aber zu schätzen gelernt, und möchte zeigen, wie diese alle in vim genutzt werden können:

Die Exuberant CTags bringen Tagging-Funktionen für 34 Programmiersprachen mit. Ein einfaches "ctags -R" taggt alle Dateien rekursiv vom aktuellen Ordner in die Datei "tags"; ein Aufruf von "vim -t tags" lässt vim die Tags einlesen und öffnet, sofern vorhanden, eine als Tag markierte Datei. Mithilfe eines einfach ":ca " kann ich nun blitzschnell zwischen den gewünschten Positionen pendeln, tab-completion ist auch integriert.

Folding ist seit Vim7 problemlos möglich: Im Visual-Modes (v) den Bereich markieren, und mit zf einklappen.

Aus der globalem /etc/vim/vimrc sollten mindestens folgende Optionen in die eigene .vimrc übernommen werden:

set showcmd " Show (partial) command in status line.

set showmatch " Show matching brackets.

set ignorecase " Do case insensitive matching

set smartcase " Do smart case matching

set incsearch " Incremental search

set autowrite " Automatically save before commands like :next and :make

set hidden " Hide buffers when they are abandoned

set mouse=a " Enable mouse usage (all modes)

syntax on

der Untergang des rheinländischen Kapitalismus durch die Finanzkriseninszenierung

Ergänzend zu meiner Kurztabelle über die Unterschiede zwischen dem Angelsächsischem und dem Kontinentaleuropäischen Kapitalismus findet sich in Richard Sennetts der flexible Mensch eine ähnliche Perspektive. Im Kapitel "Flexibility" beschreibt er*1, wie es ein angloamerikanisches und ein rheinisches Modell gibt. Das rheinische Modell sei das klassischerweise durch Holland, Deutschland und Frankreich*2 praktizierte, in dem die Gewerkschaft und das Konzernmanagement die finanzielle Macht teilen, während der Wohlfahrts/Sozial-Staat ein enges Netz von Rentenverfügbarkeit, Bildung, Gesundheitsversorgung, Versicherung, usw. produziert.

Das anglo-amerikanische Modell sei der Inbegriff des ungeregelten Marktes, die völlig ungezügelte Form der freien Marktwirtschaft. Soziale Verpflichtungen werden im rheinischen Modell zur Aufgabe des Staates, der Kommune und des Gemeinwesens, während diese Ziele im angloamerikansichen Modell der Wirtschaft untergeordnet sind.

Die Staaten des Rheinmodells bremsen im allgemeinem Veränderungen, bei denen ihre schwächeren Bürger Nachteile erleiden, während das angloamerikanische Modell sämtlichen wirtschaftlichen Organisationen freie Fahrt erteilt.

Es ist diese dem rheinländischem Modell anliegende Bremse, welche verhindert, daß gesellschaftliche Zustände wie in Amerika hier zu lande herrschen. Der Import des durchwegs neoliberalen Gesellschaftskonzeptes wird zwar schrittweise durchgeführt, ich nenne die ständigen Privatisierungswellen, die Riesterrente und die Hochschulreform als Beispiel; das traditionelle soziale Netz der strengeuropäischen Staaten hinderten diese Importe in den letzten Jahren aber immer wieder, aufzublühen.

Erst unsere neue, seit Ende 2008 in die Öffentlichkeit projizierte langjährige Rezession wird es schaffen, die letzten Hürden des rheinländischen Kapitalismus aufzulösen und echte neoliberale Zustände hinauf zu beschwören.

Erst unter dieser Legitimation kann die gegenseitige Unterstützung der liberalen Wirtschaft und des Staates, in diesem Fall durch die Verstaatlichung insolventer Banken so erfolgreich und protestlos durchgeführt werden.

Zu diesem bewundernswerten stoischen Gleichmut der Bevölkerung hat auch die Gewöhnung an den nächstjährigen Status Quo beigetragen, gar nicht zu sprechen vom nahezu perfekten Medienmonopol.

Zu dieser festgefahrenen gesellschaftlichen Situation gibt es viele Alternativen; doch während diese große gesellschaftliche Umbruchsphase zu ihrem Endspurt kommt sollten diese eigentlich eine Konjunktur haben. Diese Konjunktur bleibt aus, und ich sehe keine andere Möglichkeit, als dass dieser Endspurt so stattfinden wird, wie es die letzte, vergleichbare Rezession geschafft hat.

Sie endete mit dem Beginn des zweiten Weltkrieges.

*1 Dieses Modell nimmt er von Michel Albert, einem französischem Wirtschaftsmodelltheoretiker.

*2 Dieses Modell ist auch in Italien, Japan, Skandinavien und Isreal übernommen worden.

*3 Dieses Monopol wird momentan durch die Internet-Zensur weiter perfektioniert.

Traits vs. Grafts in PHP6

Nach dem heutigen Release von PHP 5.3 möchte ich etwas über zwei potenzielle Implementierungen, die das objektorientierte Paradigma in PHP6 fundamental verändern könnten, berichten.

Den bekannten Problemen (z.B. das "Diamond Problem" & hier) mit der klassischen Mehrfachvererbung (multiple Inheritance) in Programmiersprachen wie C++ 0der auch python halten strengere OOP-Sprachen wie Objective-C und Java Interfaces entgegen. Ausgehend vom Prinzip des Interfaces gibt es zwei Vorschläge, wie PHP6 in Zukunft mit dieser Problematik umgehen wird.

Ein trait, als abstrakte, nicht-instanziierbare Schemaklasse entspricht dabei weitestgehend dem Interface der Java-Welt. Zusätzlich erlauben traits nun auch das einbeziehen vorhergehender traits:

trait A { public function print() { echo 'A &';}}

trait B { public function print() { echo ' B!';}}

trait AandB { use A, B; }

class MyClass { use AandB; }

Ein Graft ist ein, so weit ich weiss, neuartiges Konzept, dass bisher in keiner Programmiersprache implementiert wurde. Ein Graft ist eine Klasse, die innerhalb ihrer Klassendefinition auf mindestens zwei vorherig definierte Klassen zurückgreift, und den Geltungsbereich in der Klassendefinition explizit definiert:

class MyGraft {public function foo() { echo 'foo'; }}
class MyGraftedClass {
use MyGraft {  public foo();}
use MyGraft {  public bar() from foo(); }
}

Ein Graft zieht sich also aus den vorhandenen, unabhängigen Basisklassen die Methoden, die wiederverwendet werden sollen, heraus, und setzt in der neuen Klasse einen neuen, künstlichen Namensraum, der die Eigenschaften der Ursprungsklassen kopiert. Bei Namensüberschneidungen gilt die Reihenfolge der hineinge-graft-eten Klassen.

Ich denke, dass ein Graft zu einem schlechtem OOP-Design verführt. Es ist ein Kompromiss, der versucht, die Probleme, die die Mehrfachvererbung erzeugen kann, zu dämpfen. Ein Interface resp. Trait ist nach wie vor der Stand der objektorientierten Programmiertechnik, da es Probleme bereits im Design auszuschliessen versucht.

Geistreiche Vorschläge zu diesem spannendem Thema, gibt es hier. Ich hoffe und könnte mir vorstellen, dass des Konzept des Graft aufgrund konzeptioneller Fehler und der immensen Ungewohntheit den Kampf um das zu verwendete Programmierkonzept verliert.