Ich HASSE *insert Sprache here*, aber ich LIEBE *insert another Sprache here*

Was mich ja schon oft mal interessiert hat und was ja auch mal durchaus spannend zu hören ist, ist wie ihr zu eurer "Lieblingssprache" gekommen seit und welche eure "Hasssprache" ist. Jeder hat ja da so seine Vorlieben (auch was IDE's angeht). Mich persönlich würde interessieren wie einige zu ihren Sprachen gefunden haben und warum sie die Sprache so mögen :D

Was mich angeht da wissen sicher einige das ich viel in Java mache und es sich dabei auch um meine Lieblingssprache handelt. Was aber viele nicht wissen ist, dass ich eigentlich Java früher weniger gemocht habe. Erst als ich angefangen habe darüber nachzudenken was ich denn überhaupt mit meinen Programmen machen will bin ich zu Java gekommen. Doch fangen wir mal an wo ich angefangen habe...

Ich bin ja noch recht jung und trotzdem war der Informatikkurs im Abitur darauf ausgelegt Turbo Pascal zu lernen (Rückblickend fand ich das super). Das heißt ich hab mit einer eher "hardware"-nahe Sprache die auch noch prozedural ist angefangen. Ich hab es damals schon geschafft eine Anwendung zu schreiben mit dem man Englisch lernen sollte mit bunter (16 Farben :D) ASCII-GUI die ich selbst gemacht habe. Meine Liebe für das Programmieren wurde geweckt. Ich hab in der Anwendung schon damals kleine Spiele eingebaut und wollte da auch mehr machen. Deswegen habe ich nach dem Abi eine Sprache gesucht mit der ich Spiele machen kann.

Da kam Cherry mit seinen ganzen Patches und erzählte mir er tut das alles in FreeBasic, also dachte ich mir: "Hey, klar warum nicht!" Allerdings gefiel mir die Sprache einfach nicht, ich weiß nicht mehr genau warum muss ich sagen... Dann habe ich gelesen das viele Spiele usw. in C++ gemacht werden also hab ich mir das vorgenommen... Das war keine gute Idee. Ein tiefer Hass für C/C++ wurde geboren! Grund dafür war das doofe Tooling und die die nicht vorhandene Dokumentation. Außerdem hatte ich immer das Gefühl man muss C++ schon sehr gut können um damit auch gute Spiele zu machen (Ich glaube aber dennoch das performancelastige Applikationen eher in C++ als in Java gemacht werden sollten). Aaaaaaalso musste etwas anderes her. Etwas wo ich nicht darauf achten musste wie der Speicher verwaltet wird.

In der Uni traf ich das gezwungenermaßen (zunächst) auf Java. Und da bin ich dann auch hängen geblieben. Ich hab noch viele andere Sachen versucht. z.B. C# was aber der VM nachhinkt und für gute Performance muss ich dann doch wieder Unsafe Code nutzen. Die Gründe warum ich immer bei Java geblieben bin will ich mal kurz erläutern.

Zunächst ist der IDE Support einfach gut. Man kann mir sagen was man will aber mit Eclipse/Netbeans hat man schon 2 verdammt mächtige IDE's. Vor allem das tolle Refactoring und wie einfach man Projekte verwalten kann. Es gibt sicher Hardliner die mit Notepad++ oder vim Java coden, aber das wäre ein Grund nicht Java zu nutzen denn: Java ist verbose, verdammt verbose. Das ist natürlich extrem hinderlich für die Produktivität. Aber dank Eclipse/NetBeans hab ich einfach ne Tastenkombi die mir das anzeigt was ich haben will. Noch viel besser, wähle ich Klassen oder Methoden aus zeigt mir das Ding gleich geparsten Textcode mit Klick-Bunti an und zeigt mir was die Klasse/Methode macht. Einfach super :D Und das gibt es in viele Sprache erst gar nicht. Etwas das mich sehr nervt :/ Ich bin überhaupt nicht der Typ mensch der sich den Inhalt jeder Lib/Klasse/Methode merkt. Ich nutze das Java-Doc gerne. Dank Auto-Completion wurde mein Leben viel einfacher gemacht xD Weiter will ich IDE's nichts sagen. Den Rest wie Projektistorie, auto-build, ants, syntax-highlighting usw. gibt es ja auch in anderen IDE's

Plattformunabhänigigkeit von Haus. Ich bin mir darüber in klaren das es auch andere Sprache auf die das zutrifft (wobei ich aus der Wertung mal Scriptsprachen auslasse). Ich meine damit auch nicht nur Windoof, Mac und Linux. Ich meine damit auch Android, iOS und Konsolen. Mittlerweile gibt es versuche Java Bytecode in C++ zu übersetzen (https://github.com/badlogic/jack). Was wurde schon gut läuft. iOS geht über MonoTouch und IKVM. Aktuell nutze ich ja libgdx und das Ding läuft sogar im Web via WebGL und GWT. Ich finde es toll eine Codebasis zu haben und dann mit einem Klick für die jeweilige Plattform das Spiel zu publishen. Natürlich gibt es schon Abstriche zu die man machen muss, vor allem wenn man an GWT denkt da man viele Sachen emulieren muss. Und von Sound im Web will ich gar nicht erst nachdenken...

Tooling und Support. Ich hab immer das Gefühl, egal was ich brauche, es wurde bereits in Java gemacht. Außerdem ist auch oft alles gut dokumentiert so dass man libs auch versteht und nutzen kann. Diese "eine Metode oder Klasse muss sich selbst erklären"-Einstellung kann ich ja auf den Tod nicht ab :/ Sogar im Web gibt es Java im Form von Java EE. Und das gar nicht mal soooo übel. Mit Vaadin im Schlepptau kann schon einige coole Sachen im Web machen. Und dank der ganzen abgefahrenen Webtechnologien geht das auch noch ohne große Schmerzen. In meinem Praktikum hatte ich viel mit Android zu tun, was ich für ein Paradebeispiel an guter Dokumentation halte (Klar gibt auch Sachen die man da hätten anderes lösen können, ich hab mittels der Doku das programmieren auf dem Android gelernt).

Ich könnte jetzt noch ein paar weitere Gründe nennen, aber ich finde das reicht, man merkt ich steh schon ziemlich auf diese Sprache. Ich bin aber auch durchaus offen für neue Sachen. Erst vor kurzem habe ich Javascript meine Liebe gestanden (danke Lachsen). Tolle Sprache :) Nicht so toll viel Java aber es macht Spaß mit Javascript zu werkeln. Und da es im Web läuft kann man es ziemlich cool debuggen :D

So das wars :) Lasst mal hören wie es bei euch aussieht :D (Aber bitte nicht sagen: "Hallo ich hab vor 10 Jahren auch mal Java angefasst, war langsam" xD)

