Empfehlung einer aktuellen OOP Sprache zum "reinschnuppern"

[Kurzer]

Hallo,

kann mir jemand eine aktuelle und leicht erlernbare objektorientierte Programmiersprache zum "mal reinschnuppern" und bei gefallen "für mehr" empfehlen?

Ich bin reiner Teilzeit-Hobbyprogrammierer und habe in den 80ern mit prozeduraler Programmierung angefangen (Maschinensprache, Assembler und Basic auf VIC-20, C-64, Amiga, DOS und Atmel uControllern). Leider bin ich kein ausgebildeter IT-ler, sondern habe mir das alles autodidaktisch angeeignet. Von daher fehlen mir sicherlich auch die ein oder anderen Grund-/Fachkenntnisse und Terminas.

Da ich mich beruflich in anderen Bereichen als der IT aufgehalten habe und sonst auch nicht viel über den Tellerrand geschaut habe, ist die gesamte Entwicklung in diesem Bereich mehr oder weniger an mir vorbei gegangen.

Keine Frage, momentan bin ich mit PureBasic auf Windows sehr glücklich. Aufgrund aktueller Motivationseinbrüche bei meiner Hobbyprogrammierung, möchte aber schauen, ob es Vorteile gibt, wenn ich mich für einige Projekte mit einer objektorientierten Sprache beschäftige. Hier hoffe ich auch auf einen Motivationsschub, da es sich um "etwas neues" handelt.

Ich bin bezüglich der Auswahl einer aktuellen OOP Sprache ziemlich aufgeschmissen und meinen Vorstellungen dazu sind vermutlich auch naiv, aber möglicherweise gibt es trotzdem Empfehlungen, die in die selben Rahmenbedingungen passen, die ich bei PureBasic so sehr mag. Als da wären...

- Die erzeugte Exen haben keine Abhängigkeiten von irgendwelchen Frameworks (.NET, Qt oder sowas)
- Die Entwicklungsumgebung ist schmal und benötigt kein .NET o.ä. (im Optimalfall sogar portabel "installierbar")
- Im Optimalfall ist es eine Sprache, die nicht nach ein paar Jahren in Vergessenheit gerät
- Es ist eine ausführliche Hilfe für das Entwicklungswerkzeug verfügbar
- Es sind Beispiele und Tutorials für Einsteiger verfügbar. Die generelle Erklärung bzgl. OO Programmierung habe ich soweit verstanden (Das Beispiel mit der Klasse "Auto", Methoden Gasgeben() und Bremsen() usw., aber mehr ins Detail bin ich nie gegangen. Ist ohne Entwicklungsumgebung dann auch zu trocken, wenn man selbst keine Beispiele bauen kann)
- Es gibt Foren in denen Wissen zu dieser Sprache und der dahinter stehenden Philosophie vermittelt wird (wie gesagt gingen auch die Anfänge der OOP an mir vorbei, ich muss mich da ganz vom Urschleim durcharbeiten)

Ich habe bereits im Netz recherchiert, bin aber ehrlich gesagt durch die hohe Anzahl der mittlerweile verfügbaren Programmiersprachen völlig überfordert eine richtige Auswahl zu treffen.

Mein Ziele sind:

- Das Erlernen von OOP
- Das Erstellen von Windows Executablen (Standalone-Programme)
- Das Erstellen von DLLs, die ich mit PB nutzen kann
- Das Erstellen von Libs / neue Funktionen für PureBasic, wobei ich dies bisher noch nicht gemacht habe und den genauen Workflow dafür nicht kenne. Das wäre dann aber eine andere Baustelle. Ich erwähne es nur der Vollständigkeit halber.

Kann hier jemand aus dem Nähkastchen plaudern?

[NicTheQuick]

Also wenn du keine Frameworks nutzen willst, und schmale standalone Executables willst, dann wäre meiner Meinung nach C++ das Mittel der Wahl. Damit kannst du all das machen, was du vorhast, es gibt zig IDEs dafür, mehrere Compiler, Plattformunbhängigkeit und das wird es bestimmt auch noch lange geben. Außerdem gibt es zig Bücher und Totorials dafür.

[Kurzer]

Moin Nic,

danke für Dein feedback.

Nach ein paar Vergleichen bzgl. C++ Entwicklungsumgebungen, werde ich mir DevC++ von Orwell ansehen (das ist ein aktuell gepflegter Fork des nicht mehr weiterentwickelten DevC++ von Bloodshed). Die IDE hat bereits den TDM-GCC 4.9.2. Compiler on board, unterstützt noch andere Compiler und ist sogar portable (was mein Herz erfreut ).
http://orwelldevcpp.blogspot.de/

Leider habe ich noch keine Tutorials gefunden, die die ersten Schritte inkl. der optimalen Einstellungen des Compilers beschreiben. Da werde ich mich erstmal mit beschäftigen.

[X0r]

Schade, dass du .NET ablehnst. Denn sonst würdest du mit C# als reine objektorientierte Sprache die perfekte Wahl treffen. C++ hingegen lässt sowohl das prozedurale, als auch das objektorientierte Paradigma zu. Dadurch können Programme in C++ schon mal ganz schön unsauber werden.

[Kurzer]

Über kurz oder lang werde auch ich zu Win7 wechseln(*) (ja, ich bin so ein Upgradeverweigerer ). Vermutlich schon recht bald. Da wird dann .NET wahrscheinlich eh von Haus aus bei sein, oder?

