Paul Graham: Great Hackers

[Chromanoid]

Diskussion zu diesem Artikel
Great Hackers, Paul Graham, paulgraham.com, 2004
aus Artikelempfehlungen, interessante Publikationen o.Ä. verschoben.

Eingangsbeitrag siehe http://zfx.info/viewtopic.php?f=11&t=381&p=40570#p40538.

------

Interessanter Artikel :) Mal meine Meinung dazu: Ich kann solchen Elitarismus nicht leiden. Besonders den "Zusammenhang" zwischen der Wahl einer ungewöhnlichen Sprache und der Anziehungskraft auf neue Talente finde ich höchst fragwürdig. Davon liest man ja öfter mal. Wenn sich ein Programmierer künstlerisch austoben möchte, dann sollte er lieber Gedichte schreiben und nicht krude LISP Verrenkungen in kommerziellen Softwareprojekten aufführen. Ein Softwareprojekt ist aus meiner Sicht erst dann gelungen, wenn es nicht auf Einzelne angewiesen ist. Und genau das Gegenteil erlebt man sicher viel häufiger, wenn "ausdrucksstarke" Programmiersprachen eingesetzt werden: Einzelne, die sich durch schwer nachvollziehbare vermeintlich geniale Lösungswege praktisch unersetzlich machen. Da muss dann nur mal ein tolleres Softwareprojekt um die Ecke schauen und schon hat man viel Code, bei dem man nicht weiß, wie man ihn warten soll. Gerade im unternehmerischen Umfeld sollte es darum gehen standardisiert zu arbeiten. Wiederholbare Prozesse werden nicht durch begabte Einzeltäter möglich. Zu allerletzt mystifiziert der Autor dann auch noch ungünstiges Kommunikationsverhalten als Geheimsprache der Genies... :roll:

[Krishty]

Ich persönlich kann besser mit C- und C++-Leuten arbeiten. Alle C#ler und die paar Java-ler, mit denen ich bisher arbeiten musste, waren Vollidioten. Dass sie einfach runtertippen konnten statt sich auch nur halbwegs ernsthaft mit dem Thema zu beschäftigen war imo auch großer Teil der Misere. Das ist natürlich nur der winzig kleine Ausschnitt, den ich durch mein Schlüsselloch auf die Welt sehe.

Naja; vllt ist heute mein misanthropischer Montag.

[Chromanoid]

Ich glaube ja sofort, dass man sich beruflich schneller gut versteht, wenn man die gleichen Werkzeuge vorzieht. Einzelne Programmiersprachen stehen sicher auch für gewisse Herangehensweisen. Es ist sicher auch so, dass sehr komplizierte Systeme auch nur von entsprechenden Menschen geistig durchdrungen werden. Allerdings sehe ich Intelligenz weder als einzige Bedingung für unternehmerisch sinnvolle Lösungen noch als Garant für ein angenehmes Arbeitsumfeld. Und genau das scheint mir der Artikel zu vergessen. Ich glaube es ist für ein Unternehmen viel wichtiger ein vielfältiges Arbeitsumfeld mit unterschiedlichsten Mitarbeitern zu schaffen. Diese Mitarbeiter müssen neugierig und fachlich aneinander interessiert sein, sie müssen gute Lösungen anerkennen, eigene Fehler eingestehen und bei Experten um Rat fragen können - das hat vor allem mit Kultur und Sozialisation zu tun. Ich glaube nicht, dass geniale Ideen Genies erfordern, die sie ausbrüten. Sicher bringen Think Tanks mit hellen Köpfen viele gute Ideen hervor, aber sicher auch viele schlechte, die bei mehr Diversität vielleicht früher als solche erkannt worden wären. (BTW mir ist gerade aufgefallen, dass hier doch so einige Strohmänner drin sind...)

[Krishty]

Der Artikel erwähnt ja sogar, dass es absolut lebensnotwendig für die Firma ist, dass man die kreativen Köpfe nicht damit belastet, eine vollständige auslieferbare Implementierung ihrer Geistesblitze zu machen. Dafür braucht man die Bürodrohnen.

[Chromanoid]