Zitat:

---

Zitat von R.D.

Ich hab noch viele andere Sachen versucht. z.B. C# was aber der VM nachhinkt und für gute Performance muss ich dann doch wieder Unsafe Code nutzen.

---

Sicher? Meines Wissens nach ist der IL-Compiler ziemlich effektiv und es dürfte keine relevanten Unterschiede in der Performance zwischen Managed und Unmanaged Code geben. Sowieso sollte es eigentlich auch fast nie einen guten Grund geben Unmanaged Code zu schreiben. Falls doch, ist wahrscheinlich C# ohnehin nicht die richtige Sprache für das jeweilige Projekt.

Zum Thema: Ich liebe C# und ich hasse C++. ^^
Und da treffen es die Wörter lieben und hassen wirklich sehr genau.
Ich habe in keiner anderen Sprache so viel Freude am Programmieren wie in C#. Die Sprache ist meiner Ansicht nach syntaktisch wunderschön designed, das .NET-Framework mächtig und einfach zu benutzen und Visual Studio eine großartige IDE.
Und C++ ist irgendwie für mich der Inbegriff dessen, was man beim Design einer Sprache alles falsch machen kann. :%

Ich fühle mich immer so alleine, aber ich liebe c++. Ernsthaft hassen tu ich keine andere Sprache, aber meistens hab ich das Gefühl das ich das, was ich machen will, besser in c++ hinbekomme, wohl einfach aus Gewohnheit ( Okay, web Anwendungen würde ich dann wohl doch eher mit Java und co anfertigen ... ).
Als ich damals mit Visual basic angefangen hatte war ich froh irgendwann mal einer rein textuelle Sprache ( ich hatte viel mit dem früheren Oberflächenprogrammierung im Visual studio rumhantiert) wie c++ zu lernen. Ich bin ehrlich, viel informiert hatte ich mich damals nicht. Ich hab nach Aussagen gesucht, welche Sprache sich am besten für Spiele eignen würde und hab wohl bei der erstbesten google Anfrage gefunden, dass die meisten Spiele eben mit c++ erstellt werden, so bin ich da gelandet wo ich heute bin.
Die Sprache die ich am wenigstens gerne benutze ( von denen, die ich kenne versteht sich ) ist aber dennoch Java. Einfach aus dem simplen grund, dass ich das strikte OOP Modell der sprache nicht mag. Sicher mag ich oop und es ist auch in c++ das Paradigma das ich am häufigsten verwende, aber ich habe dennoch gerne die möglichkeit - die ich auch nach wie vor nutze! - das zu ändern und einen Ausflug in andere Richtungen zu unternehmen.

Vorneweg, ich programmiere großteils alleine und in meiner Freizeit. So richtig "professionell" programmieren kann man das eher nicht nennen, was ich gelegentlich mal zusammenschustere^^

Bzgl. Sprachen: Ich hasse einfach C und C++, aus mehreren Gründen: Schonmal die Speicherverwaltung ansich, die man ggf. selbst zusammenprogrammieren muss, wenn man nicht gerade Megabyte-großen Speicher als Arrays ablegen kann (seit ich damit in meiner Ausbildung konfrontriert wurde, hege ich eine tiefe Abscheu vor Pointer). Außerdem mag ich die Syntax nicht, einerseits wegen der Benachteiligung von Non-US-Keyboardusern (Klammern, Strichpunkte), andererseits wegen der teils seltsam benannten Funktionen ansich, an denen man durch den Namen überhaupt nicht erkennen kann, was genannte Funktion tut. Man merkt deutlich, dass bei der Entstehung von C nicht die leichte Erlernbarkeit im Vordergrund stand, was wohl dem Alter geschuldet ist... Die Syntax kann man ziemlich stark verhunzen...

"Lieben" tue ich eigentlich Python, weil es dem Entwickler beim Lernen und Debuggen sehr entgegenkommt. Vom Komfort her ist es quasi das genaue Gegenteil von C/C++ , und die Standardbibliothek deckt sehr viele Funktionen ab. Die vordefinierten Datentypen (v.a. Lists, Tuples, Dicts) mitsamt deren Methoden zur Manipulation erleichtert die Arbeit eines Programmierer schon erheblich...

