Welche Programmiersprachen gefallen euch neben C und C++?

SeppJ

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

Schlangenmensch

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...

Artchi

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).

Artchi

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.

muemmel

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

SeppJ

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.

Zee++ 0

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?

Zeus

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.

Finnegan

Artchi schrieb:

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."

Das ist ein sehr oberflächliches Urteil: Das Kernargument war nicht dass man OOP irgendwie dazufrickeln kann, sondern dass man es am Ende "gar nicht mehr merkt, dass die Sprache kein OOP direkt unterstützt". Mein Satz war zwar etwas holprig formuliert, aber die Information lässt sich durchaus noch herausdestillieren. Das C-Analogon dazu wäre dass man nach einem "#include <oop.h>" glaubt, in C++ weiter zu programmieren (zumindest was Objektorientierung angeht).

Artchi schrieb:

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.

Ich sehe das nicht so eng: Ich empfinde die Abstraktionen, die OOP ermöglicht, auch in kleineren Skripten als sehr praktisch. Es reicht die Funktionalität einmal zu implementieren, und dann eine kleine Datei einzubinden, wenn man sie benötigt (include von einmal geschriebenen ~100 Zeilen). Sicher braucht man das nicht immer, und ich bin auch kein Freund davon, es mit der OOP allzu wild zu trieben, wie es beispielsweise Java tut. Ich implementiere in Lua allerdings die Logik diverser Objekte in einer 3D-Welt, und dort kommt mir das durchaus gelegen, da man damit von der Programmstruktur her elegant ein Interface and die "Weltobjekte" flanschen kann.

Artchi schrieb:

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.

Ich verstehe die Argumentation dahinter, mit 1 anzufangen, geschenkt. Meine persönliche Erfahrung damit ist allerdings, dass damit Indexberechnungen oft komplizierter wurden, so dass ich es letztendlich eher als Nachteil empfand. Das kann allerdings auch vornehmlich an dem liegen, was ich implementiert habe, vielleicht fällt es in anderdem Code weniger auf. Als typisches Beispiel sei hier die Adressierung von Elementen in einem eindimensionalen Array genannt, welches ich als zweidimensionale, x/y-adressierte Matrix interpretieren möchte:
So etwas wie i = ((y - 1) * width + (x - 1)) + 1 anstatt i = y * width + x ist mir halt oft genug untergekommen*, um meinen Mißmut über die Array-Adressierung auf das derzeitige Level zu steigern. Ich komme damit klar, aber "mögen" tue ich es deshalb nicht.

*Nachtrag: Wenn ich mir das gerade nochmal so ansehe, fällt mir auf, dass ich die Berechnung nicht wirklich vereinfacht habe, das Beispiel ist also nicht so gut gewählt ... dennoch hatte ich immer den Eindruck, dass solche -1/+1-Korrekturen für den Index häufiger notwendig sind, als in vergleichbarem Code in Sprachen, wo Arrays bei 0 beginnen. Für mich sind dadurch einige Algorithmen oft ein wenig unübersichtlicher geworden, obwohl ich zugebe, dass das auch Gewöhnungssache sein kann. Und auch wenn es subjektiv sein mag: Das "nicht mögen" ist nicht unbegründet

Artchi schrieb:

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?

Man bildet den int64 mit zwei number -Werten ab, und kümmert sich "manuell" um Übertrag bei Berechnungen (auch hier ist selbstgebaute OOP mit überladenen Operatoren hilfreich). Unterm Strich ist das de facto schon eine kleine BigInt-Implementierung, daher "umständlich". Ich denke dass sich 32-bit-integer-Operationen korrekt mit double -Werten implementieren lassen ist dir bewusst (?).

Artchi schrieb:

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...

Das wäre eine Möglichkeit, allerdings benötige ich auch Fließkommaberechnungen*, daher ist den number -Typen komplett durch int64 zu ersetzen keine gute Lösung. Da ich LuaJIT verwende, nutze ich derzeit den von dieser Implementation zur Verfügung gestellten 64-bit-Datentypen. Dennoch wäre es mir lieber wenn so etwas von der Sprache direkt unterstützt würde.

* Das hägt in meinem Fall mit den absoluten Weltkoordinaten zusammen, die ich verwende. Das System unterstützt sehr große Welten, daher ist eine absolute Weltkoordinate ein ( int64 , float )-Paar, da reine Fließkomma-Werte auf große Entfernungen eine zu hohe Ungenauigkeit hätten. Die meisten Berechnungen werden zwar in relativen Koordinaten und definitiv nicht mit Lua durchgeführt, dennoch ist es hilfreich, wenn sich solche Koordinaten ohne allzu viel Gepfriemel auch mit Lua handhaben lassen.

