Hey,
es hat einen Grund, warum ich diesen Thread aufmache, auch wenn es vielleicht schon hunderte dieser Art gibt. Ich überlege mir langsam, ob es noch Sinn macht weiter Delphi zu lernen. Ich bin jemand, der gerne plattformübergreifend programmiert, und weil ich eben noch ein Schüler bin, mir nicht die neuste Version von Delphi leisten kann. Klar mit den .NET Sprachen hab ich auch schon gearbeitet, aber ich finde sie nicht performant genug und zu leicht zu knacken. Deshalb habe ich eigentlich auch auf native Programmierung gesetzt. Von C++ hört man viel. Viele kostenlose Compiler und Entwicklungsumgebungen sehr gute Performance, kleine Anwendungen. Nur was haltet ihr von C++? Den C++ Builder 2010 hätte ich ja, nur da frage ich mich wiederum, ob das wirklich C++ ist. Immerhin ist da auch die ganze VCL dabei. Ich hab mein ganzes Leben noch vor mir und bin nicht mal in der Oberstufe, ich möchte aber trotzdem eine Sprache lernen, mit der ich später arbeiten kann. Würdet ihr mir da C++ empfehlen?

Eine weitere Frage währe, ob ich die VCL Dateien nehmen kann und dann z.B. in CPPBuilder erstellte Projekte mit einem anderen Compiler zu compilern? Damit ich auch für andere Systeme programmieren kann.

Vielen dank für eure Antworten!

Zunächst mal: Du wirst mit einer Sprache alleine sowieso nicht weit kommen, wenn du das beruflich machen willst. Egal ob C++, C#, Java oder Delphi: Wenn du auf eine Sprache festgelegt bist, kannst du es vergessen.

Nano-Ware hat folgendes geschrieben :

Eine weitere Frage währe, ob ich die VCL Dateien nehmen kann und dann z.B. in CPPBuilder erstellte Projekte mit einem anderen Compiler zu compilern? Damit ich auch für andere Systeme programmieren kann.

Du kannst deine Programme zwar z.B. mit dem C++-Builder für andere Plattformen kompilieren, aber nur ohne die VCL-Oberfläche. Bis jetzt geht auch das nur für Mac OS, aber weitere werden folgen. VCL ist aber Windows, egal ob Delphi oder C++-Builder. Für andere Plattformen musst du eine andere Oberfläche an dein Programm koppeln. Wenn das Programm sauber geschrieben ist, sollte das bei kleineren Programmen aber recht schnell gehen.

Nano-Ware hat folgendes geschrieben :

Von C++ hört man viel. Viele kostenlose Compiler und Entwicklungsumgebungen sehr gute Performance, kleine Anwendungen. Nur was haltet ihr von C++?

Ich halte davon weniger als von Delphi. In C++ brauche ich für die selben Programme deutlich länger als in Delphi. Das liegt natürlich auch daran, dass ich es weniger gut kann, aber auch an der Sprache und den Tools dafür. Das ist wie mit Lazarus, es macht mir keinen Spaß damit zu arbeiten, anders als mit Delphi, Visual C#, Prism, Java, ...

Und schon das Oberflächendesign und die entsprechenden Toolkits... Es hat einen Grund warum kleine mit reinem C++ geschriebene Programme oft einfach nur schlecht aussehen und sich nicht gerade nutzerfreundlich verhalten. Dazu zählen auch diverse Systemdialoge von Windows, die mit Delphi oder dem C++-Builder geschrieben deutlich nutzerfreundlicher wären (resizeable, ...).
Klar, große Programme haben das Problem weniger, aber da stecken eben auch bessere Ressourcen dahinter.

Nano-Ware hat folgendes geschrieben :

Klar mit den .NET Sprachen hab ich auch schon gearbeitet, aber ich finde sie nicht performant genug

Hast du da ein Beispiel? Ich merke davon nichts, egal ob mit Prism oder C#.
Ich arbeite zwar auch lieber nativ, aber das ist keiner meiner Gründe.

jaenicke hat folgendes geschrieben :

Nano-Ware hat folgendes geschrieben : Klar mit den .NET Sprachen hab ich auch schon gearbeitet, aber ich finde sie nicht performant genug Hast du da ein Beispiel?

Ein Onlineshop mit ASP.NET vs. Onlineshop mit PHP.
Ich kann dir nur empfehlen, verschiedene Sprachen auszuprobieren. Dann kennst du deren Stärken und Schwächen besser und weißt, wann du welche Sprache einsetzen solltest.

jaenicke hat folgendes geschrieben :

Und schon das Oberflächendesign und die entsprechenden Toolkits...

Ja, unschön alles und wenig Drag&Drop von Komponenten auf die Oberfläche. Da ist Delphi sehr schön. Dafür bläht es die Programme schnell auf, weil die Komponenten mitgeliefert werden müssen.

@GUI: Mit WinRT kannst du C++ und XAML haben. D.h. coole, flüssige, moderne, ansprechende GUIs mit C++. Natürlich ist das nicht mehr plattformübergreifend.