Als IDE nutze ich SPE (Stani's Python Editor), das zumindest meine Bedürfnisse vollkommen erfüllt^^. Eclipse ist ansich auch eine schöne IDE mit Pydev, aber da ich primär alleine programmiere, brauche ich den Großteil der Funktionen einfach nicht...

Ich liebe Java, einfach wegen der hohen Verbreitung und weil es so gut wie überall läuft (was aber auch zwischendurch einem auf die Füße fällt). Kennen und schätzen gelernt habe Java in der Uni. Mit Eclipse rockt Java-Programmieren richtig.

Für C und C++ habe ich wenig viel zu haben. Ich hasse die beiden zwar nicht, arbeite aber sehr ungern mit - wegen der fehlenden Speicherverwaltung und grauseligen Syntax.
C# mag ich wegen der schlechten Unterstützung für Linux und MacOSX nicht, hat aber einen guten Syntax.

Hassen tue ich Funktionale Programmiersprachen, besonders die, die sich OPAL nennt, und (wenn es zählt) verschiedene Assembler-Sprachen. Wurde damit genug in der Uni gequält.

In der Schule hatte ich mit Delphi zu tun. Im Nachhinein betrachtet, konnte ich mich damit nicht wirklich anfreunden.

Vor dem Studium kam dann für eine kurze Weile freizeittechnisch noch C hinzu, allerdings kann ich da nicht allzu viel sagen, weil ich mich nicht allzu sehr mit den tieferen Sachen beschäftigt hatte.

Die ersten Semester hab ich dann mit C# zutun gehabt, allerdings bin ich mit der Sprache nie warm geworden. Seit ich Linux benutze ist es nur schlimmer geworden, einfach nur, weil mono leider noch keine vollständige Unterstützung dafür bietet und es sich gar nicht lohnt (mMn), C#-Programme auf und für Linux zu entwickeln.

Ich bin dann noch während des Studiums schnellstens auf C++ gewechselt. Ich mag C++ und kam damit auf jeden Fall besser klar als mit C# (selbst ohne Speicherverwaltung, liegt vielleicht auch daran, dass ich lieber gründlich bin, wozu auch das manuelle freigeben des Speichers gehört xD)

Gegenüber Java hatte ich ja anfangs einige Vorurteile, hab mich dann aber zwecks Praktikum damit beschäftigen müssen und so einiges an Erfahrung damit gewonnen, mehr als C++, weshalb ich dann doch lieber Java zum Programmieren nehme ^^

kurz gesagt: Java > C++ > C > C#, Delphi

Außerdem gibts da noch Haskell, allerdings außer Wertung, weil ich es nur für mathematischen Kram benutze.

Ich hab folgende Sprachen in folgender Reihenfolge gelernt.

• C
• C++
• C#
• Java

Mittlerweile arbeite ich im Job und privat soweit es geht mit C#. Die Sprache ist einfach schön, sauber, einfach und logisch. Visual Studio ist auch eine tolle IDE.

C++ benutze ich gelegentlich wegen DynRPG und einem beruflichen Projekt. C++ ist eigentlich keine schlechte Sprache, aber damit arbeiten ist trotzdem irgendwie scheisse.
Wäre ich nicht gezwungen C++ in den beiden Fällen zu benutzen würde ich es nicht tun.
Gäbe es keine schöneren Sprachen könnte ich mit C++ sicherlich gut leben, aber wieso sollte ich mir das Leben unnötig schwer machen?

Mit Java hatte ich viel Spass ist von der Syntax her fast C#~ Dass ich trotzdem C# nutze liegt dran, dass ich es beruflich muss und C# subjektiv ein bischen besser finde.

Cooles Thema.
Seit ich mit dem Programmieren angefangen habe (da war ich bereits 16 ^^"), habe ich mit einer Reihe von Sprachen gearbeitet, einige wieder schnell vergessen (SML, Lisp, Pascal...)
Mit folgenden Sprachen habe ich mehr Erfahrung gesammelt (insofern, dass ich mit jeder dieser Sprache mal eine größere Anwendung geschrieben habe) und könnte auch noch heute damit arbeiten:

• Java
• C/C++
• PHP
• JavaScript
• Ruby

Und ehrlich gesagt, hasse ich keine Sprache wirklich. Jede Sprache hat irgendwie seine Vorzüge und Nachteile

Java ist sehr einfach mit zu arbeiten, hat super IDE Support, ist Plattform unabhängig, aber hat imho eine zu globige und umständlich Syntax in vielen Fällen (strongly typed). Ich habe längere Zeit GUI Entwicklung mit Java + Swing gemacht und es ist echt nicht witzig, was für eine Masse an Klassen man schreiben muss, um dort alles "ordentlich" zu machen.

C/C++ ist schwer rein zu kommen und auch generell kompliziert zu handhaben, aber auch sehr mächtig (multiple inheritance, operator Überladung). So sehr wie ich diese Sprache anfangs gehasst habe, mittlerweile habe ich auch Programme damit geschrieben, die echt gut liefen und vom Code her recht gut aussahen... Relativ...

PHP ist super einfach zu installieren und zu verwenden und macht das, wofür es gedacht ist, immer möglichst einfach und schmerzfrei. Sehr einsteiger freundlich. Außerdem das hässlichste Sprachdesign das man sich vorstellen kann.

JavaScript ist unglaublich minimalistisch und dennoch erstaunlich mächtig. Man kann sehr kompakten Code schreiben und auf modernen Browsern läuft er auch noch erstaunlich schnell für eine Script-Sprache. Die Entwicklungsumgebung, die mit den meisten modernen Browsern kommt, ist bereits extrem ausgereift (mit Code Editor, Debugging, Life Code Update usw.). Dann wiederum ist die Sprache sehr, sehr locker und "versatile". Man kann wirklich alles ändern, wodurch sehr schnell Chaos entstehen kann. Sicherlich nichts für Kontrollfreaks und schwerer für große Projekte. ^^" Darüber hinaus ist es etwas schwer, richtig in die Sprache rein zu kommen, da es im Kern mehr eine Funktionale Sprache ist und nicht wirklich Objekt Orientiert.

Ruby hat imho die schönste Syntax, die ich je in einer Programmiersprache gesehen habe. Allein schon, wie man Code-Blöcke an Funktionsaufrufen dranhängt usw. Leider macht bei mir Ruby generell Probleme unter Windows (speziell bei Ruby on Rails - Runtime stürzt ab, Gems brauch ewig um Komponenten zu laden usw.), was mich bisher noch davon abhielt, mich weiterhin mit der Sprache zu befassen (habe also nur die Erfahrung vom Praktikum von einem halben Jahr).

Generell muss ich sagen, dass ich lieber mit dynamischen Script Sprachen (Ruby, JavaScript, vielleicht noch PHP), arbeite als streng getypten Sprachen (C++, Java), weil ich auch immer gut ohne Typ Kontrollen auskam (Meine Anfänge kamen immerhin aus der Anarchie des RPG-Maker "Assemblers") und generell lieber weniger schreibe als mehr.

Im Moment ist bei mir JavaScript recht weit vorne auf der Rangliste. ^^
JavaScript ist toll.

Nice ein Thema über Programmiersprachen :)

Wo fangen wir da mal an.

Also meine Sprachen die ich auch gerne nutze sind:

C
C++
Ruby
Java
PHP


Fangen wir mal bei C++ an, diese Sprachen benutze ich seit meinem Studienanfang und seitdem gefällt Sie mir am besten von allen.
Das ich meine Speicherverwaltung selber tätigen muss, macht mir nix aus.
Ich weiss nicht ob vllt einer der wenige bin, aber ich mag Pointer einfach, man kann sovieles damit machen, das ich bei Java vermisse. :/
C++ wird auch noch mächtiger wenn man die Boostlib hinzunimmt, man hat soviele schöne Dinge in die Lib gesteckt. :)
Freue mich das einige Sachen ins neue c++x11 übernommen wurden.