Zeus schrieb:

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...

davon gehe ich mal aus, daß es kein Problem ist. Aber wenn muemmel erklärt, daß es ein Vorteil von delphi sei, daß der Header Teil des Implementationsfiles ist, wie geht das dann beim Anbinden von nicht-offenen Libraries? In C/C++ braucht man dazu nur den Header, nicht die Implementation.

Tyrdal

muemmel schrieb:

Hi Artchi,

Artchi schrieb:

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

Eindeutig schlechtes Sprachdesign.

Das war der schwachen Hardware damals geschuldet.

Schlangenmensch

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.

Selbstverständlich war das nicht 100%ig ernst gemeint. Aber es ist perfekt legal auch cpp Dateien zu includen. Dann hat man nicht mal alles in einer Datei, auch wenn der Kompiler das dann alles zusammen zieht.

Aber ansonsten finde ich die C++ Lösung gar nicht mal so schlecht. Ich kann mir in der einen Datei in Ruhe anschauen, welche Funktionalität bereit gestellt wird, muss mich aber um die Implementierungsdetails nicht kümmern, welche schön gekapselt in einer cpp Datei liegen.

Artchi

Naja, es gibt ja heute IDEs die einem eine super Übersicht über die Schnittstellen anzeigen, da muss ich nicht extra eine Header-Datei schreiben/anbieten. Das Argument ist doch heute obsolet.

Viele Argumente sind doch welche aus den 1970er Jahren, als es keine Rechenleistung gab. Geschenkt! Die Argumente kommen mir immer trotzig vor, und nicht ehrlich. Aber heute langweilen sich die Entwicklungs-PCs die meiste Zeit.

Und die Header-Dateien widersprechen dem DRY-Prinzip (Don't Repeat Yourself). Ich muss code doppelt pflegen und synchron halten. Damals musste man da den Compiler und Computer unterstützen, weil der zu wenig Leistung hatte. Aber heute erwarte ich, das die Sprache mir verdammt nochmal die Arbeit abnimmt in dem ich nur eine Datei habe! Ich will am eigentlichen zu lösenden Problem arbeiten und nicht an einem Problem aus den 1970er. Sobald ich eine Signatur ändere/hinzufüge, muss ich das in einer zweiten Datei tun? Horror!

muemmel

Hi Zufallswert,

zufallswert schrieb:

Aber wenn muemmel erklärt, daß es ein Vorteil von delphi sei, daß der Header Teil des Implementationsfiles ist, wie geht das dann beim Anbinden von nicht-offenen Libraries? In C/C++ braucht man dazu nur den Header, nicht die Implementation.

Dafür gibts dann extra .pas-Dateien, bei denen der Implementierungsteil leer ist.

Gruß Mümmel

muemmel

Hi Artchi,

Artchi schrieb:

Ich muss code doppelt pflegen und synchron halten.

Ja und es besteht immer die Gefahr, dass man zwei nicht zueinander gehörende Dateien verwendet.

Gruß Mümmel

Zee++ 0

Artchi schrieb:

Ich muss code doppelt pflegen und synchron halten. Damals musste man da den Compiler und Computer unterstützen, weil der zu wenig Leistung hatte. Aber heute erwarte ich, das die Sprache mir verdammt nochmal die Arbeit abnimmt in dem ich nur eine Datei habe! Ich will am eigentlichen zu lösenden Problem arbeiten und nicht an einem Problem aus den 1970er. Sobald ich eine Signatur ändere/hinzufüge, muss ich das in einer zweiten Datei tun? Horror!

Zum Glück haben sich Programmiersprachen weiterentwickelt. Kotlin macht das nicht schlecht, zumal mit Kotlin Native auch noch nach Bare Metal gegriffen wird. Ich finde es toll, wenn eine Sprache sowohl mit einem JIT als auch native verwendet werden kann. Was für Smartphones reicht, sollte auch für das meiste andere reichen.

Ich denke C++ in der jetzigen Form wird immer mehr zur Nische, die gern gemieden wird. Das macht man nur noch wenn es gar nicht anders geht. Da wird dann ausgelost wer ins C++ Team muss.

Mechanics

Zee++ schrieb:

Ich denke C++ in der jetzigen Form wird immer mehr zur Nische, die gern gemieden wird.

Träum weiter

Fytch

Zee++ schrieb:

Welche Programmiersprachen gefallen euch neben C und C++?

Echte Männer programmieren in APL.

muemmel

Hi Fytch,

Fytch schrieb:

Zee++ schrieb:

Welche Programmiersprachen gefallen euch neben C und C++?

Echte Männer programmieren in APL.

Ne FORTRAN

Gruß Mümmel