Welche Programmiersprachen gefallen euch neben C und C++?



  • Für kleine Anwendungen C#.



  • Hi,

    für kleine und mittlere Aufgaben ist auch Delphi nicht von der Hand zu weisen. Es erzeugt recht sichere Programme, zumindest stellt es alle dafür nötigen Hilfsmittel bereit und die Programmentwicklung ist eigentlich schneller als mit c++.

    Ein wesentlicher vorteil von Delphi ist die gegenüber C++ andere Syntax, so dass es leichter fällt, die beiden Programmiersprachen auseinander zu halten und nicht so die Gefahr besteht wie bie c++, c# und Java, dass man in allen dreien den gleichen Mischmasch-Stil versucht.

    Gruß Mümmel



  • Vorwort: Ich programmiere in C++ seit knapp 10 Jahren. War von Anfang an begeistert und positiv überrascht (Destruktoren, Templates). Aber die Sprache hat eben auch ihre hässlichen Warzen. C mag ich nicht so. Es ist doch nur "portable assembly" und bietet in Sachen Abstraktion zu wenig für meinen Geschmack.

    Welche Sprachen mir noch so gefallen? Rust! Und wenn ich irgendwann mal wieder selbst geschriebenen Code auf einer JVM oder DVM laufen lassen will, dann würde ich es mit Kotlin probieren.



  • Vielleicht doch noch etwas, das bisher nicht erwähnt wurde (auch wenn mich der OP nicht gerade motiviert hat, ernsthaft zu antworten ;)):

    Ich bin von Lua sehr angetan, vor allem wegen der Flexibilität der Sprache bei gleichzeitig sehr kleinem Interpreter. Von Haus aus kennt die Sprache noch nicht einmal OOP, aber sie ist dank Metatables so dynamisch, dass man OOP so gut mit vorhandenen Sprachelementen hinzu-implementieren kann, dass man gar nicht mehr merkt, dass der Sprache selbst eigentlich keine OOP direkt untersützt. Auch dass das kleine Ding Operator Overloading beherrscht, finde ich sehr erfreulich.

    Was ich an Lua nicht mag, ist dass Indizes mit 1 beginnen - bei den ganzen zusätzlichen "+1/-1" zur Korrektur bei Index-Berechnungen merkt man schon, dass bei 0 zu beginnen, die "natürlichere" Variante ist, besonders wenn man viel mit Indizes und "Ranges" hantiert.

    Auch dass alle numerischen Berechnungen mit double -Werten erfolgen stört mich, allerdings auch nur da ich die Sprache in einem System einsetze, wo ich viel mit int64 -Werten zu tun habe, deren Wertebereich auch voll ausgenutzt wird. Diese lassen sich in Lua in Gegensatz zu int32 , nur sehr umständlich korrekt mit double -Werten abbilden.

    Dennoch, Lua ist meistens eine gute Wahl wenn man in einem Softwareprojekt irgendwann mal Skripting-Funktionalität benötigt und das Ganze dennoch schlank halten möchte, die Entwicklung einer eigenen Skriptsprache zu aufwändig ist, oder aus NIH-Gründen abgelehnt wird (Hurra! Noch eine neue Sprache! ;)).



  • Hi Finnegan,

    Die Frage der Indices ist in Delphi optimal gelöst, da gibt man an, von wo bis wo die gehen sollen.

    Gruß Mümmel



  • Kotlin sieht ja mal sehr interessant aus. Danke für den Tipp. Vor allem wird als Plattform Android und Javascript unterstützt.



  • Finnegan schrieb:

    Was ich an Lua nicht mag, ist dass Indizes mit 1 beginnen - bei den ganzen zusätzlichen "+1/-1" zur Korrektur bei Index-Berechnungen merkt man schon, dass bei 0 zu beginnen, die "natürlichere" Variante ist

    Ja, wenn man routinemäßig den Index auf die Startadresse addiert, um die Zieladresse zu erhalten, ist es natürlicher, mit Index 0 anzufangen. Sonst ja eher nicht - natürlicher ist, von 1 an zu zählen.

    Finnegan schrieb:

    Diese lassen sich in Lua in Gegensatz zu int32 , nur sehr umständlich korrekt mit double -Werten abbilden.

    wie machst Du das denn mit dem int64-auf-double-Abbilden?



  • Finnegan schrieb:

    Ich bin von Lua sehr angetan,

    ich auch.

    Finnegan schrieb:

    vor allem wegen der Flexibilität der Sprache bei gleichzeitig sehr kleinem Interpreter. Von Haus aus kennt die Sprache noch nicht einmal OOP, aber sie ist dank Metatables so dynamisch, dass man OOP so gut mit vorhandenen Sprachelementen hinzu-implementieren kann, dass man gar nicht mehr merkt, dass der Sprache selbst eigentlich keine OOP direkt untersützt. Auch dass das kleine Ding Operator Overloading beherrscht, finde ich sehr erfreulich.

    Das ist ja mal das blödeste Argument: OOP in einer Nicht-OO-Sprache durch zusätzliche Krücken betreiben. Nein, da kann ich ja auch sagen "Das tolle an C und ASM ist, das ich da auch mit Hilfsmitteln OOP machen kann."

    Eine Sprache soll MIR Arbeit abnehmen! Warum soll ich der Sprache Arbeit abnehmen? Wenn ich OOP machen will, nehme ich eine OO-Sprache. Davon gibt es reichlich zur Auswahl, z.B. AngelScript.

    Und wenn Lua mir keine OO-Features anbietet, dann mache ich das damit auch nicht. Ich benutze Lua so, wie es gedacht wurde: für Scripte und Konfigurationen. Dafür ist Lua 1A geeignet.

    Finnegan schrieb:

    Was ich an Lua nicht mag, ist dass Indizes mit 1 beginnen - bei den ganzen zusätzlichen "+1/-1" zur Korrektur bei Index-Berechnungen merkt man schon, dass bei 0 zu beginnen, die "natürlichere" Variante ist, besonders wenn man viel mit Indizes und "Ranges" hantiert.

    Ehm, jeder nicht Informatiker oder C-lastige Programmierer fängt bei 1 an zu zählen. Sage einem Schüler "Zähl mal bitte bis 10!", und er wird nicht mit "0" anfangen. Selbst jeder Informatiker wird in der Freizeit bei 1 anfangen zu zählen.

    Finnegan schrieb:

    Auch dass alle numerischen Berechnungen mit double -Werten erfolgen stört mich, allerdings auch nur da ich die Sprache in einem System einsetze, wo ich viel mit int64 -Werten zu tun habe, deren Wertebereich auch voll ausgenutzt wird. Diese lassen sich in Lua in Gegensatz zu int32 , nur sehr umständlich korrekt mit double -Werten abbilden.

    Verstehe ich nicht, wie das funktionieren soll? Da sollten doch irgendwann falsche Berechnungen bei dir auftauchen?

    Warum kompilierst du das Lua nicht einfach mit dem passenden int64? Immerhin kann man das durch ein Makro bei Lua machen. Auf alten Systemen ohne FPU wird Lua meistens mit int32 kompiliert, weil Fließkomma da nur mit Emulation funktionieren würde und zu langsam wäre. Dann solltest du Lua auch an deine Bedürfnisse anpassen können...



  • Zee++ schrieb:

    Welche Programmiersprachen gefallen euch neben C und C++?

    • C gefällt mir nicht
    • C++ gefällt mir zwar besser, aber auch nicht perfekt
    • Java find ich vom Grundsatz her angenehmer als C++ (mit Abstrichen)
    • Bevorzugen tue ich seit einigen Jahren C#

    Viele Sprachen die gerne auch als "C++"-Nachfolger propagiert werden sagen mir garnicht zu. Entweder akzeptiert man das es gänzlich andere Sprachen sind und stellt sie auch entsprechend vor, oder man sollte sich Semantisch und Syntaktisch an C++ orientieren (nicht in allen Details, C++ hat einige Mängel, aber auch nicht so das man sich fragt warum man dann überhaupt C++ erwähnt).

    Gänzlich nicht gefallen tuen mir die an Pascal und Basic orientierten Sprachen, alle Sprachen wo man selbst mit C++ weniger Klammern nutzt...



  • QuickBasic



  • Ich habe mal eine wenig zu Kotlin recherchiert. Wirklich nett aber ich starte doch erst einmal mit Java durch. Das sollte für all meine Projekte reichen und geht auch gut von der Hand.

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.


  • Mod

    Wolltest du diesem pösen, pösen Forum nicht fernbleiben?



  • Zee++ schrieb:

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.

    Zwingt dich ja keiner zu. Kannst doch alles in cpps schreiben... 🙄



  • Zee++ schrieb:

    Ich habe mal eine wenig zu Kotlin recherchiert. Wirklich nett aber ich starte doch erst einmal mit Java durch. Das sollte für all meine Projekte reichen und geht auch gut von der Hand.

    Mit Java 8 ist Java gar nicht mehr so schlecht und ich benutze sie heute ganz gerne. Gibt zwar noch ein paar Dinge die man vermisst und man mehr Code schreiben muss, aber ich finde, eine Sprache sollte irgendwann auch mal einen Schlußstrich ziehen können.

    Zee++ schrieb:

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.

    Der Header-Quatsch ist so ziemlich das einzige wofür ich C++ hasse. Ansonsten finde ich C++ super, wenn man mich nicht zwingt jeden Template-Magic-Unsinn zu benutzen (für die die es mögen und können, soll es drin sein).



  • Schlangenmensch schrieb:

    Zee++ schrieb:

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.

    Zwingt dich ja keiner zu. Kannst doch alles in cpps schreiben... 🙄

    Nein, kann man eben nicht. Außer du willst ihn in die Pfanne hauen, das er eine riesige Datei hat. Was aber keine Lösung ist. Es geht um Lösungen, nicht um Unsinn.



  • Hi Artchi,

    Artchi schrieb:

    Der Header-Quatsch ist so ziemlich das einzige wofür ich C++ hasse.

    Eindeutig schlechtes Sprachdesign. 😉
    Das ist in Delphi um Welten besser gelöst:
    Da hat jede Datei einen "Headder-Teil" und einen "Programm-Teil"
    interface stellt die Headder-Datei dar und implementation die eigentliche Programmdatei
    Die uses-Angaben entsprechen den include-Anweisungen.
    Alles im Interface-Teil ist nach außen sichtbar, der Rest nicht.
    Dazu noch ein par andere syntaktische Schnerzchen.

    unit EineUnit;
    
    interface
    
    uses
      Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
      Dialogs, StdCtrls, ExtCtrls, Buttons;
    
    type
      TForm1 = class(TForm)
        Panel1: TPanel;
        Image1: TImage;
        Label1: TLabel;
        TBitBtn1: TBitBtn;
      private
        { Private-Deklarationen }
      public
        { Public-Deklarationen }
        function  Irgendwas( Parameter : integer ) : String;
      end;
    
    var
      GrussForm: TGrussForm;
    
    implementation
    
    {$R *.dfm}
    uses NochNeUnit;
    
    function TForm1.Irgendwas( Wert : integer): String;
    var
      n : integer;
    begin
      case Wert of
        1 : n := Label1.Caption := 'Müller';
        2 : n := Label1.Caption := 'Meier'
      end;
    end;
    
    end.
    

    Der einzige Nachteil ist, dass an Stelle von {} begin und end geschrieben werden muss, und das Zuweisungen wie
    a += b;
    oder
    a = (b < c ) ? c : b;
    in Delphi nicht möglich sind. Gewöhnt man sich aber auch dran.

    Gruß Mümmel


  • Mod

    Artchi schrieb:

    Schlangenmensch schrieb:

    Zee++ schrieb:

    Ist eigentlich mal anzusehen ob bei C und C++ dieser Header/Source Quatsch weg fällt? Wir haben 2017, da muss man sich sowas nun wirklich nicht mehr freiwillig antun.

    Zwingt dich ja keiner zu. Kannst doch alles in cpps schreiben... 🙄

    Nein, kann man eben nicht. Außer du willst ihn in die Pfanne hauen, das er eine riesige Datei hat. Was aber keine Lösung ist. Es geht um Lösungen, nicht um Unsinn.

    Das ist Reaktion auf Zee++s anderen Thread, wo er genau dieses Vorhaben beschrieb, und ziemlich pampig wurde, weil ihm nicht gefiel, dass ihm von diesem Vorhaben abgeraten wurde.



  • Wo wurde ich denn pampig. Da hast bloß nicht gerafft worum es mir da ging.

    P.S. Lösche lieber meinen Account, oder weißt du auch nicht was ich damit meine?



  • muemmel schrieb:

    Das ist in Delphi um Welten besser gelöst:
    Da hat jede Datei einen "Headder-Teil" und einen "Programm-Teil"

    und was ist, wenn man an eine externe Library linken will, deren Quellcode nicht offen ist? In C/C++ reichen dem Compiler dazu die Header. Wie ist das in delphi?



  • zufallswert schrieb:

    muemmel schrieb:

    Das ist in Delphi um Welten besser gelöst:
    Da hat jede Datei einen "Headder-Teil" und einen "Programm-Teil"

    und was ist, wenn man an eine externe Library linken will, deren Quellcode nicht offen ist? In C/C++ reichen dem Compiler dazu die Header. Wie ist das in delphi?

    Du weisst schon dass die VCL in der Starter Edition ohne Quellcode geliefert wird? Es ist kein Problem...

    So Ähnlich ... warum in D DI File existieren.


Anmelden zum Antworten