Coffee++ - Sprache, die zu C++ kompiliert

joomoo

Ich hab im Internet ein paar Fragen zu Programmiersprachen gefunden, die ähnlich wie CoffeeScript, C++-Code ausgeben. Die Idee hat mir gefallen. Deswegen habe ich eine einfach erste Version dieser Sprache mal versucht zu entwerfen:

http://jhasse.github.io/coffeepp/

Der Compiler unterstützt bis jetzt nur sehr einfache Sachen, allerdings glaube ich ein fertiger Compiler wäre nicht mehr sehr weit entfernt, da ich ja wirklich kaum was ändere.

Was haltet ihr von der Idee? Lohnt es sich daran weiter zu arbeiten? Hätte vllt sogar jemand Lust daran mitzuarbeiten?

Zeus

Grrrr sorry wegen der Nebensächlichkeit - aber weiß du wielang ich gebraucht habe, zu peilen, dass deine URL nicht github ist?

hustbaer

joomoo schrieb:

da ich ja wirklich kaum was ändere.

Was ist dann der Sinn der ganzen Sache?
Wenn du nicht viel mehr machst als Textverarbeitung, dann wird sich die Sprache in keinem wesentlichen Punkt deutlich von C++ unterscheiden. Ok, etwas andere Syntax, aber was bringt das? Ist doch eher lästig.

Wer, der schon C++ kann, wird Lust haben nochmal ne andere Syntax zu lernen, damit er dann XYZ++ programmieren kann? Was ja im Endeffekt das selbe ist, nur halt anders geschrieben.

Und wie sollen Leute die nicht C++ können jemals deine Sprache lernen, ohne vorher C++ zu lernen? Und wenn sie das tun (vorher C++ lernen), dann können sie ja nachher C++, und gehören damit wieder zur ersten Gruppe. Für die es eben keinen Grund gibt XYZ++ zu lernen.

Was haltet ihr von der Idee? Lohnt es sich daran weiter zu arbeiten? Hätte vllt sogar jemand Lust daran mitzuarbeiten?

Ehrlich gesagt nichts.

Ist vielleicht eine nette Spielerei, aber so lange du hier keinen "echten" Compiler baust (und was du schreibst legt nahe dass du das nicht tust), wirst du nichtmal besonders viel dabei lernen.

Und praktische Anwendung sehe ich eben keine.

joomoo

hustbaer schrieb:

joomoo schrieb:

da ich ja wirklich kaum was ändere.

Was ist dann der Sinn der ganzen Sache?
Wenn du nicht viel mehr machst als Textverarbeitung, dann wird siche die Sprache in keinem wesentlichen Punkt deutlich von C++ unterscheiden. Ok, etwas andere Syntax, aber was bringt das?

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

hustbaer schrieb:

Ehrlich gesagt nichts.

Ist vielleicht eine nette Spielerei, aber so lange du hier keinen "echten" Compiler baust (und was du schreibst legt nahe dass du das nicht tust), wirst du nichtmal besonders viel dabei lernen.

Und praktische Anwendung sehe ich eben keine.

Okay, danke für die ehrliche Meinung.

Also gelernt hab ich bis jetzt einiges (Boost.Test, waf-build), aber jetzt würden halt langsam so die Arbeiten kommen, bei denen man weniger lernt, die eher nerven, deswegen frag ich.

SeppJ

joomoo schrieb:

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Ich verstehe nicht, wie deine Sprache diese umgehen will. Soll alles in eine Datei? Das kannst du in C++ doch auch machen - es zwingt dich niemand Header zu schreiben. Die sind der Übersicht halber da, damit du den Code in Module trennen kannst, ohne jedes Mal alle Deklarationen zu wiederholen. Wenn bei deiner Sprache der Code in Module getrennt werden sollte, wie weiß dann der Compiler, wie die Deklarationen aussehen?

knivil

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Und finde das gerade gut, nicht so wie Java.

joomoo

SeppJ schrieb:

joomoo schrieb:

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Ich verstehe nicht, wie deine Sprache diese umgehen will. Soll alles in eine Datei?

Siehe http://jhasse.github.io/coffeepp

Das kannst du in C++ doch auch machen - es zwingt dich niemand Header zu schreiben. Die sind der Übersicht halber da, damit du den Code in Module trennen kannst, ohne jedes Mal alle Deklarationen zu wiederholen. Wenn bei deiner Sprache der Code in Module getrennt werden sollte, wie weiß dann der Compiler, wie die Deklarationen aussehen?

Lassen sich aus den Definitionen herleiten.

knivil schrieb:

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Und finde das gerade gut, nicht so wie Java.

Okay dann ist meine Sparache nichts für dich
Aber ich glaube damit bist du in der Minderheit, die meisten modernen Programmiersprachen machen es nicht so wie C++.

SeppJ

joomoo schrieb:

SeppJ schrieb:

joomoo schrieb:

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Ich verstehe nicht, wie deine Sprache diese umgehen will. Soll alles in eine Datei?

Siehe http://jhasse.github.io/coffeepp

Das habe ich schon gelesen, aber ich verstehe es nicht. Was, wenn ich einen Dog auch woanders benutzen möchte?

Lassen sich aus den Definitionen herleiten.

Und wo kommen die her? Aus einem Header?

Xin

joomoo schrieb:

Die Idee hat mir gefallen. Deswegen habe ich eine einfach erste Version dieser Sprache mal versucht zu entwerfen:

http://jhasse.github.io/coffeepp/

Das sieht für mich nach einer deutlichen Tendenz zu Python aus.

joomoo schrieb:

Der Compiler unterstützt bis jetzt nur sehr einfache Sachen, allerdings glaube ich ein fertiger Compiler wäre nicht mehr sehr weit entfernt, da ich ja wirklich kaum was ändere.

Was wäre dann der große Vorteil Deiner Sprache.

joomoo schrieb:

Was haltet ihr von der Idee? Lohnt es sich daran weiter zu arbeiten? Hätte vllt sogar jemand Lust daran mitzuarbeiten?

Ich arbeite ebenfalls an einer Programmiersprache, die in der Lage ist C++-Code zu "rendern". Der Grund ist vergleichbar einfach: ich möchte meine Sprache zur C++-Codegenerierung nutzen, solange ich noch nicht wirklich sinnvoll darin programmieren kann. Ich plane derzeit allerdings nicht, komplette Programme nach C++ zu transferieren. Hier gehen wir also offenbar einen unterschiedlichen Weg.

Wenn Deine Sprache keinen Mehrwert zu C++ liefert, wird sie sich niemand ansehen, schon alleine weil es ein zusätzliches Risiko darstellt eine weitere Schicht einzuführen, die ja auch Fehler enthalten könnte und in die man sich zunächst einarbeiten muss.

Dieses Risiko und der Mehraufwand muss durch einen entsprechenden Mehrwert kompensiert werden.

Ich generiere vorrangig spezielle Wrapper-Klassen, die sich bei mir laufend wiederholen, zum Beispiel "Enum-Klassen":

TrafficLightState is flags
{
  Red, Yellow, Green
};

wird zu

class TraficLightState
{
  unsigned int Value;

  TrafficLightState( unsigned int value )
    : Value( value ) {}

public:
  static TrafficLightState const Red;
  static TrafficLightState const Yellow;
  static TrafficLightState const Green;

  // Vergleichsoperatoren etc...
};

und die entsprechende .cpp Datei.

Mir gefällt Deine Idee, schließlich arbeite ich an etwas ähnlichem. ^^

Was Deine Tendenz angeht, Headerdateien zu vermeiden, so bin ich halb auf Deiner Seite. Es wird bei mir auch keine vom User generierten Headerdateien mehr geben, da sie vorrangig Redundanz erzeugen. Redundanz ist zu vermeiden und daher gehen neuere Sprachen den durchaus richtigen Weg, Headerdateien zu vermeiden, um Redundanz zu vermeiden.

