suche passende Programmiersprache

[Xin]

Meine Intuition oder vielleicht doch meine Erbkrankheit "faulizitis" ^^ sagt mir, dass es Unsinn ist, dass in der Sprache X eine Datei mit "FileOpen" und in der anderen Sprache Y eine Datei mit "OpenFile" geöffnet wird. Mal haben sie gleiche Parameterfolgen, mal unterscheiden sie sich in der Reihenfolge. Was soll dieses Tohuwabohu?

Da es keine ganzheitliche Sicht auf die Welt gibt, es nicht überall Norm-Behörden gibt, gibt es Evolution.
Das eine entwickelt sich zu OpenFile() und das andere zu FileOpen(). Darum darf man in Amerika nicht schneller als 55 Meilen fahren und gilt z.B. in Australien als Geisterfahrer, wenn man rechts fährt.

Die Evolution findet inzwischen allerdings wieder zusammen: File.Open() ist derzeit Standard in allen populären Sprachen, das Metrische System setzt sich langsam durch und mir scheint, dass sich auch der Rechtsverkehr durchsetzen wird.

Ich bin dafür einen Standard für ALLE Sprachen einzuführen, die die wesentlichen Funktionen nach gleichem Schema definieren.

Wenn es nur einen Standard gibt, dann gibt es auch nur eine Sprache. Das ist ja zunächst auch gar nicht mal schlimm, schließlich könnten dann alle Entwickler das Problem auf die gleiche Art angehen.

Drei Kritikpunkte gibt es hier: Bestehende Systeme interessieren sich nicht für neue Standards. Was in Cobol geschrieben wurde, interessiert sich nicht dafür, wenn ein Java-Hype ausgebrochen ist. Da heißt es nur OPEN und wenn das System weiter kompilierbar sein soll, wird es auch in Zukunft OPEN heißen, bis das System neu geschrieben wird.
Cobolentwickler werden händeringend gesucht und mit viel Geld bestochen, ihr Hirn für die bestehende Systeme einschmelzen zu lassen. Das ist billiger als Neuschreiben. Kurz: als Standard wäre es unbezahlbar.

Kritikpunkt #2: Standards schränken Evolution ein. Hätte man sich auf OpenFile geeinigt, hätte man ein großes Dilema, als sich objektorientierte Programmierung durchgesetzt hat. File.Open() - das Objekt steht ganz vorne, abgetrennt von den Parametern.

Kritikpunkt #3: Standardisiert Lösungen helfen gut bei standardisierten Problemen. Das ist gleichzeitig der größte Kritikpunkt an Java und C#, weswegen sich diese Sprachen eben nicht für Probleme eignen, die für den Standard-Anwendungsentwickler nicht denkbar sind.

Das wäre schon mal ein kleiner Schritt für mein Ego und ein großer Schritt für alle Programmierer.

Setze gut begründete Regeln auf und hoffe darauf, dass sie von zukünftigen Entwicklern von künftigen Programmiersprachen gelesen und übernommen werden. Oder entwickle Deine eigene Sprache.

Im ersten Fall würde ich gerne mal drüber gucken.

[Necip]

... ich sehe schon, ich bin hier im richtigen Film! ^^

"Gut begründete Regeln"... hmm.... definiere "gut", definiere "grund", definiere "regel"

Abgeleitetet von den schmerzlichen Erfahrungen mit der Realität wäre ein signifikanter Grund der Schmerz- oder Lust-Faktor.

Tut es weh, ist es ein Grund das, was man tut, nicht wieder zu tun.
Macht es Spaß, spricht nichts dagegen es noch einmal zu tun. *ups i did it again* ^^

Mir fällt gerade ein, dass man eine Meta-Sprache sehr wohl für alle gängigen Sprachen definieren kann. Dies wäre nichts anderes als ein "Adapter"-Bibliothek.
In diese Bibliothek befinden sie alle Klassen und Methoden, die nach Namen und Aufrufkonvention exakt definiert sind.

// Unit: Adapter-Bib.
type
TMetaSprache_FileOperations = class
function Open(Name: string) : integer;
etc.
end;