Zu C kann ich nur sagen das ich es im Embeddedbereich für ARM-boards benutzen musste und fand es sehr gut, nur konnte ich es im privaten Bereich noch net sehr ausleben (hoffe mein Raspberry Pi kommt bald :D )


Kommen wir mal endlich zu Java, ich weiss nicht aber irgendwie gefällt mir der Aufbau der Sprache nicht.
Dem Kommentar vom Lachsen wegen Java&Swing kann ich nur bewohnen.
Finde es halt gut das es Plattformunabhängig ist und viele Funktionen von Haus aus,aber ich weiss nicht, es ist und wird irgendwie nie eine meiner wirklichen Lieblingssprachen werden.


Als ich Ruby lernte war es Anfangs komisch wie alles gehandhabt wird, aber man gewöhnt sich daran und findet es Klasse wie es umgestzt wurde.
Diese Sprache benutze ich für kleine Programme weil es viel Spass macht damit zu programmieren :)

@Lachsen: Benutze lieber ein Linuxsystem für Ruby, die Windowsportierung ist wirklich so lahm, als im Studium im Team damit programmierten, mussten wir immer auf die Windows Leute warten,
weil es ne halbe Ewigkeit dauerte bis bei dennen alles gestartet hatte das war was ....

Der Thread ist zwar schon etwas älter, aber ich bin heute mal zufällig drauf gestoßen und möchte auch meinen Senf dazugeben, da ich das Thema doch sehr interessant finde. Ich werde mich dabei mal auf drei Programmiersprachen konzentrieren: Eine, die ich hasse, eine, die ich mag und eine, die ich liebe.


Sprache, die ich hasse: C/C++

OH GOTT! Ich weiß gar nicht, wo ich anfangen soll. Noch nie hat mir irgendeine technische Sache so viel Kopfzerbrechen bereitet, wie C bzw. C++. Es gibt so vieles, was ich daran hasse, dass ich nichtmal einen Text darüber schreiben will, sondern lieber einfach eine Liste nehme:

• Fangen wir erstmal bei dem an, was schon des öfteren genannt wurde: Die Speicherverwaltung. Eigentlich ist fehlende Speicherverwaltung durchaus etwas, womit ich leben kann, da meine erste Programmiersprache Pascal war und ich eigentlich schon daran gewöhnt bin, mich selbst darum zu kümmern. Das Problem ist nur, dass das in C/C++ so fucking kompliziert ist und darüber hinaus auch noch jeder blöde Scheiß es erfordert. Am schlimmsten empfand ich hier strings (also ich meien damit char*, weil mit cstrings habe ich nie wirklich gearbeitet). Die Teile sind sowas von unflexibel und es ist quasi unmöglich, damit irgendwelche komplizierteren Operationen durchzuführen, ohne die ganze Zeit Speicher zu reservieren und wieder freizugeben. Und selbst die String-Funktionen aus den Standard-Libraries sind größtenteils eher mittelmäßig und helfen nicht so wirklich weiter.
• Ein weiterer Kritikpunkt - und vielleicht mein größter - ist die hässliche Syntax. Mal ehrlich: Wenn man jedes mal, wenn man einen Funktionspointer deklarieren will, erst nochmal auf Google nachgucken muss, wie das funktioniert, dann hat eine Programmiersprache eindeutig etwas falsch gemacht. Obwohl ich schon des öfteren Funktionspointer gebraucht habe, weiß ich selbst heute noch nicht aus dem Kopf, wie die funktionieren. Überhaupt ist die Pointer-Syntax in C/C++ eher suboptimal. Man weiß nie so recht, wozu das Reference-Zeichen gerade gehört (z.B. bei so Fällen wie "const* char" vs "const char*") und wenn man structs oder classes hat, die selbst wiederum Pointer enthalten, kommt man irgendwann gar nicht mehr drumherum, tausend Klammern in seinem Code zu verwenden. Da hat es Pascal doch wesentlich besser gemacht. Tatsächlich musste der Dereferencer dafür einfach nur auf die andere Seite gepackt werden. Jedenfalls sind sämtliche Arten von Pointern (also auch Funktionspointer) in Pascal leichter zu deklarieren und zu nutzen.
  
  Auch hässlich finde ich die Syntax von Type-Casts. Mittlerweile habe ich mich durch C# zwar schon an deren Nutzung gewöhnt, aber zumindest am Anfang musste ich immer Umdenken, als ich sie benutzt habe. Ich war es nunmal von Funktionen gewöhnt, dass immer erst der Funktionsname und dann in Klammern die Paramater kommen, also z.B. "Function(a)". Bei Type-Casts musste das aber natürlich genau umgedreht werden in "(int)a". Das sieht nicht nur hässlich aus und macht den Source Code noch unübersichtlicher, als er eh schon ist, es ist auch noch absolut un-inovativ. Naja, wenigstens hat C++ es später dann ermöglicht, die Type-Casts tatsächlich in Funktionsform (also "int(a)") zu verwenden. Schade, dass C# das dann wieder rausgenommen hat.