Welche Entwicklungsumgebung würdest Du für C# denn empfehlen und kann man damit dann EXEn bauen, die dann selbst nicht das .NET benötigen?

*) Vorher will ich aber eine wasserdichte Möglichkeit finden, um das Win7 zwar auf dem neusten Stand zu halten, aber diese Win10 Spy-Updates nicht zu installieren. Solange ich dazu keine wirklich gute Lösung habe, bin ich noch zögerlich.

[Kurzer]

WTF!?

Code: Alles auswählen

#include <iostream>
int main()
{
  auto x = R"(Hello world!)";
  std::cout << x;
}

Die erzeugte EXE ist 1,3 MiB groß.

Kennt sich jemand mit dem MinGW64 Compiler aus und kann mir sagen, ob man da noch so ca. 95% reduzieren kann?

[shadow]

Hallo,

nimm die Debug-Symbole aus dem Kompilat raus (weiß nicht mehr, wie da die Parameter genau lauten). Und dann mit dem beigelegten Tool strip.exe mit "strip --strip-all meine.exe" alle sonstigen unnötigen Symbole entfernen. So habe ich zu "meiner Zeit" es immerhin auf 70-80 KB geschafft.

[Edit]
Empfehlen kann ich dir (Free-)Pascal.
www.freepascal.org
mit eigener IDE
www.lazarus.freepascal.org

Das ist wesentlich leichter für den Einstieg in OOP. Dafür hast du aber gewaltige EXE-Dateigrößen. Ich nutze auch heute noch ObjectPascal mit Delphi im professionellen Einsatz.
Und noch Java. Aber da kannst du damit bestimmt nichts wegen der Runtime wie bei .NET anfangen.

[edel]

- Das Erstellen von DLLs, die ich mit PB nutzen kann
- Das Erstellen von Libs / neue Funktionen für PureBasic, wobei ich dies bisher noch nicht gemacht habe und den genauen Workflow dafür nicht kenne. Das wäre dann aber eine andere Baustelle. Ich erwähne es nur der Vollständigkeit halber.

Hier faellt .Net raus. Bei einer DLL mag es noch uber Umwege gehen, hoert aber bei statischen Libs dann auf. Hier waere nur Compiler die C/C++ koennen (oder erzeugen) interessant. Mir fallen auch nur ein paar Sprachen ein: Vala, Freebasic oder eben C++.

[NicTheQuick]

@Kurzer: C++ Compiler haben in der Regel unendlich viele Flags, die alles mögliche darin bewirken können. Mit MinGW direkt hab ich keine Erfahrung, aber schau doch mal hier: How to reduce the size of executable produced by MinGW g++ compiler?
Damit kriegst du ein "Hello World" offenbar auf 9 kB.
Die wichtigsten Gründe zum "kleiner" machen sind das Optimize-Flag, das auf die Größe optimiert und die Wahl des Linkens, dynamisch oder statisch.
Aber denk dran, dass die Größe der Executable nicht alles ist. Ich erreiche meistens höhere Ausführgeschwindigkeiten, wenn ich auch auf Geschwindigkeit optimieren lasse. Das erhöht die Größe des Executable meistens, aber das liegt daran, dass viele Funktionen dann "inline" verwendet werden und nicht per Function Call aufgerufen werden. Also versteife dich zukünftig besser nicht ganz auf die Größe.

[Kurzer]

@Shadow & Nic:

Danke für Eure Hinweise bin gerade fast gleichzeitig mit Euch über die statische Bindung der libs gestolpert.

strip.exe (Kommandozeilenoption -s) zusammen mir "-Os" bringt schon mal Reduktion um 50% auf 512 KiB.

Unter http://tdm-gcc.tdragon.net/quirks habe ich dann folgendes gelesen:

TDM-GCC doesn't link your programs with the libgcc or libstdc++ runtime DLLs by default.
[...]
Your programs will not rely on any additional DLLs when compiling with default options.
TDM-GCC still includes DLL versions of the libgcc and libstdc++ runtimes, which you can enable for your program with "-shared-libgcc" and "-shared-libstdc++" if desired.

Wenn ich "-shared-libgcc" nutze und damit die statische Einbindung der Libs unterdrücke, dann komme ich auf eine EXE von ca. 12 KiB Größe, muss dann aber zwei DLLs mitliefern, die zusammen ca. 1 MiB groß sind. Wenn ich das richtig verstanden habe, dann kann, im Vergleich, der Microsoft C++ Compiler aus Visual Studio nur deswegen so kleine EXEn bauen, weil seine DLLs eh schon auf den meisten Windows Rechner vorhanden sind und man diese nicht statisch einbinden muss.
Zum Ausprobieren mache ich mir wegen der Größe keine Sorgen. Sollte ich aber Funktionserweiterungen für PB damit erstellen wollen, dann würde ich ungern bei jeder Funktion diese 512 KiB mit rumschleppen.

Wie hat Fred das mit dem PB Libs gemacht? Ich glaube er nutzt Visual Studio von Microsoft, oder? Da eine "Hello World" Exe aus PB nicht so groß wird, scheint es hier diese (wie sagt man?) späte Bindung zu geben?

- Heißt das, dass PB Exen unter Windows in jedem Fall auf irgendwelche Windows DLLs angewiesen sind (auch wenn keine API Aufrufe im Code stecken)?

- Wäre es eine Option den Linker aus einer Visual Studio Installation zu extrahieren und in DevC++ einzubinden oder geht sowas nicht?

@edel: Danke für Deinen Tipp mit FreeBasic. Das schaue ich mir auch an.