Ich kann mir kaum vorstellen, dass so eine binäre Unterscheidung von Menschen möglich ist. Eine derartige Bezeichnung von ausführenden Kräften, halte ich übrigens nicht nur aus Gründen der "political correctness" für ziemlich fragwürdig. Daraus wird schnell eine self-fulfilling prophecy.

[Krishty]

Keine Regel ohne Ausnahmen; klar – darum stand da „ich persönlich“. Aber Leute können Programmierung imo unmöglich mit Erkenntnisdrang begegnen indem sie proprietäre Plastiksprachen benutzen. Wer wissen will, wie’s läuft, kompiliert sich lieber Linux-Kernel selber zusammen.

[Artificial Mind]

Kommt das nicht auch darauf an was man will? Erkenntnis bzgl. Speicherlayout, Ausführung, Performanz, Allokation usw. wird man bei "Plastiksprachen" (oder "managed" was ja deren Buzzword zu sein scheint) wahrscheinlich weniger erlangen. Wenn es aber darum geht eine externe Problemstellung (z. B. aus einem etwas theoretischeren Forschungsfeld) zu lösen, können (imho) Programmiersprachen, die einem den "low-level Anteil" abnehmen, durchaus produktivitätssteigernd sein.

[Krishty]

Natürlich entwickeln Profis nicht alles in C sondern hacken sich Perl-Skripte zusammen wenn die ausreichen. Aber sie sind vor allem produktiv weil sie wissen, wie alles funktioniert; weil sie die Probleme abschätzen können; und dann das richtige Werkzeug kennen. Aber das ist ganz bestimmt nie Java. Vor allem lernt man das nicht durch Java. Und wer nichts von Gleitkomma versteht, aber eine Molekülsimulation schreiben will, ist mit C# genau so unproduktiv wie mit C.

Das wird ja im Artikel beschrieben: Wenige Leute mit Ahnung („Great Hackers“) hacken Lösungen für komplexe Probleme hin bis sie das Interesse verlieren; und viele Java-Arbeitsdrohnen tippen das zum fertigen Produkt um.

Und ich finde durchaus, dass man diese Unterscheidung recht gut machen kann. Die Fähigkeiten sind nämlich exponentiell verteilt.

[Chromanoid]

Dir ist schon klar, dass Du hier alles auf bestimmte Probleme reduzierst, die Dich interessieren?

Software ist nicht immer nur deswegen kompliziert, weil man einen Prozessor braucht, der die Software ausführt.

Wenn die Kompetenz eines Entwicklers so wertvoll ist, dass er Lösungen nicht zu Ende implementieren soll, dann wird er nicht selten zu einem Softwarearchitekten und schreibt nur noch Konzepte.

Wie Du oder Graham das ganze dann auch noch an Java festmachen ist mir unbegreiflich. Mit Java lässt sich unheimlich produktiv sein, insbesondere in großen Teams. Gerade weil es eine Sprache ist, in der sich recht leicht programmieren lässt. Und keiner hat gesagt, dass man sich als Java-Entwickler nur Java angeschaut haben darf. Ist es denn wirklich so unvorstellbar für Dich, dass man sich freiwillig für Java entscheidet?

Nachtrag: Ich glaube ja mittlerweile fast, dass "freiwillige" Java Entwickler einfach bescheidener und praxisorientierter sind.

[Alexander Kornrumpf]

Ich hacke mich in meiner Freizeit übrigens gerade durch TDD mit python. Hat was unheimlich Meditatives.

[Chromanoid]

Machst Du das im Rahmen eines Projektes oder im Rahmen der akademischen Auseinandersetzung?

[Alexander Kornrumpf]

In erster Linie wirklich aus "Spaß an der Maschine". Ich habe eine Idee was das Ding (eine Web-Anwendung) mal können soll, und falls es was wird, werde ich mir sicherlich einen Uberspace dafür leisten, um es öffentlich zu hosten, aber wenn nicht, so what.

Nach zig angefangenen und abgebrochenen Projekten in "jungen Jahren" und fast keiner selbst geschriebenen Zeile Code in den letzten 30 Monaten sehe ich die ganze Geschichte weniger ambitioniert und eure Diskussion eher gelassen :)