implementation

TMetaSprache_FileOperations.Open(Name: string);
begin
Exit(FileOpen(Name); // implementation der Zielsprache
end;

// Unit Main

uses
AdapterBib;

procedure Main;
begin
TMetaSprache_FileOperations.Open('text.txt');
end;

[Xin]

... ich sehe schon, ich bin hier im richtigen Film! ^^

"Gut begründete Regeln"... hmm.... definiere "gut", definiere "grund", definiere "regel"

Hier kommen die Probleme auf: Um gut zu begründen musst Du soviele Szenarien abdecken, dass sich mindestens 99% der Programmierer darin wiederfinden.
Oder Du musst Einschränkungen machen in der Form: Diese Regeln gelten für ...
So wie bei Java und C#, die sich auf die Anwendungsprogrammierung konzentrieren.

Abgeleitetet von den schmerzlichen Erfahrungen mit der Realität wäre ein signifikanter Grund der Schmerz- oder Lust-Faktor.

Was Dich in der Realität schmerzt ist für andere das Lebenselixier. Womit wir wieder bei C# und Java wären, die z.B. Mehrfachvererbung ausschließen, was meine Form der Programmierung ad absurdum führt, da ich sehr viel über Mehrfachvererbung aufbaue.

Mir fällt gerade ein, dass man eine Meta-Sprache sehr wohl für alle gängigen Sprachen definieren kann. Dies wäre nichts anderes als ein "Adapter"-Bibliothek.
In diese Bibliothek befinden sie alle Klassen und Methoden, die nach Namen und Aufrufkonvention exakt definiert sind.

Klingt nach einer Header-Datei.

TMetaSprache_FileOperations.Open(Name: string);
begin
Exit(FileOpen(Name); // implementation der Zielsprache
end;

Da kommt was zurück. Ein Handle.
Du definierst hier einen sogenannten "Wrapper".

Wer hindert Dich daran, einen Wrapper in der Deiner bevorzugten Sprache zu definieren?

Mal so auf die Schnelle und nich' in schön:

Code: Alles auswählen

typedef FILE * fileHandle;

FileHandle OpenFile( std::string const &  filename, OpenFlags flags )
{
  return fopen( filename.c_str(), flags.StdCRepresentation() );
}

Du bist recht Delphi-lastig, wie mir scheint. Als C++-Favorisierer ist mir das zuviel Prosa. Mich schmerzt das. Mit welcher Begründung überzeugst Du mich von dem Roman, der da als Quelltext kommt?

[Necip]

... ich bin in einer C - Sekte gelandet? In einer Gruppe, die es gerade noch geschafft hat, knapp über dem AssemblerCode zu schweben - Ist nur Spass! Ich habe lange Zeit auch in C und C++ programmiert. Sie hat einen eleganten Syntax, mit ausreichend viel Spielraum durch PointerYoga im Nirwana der Bytes zu landen... dort wo die Programme ewig auf Eis gelegt sind.

Delphi habe ich unter Drohung eines Gehaltes hingenommen und wie es so schön heißt 1000 mal berührt und 1000 mal nichts passiert, setzt beim 1001. mal der Autopilot des Minds in Kraft, der mir dann suggeriert, wie wunderschön doch die Häßlichkeit ist!

Wie dem auch sei, beide Sprachen scheinen statistisch laut Google Insight auszusterben. Diese meine Maßnahmen sind also nur der klägliche Versuch ein letztes Frühling der Sprachen zu erleben, bevor das Licht ausgedreht wird...

Ok, tun wir so, als ob wir Morgen noch ein Tag zu leben haben!



Für den einen ist es nur ein "Wrapper" und für den anderen ist es eine "abgefahrene Möglichkeit Code so zu schreiben, dass sie leicht in jede andere Sprache zu portieren ist". Und das war auch schon mein ganzer Pulver, den ich verschießen konnte, um Dich doch noch von meiner Idee zu überzeugen.

Ist es mir gelungen? Nein? ... okä! Sprechen wir über etwas interessanterem: wer wird der nächste Fußballweltmeister?

[cloidnerux]

... ich bin in einer C - Sekte gelandet? In einer Gruppe, die es gerade noch geschafft hat, knapp über dem AssemblerCode zu schweben - Ist nur Spass! Ich habe lange Zeit auch in C und C++ programmiert. Sie hat einen eleganten Syntax, mit ausreichend viel Spielraum durch PointerYoga im Nirwana der Bytes zu landen... dort wo die Programme ewig auf Eis gelegt sind

Man muss immer Kompromisse eingehen^^

Wie dem auch sei, beide Sprachen scheinen statistisch laut Google Insight auszusterben. Diese meine Maßnahmen sind also nur der klägliche Versuch ein letztes Frühling der Sprachen zu erleben, bevor das Licht ausgedreht wird...

C wird nicht aussterben, dafür gibt es immer noch zu viel, was einfach sehr Hardwarenah geschrieben werden muss, wie z.B die Betriebssysteme, Treiber und ähnliches.
Pascal schon eher, da es nicht die selbe Stellung wie C/C++ hat.

Ist es mir gelungen? Nein? ... okä! Sprechen wir über etwas interessanterem: wer wird der nächste Fußballweltmeister?

RFC Stuttgartd oder Carpe Noctem natürlich!
Warte, reden wir vom RoboCup Fußballweltmeisterschaft?

[Xin]

... ich bin in einer C - Sekte gelandet? In einer Gruppe, die es gerade noch geschafft hat, knapp über dem AssemblerCode zu schweben - Ist nur Spass! Ich habe lange Zeit auch in C und C++ programmiert. Sie hat einen eleganten Syntax, mit ausreichend viel Spielraum durch PointerYoga im Nirwana der Bytes zu landen... dort wo die Programme ewig auf Eis gelegt sind.

C/C++-Sekte nicht, aber die Seite ist C++-lastig, ja.
Damit ergibt es sich, dass auch einige Leute da sind, die sich darum Gedanken machen, wie man Programme mit PointerYoga nicht gegen die Wand fährt.

Delphi habe ich unter Drohung eines Gehaltes hingenommen und wie es so schön heißt 1000 mal berührt und 1000 mal nichts passiert, setzt beim 1001. mal der Autopilot des Minds in Kraft, der mir dann suggeriert, wie wunderschön doch die Häßlichkeit ist!

Delphi ist Prosa, aber im Vergleich zu dem, was folgte durchaus akzeptabel.

Wie dem auch sei, beide Sprachen scheinen statistisch laut Google Insight auszusterben. Diese meine Maßnahmen sind also nur der klägliche Versuch ein letztes Frühling der Sprachen zu erleben, bevor das Licht ausgedreht wird...

Ok, tun wir so, als ob wir Morgen noch ein Tag zu leben haben!

Ich denke, dass hier ein ganz anderer Trend abzusehen ist: Desinteresse.

Programmierung steht bei Jugendlichen in Konkurrenz zu Battlefield 3, 400 Satellitenprogrammen, dem Internet mit all seinen Facebook, Chat und Pornoseiten.
Spaß, Kommunikation und "Befriedigung" sind ohne großen Aufwand erreichbar.

Warum also programmieren?
Ich halte das für einen der wichtigsten Gründe, warum auch dieser Seite eher jugendlicher Nachwuchs etwas fehlt.

Gib mal Java bei Insight ein. Alles stirbt.
Trotzdem wird weiter programmiert. Und vermutlich wird jeder, der auf dieser Seite aktiv ist in diesem Bereich gutes Geld verdienen.

Für den einen ist es nur ein "Wrapper" und für den anderen ist es eine "abgefahrene Möglichkeit Code so zu schreiben, dass sie leicht in jede andere Sprache zu portieren ist". Und das war auch schon mein ganzer Pulver, den ich verschießen konnte, um Dich doch noch von meiner Idee zu überzeugen.

Formuliere es weiter aus, ich "lese zu"...

Ist es mir gelungen? Nein? ... okä!

Wer weiß.

Ich hege ähnliche Pläne, wenn auch aus einer anderen Motivation heraus, von daher lasse ich mich gerne inspirieren.

Sprechen wir über etwas interessanterem: wer wird der nächste Fußballweltmeister?

Mir ist Fussball egal. Nur über das hier bin ich heute gestolpert.

[Necip]

^^ ... ihr seid's lustig. Hier gefällt's mir!

Bin kurz angebunden - Antworten folgen. Aber bevor ich mich in die Sünden des www stürze noch eine exaktere Wegbeschreibung der menschlichen Anatomie: from: essen to: darmstadt to: pforzheim to: scheisse

[Necip]

... sorry, war die Tage ein wenig auf Eis gelegt, wegen tierischen Zahnschmerzen.

Um die Portabilität zu Gewährleisten ist es natürlich zwingend nötig alle Schlüsselwörter der Sprache zu meiden. So darf man also in C nicht mehr "for", "while" etc. benutzen. Stattdessen bietet die MetaSprache (oder der Wrapper) diese Datensteuerungskommandos an: ml_for( <StartBedingung>, <EndBedingung>, <ForBlockAnweisungen> )

Schauen wir mein Ansatz doch gleich an einem Beispiel an:

Code: Alles auswählen

void ErgebnisNegativ(TMetaLanguage *ml)
{
	ml->If(
		ml->GetVariable("i").LessThen("100"),	// Bedingung
		ml->write("Das Ergebnis ist kleiner 100!"),
		ml->exception("Unerwarteter Wert!")
}

void Ausgabe(TMetaLanguage *ml)
{
	ml->SetFunction("ErgebnisNegativ", &ErgebnisNegativ);
	
	ml->If(
		ml->GetVariable("i").LessThen("10"),		// Bedingung
		ml->write("Das Ergebnis ist kleiner 10!"),	// Aufruf, wenn Bedingung true
		ml->Call("ErgebnisNegativ"));				// Aufruf, wenn Bedingung false
}
	
void Auswertung(TMetaLanguage *ml)
{
	ml->SetFunction("Ausgabe", &Ausgabe);
	ml->CreateVariable("i", "integer");
	
	ml->for(
		ml->SetVariable("i", "0"),		// Initialisierung
		ml->GetVariable("i").LessThan(ml->GetConst("10", "integer")),		// Bedingung
		ml->IncVariable("i", "1"),		// Inkrement um 1
		ml->Call("Ausgabe"));			// Ausführungsblock: ruft die Funktion "Ausgabe" auf mit Parameter "self"
}
	
int main()
{
	ml : TMetaLanguage;
	ml = TMetaLanguage.Create;

	ml.SetFunction("Auswertung", &Auswertung);
	ml.Call("Auswertung");
	
	ml.Free;
}

Weitere CodeSchnipsel:
======================

Definition eines Records:

Code: Alles auswählen

	ml->CreateVariables("local");					
	ml->Variables("local")
		.Add("i", "integer")
		.Owner.Add("d", "double");

Projektbeschreibung im Code:

Code: Alles auswählen

	ml->Docu.Title("Überschrift")
		.SubTitle("Eine knappe Zusammenfassung")
		.Description("... und hier steht ein langer Text der Problembeschreibung");

Ist doch mal was neues, eine Dokumentation zu schreiben,
dass aus dem aktuellen Verlauf der Programmausführung generiert wird!
- ob es sinn macht steht auf einem anderen Blatt.

Sinn macht es für das Debugging:

Code: Alles auswählen

	ml->Debug.EnterMethod;
	ml->Debug.LogMessage(...);
	ml->Debug.LogError(...);
	ml->Debug.LogWarning(...);
	ml->Debug.LeaveMethod;

Gruppierung von Funktionen:

Code: Alles auswählen

	ml->CreateFunctions("funcs");					
	ml->Functions("funcs")
		.Add("FunktionA", &FuncA)
		.Owner.Add("FunktionB", &FuncB);

	
	ml->CallGroup("funcs");		// Jede Funktion wird nacheinander ausgeführt
		
	ml->SetFunction("FunktionA").Attributes
			.Add("disabled")			// Funktionen können deaktiviert werden!
			.Owner.Add("repeat 10")		// Funktionen können x mal aufgerufen werden!		

Todo
====

Der "&"-Operator ist C-Spezifisch und dafür müsste noch eine Weg gefunden werden sie ml-technisch zu bekommen.


Resumé
======

Was haben wir nun durch diesen Code gewonnen?
Wir haben ein Programm so geschrieben, dass sie mit Leichtigkeit in jede andere Sprache zu portieren ist.

An der Lösung selbst muss nichts geändert werden. Was einmalig in der jeweiligen Sprache zu tun ist,
ist, die Klasse TMetaLanguage sprachspezifisch auszufüllen. Wir programmieren also nicht die Lösung neu,
sondern den Rahmen, in dem diese zugegebenermaßen ein wenig bizzar aussehnder Code ausgeführt wird.

[MoonGuy]

... sorry, war die Tage ein wenig auf Eis gelegt, wegen tierischen Zahnschmerzen.

Um die Portabilität zu Gewährleisten ist es natürlich zwingend nötig alle Schlüsselwörter der Sprache zu meiden. So darf man also in C nicht mehr "for", "while" etc. benutzen. Stattdessen bietet die MetaSprache (oder der Wrapper) diese Datensteuerungskommandos an: ml_for( <StartBedingung>, <EndBedingung>, <ForBlockAnweisungen> )

Schauen wir mein Ansatz doch gleich an einem Beispiel an:

Code: Alles auswählen

void ErgebnisNegativ(TMetaLanguage *ml)
{
	ml->If(
		ml->GetVariable("i").LessThen("100"),	// Bedingung
		ml->write("Das Ergebnis ist kleiner 100!"),
		ml->exception("Unerwarteter Wert!")
}

void Ausgabe(TMetaLanguage *ml)
{
	ml->SetFunction("ErgebnisNegativ", &ErgebnisNegativ);
	
	ml->If(
		ml->GetVariable("i").LessThen("10"),		// Bedingung
		ml->write("Das Ergebnis ist kleiner 10!"),	// Aufruf, wenn Bedingung true
		ml->Call("ErgebnisNegativ"));				// Aufruf, wenn Bedingung false
}
	
void Auswertung(TMetaLanguage *ml)
{
	ml->SetFunction("Ausgabe", &Ausgabe);
	ml->CreateVariable("i", "integer");
	
	ml->for(
		ml->SetVariable("i", "0"),		// Initialisierung
		ml->GetVariable("i").LessThan(ml->GetConst("10", "integer")),		// Bedingung
		ml->IncVariable("i", "1"),		// Inkrement um 1
		ml->Call("Ausgabe"));			// Ausführungsblock: ruft die Funktion "Ausgabe" auf mit Parameter "self"
}
	
int main()
{
	ml : TMetaLanguage;
	ml = TMetaLanguage.Create;

	ml.SetFunction("Auswertung", &Auswertung);
	ml.Call("Auswertung");
	
	ml.Free;
}

Weitere CodeSchnipsel:
======================

Definition eines Records:

Code: Alles auswählen

	ml->CreateVariables("local");					
	ml->Variables("local")
		.Add("i", "integer")
		.Owner.Add("d", "double");

Projektbeschreibung im Code:

Code: Alles auswählen

	ml->Docu.Title("Überschrift")
		.SubTitle("Eine knappe Zusammenfassung")
		.Description("... und hier steht ein langer Text der Problembeschreibung");

Ist doch mal was neues, eine Dokumentation zu schreiben,
dass aus dem aktuellen Verlauf der Programmausführung generiert wird!
- ob es sinn macht steht auf einem anderen Blatt.

Sinn macht es für das Debugging:

Code: Alles auswählen

	ml->Debug.EnterMethod;
	ml->Debug.LogMessage(...);
	ml->Debug.LogError(...);
	ml->Debug.LogWarning(...);
	ml->Debug.LeaveMethod;

Gruppierung von Funktionen:

Code: Alles auswählen

	ml->CreateFunctions("funcs");					
	ml->Functions("funcs")
		.Add("FunktionA", &FuncA)
		.Owner.Add("FunktionB", &FuncB);

	
	ml->CallGroup("funcs");		// Jede Funktion wird nacheinander ausgeführt
		
	ml->SetFunction("FunktionA").Attributes
			.Add("disabled")			// Funktionen können deaktiviert werden!
			.Owner.Add("repeat 10")		// Funktionen können x mal aufgerufen werden!		

Todo
====

Der "&"-Operator ist C-Spezifisch und dafür müsste noch eine Weg gefunden werden sie ml-technisch zu bekommen.


Resumé
======

Was haben wir nun durch diesen Code gewonnen?
Wir haben ein Programm so geschrieben, dass sie mit Leichtigkeit in jede andere Sprache zu portieren ist.

An der Lösung selbst muss nichts geändert werden. Was einmalig in der jeweiligen Sprache zu tun ist,
ist, die Klasse TMetaLanguage sprachspezifisch auszufüllen. Wir programmieren also nicht die Lösung neu,
sondern den Rahmen, in dem diese zugegebenermaßen ein wenig bizzar aussehnder Code ausgeführt wird.

ODER, wir suchen uns eine Programmiersprache, um ein Problem zu lösen. Das Problem wird mit UML strukturiert und die Algorithmen mit Struktogrammen und Pseudo-Code durchdacht. So sind sowohl Algorithmen als auch Konzepte für Leihen nachvollziehbar, und Programmierer können sich über ihren Code austauschen.

[Xin]

... sorry, war die Tage ein wenig auf Eis gelegt, wegen tierischen Zahnschmerzen.

Um die Portabilität zu Gewährleisten ist es natürlich zwingend nötig alle Schlüsselwörter der Sprache zu meiden. So darf man also in C nicht mehr "for", "while" etc. benutzen. Stattdessen bietet die MetaSprache (oder der Wrapper) diese Datensteuerungskommandos an: ml_for( <StartBedingung>, <EndBedingung>, <ForBlockAnweisungen> )

Was bringt es eine Sprache zu entwickeln, die ein Konstrukt, dass es semantisch identisch in einer Sprache gibt, komplizierter auszudrücken, um daraus die einfachere Form zu erzeugen.

Der Zweck sollte doch eigentlich sein, ein Konstrukt zu vereinfachen.

Was haben wir nun durch diesen Code gewonnen?
Wir haben ein Programm so geschrieben, dass sie mit Leichtigkeit in jede andere Sprache zu portieren ist.

Nein, nur in Sprachen, die dem gleichen Paradigma folgen.
Was bringt mir das? Warum sollte ich ein Programm komplizierter machen, nur um dann später noch zu überlegen, ob ich das als C oder Delphi Code sehen will.

An der Lösung selbst muss nichts geändert werden. Was einmalig in der jeweiligen Sprache zu tun ist,
ist, die Klasse TMetaLanguage sprachspezifisch auszufüllen. Wir programmieren also nicht die Lösung neu,
sondern den Rahmen, in dem diese zugegebenermaßen ein wenig bizzar aussehnder Code ausgeführt wird.

Ist Programmieren nicht schon in den vorhandenen Sprachen schwer genug, als dass man einen bizarr wirkenden Code daraus machen soll?

Programmier mal einen Quicksort in dieser Meta-Language. Das ist in C++ etwa 15-20 Zeilen.

ODER, wir suchen uns eine Programmiersprache, um ein Problem zu lösen. Das Problem wird mit UML strukturiert und die Algorithmen mit Struktogrammen und Pseudo-Code durchdacht. So sind sowohl Algorithmen als auch Konzepte für Leihen nachvollziehbar, und Programmierer können sich über ihren Code austauschen.

Laien verleiht man nicht und sie verstehen auch kein UML, keinen Pseudocode und keine Struktogramme. Struktogramme müssen aufwendig erklärt werden und erlauben nur kleinste Algorithmen, Pseudocode verstehen nur Leute, die das in ihre Haus- und Hof-Programmiersprache umdenken können und UML ist was, um schöne Bildchen in eine PowerPoint-Präsentation zu bringen, die dann der Chef nicht versteht, aber als wichtig erachtet.