C#-ähnliche Programmiersprache gesucht
-
Hi,
ich habe vor ein paar Jahren mit C++ angefangen und bin nun seit einigen Monaten berufsbedingt mit C# zu Werke. Dabei ist mir aufgefallen, dass C# viel besser designt wurde als C++. Die ganze Sprache wirkt viel sauberer und die Funktionen wirken wirklich einheitlich und nicht wie eine über Jahre zusammengebastelte Standardbibliothek und dutzender halbgarer GUI-Frameworks.Sachen, die mir an C# im Gegensatz zu C++ positiv aufgefallen sind, sind:
- Endlich mal ein vernünftiger String-Datentyp im Gegensatz zum armseligen std::string.
- Vernünftige Array- und Listen-Klassen ohne Notwendigkeit dieser nervigen Iteratoren.
- Enums müssen mit ihrem Typ angegeben werden (ConsoleColor.Black statt einfach nur black)
- Eine korrekte Abfragerealisierung. Kein int i = 5; if (i) {...} mehr.
- Nur ein Scope-Operator statt drei (. -> ::).
- Alle möglichen Fehler werden per Exception behandelt. Kein undefiniertes Verhalten und keine nicht aufzuhaltenden Programmabstürze bei falschem Zugriff wie bei C++ mit seinem sehr spärlichen Exception-Handling.
- Meine geliebte Konsolenmanipulation (sowas wie gotoxy und texcolor) kann komfortabel ausgeführt werden und man muss sich pro Konsolen-Format-Funktion nicht erst einen mehrzeiligen WinAPI-Code zurechtschreiben.
- Die erstellten Fenster im Windows-Framework sind mit ihren Funktionen sehr sauber aufgebaut (im Gegensatz zum Beispiel zur MFC) und selbst das Erstellen der Fenster mit dem GUI-Designer des Visual Studios produziert absolut sauberen Code (auch wieder im Gegensatz zur MFC, wo eine automatisch generierte Ressourcendatei viel zu viel unsinnigen Text enthält, den man per Hand nie reinschreiben würde).
- Einfache GDI-Grafik-Programmierung ohne Device Contexts und ähnlichem Quatsch. Ein kleines Spiel ist, was den grafischen Teil angeht, also schnell erledigt. Bei C++ müsste man da erst eigene Grafikmanipulationsfunktionen schreiben oder die externe GDI+-Lib einbauen, bei C# gehört das alles zum Standardrepertoire.Das einzige, was mir an C# missfällt, ist die Sache mit dem Zwischencode. Ich habe schon immer am liebsten Programme geschrieben, die auch der letzte Depp und jeder mit einem Asbach-Uralt-PC mit Windows 95 drauf durch einen simplen Doppelklick starten kann.
Und deshalb würde ich gern erfahren: Gibt es eine Programmiersprache, die all die oben genannten Punkte auch erfüllt und die nicht auf einer Virtual Machine basiert, sondern üblichen Maschinencode erstellt? Dabei ist mir übrigens egal, wenn die Sprache eine etwas andere Syntax hat. Es muss nicht unbedingt { und } und for (...; ...; ...) sein.
-
ganz klar: D
-
Eine Sprache wie C#, die nativ kompiliert wird, wäre auch mein Traum. Mir ist jedoch keine bekannt.
-
this->that schrieb:
Eine Sprache wie C#, die nativ kompiliert wird, wäre auch mein Traum. Mir ist jedoch keine bekannt.
D
-
Eine korrekte Abfragerealisierung. Kein int i = 5; if (i) {...} mehr.
Kannst du mir erklären was du damit meinst?
-
Er meint wohl keinen impliziten Cast nach bool.
-
Fed up with C++ schrieb:
Das einzige, was mir an C# missfällt, ist die Sache mit dem Zwischencode. Ich habe schon immer am liebsten Programme geschrieben, die auch der letzte Depp und jeder mit einem Asbach-Uralt-PC mit Windows 95 drauf durch einen simplen Doppelklick starten kann.
Gerade der Zwischencode ist doch der Ansatz durch den deine Programme auch auf dem letzten Rechner laufen werden, selbst auf solchen die noch gar nciht gebaut sind und deren Konfiguration Du selber noch gar nciht kennen kannst.
Die große Stärke am Ansatz mit Zwischencode liegt darin, daß erst auf dem Zielrechner endgültig Compiliert wird (JIT-Compiler, Just In Time Compiler). Der JIT kann sich dabei auf die Zielmaschiene anpassen, diese also voll ausnutzen.
Zig verschiedene Hardwareplattformen zu haben wo man für jede einzelne Plattform dann die nativen Executeables erzeugen, Testen und ausliefern muß _kann_ einfach nicht die richtige Lösung sein.
-
loks schrieb:
Zig verschiedene Hardwareplattformen zu haben wo man für jede einzelne Plattform dann die nativen Executeables erzeugen, Testen und ausliefern muß _kann_ einfach nicht die richtige Lösung sein.
Ausliefern und auf nem System laufen lassen, auf dem man noch nie getestet hat, würde ich auch mit C# oder Java nicht machen. Wäre schon extrem peinlich, wenn man behauptet, dass es auf einem System funktioniert und es dann doch nicht geht und sich rausstellt, dass man es noch nicht mal getestet hat.
-
Honigkuchenpferd schrieb:
loks schrieb:
Zig verschiedene Hardwareplattformen zu haben wo man für jede einzelne Plattform dann die nativen Executeables erzeugen, Testen und ausliefern muß _kann_ einfach nicht die richtige Lösung sein.
Ausliefern und auf nem System laufen lassen, auf dem man noch nie getestet hat, würde ich auch mit C# oder Java nicht machen. Wäre schon extrem peinlich, wenn man behauptet, dass es auf einem System funktioniert und es dann doch nicht geht und sich rausstellt, dass man es noch nicht mal getestet hat.
Es ist aber ein Unterschied ob ich ein Assembly habe das ich gegen alle möglichen Plattformen teste oder ob ich 10 verschiedene Executeables habe die sich möglicherweise auch noch abhängig von der Zielplattform voneinander unterscheiden.
-
Ich denke auch, dass du D mal ausprobieren könntest. Link: http://digitalmars.com/d/2.0/overview.html
-
Du könntest Dir auch mal ADA ankucken. Die Syntax erinnert dabei etwas an Pascal, aber die Sprache wurde vor allem dazu entworfen, Programme beweisbar fehlerfrei zu gestalten.
-
loks schrieb:
Gerade der Zwischencode ist doch der Ansatz durch den deine Programme auch auf dem letzten Rechner laufen werden, selbst auf solchen die noch gar nciht gebaut sind und deren Konfiguration Du selber noch gar nciht kennen kannst.
In der Theorie mag das funktionieren, aber in der Praxis wird das .NET-Framework nur für Windows-Plattformen angeboten. Benutzer anderer Betriebssysteme müssen sich mit Mono, einer nichts mit Microsoft zu tun habenden Drittanbieterlösung begnügen. Tut mir leid, aber ich sehe da nicht mehr Plattformunabhängigkeit als bei der WinAPI. Auf Java bezogen mag dein Argument richtig sein, aber C# ist nun mal in der Hand des Windows-Herstellers und daher ist ein C#-Programm nicht plattformunabhängiger als eine Win32-Anwendung, die ich auf Linux mit Wine laufen lasse. (Aber das sollten wir nicht weiter vertiefen, denn sonst wird das ganze hier zu Off-Topic.)
Außerdem ist mein primäres Ziel gar nicht die plattformunabhängige Programmierung, aber ich lege großen Wert darauf, dass alle, die mein Programm abspielen können (und nicht nur die Windows-Vista-Nutzer), es auch ohne Installation eines eigenen Frameworks benutzen können. Deshalb eben der Wunsch nach einer Sprache, die richtigen Maschinencode erzeugt.
D werde ich mir mal ansehen.
(Hat das auch eine anständige eingebaute Windows-GUI-Bibliothek?)PS: Wie würdet ihr denn die Sprache Pascal (bzw. Delphi (und die VCL)) so bewerten? Ken Thompson, Dennis Ritchie und Brian Kernighan scheinen davon ja sehr überzeugt zu sein.
-
Zwischencode find ich geil - ich brauche nur Minuten um ein x-beliebiges C#-Programm zu reversen und patchen.
Reversers dream comes true...
-
Fed up with C++ schrieb:
Außerdem ist mein primäres Ziel gar nicht die plattformunabhängige Programmierung, aber ich lege großen Wert darauf, dass alle, die mein Programm abspielen können (und nicht nur die Windows-Vista-Nutzer), es auch ohne Installation eines eigenen Frameworks benutzen können. Deshalb eben der Wunsch nach einer Sprache, die richtigen Maschinencode erzeugt.
Du siehst Probleme, wo keine sind. Deine Software muss sowieso beim Anwender installiert werden, dabei wird dann eben die nötige Laufzeitumgebung (z.B. .NET oder JRE) gleich mit installiert. Der Anwender muss davon gar nicht viel mitbekommen. Bei "nativer" Software musst du ja auch manchmal Libs von Fremdanbietern mit verteilen. Oder willst du statische gelinkte Exes per EMail verschicken - ohne Installation?
-
tfa schrieb:
Du siehst Probleme, wo keine sind. Deine Software muss sowieso beim Anwender installiert werden, dabei wird dann eben die nötige Laufzeitumgebung (z.B. .NET oder JRE) gleich mit installiert. Der Anwender muss davon gar nicht viel mitbekommen. Bei "nativer" Software musst du ja auch manchmal Libs von Fremdanbietern mit verteilen. Oder willst du statische gelinkte Exes per EMail verschicken - ohne Installation?
Nicht per Mail, aber im wesentlichen hast du's erfasst: Meine Programme brauchen keine Installation. Wieso auch? Ich programmiere ja nicht MS Office nach. Und da das ganze dann ohnehin nur aus einer Exe-Datei besteht, wäre ein Setup absolut überflüssig. (Das ist ja bei so Sachen wie dem Foxit Reader, Restoration und Konsolenemulatoren genauso. Oder glaubst du, ich würde einen Super-Nintendo-Emulator benutzen, den man erst installieren muss und der auch noch das .NET-Framework braucht?) Erst recht, wenn die eigentliche Anwendung unter einem MB groß ist, man dann aber noch 20 MB eines Frameworks braucht.
-
Bist du NES-Spieler?
-
EOP schrieb:
Zwischencode find ich geil - ich brauche nur Minuten um ein x-beliebiges C#-Programm zu reversen und patchen.
Das mit dem "x-beliebig" wage ich zu bezweifeln.
-
o.O schrieb:
Bist du NES-Spieler?
Nein. Wieso? Wegen dem Super-Nintendo-Emulator?
-
Wenn deine Software es Wert ist benutzt zu werden, wird niemand sich durch die Installation einer Laufzeitumgebung abschrecken lassen - wenn sie nicht schon von vornherein da ist. Vor allem: 20 MB zu viel? In welcher Zeit lebst du?
-
Fed up with C++ schrieb:
o.O schrieb:
Bist du NES-Spieler?
Nein. Wieso? Wegen dem Super-Nintendo-Emulator?
Lügner!