Wollte das auch nur einwerfen, weil mein Eindruck ist dass es neben "Managed" vs "Nativ" mit "Interpretiert" eine ziemlich große dritte Kultur gibt. Das hier war mal ein Hobbyforum, bei dem der Spaß im Vordergrund stand. Ich glaube wenn man beruflich "gezwungen" ist mit einem ungeliebten Tool zu arbeiten wird man schnell grantelig (geht mir schon mit Word vs. LaTex so).

[Krishty]

Dir ist schon klar, dass Du hier alles auf bestimmte Probleme reduzierst, die Dich interessieren?

Nein; inwiefern?

Wie Du oder Graham das ganze dann auch noch an Java festmachen ist mir unbegreiflich.

Ich versuche hier Java und C# abwechselnd einzubauen, als Beispiele für proprietäre Neusprachen, die mit Marktdurchdringung als einzigem Ziel entwickelt werden. „Managed Language“ ist mir zu Microsoft-spezifisch; „Plastiksprache“ zu polemisch :-) Vorschlag?

[Chromanoid]

Das hier war mal ein Hobbyforum, bei dem der Spaß im Vordergrund stand.

Ich hoffe das ist immer noch so :)

Dir ist schon klar, dass Du hier alles auf bestimmte Probleme reduzierst, die Dich interessieren?

Nein; inwiefern?

Die meisten Probleme erfordern schlaue Algorithmen und nicht besonders Prozessor-gerechte Programmierung. Divide and conquer und andere Prinzipien kann man auch mit "Plastiksprachen" lernen. Es kommt bei vielen Problemen darauf an, dass man etwas hat, das Anweisungen ausführt und bestimmte Bedingungen erfüllt. Bei der Softwareentwicklung geht es vor allem um Logik und Abmachungen und nicht um technische Details.

[Krishty]

Öh ja. Und dann fangen Leute an, Geldbeträge in REAL zu speichern.

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

[Chromanoid]

Öh ja. Und dann fangen Leute an, Geldbeträge in REAL zu speichern.

Das liegt dann einfach nur daran, dass sie die Abmachung nicht berücksichtigt haben. Es reicht doch aus, wenn man die Constraints kennt. Warum diese Constraints vorliegen, ist insbesondere bei VM-basierten Sprachen relativ unwichtig, da sie überall gleich sind (so zumindest die Abmachung). Das ist ja das tolle an VMs.

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Das sehe ich anders, Du wärst sicher auch ein guter Programmierer, wenn Du nicht wüsstest, wie genau Dein Code ausgeführt wird, solange Du eine Dokumentation hast, die alle Abmachungen auflistet.

@Plastiksprache: Wie wäre es einfach mit VM-basierten Sprachen, denn das stört Dich ja scheinbar daran. Da scheinst Du übrigens anderer Meinung als Graham zu sein, der ja in höchsten Tönen Python und scheinbar auch LISP zu loben scheint.

[Alexander Kornrumpf]

Öh ja. Und dann fangen Leute an, Geldbeträge in REAL zu speichern.

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Könnte hier ein Problem mit der Schlussrichtung vorliegen?

"Ist Person die nur irgendwas ..." => "verwendet Java/C#"

ist nicht dasselbe wie

"verwendet Java/C#" => "Ist Person die nur irgendwas ..."

Ich glaube Chromanoid verwahrt sich vor allem gegen die zweitgenannte Richtung.

[Krishty]

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Das sehe ich anders, Du wärst sicher auch ein guter Programmierer, wenn Du nicht wüsstest, wie genau Dein Code ausgeführt wird, solange Du eine Dokumentation hast, die alle Abmachungen auflistet.

Dann wäre ich die perfekte Tippseldrohne. Aber wer arbeitet den Plan, den ich abprogrammieren soll, aus, und überprüft an einem Prototypen, dass er funktionieren wird?

@Plastiksprache: Wie wäre es einfach mit VM-basierten Sprachen, denn das stört Dich ja scheinbar daran. Da scheinst Du übrigens anderer Meinung als Graham zu sein, der ja in höchsten Tönen Python und scheinbar auch LISP zu loben scheint.

