@alzaimar:
Manchen ist das nicht klar und bevor hier wieder ein Streit zwischen Java und .NET anbrennt
hab ich die lieber getaggt

baka0815 hat folgendes geschrieben:

Garbage Collection hat Microsoft ja von Sun geklaut, sowie einige andere Features. Andere hat Sun/Java dann jedoch wieder von MS geklaut, ist also quasi ein hin und her

Und Java hat es von SmallTalk welches es wiederum von LISP geklaut hat... die meisten heute benutzten Technologien sind eigentlich schon ur alt und werden nur immer wieder adaptiert und an neue Verhältnisse angepasst. Wer da von wem abschaut ist kaum mehr nachzuvollziehen.

Prinzipiell gibt es nicht DIE Programmiersprache. Am besten ist es man hat zwar von allem ein bisschen Ahnung aber man spezialisiert sich trotzdem auf ein bis zwei Bereiche, denn einen Allrounder der alles kann gibt es heutzutage nicht mehr, dazu ist der Bereich IT einfach schon zu groß.
Wenn es um hardwarenahe Programmierung geht (zB Firmware) so wird diese häufig in Forth geschrieben (eine rein stackbasierte Sprache).

Du musst einfach für dich selbst entscheiden in welchen Bereich zu gehen willst...

Zum Thema GUI, Krampf und Java:

Es stimmt auf jeden Fall, dass Java GUI Anwendungen langsamer sind als native Anwendungen, sofern man keine entsprechenden Bindings verwendet.
Java mit den Bindings für GTK+ läuft nicht langsamer als C++ für GTK+.

Das Problem ist die Oberfläche Swing welche das native GUI nur emuliert und somit Zeit frisst. SWT z.B. ist da deutlich(!) schneller - Eclipse ist alles, aber nicht langsam
Allerdings ist das ab 1.5 (bzw. 5) deutlich besser geworden. Ich habe mit ein paar Bekannten mal an einem GB Emulator gearbeitet und nur die Verwendung von 1.5 statt 1.4 hat einen Geschwindigkeitsvorteil von ~30% gebracht.

Falls mit "Krampf" jedoch die Verwendung der LayoutManager gemeint ist, kann man da durchaus geteilter Meinung sein. Es ist zwar nicht immer einfach ein GridBagLayout mit den ganzen GridBagConstrains zu konfigurieren, aber allein die Möglichkeit zu haben, zwischen den ganzen LayoutManagern zu wählen bzw. sich eigene zu basteln finde ich grandios!

Motzi hat folgendes geschrieben:

Und Java hat es von SmallTalk welches es wiederum von LISP geklaut hat...

Java hat sich ja einiges bei Smalltalk abgeguckt, aber das wollte ich mit "ein hin und her" deutlich machen. Hab's unglücklich formuliert, so dass es klang als wäre es nur auf .NET/Java bezogen - sorry.

Einen Allrounder wird es vermutlich wirklich nicht mehr geben, es sollte aber auf jeden Fall das Grundverständnis von Programmierung existieren, dann kann man sich in (fast) alle Sprachen einarbeiten.
Jemand der Java kann, kann recht schnell auf C# umsteigen, da diese viele Ähnlichkeiten haben und der Ansatz der OOP in beiden sehr ähnlich ist. Dann muss man fasst(!) nur noch Klassennamen und etwas Syntax lernen (ob ich das mit der "+="-Verkettung von Listenern jetzt gut oder schlecht finde, weiß ich bis heute nicht).

baka0815 hat folgendes geschrieben:

Zum Thema GUI, Krampf und Java: Es stimmt auf jeden Fall, dass Java GUI Anwendungen langsamer sind als native Anwendungen, sofern man keine entsprechenden Bindings verwendet. Java mit den Bindings für GTK+ läuft nicht langsamer als C++ für GTK+.

Es bedarf genau 2 Befehlen und einem Try-Except-Block um Java auf native Bindings umzustellen. Danach läuft Java mit den Zeichenroutinen des OS ... Auf die Art schlage ich selbst bei aufwändigen GUIs Delphi-Anwendungen beim Start UND in der Zeichenperformance um längen ...

