C, C++, C#, Java, Pascal, Basic, Swift, Haskell, Go, Python3, Python2, JS, PHP, Perl, Ruby, Lua, Scala es gibt so unglaublich viele.
Es gibt einen Wikipedia Artikel der nur Programmiersprachen aufzählt. Aber warum?
Es werden über wenig Dinge mehr Trollkriege geführt, als über die "richtige" Programmiersprache. Dann gibt es wieder Leute, die sagen man könne mit jeder Sprache programmieren. Aber wer hat Recht? Der es muss Java oder der es muss Ruby? Nein.
Man kann nicht mit jeder Sprache programmieren. Und man kann auch nicht mit einer Sprache programmieren. Es gibt nähmlich mehr als nur ein Anwendungsgebiet für Sprachen. Wenn man aber die richtige Sprache für sich finden will muss man sich mit sich selbst, mit dem was man (generell)tut und was man in genau diesem Fall tut auseinander setzen.
Application Developer gibt es wie Sand am Meer. Einfach schon weil App Dev die wohl größte Sparte der Softwareindustrie ausmacht.
Viele von ihnen sind -- Verzeihung -- nicht das gelbe vom Programmierer-Ei. Vielleicht, weil man keinen Bachelor of Science in Computer Science braucht um Applications zu entwickeln. Und mit Sicherheit auch weil App Dev das ist, was sich nicht-Programmierer als Programmieren vorstellen, also entsprechend viele Anfänger dabei sind.
Was für ein Typ von Sprache empfiehlt sich für einen App-Entwickler? Sie muss in erster Linie
So eine Sprache sollte den Entwickler sogar zu lesbarem Code zwingen! Darum fallen Sprachen wie Python, Basic, Haskel, Lua, JS, PHP und ähnliche schon raus. Sie braucht außerdem Klassen und eine Speicherverwaltung.
Also was ist diese Sprache? Java! (Oder C# und Swift)
Der elitäre Kreis der Wissenschaftlichen Programmierer hat, eigentlich, ganz andere Ansprüche an eine Programmiersprache:
Sie sollte mächtig sein, elegant und mit mächtigen Datentypen bestückt sein. Da gibt es vor allem eine Sprache: Python3. Sie besitzt die Möglichkeit wunderschönen Code zu schreiben und neue Datentypen (Also Klassen) mit gewöhnlichen Operatoren an zu steuern. Ein Beispiel dafür ist diese (Teil-)Implementation eines Ganzzahltyps mit fester Breite.
In wie weit ein solcher Datentyp sinnvoll ist sei mal dahingestellt, wichtig ist, dass das Konzept auch auf andere Datentypen anwendbar ist, wie Matrizen, Vektoren oder (theoretisch) unendliche Gleitkommazahlen (die sind aber alle deutlich schwerer zu realisieren).
In [1]:
class FixedWidthInteger(object):
def __init__(self, value, maxval = (2 ** 64) - 1):
self._value = value
self._maxval = maxval
def __add__(self, other):
if(isinstance(other, FixedWidthInteger)):
other = other._value
elif(isinstance(other, int)):
pass
else:
raise ValueError()
res = other + self._value
if(res < 0):
res *= -1
res %= self._maxval
res *= -1
else:
res %= self._maxval
return FixedWidthInteger(res, maxval = self._maxval)
def __radd__(self, other):
if(isinstance(other, FixedWidthInteger)):
maxval = other._maxval
other = other._value
elif(isinstance(other, int)):
maxval = self._maxval
else:
raise ValueError()
res = self._value + other
if(res < 0):
res *= -1
res %= maxval
res *= -1
else:
res %= maxval
return FixedWidthInteger(res, maxval = maxval)
def __repr__(self):
return repr(self._value)
def __str__(self):
return str(self._value)
In [2]:
f = FixedWidthInteger(2 ** 16 - 5, maxval = 2 ** 16 - 1)
f + 10, (2 ** 16) - 5 + 5600000 # Ueberlauf
Out[2]:
Aber natürlich gibt es auch andere Felder, die man beachten sollte, beispielsweise Performance.
Wer daran Interresse hat sollte einen Blick auf GoLang werfen, oder auf, meist von Hardwareherstellern entworfenen Hochparalelisierenden Sprachen.
Ist immer noch (respektive wird immer mehr) wichtig. Kaum eine Branche hat einen derartigen Umsatz wie die Computerspielbranche und Perspektiven hat sie auch noch. Ich persönlich hatte noch nie so richtig Kotakt mit Spieleentwicklung, nur so viel, dass man ganz viele Grafiker braucht und Fast immer mit C++ Programmiert.
Warum C++? Ganz einfach: Es soll alles eine gute Performance haben (das können v.a. C, C++ und Hochparalelisierte Sprachen) und es lässt sich schlecht paralellisieren, da Spiele meist sehr sequenziell sind, und das was man doch paralellisieren kann, kann man gut mit Threads lösen. Und wieso man nicht C nutzt ist fast schon trivial: C ist viel zu umständlich und für Anfänger zu unsicher (Schon mal was von SIGSEGV gehört?).
Außerdem läuft C++ auf fast allen Platformen, d.h. auf allen wichtigen Platformen.
Auch (noch immer) groß am Kommen, und so gar nicht meins. Man muss ganz viel mit Grafik arbeiten (was ich nicht so recht kann) und mit obskuren Scriptsprachen, wie Ruby, JS o.ä.. Dabei muss ich hinzufügen, dass diese Sprachen, nur weil sie mir obskur sind, nicht schlecht sein müssen und wundervolle Frameworks, wie d3.js bestätigen das.
Vom Web Dev kommt auch der Mythos Full-Stack-Developer, d.h. jemand macht einfach alles, vom Frontend bis zum Backend. Wer sich intensiv mit Software Entwicklung auseinander gesetzt hat weis, dass ein Full-Stack-Developer weder sinnvoll, noch (aller Wahrscheinlichkeit nach) besonders gut ist, die Gründe aus zu führen würde aber diesen Rahmen sprengen.
Damit habe ich auch schon mal einen Trollkrieg ausgelößt, denn es gibt Leute die da ganz anderer Meinung sind.
Darunter fallen für mich Sprachen wie Haskell und Ähnliche. Sie nutzten meistens irgendwie exotische Konzepte (z.B. Deklaratives Programmieren) und sind nicht mainstreamtauglich, weil der Code für Außenstehende kaum lesbar ist und man sich wirklich einarbeiten muss.
Das heißt aber bei weitem nicht, dass es sich nicht lohnen kann, weil man manche Probleme sehr elegant löst und auch die Performance sehr gut sein soll. Und wer weiss, vielleicht wird es irgendwann notwendig sein deklarativ zu programmieren.
Ich habe bewusst Datenformatsprachen (wie XML, JSON, ...), Hardwarebeschreibungssprachen und CodeGolf-Sprachen weggelassen, weil sie nicht zur Softwareentwicklung dienen.
In [3]:
class Singleton(object):
_instance = None
def __init__(self):
if(Singleton._instance):
raise Exception("Cannot create Singleton Object, there is already an instance!")
Singleton._instance = self
@staticmethod
def get_instance():
if(not Singleton._instance):
return Singleton()
return Singleton._instance
In [4]:
Singleton.get_instance()
Out[4]:
In [5]:
Singleton.get_instance()
Out[5]:
In [6]:
Singleton()