LISP, keine Ahnung; aber Python ist klasse. Man kann die VM einsehen und modifizieren, Python kann Neugier stillen. Bei Java und C# kannst du das vergessen – wenn du Open-Source-VMs findest und drin rumstöberst, sehen diese Sprachen aus, als wären sie von Leuten, die nicht programmieren können, geschrieben worden für Leute, die nicht programmieren können. Das ist natürlich nicht so, sondern eine Marketingentscheidung. Wenn du ein Problem schnell verstehen und lösen willst, benutz besser Python – dann tippst du nur halb so viel.

Könnte hier ein Problem mit der Schlussrichtung vorliegen?

"Ist Person die nur irgendwas ..." => "verwendet Java/C#"

ist nicht dasselbe wie

"verwendet Java/C#" => "Ist Person die nur irgendwas ..."

Ich glaube Chromanoid verwahrt sich vor allem gegen die zweitgenannte Richtung.

Das zweite. Welche Sprache ein Mensch benutzt ist anfangs Ausdruck seiner Umgebung (was seine Vorbilder machen und was er in Schule / Universität gelernt hat). Solche Menschen taugen sowieso nur zu Programmierung auf Hausaufgabenniveau. Wenn sie erfahren genug sind um sich umzusehen, sind die Sprachen, die sie wählen, imo sehr wohl Ausdruck ihres Charakters, ihrer Denkweise, und ihrer Fähigkeiten. (Oder würdet ihr bestreiten, dass Leute, die freiwillig entgegen aller Ratschläge Assembler programmieren, paranoide kontrollsüchtige Perfektionisten sind?)

[Chromanoid]

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Das sehe ich anders, Du wärst sicher auch ein guter Programmierer, wenn Du nicht wüsstest, wie genau Dein Code ausgeführt wird, solange Du eine Dokumentation hast, die alle Abmachungen auflistet.

Dann wäre ich die perfekte Tippseldrohne. Aber wer arbeitet den Plan, den ich abprogrammieren soll, aus, und überprüft an einem Prototypen, dass er funktionieren wird?

edit: Ich glaube Du hast mich falsch verstanden. Stell Dir vor niemand weiß wie Computer funktionieren und Du hast einfach eine Doku in der steht wie die Programmiersprache logisch funktioniert und ein CLI mit der Du die Programme ausführen kannst. Selbst bei Assembler oder C++ Programmen weiß man nicht wie der Code am Ende ausgeführt wird. Das kann theoretisch auf einer VM auf einer VM passieren und im Unternehmensumfeld wird es wahrscheinlich immer auf eine VM hinauslaufen. Was sagst Du denn zur theoretischen Informatik und Mathematik? Sind die Lösungen dort schlecht nur weil man nicht weiß mit welcher Programmiersprache sie später umgesetzt werden?

@Plastiksprache: Wie wäre es einfach mit VM-basierten Sprachen, denn das stört Dich ja scheinbar daran. Da scheinst Du übrigens anderer Meinung als Graham zu sein, der ja in höchsten Tönen Python und scheinbar auch LISP zu loben scheint.

LISP, keine Ahnung; aber Python ist klasse. Man kann die VM einsehen und modifizieren, Python kann Neugier stillen. Bei Java und C# kannst du das vergessen – wenn du Open-Source-VMs findest und drin rumstöberst, sehen diese Sprachen aus, als wären sie von Leuten, die nicht programmieren können, geschrieben worden für Leute, die nicht programmieren können. Das ist natürlich nicht so, sondern eine Marketingentscheidung. Wenn du ein Problem schnell verstehen und lösen willst, benutz besser Python – dann tippst du nur halb so viel.

Dieser Schluss ist einfach falsch. Selbst wenn die JVM Implementierung nicht besonders gelungen ist, kann man trotzdem sauber Software mit Java entwickeln. Stell Dir einfach vor man würde eine JVM ganz neu implementieren. Der Java Code würde schließlich gleich bleiben. Zumindest der VC++ Compiler scheint mir ziemlich gruselig implementiert, trotzdem wird er viel benutzt. Auch von vielen Leuten, die nicht jeden Code Abschnitt in Assembler anschauen. Und nein, das sind keine Versager oder Abtipper, sondern Leute die sich lieber mit echten Problemen beschäftigen.