• Weiterhin mag ich an C++ nicht die Header-Files. Was soll deren Nutzen sein? Die erfordern es nur, dass ich alles zweimal schreiben muss. Wenn ich aber mal einen kleinen Forward vergessen oder eine Deklaration an die falsche Stelle packe, spackt der Compiler sofort wieder rum und nichts funktioniert. Absolut unspaßig!
• Auch recht kompliziert in C/C++ (auch, wenn das wohl teilweise an den IDEs liegen mag) ist das Einbinden von Libraries. Insbesondere dann, wenn man diese vorher auch noch selbst kompilieren muss. Das liegt vielleicht auch daran, dass es einfach so viele Arten von Libraries gibt und dann auch noch so viele Arten, diese einzubinden. Für mich entscheidend sind eigentlich nur dynamische und statische Einbindung. Aber wie viele Versuche es mir alleine hier immer wieder abverlangt, beispielsweise die MinGW-Libraries statisch in mein Programm einzubinden, damit ich einem Freund ein Programm schicken kann oder so. Es ist immer wieder das gleiche: Für das Einbinden der Libraries muss ich mich nach irgendwelchen Anleitungen richten, weil ich es von selbst nicht hinbekomme, und dann, sobald ich einem Freund das Programm schicke, funktioniert da wieder nichts, weil irgendwelche Libraries fehlen, sodass ich dann erstmal wieder suchen muss, wohl der Fehler liegt. Bullshit!
• Was mir an C++ auch nicht gefällt ist dass es bisher einfach noch keine so wirklich richtig gute IDE dafür gibt. Gut, bisher habe ich nur mit zwei IDEs wirklich viel gearbeitet, nämlich Code::Blocks und Visual Studio. Beide hatten aber größere Defizite und es hat keinen Spaß gemacht, mit ihnen zu arbeiten. Visual Studio ist für C# eigentlich eine grandiose IDE, für C++ ist das aber einfach nur ein verbuggter Haufen Scheiße, der lieber eigene Regeln erfindet anstatt sich an irgendwelche C++-Standards zu halten. Code::Blocks hat da (zumindest meiner Erfahrung nach) wesentlich weniger Bugs und ist dazu noch plattformunabhängig, hat dafür aber auch bei weitem nicht denselben Funktionsumfang. Ich meine mich beispielsweise zu erinnern, dass Debugging in Code::Blocks immer eine recht unangenehme Angelegenheit war und nicht einmal funktioniert hat, wenn man im Pfad zum Projekt irgendwo ein Leerzeichen hatte. Dann wurden selbst Breakpoints einfach übersprungen. Insgesamt ziehe ich Code::Blocks aber trotzdem Visual Studio vor.
• Unicode-Support. Ich kann es einfach nicht verstehen, dass es selbst zu Zeiten des Internets immer noch so kompliziert ist, ordentlichen Unicode-Support in C++ zu bekommen. Ohne externe Libraries geht da einfach gar nichts. Die paar Funktionen, die in den Standard-Libraries drin sind, unterstützen erstens fast immer nur UTF16 und decken zweitens auch nur Code Points bis FFFF ab. In Zeiten der Internationalität geht sowas einfach gar nicht. Oh, und habe ich schon die Bugs in Visual Studio erwähnt? Visual Studio kann nur Resource Files im UTF16-Format kompilieren. Bei anderen Formaten kommt es zu unsinnigen Fehlermeldungen. Selbst dann, wenn der eigentliche Source Code in UTF8 oder ASCII geschrieben ist. Das ist natürlich besonders praktisch, wenn man, weil man nur die kostenlose Version von Visual Studio benutzt, einen externen Resource Editor benutzt, der natürlich davon ausgeht, dass Source Code und Resource Files bei eurem Projekt im selben Format gespeichert sein sollen und die Resource Files dann automatisch als UTF8 abspeichert, bloß weil euer Source Code in UTF8 gespeichert ist. Das heißt ihr schreibt eure Resource Files entweder direkt manuell in Textform oder ihr müsst jedes mal ihr Format konvertieren, wenn ihr den Resource Editor verwendet habt.

Sprache, die ich mag: Free Pascal

Ähnlich wie R.D. kam ich beim Abitur erstmalig mit Pascal in Berührung. Es war meine erste richtige Programmiersprache, in der ich auch größere und kompliziertere Programme (einschließlich eines Tetris-Klons) geschrieben habe. Was Funktionalität angeht hat Pascal gegenüber C++ eigentlich keine all zu großen Vorteile. Eher sogar ein paar Nachteile. Die Sprachen sind von der Funktionalität her ungefähr auf einem Level. Pascal punktet gegenüber C++ aber definitiv in Sachen Benutzerfreundlichkeit. Die Syntax ist stets sauber und nachvollziehbar und man kann selbst nach mehreren Jahren noch problemlos mit Pascal arbeiten, ohne vorher erstmal ein paar Stunden zu googlen, wie man nochmal X/Y deklariert. Vor allen Dingen die Pointer-Arithmetik ist in Pascal sehr viel sauberer, unkomplizierter und verständlicher, als in C++. Um mal ein Beispiel anzubringen:

Pascal-Version:

Code:

---

DreifachPointerInt^^^ = 0;
StructPointer1^.StructPointer2^.StructPointer3^.VariableInt = 0;

---

In C++ sähe das ganze ungefähr so aus:

Code:

---

*(*(*DreifachPointerInt)) = 0;
(*StructPointer1).(*StructPointer2).(*StructPointer3).VariableInt = 0;

Oder Alternativ bei Structs und Classes:
StructPointer1->StructPointer2->StructPointer3->VariableInt = 0;

---

Gut. Ich weiß nicht genau, ob die Klammern im ersten Fall wirklich notwendig sind, trotzdem finde ich die Syntax in Pascal sauberer und nachvollziehbarer.

Weiterhin sind in Pascal String-Operationen sehr viel unkomplizierter, als in C. Gut, die unterstützen zwar in der Basis-Version dafür auch nur bis zu 255 Zeichen, dafür muss man sich aber nicht um die Speicherverwaltung kümmern und kann nach Belieben Strings addieren, Strings abschneiden, die Länge von Strings ermitteln, Strings durchsuchen etc.