Allerdings sind die Headerdateien auch Kurzinformationen, die für den Compiler schnell zu lesen sind und für den Menschen einen schnelleren Überblick erlauben. Sie haben also durchaus auch Vorteile. Ich werde daher auf Header-Dateien nicht verzichten, allerdings generiere ich automatisiert Header aus den Quellen.

Eine ganz klare Absage muss ich dir allerdings für die Verwendung von "auto" erteilen. Du bleibst zwar statisch typisiert, aber ich befürchte, dass das für den Benutzer auf kurz oder lang unverständlich wird, wenn er die gewählten Typen nicht wirklich nachvollziehen kann, aber trotzdem casten muss. Ich denke - ohne das groß gedanklich durchgespielt zu haben - hier wirst Du Dir bei größeren Programmen Probleme ins Haus holen.

joomoo

SeppJ schrieb:

joomoo schrieb:

SeppJ schrieb:

joomoo schrieb:

Z.B. getrennte Header und Source-Dateien stören mich schon sehr an C++.

Ich verstehe nicht, wie deine Sprache diese umgehen will. Soll alles in eine Datei?

Siehe http://jhasse.github.io/coffeepp

Das habe ich schon gelesen, aber ich verstehe es nicht. Was, wenn ich einen Dog auch woanders benutzen möchte?

Dann schreibst du

import Dog

sofern die Datei Dog.cf++ und nicht Test.cf++ heißt wie auf der Seite (das sollte ich vllt noch ändern).

Dies führt dann zu

#include "Dog.hpp"

und diese Datei wurde von Coffee++ generiert.

Lassen sich aus den Definitionen herleiten.

Und wo kommen die her? Aus einem Header?

Aus der .cf++ Datei.

Xin schrieb:

joomoo schrieb:

Die Idee hat mir gefallen. Deswegen habe ich eine einfach erste Version dieser Sprache mal versucht zu entwerfen:

http://jhasse.github.io/coffeepp/

Das sieht für mich nach einer deutlichen Tendenz zu Python aus.

Stimmt

joomoo schrieb:

Was haltet ihr von der Idee? Lohnt es sich daran weiter zu arbeiten? Hätte vllt sogar jemand Lust daran mitzuarbeiten?

Ich arbeite ebenfalls an einer Programmiersprache, die in der Lage ist C++-Code zu "rendern". Der Grund ist vergleichbar einfach: ich möchte meine Sprache zur C++-Codegenerierung nutzen, solange ich noch nicht wirklich sinnvoll darin programmieren kann. Ich plane derzeit allerdings nicht, komplette Programme nach C++ zu transferieren. Hier gehen wir also offenbar einen unterschiedlichen Weg.

Wenn Deine Sprache keinen Mehrwert zu C++ liefert, wird sie sich niemand ansehen, schon alleine weil es ein zusätzliches Risiko darstellt eine weitere Schicht einzuführen, die ja auch Fehler enthalten könnte und in die man sich zunächst einarbeiten muss.

Dieses Risiko und der Mehraufwand muss durch einen entsprechenden Mehrwert kompensiert werden.

Da hast du natürlich Recht. Aber bei CoffeeScript hat es z.B. auch gereicht.

Eine ganz klare Absage muss ich dir allerdings für die Verwendung von "auto" erteilen. Du bleibst zwar statisch typisiert, aber ich befürchte, dass das für den Benutzer auf kurz oder lang unverständlich wird, wenn er die gewählten Typen nicht wirklich nachvollziehen kann, aber trotzdem casten muss. Ich denke - ohne das groß gedanklich durchgespielt zu haben - hier wirst Du Dir bei größeren Programmen Probleme ins Haus holen.

Also die alte Syntax ist immer noch möglich:

int a = 5;

Desweiteren bedeutet die verwendung von auto ja nicht, dass man keine Typen angeben kann:

dog := make_shared<Dog>(123)
vec := vector<int>(5)