[Krishty]

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Das sehe ich anders, Du wärst sicher auch ein guter Programmierer, wenn Du nicht wüsstest, wie genau Dein Code ausgeführt wird, solange Du eine Dokumentation hast, die alle Abmachungen auflistet.

Dann wäre ich die perfekte Tippseldrohne. Aber wer arbeitet den Plan, den ich abprogrammieren soll, aus, und überprüft an einem Prototypen, dass er funktionieren wird?

Das ist doch Quatsch. Stell Dir vor niemand weiß wie der Code ausgeführt wird. Bei C++ Programmen weißt Du das doch auch noch nicht mal wirklich. Das kann theoretisch auf einer VM auf einer VM passieren. Was sagst Du denn zur theoretischen Informatik und Mathematik? Sind die Lösungen dort schlecht nur weil man nicht weiß mit welcher Programmiersprache sie später umgesetzt werden?

Ich glaube, wir reden da komplett aneinander vorbei. Was für Abmachungen meintest du?

Dieser Schluss ist auch einfach falsch. Selbst wenn die JVM Implementierung nicht besonders gelungen ist, kann man trotzdem sauber Software mit Java entwickeln. Stell Dir einfach vor man würde eine JVM ganz neu implementieren. Der Java Code würde schließlich gleich bleiben.

Nein, das meinte ich explizit NICHT. Ich meinte auch explizit NICHT, dass die Entwickler der JVMs unfähig sind. Ich meinte, dass die JVMs nicht besonders gelungen ist, weil Java nicht besonders gelungen ist, und der Sprache eine Komplexität innewohnt, die die JVM auch bei bester Programmierung schwer nachvollziehbar macht ;-)

[Chromanoid]

Leute, die nur irgendwas fertigkriegen wollen und die nicht interessiert, wie und warum es funktioniert, so lange es doch läuft, sind nicht produktiv sondern gefährlich.

Das sehe ich anders, Du wärst sicher auch ein guter Programmierer, wenn Du nicht wüsstest, wie genau Dein Code ausgeführt wird, solange Du eine Dokumentation hast, die alle Abmachungen auflistet.

Dann wäre ich die perfekte Tippseldrohne. Aber wer arbeitet den Plan, den ich abprogrammieren soll, aus, und überprüft an einem Prototypen, dass er funktionieren wird?

Das ist doch Quatsch. Stell Dir vor niemand weiß wie der Code ausgeführt wird. Bei C++ Programmen weißt Du das doch auch noch nicht mal wirklich. Das kann theoretisch auf einer VM auf einer VM passieren. Was sagst Du denn zur theoretischen Informatik und Mathematik? Sind die Lösungen dort schlecht nur weil man nicht weiß mit welcher Programmiersprache sie später umgesetzt werden?

Ich glaube, wir reden da komplett aneinander vorbei. Was für Abmachungen meintest du?

Oje, ich hab schon reineditiert.

[Chromanoid]

Dieser Schluss ist auch einfach falsch. Selbst wenn die JVM Implementierung nicht besonders gelungen ist, kann man trotzdem sauber Software mit Java entwickeln. Stell Dir einfach vor man würde eine JVM ganz neu implementieren. Der Java Code würde schließlich gleich bleiben.

Nein, das meinte ich explizit NICHT. Ich meinte auch explizit NICHT, dass die Entwickler der JVMs unfähig sind. Ich meinte, dass die JVMs nicht besonders gelungen ist, weil Java nicht besonders gelungen ist, und der Sprache eine Komplexität innewohnt, die die JVM auch bei bester Programmierung schwer nachvollziehbar macht ;-)

Was sagst Du denn zu Scala, Jython, Clojure, Groovy usw.? Meine Neugier wird bei der JVM vielleicht nicht so leicht befriedigt, aber was ist, wenn meine Neugier vor allem in eine andere Richtung strebt? Mich interessieren weniger Details sondern abstrakte Lösungswege. Wie da welche Register bedient werden, interessiert mich nicht. Bis zu einem gewissen Grad bin ich natürlich vorgedrungen und jetzt interessiere ich mich eben nicht mehr dafür. Weil ich mich viel mehr für große Probleme interessiere als für kleine. Und genau da ist Java super. Die Sprache ist vergleichsweise wenig ausdrucksstark und standardisiert immer wieder neue wichtige APIs der Softwarearchitektur. Das ermöglicht einem Java Code wie ein Buch zu lesen und sofort den abstrakten Lösungsweg zu verstehen. Die Sprache selbst ist also super um die Neugier zu befriedigen.