Und das ganze ist ja nur die Basis-Version von Pascal. Free Pascal ist ja die moderne Variante davon, die konstant weiterentwickelt wird und auch tatsächlich mit modernen Funktionen aufwartet wie Klassen, modernen Datentypen und nativem UTF8-Support. Besonders die neuen String-Typen AnsiString und UTF8String sind eine sinnvolle Weiterentwicklung der Sprache. Sie funktionieren genauso, wie die Strings in der Basis-Version (das heißt man kann genauso problemlos und leicht mit ihnen arbeiten), nutzen aber intern Pointer, sodass sie beliebig lang sein können. Und darüber hinaus gibt es mit lazarus auch noch eine recht gute IDE, die Free Pascal unterstützt.

An und für sich würde ich Free Pascal in lazarus jederzeit C/C++ in Visual Studio oder Code::Blocks vorziehen. Einziges Problem: Das benutzt einfach kein Schwein mehr. Deshalb gibt es für Free Pascal auch kaum gute Ressourcen im Internet, besonders keine guten Libraries. Für meinen Tetris-Klon musste ich beispielsweise die die schon recht veraltete Version 4.2 von Allegro nutzen. Selbst jetzt ist die aktuellste Pascal-Version von Allegro Version 4.4. Für C++ hingegen ist schon seit langer Zeit die deutlich leistungsfähigere und überlegene Version 5 draußen. Das war auch letzten Endes der Grund, weshalb ich mich dafür entschieden habe, C++ zu lernen. Mein Herz hängt allerdings noch sehr an Free Pascal.


Sprache, die ich liebe: C#

Was soll ich dazu noch sagen? Wenn C++ ein Kuchen wäre, dann wäre C# derselbe Kuchen, bloß dass man ausnahmslos alle schlechten Stellen abgeschnitten und den Kuchen anschließend mit Schokolade und Sahne ummantelt hätte. Anders ausgedrückt: C# basiert auf C++, verzichtet aber auf jeglichen Scheiß, der unnötig ist und Programmierer nur frustriert und hat dafür unzählige neue Funktionen. Saubere Syntax, hohe Benutzerfreundlichkeit automatische Speicherverwaltung, keine blöden Header-Files (unter außer ein paar Using-Direktiven auch sonst nichts, was in diese Richtung geht und alles übermäßig verkompliziert), leichte Einbindung von Libraries, sehr flexibles und innovatives Klassen-System, das .NET-Framework, keine Pointer mehr (außer man braucht sie unbedingt), nativer UTF8-Support und nicht zuletzt eine der leistungsfähigsten und besten IDEs überhaupt. Ich denke ich lehne mich nicht zu weit aus dem Fenster, wenn ich behaupte, dass C# so ziemlich das beste ist, was Microsoft jemals geschaffen hat; zumindest für einen Programmierer. Das ist einfach eine Programmiersprache, in der Programmieren Spaß macht und bei der höchstens 5% des Programmierfrusts von der Sprache selbst verursacht werden, während das bei C++ so um die 75% sind.


TL;DR
C++: FFFFFFFFFFUUUUUUUUUUU...
Free Pascal: Me gusta!
C#: BOAH, GEIL!

Das ist mir jetzt irgendwie peinlich, aber genau einen Tag nach meinem Post muss ich meine Aussage bezüglich C# schon revidieren. Just gestern Abend ist C# nämlich extrem in meiner Gunst gefallen. Es stimmt zwar immer noch alles, was ich da oben gesagt habe, allerdings hat C# ein großes Problem: Den Garbage Collector. Das mag jetzt widersprüchlich klingen, denn erst gestern habe ich gerade den noch implizit gelobt. Eigentlich ist die Idee des Garbage Collectors auch eine recht clevere Sache. Das Problem ist nur, dass der Garbage Collector das absolute Todesurteil für jede komplexere Anwendung ist, die viel Speicher verwendet. Zum Beispiel ein Spiel. Und natürlich fällt mir das erst gestern Abend, als sich unser Semesterprojekt schon langsam dem Alpha-Status nähert, zum allerersten mal auf. Toll! Jetzt haben wir hier ein fast feature-komplettes Spiel in das sehr viel Zeit und Mühe investiert wurde, aber wenn zu viele Bullets verschießt, fängt das Spiel plötzlich bis zur Unspielbarkeit an zu laggen und es gibt so rein gar nichts, was wir dagegen unternehmen können. Ich habe schon alle Möglichkeiten des Garbage Collectors durchprobiert. Unser erstes Level ist nur dann bis zum Ende durchspielbar (und mit Ende meine ich nur das aktuelle Ende, ca. drei Minuten Spielzeit, es war noch mehr geplant), wenn man darin echt sparsam mit seinen Waffen umgeht und möglichst nur schießt, wenn auch Gegner in der Schusslinie sind. Damit ist mein Urteil gefallen: So sehr ich C# als Sprache auch mag, für Spiele werde ich es definitiv nie wieder einsetzen.

Zitat:

---

Zitat von RPG Hacker

So sehr ich C# als Sprache auch mag, für Spiele werde ich es definitiv nie wieder einsetzen.

---

Unity ^.^

Und gefühlte zwei Minuten später muss ich auch die Aussage wieder revidieren. Es war gar nicht der Garbage Collector, der den Slowdown verursacht hat, sondern ich hatte nur aus Versehen vergessen, nach rechts fliegende Projektile zu despawnen, nachdem sie den Bildschirm verlassen. Das hat meine Kollisionsabfrage gesprengt.

Peinlich! ^^"
Jetzt komme ich mir echt, wie so ein n00b vor! Und C# bin ich jetzt wohl eine Entschuldigung schuldig. Tut mir Leid, C#! Du bist immer noch meine Lieblings-Programmiersprache!

@RPG Hacker:
Als ich deinen Meckerpost gelesen hab war ich schon voll drauf eingestimmt dir die Ohren langzuziehen ;-)

