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.

Zitat:

---

Zitat von Corti

Was Programmierst du? Crysis3 in einem Single-Threaded Gameloop?

---

Nein, das nun nicht gerade. War ja auch nur so eine Idee. Ich weiß ja nicht, wie GC.Collect() arbeitet und wie viel Performance er benötigt. Und auch habe ich noch keine Erfahrung darin, wie viel Performance so ein 2D Sidescroll Shooter (ala Contra oder Metal Slug) schluckt. Ist ja immerhin erst unser erstes Projekt. Ich sagte ja auch nur, dass ich es mir vorstellen kann.

Zitat:

---

Zitat von niR-kun

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.

---

Der Absatz ließt sich etwas arrogant finde ich. Du denkst zu sehr aus deiner "Informatiker"-Sicht. Versuch mal das aus den Augen eines großen Bankunternehmns zu sehen. Die arbeiten mit Geld, sie arbeiten mit DEINEM Geld. Für die sind Computer nur mittel zum Zweck (ein Mittel das durchaus Fehler verursachen kann) und wenn dann ein System gut läuft und alles gut macht, dann würde ich mich auch über neuere Versionen fürchten. Gerade als Programmierer sollte man wissen wie schnell sich Fehler einschleichen die man nicht erkennt weil man Software nicht so benutzt wie das der Verbraucher benutzen würde.

Beschäftige dich mal mit den Computersystemen von Banken. Die haben fast alle Uralt-Software. Warum? Weil es funktioniert. Das ist für die wichtiger als fancy graphics oder feature-creep. Was meinst du wieviel Geld mit Softwareintegration gemacht wird (Also mit dem Entwicklen von Schnitstellen für Altsysteme).

Zitat:

---

Zitat von R.D.

(Also mit dem Entwicklen von Schnitstellen für Altsysteme).

---

Generell das Entwickeln von Schnittstellen. Bei Banken kommt ja nicht nur eine Software zum Tragen, sondern gleich mehrere, die untereinander funktionieren müssen. D.h. es müssen Schnittstellen gebaut werden.
Unsere Software bekommt die Daten von anderer Software eines anderen Hersteller. Dafür haben wir dann Schnittstellen gebaut. Wenn sich dann was an einer Software ändert und unsere Schnittstelle kann damit nicht umgehen, dann ist es meist schon zu spät. Wenn Updates eingespielt werden müssen, dann wird das eh erst Monatelang in einem Testsystem beobachtet, ob sich alles verhält, wie es soll, ehe das Update wirklich live geht.

Zitat:

---

Zitat von RPG Hacker

Nein, das nun nicht gerade. War ja auch nur so eine Idee. Ich weiß ja nicht, wie GC.Collect() arbeitet und wie viel Performance er benötigt. Und auch habe ich noch keine Erfahrung darin, wie viel Performance so ein 2D Sidescroll Shooter (ala Contra oder Metal Slug) schluckt. Ist ja immerhin erst unser erstes Projekt. Ich sagte ja auch nur, dass ich es mir vorstellen kann.

---

Generell würde ich da sagen, dass ihr euch da erstmal keine Gedanken machen braucht. Das anschmeißen des GCs sind eher minimale Optimierungen, die man erst mal vernachlässigen sollte.
Falls ihr irgendwo Performanceprobleme haben solltet, dann liegen sie meist an einer anderen stelle. Gerade was Grafiken angeht, tappt man gerne als Anfänger in diverse Fallen. Ich kann davon ein Liedchen singen, als ich in meiner Ausbildung ein MS Paint-Klon basteln sollte. So trivial ist die ganze Thematik nämlich nicht. Ich weiß zwar nicht, mit was ihr euer Spiel entwickelt, aber ich würde euch raten, mal XNA anzuschauen, falls ihr das nicht schon tut. Das Framework ist sehr mächtig und auch recht gut dokumentiert.

Und außerdem: Du arbeitet sehr wohl mit Pointern in C#. Nur nennen sich diese hier Referenzen. ;)
Wenn du ein Objekt instanzierst, bekommst du als Rückgabewert ein Pointer auf dein Objekt.

Zitat:

---

Zitat von Whiz-zarD

Ich weiß zwar nicht, mit was ihr euer Spiel entwickelt, aber ich würde euch raten, mal XNA anzuschauen, falls ihr das nicht schon tut. Das Framework ist sehr mächtig und auch recht gut dokumentiert.

