Bisher habe ich mich primär mit PHP und Python (und früher auch mit Java) auseinandergesetzt. Doch bei der Fülle an Programmiersprachen die es gibt, ist es an der Zeit über den Tellerrand zu schauen. Die Zeiten, dass man nur eine Sprache beherrscht und die dafür perfekt sind schon länger vorbei und so rückt das polyglotte Entwickeln näher. Da ich schon immer einen Faible für verschiedene Sprachen hatte, habe ich mir für dieses Jahr mal ein paar aufgeschrieben:
Aktuelle Sprachen
Ich beschäftige mich im ersten Teil der Artikelserie erst einmal mit Äußerlichkeiten. Daher nicht gleich die Kommentare fluten wenn ich mich hier nun erst einmal über Äußerlichkeiten wie Syntax, Transcompile Fähigkeiten etc. auslasse. In erster Linie muss ich als Entwickler die Sprache mögen. Was nützt es mir wenn ich jeden Tag mit einer Sprache arbeite die mich nicht anspricht oder flüssig aus der Hand geht. Da kann die Sprache noch so performant und toll sein, wenn man keinen Zugang zu ihr hat, wird man nie in die Tiefe kommen wie jemand der mit Leidenschaft die Sprache verwendet. Entwickeln ist für mich nicht nur “get the shit done” sondern eher ein kreativer Akt. Und so wie es Künstler gibt die eben nur Klavier, Geige oder mit Ölfarben hantieren, so habe ich mein Set an Sprachen die ich gern verwende – dafür aber intensiv.
Python
Meine Lieblingssprache. Klarer Syntax, schnelle Produktivität, dafür etwas langsam. Super erweiterbar, sehr stabile Libraries und Batteries inkluded, so dass man fast keine externen Libraries braucht. Einfach ein Allzwecktool für jede Gelegenheit. Böse war jedoch der Break zwischen Python 2 und Python 3. Das wurde ordentlich verkackt und ob sich die Sprache davon so schnell erholt bin ich mir nicht sicher.
PHP
Die Sprache mit der ich am längsten zu tun habe und nicht zu denen gehöre die PHP verteufeln. Die Sprache selber ist zwar hier und da etwas lazy und man muss genau hinschaun was für Daten in der Variable stehen bevor man die quer durch die App schleppt, aber ansonsten hab ich mit PHP keine Probleme. Leider ist generell bei PHP jeder der Meinung alles immer unnötig aufzupumpen und extrem komplexe Frameworks zu schreiben, die dann hinterher die eigentlich sehr schnelle Sprache derart ausbremsen, dass man wieder mit XCache und Konsorten hantieren muss. Der PHP Gemeinde täte ein PEP-20 von Python gut. Einfach mal den ganzen unnötigen Schmodder vor die Tür bringen – less is more.
Ausrangierte Sprachen
Java
Wenn es keinen expliziten Grund gibt fasse ich Java nicht mehr an. Ich habe mich damit mehrere Jahre beschäftigen müssen und das hat mir gereicht. Die neuen Dialekte die es gibt machen den Krauttopf nur noch fetter als er ist und beheben das eigentliche Problem nicht.
Neue Sprachen
Nim (früher: Nimrod)
Die Sprache sieht recht vielversprechend aus. Da ich Fan von OSR (Off-Side-Rule Languages) bin, spricht mich der Syntax direkt an. Die Sprache ist allerdings noch recht jung, so dass sich vermutlich noch einiges ändern wird. Der Compiler übersetzt die Sprache in verschiedene andere Sprachen und kompiliert dann. Aktuell gibt es C, C++ und Javascript soweit ich das gesehen habe. Mal ein Ausschnitt vom Syntax, der ähnlich Python ist:
# compute average line length
var
sum = 0
count = 0
for line in stdin.lines:
sum += line.len
count += 1
echo("Average line length: ",
if count > 0: sum / count else: 0)Als Einrückung werden immer 2 Leerzeichen verwendet, Tabulatoren sind verboten. Python nutzt 4 Leerzeichen.
Julia
Die Sprache ist noch jünger als Nim und entsteht derzeit im Umfeld von Scipy, ist also primär für Hochleistungsberechnungen gedacht. Für mich macht die Sprache aktuell den Anschein als ist es eine Weiterentwicklung von Python mit Cython im SciPy Umfeld um die Pythonproblemchen besser in den Griff zu bekommen. Besonders interessant an der Sprache ist für mich, dass der Syntax wieder ähnlich Python ist und obwohl die Sprache kompilierte Binaries erzeugen kann, dennoch dynamisch typisiert ist. Dynamische Typisierung sieht man eher bei Scriptsprachen (Python, PHP). Julia übersetzt seine eigene Syntax beim Kompilieren in eine LLVM intermediate representation sowie den Assembler Code. Die mitgelieferte Shell bietet gleich noch die Möglichkeit mal reinzuschauen was der JIT Kompiler gemacht hat. Hier mal ein Syntax Beispiel eines Quicksort Algos:
function quicksort!(A,i=1,j=length(A))
if j > i
pivot = A[rand(i:j)] # random element of A
left, right = i, j
while left <= right
while A[left] < pivot
left += 1
end
while A[right] > pivot
right -= 1
end
if left <= right
A[left], A[right] = A[right], A[left]
left += 1
right -= 1
end
end
quicksort!(A,i,right)
quicksort!(A,left,j)
end
return A
endKlasse, kein unnötiges Klammer-Gedöns. Ich hoffe, dass die Sprache vorankommt. Müsste ich mich zwischen Julia und Nim entscheiden würd ich trotzdem beide verwenden 
JavaScript / CoffeeScript
Zu JavaScript muss ich nicht viel dazu sagen. Den Syntax finde ich unhandlich, allerdings kommt man um JavaScript nicht wirklich herum, da es Dart von Google nicht bringen wird. Zum Glück gibt es aber mit CoffeeScript einen Transcompiler zu JavaScript. Da ich allerdings nicht blind irgendwelche Sprachen verwende sondern auch den produzierten Quelltext verstehen will, muss es eben beides sein. Hier mal ein Ausschnitt zu CoffeeScript:
# Functions: square = (x) -> x * x # Arrays: list = [1, 2, 3, 4, 5] # Objects: math = root: Math.sqrt square: square cube: (x) -> x * square x
Ist zwar nicht ganz so klar wie Julia, Nim und Python, kann man aber verkraften
C
Steht eigentlich schon länger auf der Liste. Einiges habe ich damit auch schon gemacht, allerdings ist mir das zu sehr das Spiel mit 2 Reagenzgläsern die bei falschem Zusammenschütten in die Luft gehen. Daher lese ich viel Quelltexte und arbeite mich Schritt für Schritt in C vor. Um schnell produktives zu erzeugen ist die Sprache aber nichts.
Rust
Während bei C (in die C++ Hölle begebe ich mich erst gar nicht) es immer das Spiel mit dem Feuer ist (irgendwo kann sich ein dangling Pointer verstecken) macht Rust einiges anders. Ursprünglich als Research Projekt von Mozilla für die neue Browser Engine Servo gestartet hat die Sprache mittlerweile 1.0 erreicht und verspricht vor allem Memory Safety. Der Kompiler ist streng und sorgt dafür dass man diszipliniert entwickelt. Dennoch hat man die Kontroller über sehr systemnahe (low-level) Funktionen. Die Zielgruppe sind frustrierte C++ Entwickler, jedoch auch für C Leute ist die Sprache nicht uninteressant. Der Syntax ist allerdings nichts für Pythoniasten. Das Beispiel zeigt ein Closure:
fn myfunction(multiply: int) -> fn@(int) -> int {
ret fn@(number: int) -> int {
ret number * multiply
};
}
fn main() {
let duplicate = myfunction(2);
let result = duplicate(5);
io::println(#fmt("%d", result));
}Steht auf der Todo und ich will damit auch einiges mal ausprobieren.
Go
Tja was ich mit Go auf längere Sicht anfangen werde ist mir aktuell nicht so klar. Die Sprache selbst bringt nichts wirklich Neues und ich frage mich aus welchem staubigen Archiv Google den Syntax ausgegraben hat (Ich sehe gerade, dass die Sprache von Alef und Limbo abstammt, also aus dem Archiv von Bell Labs). Auch wenn mit Rob Pike und den anderen Köpfe an der Sprache gesessen sind die einiges markantes geleistet haben (UTF-8, B als Vorgänger von C) ist die Sprache hinterm Mond. Da hat Rust weit mehr zu bieten. Das was die Sprache vergeigt, reisst die Community wieder raus. In der kurzen Zeit wo die Sprache publik wurde sind Libraries an allen Ecken und Enden entstanden und entstehen noch. Man weiss gar nicht wo man zuerst anfangen soll
Was mich jedoch sehr wundert ist, dass manche Unternehmen die früher primär auf Python als “Haussprache” gesetzt haben, das komplett über Board werfen und mal eben alles neu schreiben. Wenn Python an einigen Stellen hakt oder lahm ist, dann tauscht man doch nur den einen Part aus und schreibt nicht alles in einer neuen Sprache komplett neu und fängt damit mit den Kinderkrankheiten, Bugfixes von vorne an.
Ebenfalls gegen den Strich geht mir das Diktat der Sprache wie man Sourcecode Verzeichnisse zu organisieren hat. Als Entwickler wünsche ich mir Freiheiten, ich möchte meinen Quelltext so anordnen wie mir das gefällt oder ich das für richtig finde – und nicht irgend ein Kompiler vorgibt und erwartet.
Abgerundet wird die Sprache damit, dass sogar die Formatierung vorgegeben wird (go.fmt) obwohl durch die Klammern man eigentlich Formatieren könnte wie man wöllte (curly-bracket languages). Ich finde den Syntax in der Schreibweise sperrig und nicht so flüssig wie Python, Nim oder Julia.
Ich werde das weiter beobachten, jedoch Scherwpunktsprache wird Go bei mir nicht werden. Hier noch ein Ausschnitt aus der Syntax am Beispiel einer variadischen Funktion:
package main
import "fmt"
func sum(nums ...int) {
fmt.Print(nums, " ")
total := 0
for _, num := range nums {
total += num
}
fmt.Println(total)
}
func main() {
sum(1, 2)
sum(1, 2, 3)
nums := []int{1, 2, 3, 4}
sum(nums...)
}Ach eins noch. Was mir bei Go ebenfalls tierisch auf den Keks geht ist die Boilerplate für die Fehlerbehandlung. Dazu gibt es einen Blogbeitrag auf dem Go Blog “Fehler sind Werte”.
_, err = fd.Write(p0[a:b])
if err != nil {
return err
}
_, err = fd.Write(p1[c:d])
if err != nil {
return err
}
_, err = fd.Write(p2[e:f])
if err != nil {
return err
}Verbesserung:
type errWriter struct {
w io.Writer
err error
}
func (ew *errWriter) write(buf []byte) {
if ew.err != nil {
return
}
_, ew.err = ew.w.Write(buf)
}
ew := &errWriter{w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
return ew.err
}Grauenhaft. Der Go Blog erklärt dann, dass Fehler nur Values sind und man das auch wieder verarbeiten kann. Also bitte, mit Fehlern will sich eh niemand beschäftigen, jetzt soll man auch noch drum rum programmieren damit man nicht solche Boilerplates hat… Grmpf.
Abschluss
Es gibt sicher noch eine ganze Tonne anderer Sprachen, wie Haskell, OCaml etc. Die funktionalen Sprachen reizen mich aktuell noch nicht und 2016 brauch ich ja auch noch was. Geplant ist, dass ich die nächste Zeit auf jede Sprache in einem eigenen Beitrag etwas tiefer eingehe. Gerade die Sprachen die ich mir aneignen will, werde ich in “byexample” Beiträgen abarbeiten.