Der Trick mit dem GarbageCollector in Anwendungen in denen man sich GC-Lags nicht erlauben kann ist einfach: den GC erzwingen.
Ich mache das in meinen Industrieprogrammen hier alle 40 Millisekunden. Ein GC-Aufruf dauert dann eine halbe Millisekunde ( die Software dient dem Zweck Daten aufzunehmen, zu verarbeiten und wegzuschmeissen, es passiert also auch was ).

Irgendwo solltest du eine Art Gameloop haben, pack den GC.Collect(); ans Ende.

Btw. Wenn du JIT-Kompilierung "vorwegnehmen" willst:
http://www.codeproject.com/Articles/...-the-fly-or-tr
Kann auch hilfreich sein wenn man sein Timing besser im Griff haben möchte.

Zitat:

---

Zitat von Corti

Der Trick mit dem GarbageCollector in Anwendungen in denen man sich GC-Lags nicht erlauben kann ist einfach: den GC erzwingen.
Ich mache das in meinen Industrieprogrammen hier alle 40 Millisekunden. Ein GC-Aufruf dauert dann eine halbe Millisekunde ( die Software dient dem Zweck Daten aufzunehmen, zu verarbeiten und wegzuschmeissen, es passiert also auch was ).

---

Ich kann mir allerdings vorstellen, dass es spätestens bei 60 FPS trotzdem auffällt und die Anwendung verlangsamt oder Input-Lag erzeugt. Besonders, wenn man auch noch Physik-Berechnungen oder so drin hat.

Zitat:

---

Zitat von Corti

Irgendwo solltest du eine Art Gameloop haben, pack den GC.Collect(); ans Ende.

---

Bringt das denn auch was? Irgendwo im Internet habe ich gelesen, dass GC.Collect() keine wirkliche Garbage Collection garantiert, sondern nur, dass der Garbage Collector bestimmte organisationstechnische Tasks erledigt, die mit Gabage Collection im Zusammenhang stehen.

Mittlerweile wird GC.Collect() bei mir aber aufgerufen, sobald das Level beendet wird. Vorausgesetzt das Level funktioniert auch weiterhin ohne Slowdowns, dann sollte das auf jeden Fall ausreichen, da eventuelle, bemerkbare Slowdowns dann eh während eines Blackscreens auftreten würden und das nächste Level dann wieder genug RAM zur Verfügung hätte.

Zitat:

---

Zitat von Corti

Btw. Wenn du JIT-Kompilierung "vorwegnehmen" willst

---

Interessant. Ich nehme an das bringt mir eine geringe Performance-Verbesserung?

Zitat:

---

Zitat von RPG Hacker

Ich kann mir allerdings vorstellen, dass es spätestens bei 60 FPS trotzdem auffällt und die Anwendung verlangsamt oder Input-Lag erzeugt. Besonders, wenn man auch noch Physik-Berechnungen oder so drin hat.

---

Naja, wir leben ja nicht mehr in Zeiten, wo alles nur sequenziell abgearbeitet wird. Es laufen dort ja nebenbei Threads, die sich die Arbeit aufteilen. Ab C# 5.0 gibt es ja auch noch parallele Verarbeitungen. Dabei muss der Entwickler sich nicht mehr um jeden Thread selbst kümmern, sondern er regelt primär die Aufgabenverteilung. Die Erstellung der Threads geschieht dann zur Laufzeit automatisch. Hierbei wird dann auch automatisch entschieden, wie viele Threads gestartet werden sollen. Befindet sich ein Dualcore-CPU im Einsatz, werden zwei Threads gestartet. Bei einem Quadcore-CPU vier Threads, etc. Das kann erhebliche Vorteile bringen, aber auch Nachteile, wenn die ausführenden Aktionen nicht komplex genug sind und mehr Zeit beim Erstellen und Löschen der Threads verbraten wird.

GC.Collect() sollte man aber auch nur aufrufen, wenn man gute Gründe dafür hat. Es bringt nicht viel, ihn jedes Mal anzuschmeißen, da auch das wegschmeißen von Objekten nicht kostenlos ist, auch wenn viele das Gegenteil behaupten. Soll heißen: Der Prozessor braucht auch hier eine gewisse Rechenzeit. Wenn man den GC zu oft aufruft, kann es schon deutlich die Performance mindern. Es macht keinen Sinn, den GC anzuschmeißen, wenn nur eine Hand voll Objekte gelöscht werden sollen. Daher sollte man schon Performace-Tests durchführen, ob es wirklich was bringt.

In der Firma, wo ich arbeite, hantieren wir mit Millionen von Objekten rum (eine Software für Banken), und wir rufen lediglich nur ein einziges Mal den GC auf, wenn die Anwendung mit einer vorerst nicht wiederkehrenden Berechnung fertig ist. In diesem Zusammenhang empfehle ich mal eine Stack Overflow Foren-Diskussion: http://stackoverflow.com/questions/4...all-gc-collect

Zitat:

---

Ich nehme an das bringt mir eine geringe Performance-Verbesserung?

---

Njein. JIT passiert sonst beim ersten Aufruf. Der erste Aufruf sollte also geringfügist schneller gehen. Erwarte keine Wunder und nix was du siehst und fühlst wenn du nicht grade Millisekunden mit Nachkommastelle misst.

Zitat:

---

Ich kann mir allerdings vorstellen, dass es spätestens bei 60 FPS trotzdem auffällt und die Anwendung verlangsamt oder Input-Lag erzeugt. Besonders, wenn man auch noch Physik-Berechnungen oder so drin hat.

---

Was Programmierst du? Crysis3 in einem Single-Threaded Gameloop? Bei anspruchsvollen Anwendungen muss man sich sowieso überlegen, wie man die gesamte Leistung des Rechners abruft, nicht alle Operationen müssen in jedem Takt einmal gemacht werden etc. die Halbe/Millisekunde ist kein Performancekiller. GarbageCollection als großer böser, fieser Performancekiller ist ein Mythos damit Menschen ohne technischen Sachverstand besser "C++ VS C#/Java" diskutieren können ;-)