baka0815 hat folgendes geschrieben:

Das Problem ist die Oberfläche Swing welche das native GUI nur emuliert und somit Zeit frisst. SWT z.B. ist da deutlich(!) schneller - Eclipse ist alles, aber nicht langsam

Eclipse ist alles, vor allem langsam!!!

baka0815 hat folgendes geschrieben:

Falls mit "Krampf" jedoch die Verwendung der LayoutManager gemeint ist, kann man da durchaus geteilter Meinung sein. Es ist zwar nicht immer einfach ein GridBagLayout mit den ganzen GridBagConstrains zu konfigurieren, aber allein die Möglichkeit zu haben, zwischen den ganzen LayoutManagern zu wählen bzw. sich eigene zu basteln finde ich grandios!

Für sowas verwendet man in Eclipse den Visual Editor Live-Vorschau selbst bei selbstgebastelten Komponenten zur Entwurfszeit ... Und das Schöne ist: Man kann LIVE!!! die Komponenten ändern, ohne jedes Mal Packages updaten zu müssen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

baka0815 hat folgendes geschrieben: Zum Thema GUI, Krampf und Java: Es stimmt auf jeden Fall, dass Java GUI Anwendungen langsamer sind als native Anwendungen, sofern man keine entsprechenden Bindings verwendet. Java mit den Bindings für GTK+ läuft nicht langsamer als C++ für GTK+. Es bedarf genau 2 Befehlen und einem Try-Except-Block um Java auf native Bindings umzustellen. Danach läuft Java mit den Zeichenroutinen des OS ... Auf die Art schlage ich selbst bei aufwändigen GUIs Delphi-Anwendungen beim Start UND in der Zeichenperformance um längen ...

Meinst du, indem du ihm per UIManager das SystemLookAndFeel zuteilst? Das ist zwar performant, hat aber unter Windows leider noch immer nicht ganz das native LAF erreicht. Fühlt sich noch immer irgendwie "fremd" an.

BenBE hat folgendes geschrieben:

baka0815 hat folgendes geschrieben: Falls mit "Krampf" jedoch die Verwendung der LayoutManager gemeint ist, kann man da durchaus geteilter Meinung sein. Es ist zwar nicht immer einfach ein GridBagLayout mit den ganzen GridBagConstrains zu konfigurieren, aber allein die Möglichkeit zu haben, zwischen den ganzen LayoutManagern zu wählen bzw. sich eigene zu basteln finde ich grandios! Für sowas verwendet man in Eclipse den Visual Editor Live-Vorschau selbst bei selbstgebastelten Komponenten zur Entwurfszeit ... Und das Schöne ist: Man kann LIVE!!! die Komponenten ändern, ohne jedes Mal Packages updaten zu müssen.

Ja, ist 'ne feine Sache, aber 'nen vernünftigen Editor gibt's da leider nicht bzw. nicht mehr. Mantisse (der von NetBeans) lässt leider keine manuellen Änderungen zu und VE ist nur bis Eclipse 3.3 und seit Jahren nicht mehr aktualisiert worden...

Jup. Ist halt beides nicht ganz ideal. Zumal der VE arge Probleme bekommt, wenn man nicht nach dem seinem Schema die GUI aufbaut. Das ist grad bei größeren GUIs oftmals recht problematisch, das ganze vorher umzustricken, dass der VE damit dann zurecht kommt.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Aber ich glaube, wir schweifen ab

Wichtig bei der Wahl der Programmiersprache ist auf jeden Fall, was du damit später machen möchtest.
Wenn du weißt, dass du Plattformunabhängig sein willst, solltest du dir Java angucken. .NET natürlich auch, allerdings musst du dann unter Nicht-Windows Plattformen mit den Nachteilen von Mono (hängt halt hinterher, kann man nix machen) leben - oder du nimmst direkt Mono, was es ja auch für Windows gibt.

Python kann man sich auch angucken, auch wenn ich finde, dass die Einrück-Syntax stark fehleranfällig ist.