Vorteile dieser Syntax sind, dass man verschiedene Fehler vermeidet. Siehe http://herbsutter.com/2013/06/13/gotw-93-solution-auto-variables-part-2/

SeppJ

joomoo schrieb:

Dann schreibst du
import Dog
sofern die Datei Dog.cf++ und nicht Test.cf++ heißt wie auf der Seite (das sollte ich vllt noch ändern).

Verstehe. Also quasi viele der Nachteile eines Headers (außer, dass man Header ans sich benötigt) und alle Nachteile einer riesigen Einzeldatei vereint. Jetzt verstehe ich auch, was knivil meinte.

Da das zu Java vs. C++ ausarten wird, verabschiede ich mich vom Thema. Ich will dir schließlich nicht vorschreiben, was du mögen sollst. Bloß noch eine Anmerkung:

Aber ich glaube damit bist du in der Minderheit,

Glaube ich nicht.

joomoo

SeppJ schrieb:

joomoo schrieb:
Dann schreibst du
import Dog
sofern die Datei Dog.cf++ und nicht Test.cf++ heißt wie auf der Seite (das sollte ich vllt noch ändern).
Verstehe. Also quasi viele der Nachteile eines Headers (außer, dass man Header ans sich benötigt) und alle Nachteile einer riesigen Einzeldatei vereint.

Kannst du das etwas erläutern?

Aber ich glaube damit bist du in der Minderheit,

Glaube ich nicht.

Wieso machen es die meisten Sprachen dann nicht so wie C++? Und warum will man es dann auch bei C++ einführen mit Modules?

Kellerautomat

joomoo schrieb:

Wieso machen es die meisten Sprachen dann nicht so wie C++? Und warum will man es dann auch bei C++ einführen mit Modules?

Weil Module dem Include-System einfach ueberlegen sind. Vorwaertsdeklarationen sind Bullshit, genauso Copy&Paste (nichts anderes ist #include).

joomoo

@Xin:
Hier wird nochmal erklärt, warum man eigentlich immer wenn mögich auto verwenden sollte: http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ (Siehe Solution 3)

Kellerautomat schrieb:

joomoo schrieb:

Wieso machen es die meisten Sprachen dann nicht so wie C++? Und warum will man es dann auch bei C++ einführen mit Modules?

Weil Module dem Include-System einfach ueberlegen sind. Vorwaertsdeklarationen sind Bullshit, genauso Copy&Paste (nichts anderes ist #include).

Copy & Paste ist #include nicht ganz, da Compiler optimieren. Das heißt es ist schneller, als würdest du wirklich per Hand die Header an den entsprechenden Stellen einfügen.

Xin

joomoo schrieb:

@Xin:
Hier wird nochmal erklärt, warum man eigentlich immer wenn mögich auto verwenden sollte: http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ (Siehe Solution 3)

Immer wenn möglich...

Amüsant finde ich das Argument mit der Initialisierung. Eine Klasse ist initialisiert, wenn sie einen Default-Konstruktor hat. Hat sie keinen, muss ich sie initialisieren.

Die Konvertierung "auto var = type{ init }" statt "type var = init"... joah... das klingt mir teils dann doch ein wenig nach einem Beweis, dass Dinge mit auto gehen, aber für mich nicht überzeugend, dass das jetzt der Weisheit letzter Schluss ist.

Ich habe nichst gegen auto, ich benutze die Anweisung selbst regelmäßig. Aber ich benutze eine IDE nicht zur Dokumentation. Ich benutze aber Typen zur Dokumentation meines Quelltextes. auto verschweigt mir diese Typen.

Man kann für und gegen auto sein. Aber bei mir gehen die Alarmglocken an, wenn irgendwo ein immer oder ein niemals genannt wird. Ich benutze auch goto fast niemals - aber ich benutze es, obwohl man es auch anders lösen kann. Anders ist aber nicht zwangsläufig besser wenigstens gleichgut.

Wie läuft's mit Deiner Sprache?