Die Lesbarkeit einer Programmiersprache hängt natürlich auch viel von den eigenen Erfahrungen ab, aber ich finde dennoch Java ist da wirklich besonders einfach und robust.

[neon]

Ist zwar offtopic aber ich wollte sagen, dass ich die meisten essays von Graham nur empfehlen kann http://www.paulgraham.com/articles.html und http://ycombinator.com/lib.html . Viele Texte sind ziemlich lang, aber für Leute die sich für startups interessieren, sind sie must read. Grahams YCombinator ist übrigens der beste startup accelerator, also wer einige Ideen hat kann sich ycombinator gerne ansehen. Ist zwar extrem schwer da reinzukommen, aber auch wenn man da nicht teilnehmen möchte, allein das Prinzip davon zu verstehen, lohnt sich.

[MadMax]

Dir ist schon klar, dass Du hier alles auf bestimmte Probleme reduzierst, die Dich interessieren?

Das ist meiner Meinung nach die wichtigste Erkenntnis in dem gesamten Thema. Für ein Mann Projekte die keinen Wert auf Wartbarkeit legen ist so ein Hacker klasse aber für richtige Industrieprojekte kannst ihn vergessen.

Im Übrigen arbeite ich für eine der größten deutschen Firmen für Individualsoftware (unter anderem das ist nur mein Bereich) und wir würden einen solchen Hacker mit Sicherheit nicht einstellen. Eine Büro/Tippsdrohne natürlich auch nicht.

[kimmi]

Ich suche mir in der Regel nach Art des Problemes die Sprache aus und nicht umgekehrt. Das nur mal nebenbei bemerkt. Und ich bin wenn ein Tippser :).

Gruß Kimmi

[Chromanoid]

Eine kleine passende Diskussion, auf die ich über http://highscalablity.com gestoßen bin:
People seem to hate Java.
Es geht vor allem um eine Umfrage auf HackerNews (da steht ja auch u.A. Paul Graham hinter):

@Krishty: Die Google Group, die das diskutiert, gehört zu dem Blog Mechanical Sympathy. Der könnte Dich interessieren.

[hagbard]

Ich finde der Artikel ist eine Ansammlung von Binsenweisheiten, Stereotypen und Küchenpsychologie. Was er über Arbeitsbedingungen und Motivation sagt klingt vernünftig ist allerdings nicht bahnbrechend und auch nicht unbedingt nur auf Programmierer beschränkt. Die meisten Leute die geistige Arbeit verrichten haben keine Lust dies im lärmenden Großraumbüro zu tuen, egal wie hoch das Gehalt ist...
Wir er dann versucht aus den Verhaltensweisen und der Sprachwahl auf die fachliche Kompetenz zu schliessen scheint mir sehr weit her geholt...
Ich selber bin bisher da ich im Embedded Bereich arbeit kaum Java Entwicklern begegnet und den mit den ich näher zusammenarbeite durfte war eigentlich schon sehr fähig (er hat aber auch C im Selbststudium gelernt bevor er Java an der Uni hatte).
Ich denke der schlechte Ruf von Java-Enwicklern kommt einfach daher da Java inzwischen überall als Einstiegssprache in Unis und Ausbildung verwendet wird und daher jeder der mal einen Schein in Programmierung gemacht hat meint ein guter Java Entwickler zu sein. Die Tatsache dass Java eine relativ niedrige Lernkurve hat weil es ziemlich viel wegabstrahiert tut daher ihr übliches. Es gibt also somit automatisch mehr Kandidaten die "unangenehm" auffallen.
Ansonsten kann ich kimmi beipflichten. Ein guter Entwickler kann gute Software in mehr als einer Sprache entwickeln und nimmt (wenn er die Möglichkeit dazu hat) die ihn bei der Aufgabe am schnellsten zum Ziel führt.