Perl ist sicherlich 'ne schöne Sprache und hat ihre Daseinsberechtigung, ich find sie aber (vor allem am Anfang) fürchterlich zu lesen.

"Old-Skool" kannst du natürlich C verwenden, das geht auch Plattformunabhängig, aber ob man damit anfangen sollte, darüber lässt sich sicher streiten

Irgendwer muss natürlich auch noch Brainfuck vorschlagen .

nagel hat folgendes geschrieben:

Irgendwer muss natürlich auch noch Brainfuck vorschlagen .

Naja, ob man Esotherische Programmiersprachen wirklich vorschlagen muss halte ich für zweifelhaft aber wenn man es tut sollte man sich da nicht auf eine beschränken, es gibt doch so viele schöne. Den größten Vorteil gegenüber konventioneller Sprachen bieten meiner Meinung nach WhiteSpace, die spart unheimlich viel Tinte beim Ausducken der Quelltexte .

Gruß
Klabautermann

Zitat:

Irgendwer muss natürlich auch noch Brainfuck vorschlagen .

Also wenn schon esotherische Programmiersprache, dann aber auch ne schöne:
Shakespeare

Bitte kommt zurück zum Thema, das Aufzählen jeglicher Programmiersprachen dürfte bei Beantwortung der Frage des Threaderstellers nicht helfen.

Ok, vorab mal ein Danke für die vielen Antworten.
Ich tendiere erst mal zu C#.

Welche Software gibt es, womit arbeitet Ihr?
Am liebsten wäre mir natürlich, wenn es irgendwo eine Test- bzw. Demoversion gibt, damit man mal ein wenig "reinschnuppern" kann.

Also ich arbeite mit dem Borland C# Builder, viele sagen aber, dass Microsoft Visual C# besser wäre. Der Vorteil an MS Visual C# ist der, dass es (wenn ich mich nicht täusche) eine kostenlose Version gibt.

Eher das es aktueller ist

Wieso ist es aktueller? In wie fern?

Jakob_Ullmann hat folgendes geschrieben:

Wieso ist es aktueller? In wie fern?

Unterstützt .NET 3.0.

jjturbo hat folgendes geschrieben:

Am liebsten wäre mir natürlich, wenn es irgendwo eine Test- bzw. Demoversion gibt, damit man mal ein wenig "reinschnuppern" kann.

Visual C# Express bietet so wenige Einschränkungen, dass du damit weit mehr als nur "reinschnuppern" kannst. Also kein Vergleich zu Turbo Delphi.

Jakob_Ullmann hat folgendes geschrieben:

Wieso ist es aktueller? In wie fern?

Hm... möglicherweise, weil der Builder seit Jahren eingestellt ist ? CodeGear hat selbst erkannt, dass es für das Produkt keinen Berechtigungsgrund mehr gibt.

Timosch hat folgendes geschrieben:

Jakob_Ullmann hat folgendes geschrieben: Wieso ist es aktueller? In wie fern? Unterstützt .NET 3.0.

Kleiner Hint: Wir sind schon bei 3.5 . Im Sommer kommt 3.5 SP1.

Khabarakh hat folgendes geschrieben:

Timosch hat folgendes geschrieben: Jakob_Ullmann hat folgendes geschrieben: Wieso ist es aktueller? In wie fern? Unterstützt .NET 3.0. Kleiner Hint: Wir sind schon bei 3.5 . Im Sommer kommt 3.5 SP1.

Verdammt. Als Win2000-Benutzer kriegt man sowas nicht so richtig mit...

Für C# würd' ich's auf jeden Fall mal mit #Develop versuchen. Kostenlose IDE, OpenSource und recht weit entwickelt.

Das Pendant von #Develop für Mono ist MonoDevelop, falls du auch unter *NIX arbeiten möchtest oder zumindest die Kompatibilität erhalten möchtest. Mono und MonoDevelop gibt's schließlich auch für Windows und andere.

Delphi.NET und MonoDevelop hinken der Microsoft-Version natürlich hinterher (.NET 2.x statt .NET 3.x z.B.). Wie es bei #Develop aussieht, kann ich dir leider nicht sagen.