@Whiz-zarD:

Zitat:

---

GC.Collect() sollte man aber auch nur aufrufen, wenn man gute Gründe dafür hat.

---

Ich hab bisher keine Anwendung entwickelt, bei der "falsche" GC-Aufrufe irgendeine Konsequenz gehabt hätten. Ich kann mir aber vorstellen, dass man deine Bankensoftware lieber machen lassen sollte. Benutzt ihr da eigentlich schon .NET 4.5 und diese Features für paralleleles GC-Collecten? Wie häufig kommt bei euch denn automatisches GC vor?

Die Zeit zum Wegschmeissen von Objekten ist nicht das Problem bei zyklischen GC Aufrufen. Wenn man keine großen Lags durch GC haben möchte lohnt es sich öfter mal kleine Mengen Daten zu entsorgen statt einmal eine große Menge. Problematischer ist eher, dass GC auch wenn nichts zu sammeln ist eine gewisse Zeit braucht um zu prüfen ob was wegwerfwürdig ist, diese Zeit bewegt sich aber im Bereich halbe Millisekunden bis Millisekunde, also durchaus etwas, dass man in einem Gameloop mal unterbringen kann ohne, dass die Performance so kaputt geht, dass man sich denkt "Gott hätte ich lieber C++ genommen".

Zitat:

---

Zitat von Corti

Benutzt ihr da eigentlich schon .NET 4.5 und diese Features für paralleleles GC-Collecten? Wie häufig kommt bei euch denn automatisches GC vor?

---

Leider nein. Wir dümpeln noch bei .NET 2.0 rum, weil wir auf die Kunden achten müssen und viele Kunden reagieren bei Updates mit Panik.
Das ist echt schlimm. Das hat zur Folge, dass wir ungefähr 15 Release-Zweige pflegen müssen, weil Kunden Angst haben z.B. von einer Version 3.19 auf eine 3.20 zu wechseln, also müssen wir dann dort eine 3.19.100 eröffnen.
Naja, das sind halt Banken. Bei denen gilt: "Don't touch a running system!". Da kann es schon mal vorkommen, dass eine Software über 30 Jahre ihren Dienst verrichten, ehe sie gegen eine neue Ausgetauscht wird.

Den GC rufen wir nur noch ein mal auf, wenn er eine komplexe Berechnung erledigt hat. Solche Berechnungen können mehrere Stunden dauern und Millionen von Geschäftsobjekten erzeugen.

Hrm~ ^^"" Mein Beileid. Stell ich mir sehr ärgerlich vor, ich möchte die schönen neuen Asynchron- und Parallelfunktionen etc. nicht missen wollen.

Ich kann aber leider auch nicht weiter als 4.0 weil die Maschinenrechner alle XP haben und 4.5 gibts dafür nicht.

Ich habe völlig vergessen zu erwähnen, dass ich mit Turbo Pascal 5 (oder war es schon Turbo Pascal 6? naja das war 100% noch DOS mit dem schönen Runtime error 200) das erste mal mit einer Programmiersprache in der der Schule in Kontakt gekommen bin, das war aber erst 2007, wo Turbo Pascal eigentlich schon klinisch tot war.

Allerdings habe ich Pascal nie so gemocht. Das man die Funktionen/Prozeduren nicht einfach irgendwo im Quelltext packen konnte sondern er nur in Reihenfolge, hat mich angekotzt.

Ob man nun den Klammer-Affen wie bei C, Java usw. spielen muss oder nun "begin", "end" usw. als benannte Klammern hat, das ist mir recht egal.
Zur Not kann ich in C z.B. den Präprozessor nehmen und einfach oben "begin", "end" usw. als "{" und "}" deklarieren. Jeder C-Programmierer würde mich dafür erschießen, aber es ist möglich ohne das Kompilat zu verändern.

Zitat:

---

Zitat von Whiz-zarD

Leider nein. Wir dümpeln noch bei .NET 2.0 rum, weil wir auf die Kunden achten müssen und viele Kunden reagieren bei Updates mit Panik.
Das ist echt schlimm. Das hat zur Folge, dass wir ungefähr 15 Release-Zweige pflegen müssen, weil Kunden Angst haben z.B. von einer Version 3.19 auf eine 3.20 zu wechseln, also müssen wir dann dort eine 3.19.100 eröffnen.
Naja, das sind halt Banken. Bei denen gilt: "Don't touch a running system!". Da kann es schon mal vorkommen, dass eine Software über 30 Jahre ihren Dienst verrichten, ehe sie gegen eine neue Ausgetauscht wird.

---

Bei denen läuft bestimmt noch Windows 2000. Das baut doch echt Vertrauen auf, da es ja selbst für Windows 2000 keinen Extended Support mehr gibt.
Da funktionieren wahrscheinlich die ganzen Exploits der letztem 3 Jahre noch, auch wenn das ein super-abgeschottetes-System-mit-Internet-Anschluss ist.
Zumindest arbeiten ja deine Kunden anscheinend nicht mehr mit einem uralten Unix, dass ja das Jahr-2038-Problem bestimmt noch hatte.
Wenn auch schon ein kleiner Versionssprung von 3.19 auf eine 3.20 Panik aufruft, dann will ich nicht wissen, wie die z.B. auf die Versionssprünge bei Google Chrome oder (seit einiger Zeit auch) bei Firefox reagieren.

Ca. 15 Release-Zweige der selben Software zu pflegen sind schon echt viele. Da gestaltet sich die Bug-Jagd und Pflege nicht gerade einfach. Denn bei so vielen Release-Zweigen verliert man irgendwann den Überblick.
Ich höre oft, dass Software meist einen Lebenszyklus von ein paar Jahren hat, aber 30 Jahre alte Software - die wurde wahrscheinlich noch auf 5 1/4"-Disketten geliefert. Unvorstellbar dass so etwas noch mit Geld arbeitet.
Das kostet ein Haufen Geld eine veraltete Software zu warten und das bei den ganzen "Notleidenden Banken" in der Krise.