Ich persönlich find den QT CREATOR (C++) ganz nett. Wie das optisch aussieht kann ich garnicht sagen (hab da bisher nur mit OpenGL gearbeitet), ist aber plattformunabhängig.

.NET performt nicht wie C++, es spielt aber immer eine Rolle, was du programmierst. Wenn du Software für einen Kernspintomographen schreiben musst, würde ich .NET nicht empfehlen. Wenn du aber eine komplexe, mehrschichtige Anwendung hast - womöglich von mehreren Entwicklern zur gleichen Zeit geschrieben - dann sieht's wieder anders aus. Ich kann rein aus Entwicklersicht eigentlich nur C#/.NET empfehlen. Die Zeit, die du für die Entwicklung und Debuggen brauchst ist einfach massiv kleiner.
Delphi ist im Vergleich zu C# einfach verboser und hat ein schlechtes Framework. Wenn ich wieder mal was in Delphi machen muss, habe ich ständig das Gefühl, dass mir irgend was fehlt und das ganze nicht richtig sauber umsetzen kann, ohne, dass es schnell mal unübersichtlich wird.

Regan hat folgendes geschrieben :

Ein Onlineshop mit ASP.NET vs. Onlineshop mit PHP.

Gut, ich meinte jetzt eher im Vergleich zu nativer Entwicklung. Dass es schneller geht ein PHP-Skript abzuspulen als .NET DLLs anzusprechen, dürfte niemanden überraschen.
Wobei ich ASP.NET nicht kenne, also nicht genau weiß wie das intern dort abläuft.
Allerdings merke ich z.B. hier keine Geschwindigkeitsprobleme: www.nopcommerce.com/default.aspx

Davon abgesehen erinnere ich mich dabei an Java:
Programme, die ich per Kommandozeile erstellt habe, waren echt langsam, während das exakt gleiche Programm mit dem JBuilder sehr schnell war. Das mag also auch eine Optimierungsfrage sein.

delfiphan hat folgendes geschrieben :

@GUI: Mit WinRT kannst du C++ und XAML haben. D.h. coole, flüssige, moderne, ansprechende GUIs mit C++. Natürlich ist das nicht mehr plattformübergreifend.

Für einiges davon kann ich auch Firemonkey nehmen. Das geht dann auch gleich auf dem Mac und bald auch noch auf anderen Plattformen. Das kann zwar (noch) weniger, ist aber (für normale Businessanwendungen zumindest) einfacher. Es ist allerdings derzeit wohl performancemäßig noch ein wenig schlechter (ich weiß nicht, ob das an der im Vergleich zu allen meinen XAML-Experimenten deutlich größeren GUI oder am Framework selbst liegt).

Nano-Ware hat folgendes geschrieben :

Viele kostenlose Compiler und Entwicklungsumgebungen sehr gute Performance, kleine Anwendungen.

Dieser Satz kein Verb?

Nano-Ware hat folgendes geschrieben :

Nur was haltet ihr von C++? [...] Würdet ihr mir da C++ empfehlen?

Mit C & Konsorten kann man wahrscheinlich mehr und mit kürzerem Quellcode realisieren, insbesondere gibt es sehr flexible Spracheigenschaften, die das ermöglichen und die sich hingegen mit Pascal/Delphi nur "wortreicher" umsetzen lassen.

Auf der anderen Seite ist Pascal ziemlich stark - wenn auch natürlich vereinfacht - der natürlichen (angelsächsichen) Sprache angelehnt, was beim Erfassen des Algorithmus' vorteilhaft ist. Für mich ist es jedesmal eine mittlere Qual, aus C-artigen Quelltexten die Quintessenz herauszulesen. Sicher ist das natürlich auch eine Übungsfrage. Doch auf C stößt man fast überall, von BASIC und eben Pascal abgesehen. Und da komme ich schon um nächsten Vorteil: Die weite Verbreitung und wahrscheinliche Zeithorizont in bezug auf das weitere Überleben. Da muß ich C & Co. klar den Vorteil zusprechen, obwohl ich Pascal deutlich mehr mag.

Zum Thema Asp.net vs php

www.wrensoft.com/zoom/benchmarks.html

Asp.net ist beim ersten Aufruf langsamer, dann wird der Code kompiliert. Danach aber schlägt er php mit Leichtigkeit. Dann ist das Duell eben kompilierter Maschinencode, der für das System optimiert im Arbeitspeicher liegt(Asp.net) gegen Interpretersprache. Facebook zum Beispiel nutzt eine eigene php Version, die genau dieses System nachbaut

Zum Thea knackbarkeit solltest du dir vielleicht mal das hier durchlesen: de.wikipedia.org/wik...ty_through_obscurity. Wenn du immer noch meinst dein Code müsste verschleiert sein nimmst du einen Obfuscator. Dann gibt es noch Sicherheitslücken, die man eigentlich nur in nativen Code einbauen kann, Wie zum Beispiel Buffer overflow Attacken.