---

Jab, wir benutzen XNA. Aber ehrlich gesagt bin ich davon nicht nur begeistert. XNA bietet zwar ein nettes Framework, mit dem man schnell in eine Engine einsteigen kann und die wichtigsten Funktionen gleich schon geboten bekommt (was auch durch die Einfachheit von C# noch unterstützt wird), oftmals ist aber gerade dieses hohe Level genau das Problem. Bestimmte Tweaks am zu Grunde liegenden System sind erst gar nicht möglich ohne eine komplett eigene Engine zu schreiben. Die Erfahrung habe ich jedenfalls gemacht, wenn es beispielsweise um so Sachen geht wie Timing. Konkret habe ich mal versucht, Interpolation in ein Spiel einzubauen. Und obwohl auf MSDN steht, dass in XNA die Draw-Methode selbst dann noch möglichst oft aufgerufen wird, wenn man das Spiel auf Fixed Time Steps stellt, hat das bei mir nicht so wirklich funktioniert. Faktisch wurden Update und Draw bei mir immer noch gleich oft aufgerufen. Beispielsweise hatte ich mal testweise die Update-Frequenz auf 4 FPS gesetzt. Der Effekt war, dass auch Draw nur mit 4 FPS aufgerufen wurde. Solches Verhalten zu verändern wird in XNA beispielsweise nicht leicht.

Eine andere Sache, die mir in XNA nicht gefällt, ist dass es viele Sachen komplizierter macht als nötig. Zur Erläuterung: In unserem Spiel gibt es einen Laser, der Ray-Tracing verwendet und genau bis zur nächsten Wand fliegt. Zur Darstellung verwenden wir Tiles, die wir x-mal wiederholen. Nun dachten wir uns, dass es vielleicht einen ganz guten Effekt gäbe, wenn wir den Laser per Add-Blending darstellen. War auch an und für sich keine schlechte Idee, nur haben die Tiles sich an den Übergängen überlappt (was in XNA sonst kaum anders lösbar wäre aufgrund gewisesr Eigenschaften), was bei Add-Blend natürlich bedeutet, dass an dieser Stelle doppelt addiert wird und man Übergangskanten hat. Schön und gut dachte ich mir. Zeichne ich den Laser einfach vorher per Alpha-Blend auf einen Buffer und dann von da per Add-Blend auf den Bildschirm. Aber nein, Pustekuchen. Das einzige, was ich dafür hätte verwenden können, sind RenderTargets. Und die sind einfach so ziemlich das schlimmste, was es in XNA gibt. Jeder, der damit schonmal gearbeitet hat, kennt sicher das Problem mit der lilanen Farbe im Hintergrund. Ich schwöre: Ich habe ein paar Stunden lang gegoogelt und diverse als funktionierend abgestempelte Methoden teilweise eins zu eins übernommen. Ich habe es einfach nicht geschafft, die Farbe rauszukriegen. In anderen Libraries, beispielsweise Allegro, hätte ich an diesem Problem vielleicht fünf Minuten gesessen.

Also wie gesagt: XNA ist schon ein nettes Framework für den Einstieg in eine eigene Engine, weil es einem viel Arbeit schon abnimmt, aber für ein wirklich ernsthaftes Projekt, für das ich etwas mehr Zeit hätte, würde ich es nicht verwenden wollen.

Zitat:

---

Zitat von Whiz-zarD

Und außerdem: Du arbeitet sehr wohl mit Pointern in C#. Nur nennen sich diese hier Referenzen. ;)
Wenn du ein Objekt instanzierst, bekommst du als Rückgabewert ein Pointer auf dein Objekt.

---

Klar. Habe ich denn was anderes behauptet? Ich bin ja nicht auf den Kopf gefallen. Natürlich sind Referenzen in C# nichts anderes als Pointer. Fakt ist aber, dass du sie nicht als Pointer verwendest. Das macht C# eben schon automatisch für dich. Für dich als Programmierer hingegen gibt es in C# in der Nutzung erstmal keinen Unterschied zwischen Reference-Typen und Value-Typen, die werden alle wie letzterer verwendet. Was ich damit sagen will: Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich. In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.

Auch das alles hat natürlich nicht nur gute Seiten. Ein Problem hiervon ist zum Beispiel, dass du an die Vorgaben von C# gebunden bist. So kannst du beispielsweise einen int niemals als Referenztyp und eine Klasse niemals als Valuetyp übergeben. Das ist zwar nur in den seltensten Fällen überhaupt nötig, aber durchaus nicht komplett ausgeschlossen. Zumindest der erste Fall. Um das in C# hinzukriegen musst du schon einen Umweg gehen und den Valuetyp irgendwie extra in eine Klasse packen. Und das ist eben genau das, was ich meine. Wirklich mit Pointern arbeiten tust du in C# eigentlich nur in Unmanaged Code. Ansonsten tut C# das automatisch und es kann dir egal sein, ob da gerade Pointer verwendet werden oder nicht. Eben auch wegen der automatischen Speicherverwaltung und so.

Zitat:

---

Zitat von Whiz-zarD

Generell das Entwickeln von Schnittstellen. Bei Banken kommt ja nicht nur eine Software zum Tragen, sondern gleich mehrere, die untereinander funktionieren müssen. D.h. es müssen Schnittstellen gebaut werden.
Unsere Software bekommt die Daten von anderer Software eines anderen Hersteller. Dafür haben wir dann Schnittstellen gebaut. Wenn sich dann was an einer Software ändert und unsere Schnittstelle kann damit nicht umgehen, dann ist es meist schon zu spät. Wenn Updates eingespielt werden müssen, dann wird das eh erst Monatelang in einem Testsystem beobachtet, ob sich alles verhält, wie es soll, ehe das Update wirklich live geht.

---

Deswegen "Altsysteme". Ich tue mir das in der Uni auch grad an und kann daher gut mit dir mitfühlen auch wenn es bei uns nicht so schlimm ist.

Zitat:

---

Zitat von RPG Hacker

Jab, wir benutzen XNA. Aber ehrlich gesagt bin ich davon nicht nur begeistert. XNA bietet zwar ein nettes Framework, mit dem man schnell in eine Engine einsteigen kann und die wichtigsten Funktionen gleich schon geboten bekommt (was auch durch die Einfachheit von C# noch unterstützt wird), oftmals ist aber gerade dieses hohe Level genau das Problem.

---

Das fasst meine Meinung über XNA gut zusammen. Es stellt sich zwar mächtig hin, versagt aber bei den kleinen Sachen (Versuch mal ordentlich Primitves zu zeichnen...). Ich weiß jetzt nicht wie MonoGame ist und kenne auch nur ein Game damit (Bastion), aber das ist Open Source und daher würde ich nie das tote XNA empfehlen.

Zitat:

---

Eine andere Sache, die mir in XNA nicht gefällt, ist dass es viele Sachen komplizierter macht als nötig. Zur Erläuterung: In unserem Spiel gibt es einen Laser, der Ray-Tracing verwendet und genau bis zur nächsten Wand fliegt. Zur Darstellung verwenden wir Tiles, die wir x-mal wiederholen. Nun dachten wir uns, dass es vielleicht einen ganz guten Effekt gäbe, wenn wir den Laser per Add-Blending darstellen. War auch an und für sich keine schlechte Idee, nur haben die Tiles sich an den Übergängen überlappt (was in XNA sonst kaum anders lösbar wäre aufgrund gewisesr Eigenschaften), was bei Add-Blend natürlich bedeutet, dass an dieser Stelle doppelt addiert wird und man Übergangskanten hat. Schön und gut dachte ich mir. Zeichne ich den Laser einfach vorher per Alpha-Blend auf einen Buffer und dann von da per Add-Blend auf den Bildschirm. Aber nein, Pustekuchen. Das einzige, was ich dafür hätte verwenden können, sind RenderTargets. Und die sind einfach so ziemlich das schlimmste, was es in XNA gibt. Jeder, der damit schonmal gearbeitet hat, kennt sicher das Problem mit der lilanen Farbe im Hintergrund. Ich schwöre: Ich habe ein paar Stunden lang gegoogelt und diverse als funktionierend abgestempelte Methoden teilweise eins zu eins übernommen. Ich habe es einfach nicht geschafft, die Farbe rauszukriegen. In anderen Libraries, beispielsweise Allegro, hätte ich an diesem Problem vielleicht fünf Minuten gesessen.

---

In XNA kannst du eine Textur nicht stretchen? Das glaub ich irgendwie nicht :o Also wenn der Laser eine komplizierte horizontale Animation hat sondern einfach nur ein Streifen, hätte es auch ein Strech getan denke ich. Ich dachte immer RenderTargets sind einfach nur FrameBuffer. Das man da soviel kaputt machen kann wusste ich nicht (also, das die engine Entwickler offenbar da Probleme hatten.).

Zitat:

---

Also wie gesagt: XNA ist schon ein nettes Framework für den Einstieg in eine eigene Engine, weil es einem viel Arbeit schon abnimmt, aber für ein wirklich ernsthaftes Projekt, für das ich etwas mehr Zeit hätte, würde ich es nicht verwenden wollen.

---

Naja für simple pixelbasirende Spiele wird es gehen. Auch für simples 3D. Siehe Terraria oder Secret of Grindea.

Zitat:

---

Klar. Habe ich denn was anderes behauptet? Ich bin ja nicht auf den Kopf gefallen. Natürlich sind Referenzen in C# nichts anderes als Pointer.

---

Ich meine Pointer zeigen auf nichts oder? Aber eine Referenz zeigt doch auf etwas selbst wenn man nichts darauf verweißt. Zumindest ist das in Java so.

Zitat:

---

Zitat von RPG Hacker

Fakt ist aber, dass du sie nicht als Pointer verwendest. Das macht C# eben schon automatisch für dich. Für dich als Programmierer hingegen gibt es in C# in der Nutzung erstmal keinen Unterschied zwischen Reference-Typen und Value-Typen, die werden alle wie letzterer verwendet. Was ich damit sagen will: Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich. In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.

---

Doch, es gibt einen gravierenden Unterschied. Wertetypen werden im Stack alloziert und wird durch einen sog. Stack Pointer direkt vom Prozessor unterstützt.
Referenztypen hingegen werden im Heap alloziert. Das allozieren muss man explizit mit dem new-Schlüsselwort einleiten, ansonsten hat man hier einen Null-Pointer. Wertetypen hingegen können nicht null als Wert besitzen. Wer sowas braucht, der muss Wrapper-Klassen benutzen. Unter C# wäre dies z.B. int?. Das Fragezeichen deutet darauf hin, dass sich um eine Wrapper-Klasse von einem Wertetyp handelt.

Ein weiterer Unterschied ist der Pointer selbst:

Code:

---

int a = 5;
int b = a;

---

Hier haben wir zwei unabhängige Wertetypen, die jeweils den Wert 5 besitzen.

Code:

---

Circle cirlce1 = new Cirlce();
Circle circle2 = circle1;

---

Hier zeigen beide Referenztypen auf das selbe Objekt, und es ist auch egal, ob ich circle1 oder circle2 nehme.
Beide Code-Abschnitte machen im Prinzip das selbe, wir deklarieren zwei Variablen, eine Initialisieren wir und der zweiten übergeben wir dem Wert der ersten Variable, aber wir haben hier zwei unterschiedliche Ergebnisse.
Im ersten Beispiel übergeben wir den Wert und im zweiten Beispiel die Referenz.
Soll heißen: Nur weil man nicht explizit mit Pointern arbeitet, heißt es ja lange nicht, dass es keine Pointer mehr gibt, und der letzte zitierte Satz:

Zitat:

---

In C++ hingegen müsstest du selbst entscheiden, ob du die Klasse lieber als Daten oder als Referenz übergibst.

---

Zeigt, dass du die Pointer nicht so ganz verstanden hast, denn das tust du unter C# auch. Nur ist die Syntax in C# nicht ganz so kryptisch, wie bei C/C++.
Auch bei C# musst du entscheiden, ob du einen Werteparameter (Call-by-Value), oder einen Referenzparameter (Call-by-Reference) an eine Methode übergeben möchtest.

Zitat:

---

Zitat von RPG Hacker

Für dich als Programmierer hingegen gibt es in C# in der Nutzung erstmal keinen Unterschied zwischen Reference-Typen und Value-Typen, die werden alle wie letzterer verwendet. Was ich damit sagen will: Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich.

---

Machts für dich keinen Unterschied mit einer Kopie oder dem Original zu arbeiten? Nie?

Zitat:

---

Zitat von RPG Hacker

So kannst du beispielsweise einen int niemals als Referenztyp[...] übergeben.

---

Ref: http://msdn.microsoft.com/de-de/libr...=VS.80%29.aspx
Out: http://msdn.microsoft.com/de-de/libr...=vs.80%29.aspx

Nicht die empfohlenste Art in C# mit Parametern zu hantieren aber ganz praktisch.

Zitat:

---

Zitat von RPG Hacker

So kannst du beispielsweise [...]eine Klasse niemals als Valuetyp übergeben.

---

Mach einen Clon O_o , es gibt Klassen, die akzeptieren ihre eigene Art im Konstruktor, wenn man es denn unbedingt einfach haben will, oder man schreibs sich selber kurz.
Wenn das Ding eh nur Daten speichern soll mach 'n Struct draus.

Ach, da hätte ich noch was vergessen:

Code:

---

int a = 5;
int b = 5;

Circle c1 = new Circle();
c1.Radius = 10;

Circle c2 = new Circle();
c2.Radius = 10;

Circle c3 = c1;

boolean b1 = a == b; // ergibt True
boolean b2 = c1 == c2, // ergibt False
boolean b3 = c1 == c3; // ergibt True

---

b1 vergleicht die Werte. b2 und b3 vergleichen allerdings die Referenzen.
Auch hier wird deutlich, dass wir mit Pointern arbeiten. Wer c1 und c2 vergleichen möchte, muss die Equals()-Methode verwenden, und ggf. sogar die Equals()-Methode oder den Vergleichsoperator überschreiben.

Zitat:

---

Zitat von RPG Hacker

So kannst du beispielsweise einen int niemals als Referenztyp und eine Klasse niemals als Valuetyp übergeben. Das ist zwar nur in den seltensten Fällen überhaupt nötig, aber durchaus nicht komplett ausgeschlossen. Zumindest der erste Fall. Um das in C# hinzukriegen musst du schon einen Umweg gehen und den Valuetyp irgendwie extra in eine Klasse packen. Und das ist eben genau das, was ich meine. Wirklich mit Pointern arbeiten tust du in C# eigentlich nur in Unmanaged Code. Ansonsten tut C# das automatisch und es kann dir egal sein, ob da gerade Pointer verwendet werden oder nicht. Eben auch wegen der automatischen Speicherverwaltung und so.

---

Wie Corti schon sagt:
Im ersten Fall gibt es die Schlüsselwörter ref und out.
Im zweiten Fall gibt es die Structs, die nämlich im Stack alloziert werden und somit als Wertetypen gelten.

Structs sind aber ein Überbleibsel aus der strukturellen Programmierung. Klassen sind im Prinzip eine Erweiterung der Structs. In dieser Hinsicht ist C# nicht ganz konsequent. Es kann aber durchaus Sinnvoll sein, unter C# Structs zu verwenden, weil hier der Overhead deutlich geringer ist. Wer also viele Objekte auf einmal erzeugen muss, die nur Daten bereitstellen, kann mit Structs ein wenig Performance rausholen, aber C# ist hier eine Ausnahme. Z.B. unter Java gibt es für beide Fälle keine Lösung.

Zitat:

---

Zitat von RPG Hacker

Wenn du beispielsweise eine Funktion mit Parametern schreibst, macht es für dich keinen Unterschied, ob du einen int übergibst oder eine Klasse. C# wählt automatisch die bestmögliche Option für dich.

---

C# sucht keine Option aus. C# erzeugt eine Kopie. Entweder eine Kopie des Wertetyps, oder eine Kopie der Referenz, je nachdem um was für ein Typ es sich handelt.

Zitat:

---

Zitat von R.D.

In XNA kannst du eine Textur nicht stretchen? Das glaub ich irgendwie nicht :o Also wenn der Laser eine komplizierte horizontale Animation hat sondern einfach nur ein Streifen, hätte es auch ein Strech getan denke ich. Ich dachte immer RenderTargets sind einfach nur FrameBuffer.

---

Natürlich geht das. Weiß nur nicht, ob das auch noch so gut funktioniert, wenn du den Laser rotierst (du gibst bei der Skalierung X- und Y-Skalierung an). Vor allen Dingen aber wollten wir eben keinen langweiligen Laser, der einfach nur aus einem Strahl besteht. Wir wollten schon ein bisschen mehr Struktur reinbringen.

Zitat:

---

Zitat von Whiz-zarD

Soll heißen: Nur weil man nicht explizit mit Pointern arbeitet, heißt es ja lange nicht, dass es keine Pointer mehr gibt,

---

Was ich nie auch nur ansatzweise behauptet habe.

Zitat:

---

Zitat von Whiz-zarD

und der letzte zitierte Satz Zeigt, dass du die Pointer nicht so ganz verstanden hast

---

Sei mal nicht so arrogant. Das unterstreicht nur die Vorurteile, die man ohnehin schon gegenüber Programmierern hat. Ich verstehe echt nicht, warum 95% der Programmierer so verdammt arrogant sein müssen. Bloß, weil ich mich anders ausdrücke, als du, heißt das noch lange nicht, dass ich etwas nicht verstehe. Ich programmiere nun immerhin auch schon seit gut fünf Jahren und das zwar bisher noch nicht für ein Unternehmen, aber immerhin schon in den verschiedensten Programmiersprachen, darunter sogar ASM für das SNES. Und da es im guten alten Turbo Pascal noch nicht so Datentypen wie Listen oder Vektoren gab, habe ich selbst verständlich auch schon mit selbst programmierten, dynamisch verlinkten Listen gearbeitet. Zu behaupten, ich würde Pointer nicht verstehen, ist hier also pure Arroganz, bloß weil ich anderer Ansicht bin, als du (oder denselben Standpunkt anders darstelle). Komm mal von deinem hohen Ross runter, du göttlicher Super-Programmierer!

Zitat:

---

Zitat von Corti

Machts für dich keinen Unterschied mit einer Kopie oder dem Original zu arbeiten? Nie?

---

Faktisch tatsächlich eher selten. Kann mich bisher eigentlich nur an einen Fall erinnern, wo ich mal die Kopie einer Klasse brauchte. Und da hätte ich theoretisch auch mit dem Original arbeiten können. Generell ist es eben einfach so, dass man Klassen meistens als Referenzen und andere Sachen meistens nur als Wert braucht. Das Standardverhalten ist in C# ja nicht grundlos so definiert. In 90% der Fälle ist das eben genau das, was man braucht.

Zitat:

---

Zitat von Corti

Ref: http://msdn.microsoft.com/de-de/libr...=VS.80%29.aspx
Out: http://msdn.microsoft.com/de-de/libr...=vs.80%29.aspx

Nicht die empfohlenste Art in C# mit Parametern zu hantieren aber ganz praktisch.

---

Naja, ich habe da tatsächlich etwas ganz anderes gemeint, als ich gesagt habe. Was ich meinte war, dass du beispielsweise in einer Klasse nicht ohne Umwege eine Referenz auf einen Wertetyp deklarieren kannst. Also dass du beispielsweise in einer Klasse eine Eigenschaft namens intPointer hast, die auf einen int zeigt. Dafür müsstest du dann erst einen Wrapper oder so verwenden. In C++ (oder Unmanaged Code) könntest du ja einfach int* nehmen.

Zitat:

---

Zitat von Corti

Mach einen Clon O_o , es gibt Klassen, die akzeptieren ihre eigene Art im Konstruktor, wenn man es denn unbedingt einfach haben will, oder man schreibs sich selber kurz.
Wenn das Ding eh nur Daten speichern soll mach 'n Struct draus.

---

Ja, das ist auch nicht unbedingt das beste Beispiel. Der umgekehrte Fall, einen Wertetyp als Referenz zu verwenden, ist eh wahrscheinlicher.

Zitat:

---

Zitat von Whiz-zarD

C# sucht keine Option aus. C# erzeugt eine Kopie. Entweder eine Kopie des Wertetyps, oder eine Kopie der Referenz, je nachdem um was für ein Typ es sich handelt.

---

Das ist doch überhaupt nicht der Punkt. Rede ich denn gegen eine Wand? Alles, was ich sage, ist dass der Unterschied zwischen Referenztypen und Wertetypen in C# einfach in 90% der Fälle für den Programmierer egal ist. Natürlich gibt es da Unterschiede, natürlich wird da mit Pointern gearbeitet, natürlich gibt es Ausnahmen. In 90% der Fälle - so war es zumindest bei mir bisher - arbeitet C# aber immer genau so, wie du es gerade erwartest bzw. brauchst. Das liegt eben auch daran, dass C# eben automatische Speicherverwaltung hat. Wenn du in C++ eine Funktion nimmst und ihr einen Pointer übergibst, musst du dir anschließend oft sagen "so, und jetzt nach der Funktion bloß nicht vergessen, den Speicher wieder freizugeben". In dieser Hinsicht unterscheiden sich in C++ Pointer stark von Wertetypen, denn Wertetypen musst du nie manuell freigeben. In C# hingegen musst du ja so gut wie nie Speicher manuell freigeben. Dadurch verschwimmen die Grenzen zwischen Referenztyp und Wertetyp in der Anwendung. Du musst dir nie erst sagen "Ach ja, das ist ja eine Referenz, also bloß nicht vergessen, den Speicher wieder freizugeben", sondern kann sie ähnlich, wie Wertetypen verwenden. Das ist doch wirklich alles, was ich damit habe sagen wollen. War das nun wirklich so schwer zu verstehen und diese ganze Diskussion wert? Mann, Mann, Mann...

Zitat:

---

Zitat von RPG Hacker

Sei mal nicht so arrogant. Das unterstreicht nur die Vorurteile, die man ohnehin schon gegenüber Programmierern hat. Ich verstehe echt nicht, warum 95% der Programmierer so verdammt arrogant sein müssen.

---

Ich bin nicht arrogant. Anstatt die Fehler bei den anderen zu suchen, solltest du dich vielleicht mal fragen, warum du so empfindest, dass 95% der Programmierer arrogant seien.
Es liegt einfach nur daran, dass du missverständliche Dinge von dir gibst, die ein Programmierer für falsch ansieht und dich lediglich korrigiert. Dein jetziger Beitrag ist auch wieder voller falschen Aussagen. Das fängt schon damit an, dass du den Gabage Collector und Pointer in einen Pott schmeißt. Auch in C/C++ kannst du ohne weiteres einen Garbage Collector implementieren.

Genau das meine ich doch mit arrogant. Anstatt mich einfach nur sachlich auf die Fehler hinzuweisen (natürlich habe ich keine perfekte Ausdrucksweise und natürlich ist nicht alles, was ich sage, 100%ig korrekt - immerhin beginne ich gerade erst mit dem Studium und habe zuvor fast nur als Hobby programmiert) musst du mir natürlich noch unter die Nase reiben, WIE falsch ja alles sei, was ich sage, und wie viel besser du es wüsstest. Es ist schon ein deutlicher Unterschied, ob man sagt "Das ist so nicht ganz richtig. Tatsächlich gibt es da dieses und jenes.", oder ob man sagt "Das, was du gesagt hast, ist ja mal alles sowas von falsch und zeigt, dass du offensichtlich überhaupt keine Ahnung vom Programmieren hast". Ja, ich weiß, so krass hast du es nicht ausgedrückt. Aber ungefähr so kam es zumindest bei mir rüber. Mir ist klar, dass du deutlich mehr Erfahrung in der Programmierung hast, als ich und ich auch manchmal unbewusst Blödsinn verzapfe. Aber kannst du nicht versuchen, mich sachlich darauf hinzuweisen, anstatt dich als überlegen und mich als Idioten darzustellen? Und dass 95% der Programmierer auf mich arrogant wirken liegt sicher nicht daran, dass ich überhaupt etwas falsches sage, es liegt eher daran, dass diese 95% der Programmier so scheiße darauf reagieren, wenn mal jemand etwas falsches sagt. Ich kenne durchaus auch einige Programmierer, die deutlich besser sind als ich und mit denen ich mich trotzdem super verstehe, weil sie ihre Erfahrung vermitteln können, ohne dabei mit ihrer Überlegenheit zu prahlen. Und gleichzeitig bestätigt gerade mein Studium aber, dass es eben auch diverse Programmierer gibt, die gar nicht anders können, als mit ihrer Überlegenheit (oder gar Pseudo-Überlegenheit) zu prahlen. Zwar sind wir insgesamt nur 7 Programmierer im Jahrgang und davon nur 4 in meinem Kurs, aber gerade bei der geringen Menge fällt jeder eben umso mehr auf. So hat mich beispielsweise in der allerersten Woche ein Kollege total in den Boden geflamed, bloß weil ich gesagt habe - und ich zitiere - "Ach, Free Pascal ist gar nicht sooo schlecht". Daraufhin entbrannte eine Riesen-Diskussion und er wollte mir unbedingt unter die Nase reiben, dass Free Pascal scheiße und C++ das Tollste sei. Und auf meine Argumente, dass Free Pascal durchaus auch einige Vorteile gegenüer C++ biete, reagierte er nur umso bestürzter und war nichtmal mehr in der Lage, eine objektive Diskussion zu führen. Und das ist nun wirklich nicht der erste Fall, in dem irgendein Programmierer mir seine Überlegenheit reindrücken wollte und das wegen einer total unwichtigen und kleinen Sache. Also tut mir Leid, wenn ich in dieser Hinsicht überempfindlich reagiere, aber sowas kotzt mich einfach an und meine Erfahrung zeigt mir, dass an meiner Behauptung (mit den 95%) durchaus ein Fünkchen Wahrheit dran ist.

Oh man, ich hatte in meinem Informatik-Studium ebenso eine Erfahrung gemacht. Man hat echt das Gefühl, die meisten Informatiker wären sozial völlig inkompetente, autistisch anmutende Fachidioten. ;D
Ich dachte, ich hätte nur eine besonders schlechte Erfahrung gemacht, aber anscheinend geht es anderen auch so *g*

Ich bin ja selbst nicht der sozial kompetenteste, aber zumindest bemühe ich mich darum. :P

@RPG Hacker:
Nimm bitte nicht alles so persönlich. Wenn man über Sachen spricht kanns vorkommen, dass man im (Streit-)Gespräch feststellt, dass man irgendwo Wissenslücken hat oder Sachen falsch weiss. Das liegt daran, dass man nicht alles wissen kann, man mal Sachen falsch versteht, oder man Sachen einfach falsch vermittelt bekam. Normalstes Ding auf der Welt, dann kriegt man halt ein Update und weiss danach mehr.

Da z.B. Whiz-zarD dich nicht persönlich kennt und in deine Gedanken blicken kann woher soll er da wissen, ob du Sachen wirklich schon verstanden hast und nur so formulierst als wär es nicht der Fall oder ob du sie nicht verstehst? Deine Formulierungen sagen eindeutig aus, dass dir bei Pointern etwas Verständnis fehlt, du kannst in dem Fall nicht erwarten, dass er eine Information verarbeitet, die er nicht hat. Zu sagen "Ich habe Pointer verstanden - gefolgt von einer fachlich falschen Erklärung" ist keine Information, die eindeutig beinhaltet, dass du sie verstanden hättest, es ist eine Information, die primär beinhaltet, dass das Gegenteil der Fall ist mit einer geringen Chance, dass die Formulierung misslungen ist, der Inhalt aber stimmt.

Was erwartest du also? Dass man das liest und denkt "ah, nicht ganz richtig, aber das ist RPG Hacker, der wurde in seinem Leben so oft von Programmierern niedergemacht, den verbesser ich lieber nicht, der nimmt das nur wieder persönlich und fühlt sich niedergemacht"~ okey man hat gelegentlich Leute im Forum von denen man weiss, dass jede Minute des Schreibens vergebens ist weil sies eh nicht checken wolle und werden und nur rumweinen, aber zu denen zähle ich dich nicht und dazu gehören willst du sicherlich auch nicht.

Zwei Dinge:

• Wenn dir jemand etwas vermittelt, dass du nicht (so gut, ausreichend, ganz genau) wusstest, sieh es nicht als Verletzung deiner Programmiererehre sondern nimms souverän, du hast dann gerade was gelernt. Gut!
• Die Sprachendebatte ist hinfällig: Auch wenn C++ in allen fachlichen Dingen >>>>>>>> FreePascal, für einfache Dinge tuts die einfachste Sprache. Tada, Thema durch. Programmiersprachen sind keine Religionen, man kann durchaus mehrere haben, können, benutzen und mögen und man muss die Ungläubigen nicht abschlachten oder bekehren ;-)

Ich versuche mich an deinen Rat zu halten. ;)
Und ja, du hast Recht. Ich habe durchaus ein wenig überreagiert. Gewisse Formulierungen kamen mir eben mehr als Überheblichkeit und weniger als einfache Verbesserungen rüber. Aber gut, genauso wie Whiz-zarD mich noch nicht so gut kennt, kenne ich ihn natürlich auch noch nicht so gut. Deswegen tut es mir Leid, falls ich mit meinen Behauptungen daneben gelegen habe.