NG Programmiersprache?

Als NG Sprache sollte sie eine IDE wie Delphi haben mit ebensolch viel und chicken Steuerelementen.

Keinen völlig neuen Syntax mit sich bringen. ( Nicht ohne Grund schauen Java und C# da auf C++ ).

GC nur optional.

Neben der Prozeduralen und OOP auch Funktionelle Paradigmen haben.

Effizient in der Ausführung.

Zabou schrieb:

Als NG Sprache sollte sie eine IDE wie Delphi haben mit ebensolch viel und chicken Steuerelementen.

Ok windows only; eine meinung die man vertreten kann

Keinen völlig neuen Syntax mit sich bringen. ( Nicht ohne Grund schauen Java und C# da auf C++ ).

Wir hätten niemals voon der Fortran 77 oder Cobol Syntax weggehen sollen.
(die Java/c#/c++ syntax ist schrecklich)

GC nur optional.

Wo würden wir hin kommen wenn die echten Profis nicht zeigen können wie cool sie sind indem sie ohne gc arbeiten. Außerdem ist eine gespaltene Gemeinde immer gut.

Neben der Prozeduralen und OOP auch Funktionelle Paradigmen haben.

Prozedural und und (pur) funktional sind bisweilen recht gegesetzlich. Eine Imperative/OOP grundsprache die funktionale Aspekte beinhaltet funktioniert besser (siehe ruby).

Effizient in der Ausführung.

effizienz ist mittelfristig eher viele cores unterstützen als einfach schnell zu sein. Ich kann in laden gehen und einen Mac pro mit 16 (virtuellen) Kernen kaufen. Da kann eine anwendung lieber 5 mal langsamer sein dafür aber 16 core nutzen.

IPH schrieb:

Effizient in der Ausführung.

effizienz ist mittelfristig eher viele cores unterstützen als einfach schnell zu sein. Ich kann in laden gehen und einen Mac pro mit 16 (virtuellen) Kernen kaufen. Da kann eine anwendung lieber 5 mal langsamer sein dafür aber 16 core nutzen.

stell dir eine Sprache vor die 16 Cores verwenden kann und 5 mal so schnell ist.

Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5

IPH schrieb:

Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5

Was, Warum? Die meisten Bildverarbeitungs-, Numerik-, Such/Sortier-algorithmen lassen sich z.B. total einfach parallelisieren, ohne irgendwelchen Sprach-Schnickschnack. Warum braucht ihr da immer ne funktionale Programmiersprache mit was auch immer?

Dravere

knivil schrieb:

Dravere schrieb:

von zum Beispiel C++ ausgehen, dann die Makros und Templates rausschmeissen, dafür in die eigentliche Sprache hinein eine Code-Generator Sprache implementieren. Ich habe mir sogar schon mal Gedanken darüber gemacht,

Lisp, Scheme oder PLT-Scheme.

Nicht das was ich will, sonst würde ich Lisp oder Scheme verwenden und nicht mir Gedanken über eine neue Sprache oder einem Dialekt zu C++ machen.

Grüssli

knivil

Die Qualitaet des Videos ist nicht besonders berauschend: http://cs.byu.edu/colloquia/2009-02-26 . Aber wieso etwas neues erfinden, wenn es schon alles gibt.

Was, Warum? Die meisten Bildverarbeitungs-, Numerik-, Such/Sortier-algorithmen lassen sich z.B. total einfach parallelisieren, ohne irgendwelchen Sprach-Schnickschnack. Warum braucht ihr da immer ne funktionale Programmiersprache mit was auch immer?

1.) Es ist einfacher, das Problem funktional mit einer parallelen Variante von map zu spezifizieren. Auch paralleles Quicksort etc. sieht fast genauso aus, wie die normale Variante. Sowas nennt man Abstraktion. Um Parallelitaet muss sich nicht mehr explizit gekuemmert werden.
2.) FFT ist nicht trivial parallelisierbar, genauso wenig das numerische Loesen einer Differentialgleichung. Beim Traversieren von Graphen muss man auch aufpassen, wenn man keine Flaschenhaelse einbauen will.
3.) Alle trivialen Faelle sind uninteressant, da sie in jeder Sprache einfach sind. Man braucht Unterstuetzung fuer alle nicht-trivialen.
4.) Ich will mich nicht mehr explizit um die Anzahl der OS-Threads kuemmern, Haskell mit seinen Sparks bietet einen schoenen Ansatz.

Will ich sehen. So auslastung habe ich nur bei Sprachen mit Immutablen Datenstrukturen gesehen wie Clojure, aber diese Immutablen Datenstrukturen haben bis jetzt immer einen Overhead von mindestenz Faktor 5

Das ist wahrscheinlich ok, der Speedup waere dann immer noch linear in der Anzahl der Knoten. Auch ist die JVM nicht die beste Plattform.

Zeus

knivil schrieb:

Aber wieso etwas neues erfinden, wenn es schon alles gibt.

knivil

Okay, erwischt.

*john 0

knivil schrieb:

4.) Ich will mich nicht mehr explizit um die Anzahl der OS-Threads kuemmern, Haskell mit seinen Sparks bietet einen schoenen Ansatz.

Mit OpenMP und passenden Compiler ist der Aufwand relativ gering. Funktionale Programmierung ist ja ganz gut, aber genauso wie OOP ist sie nicht allein geeignet alle Algorithmen einfach und elegant zu formulieren. Daher bin ich ein Fan von Multiparadigmenprogrammiersprachen.

knivil schrieb:

Die Qualitaet des Videos ist nicht besonders berauschend: http://cs.byu.edu/colloquia/2009-02-26 . Aber wieso etwas neues erfinden, wenn es schon alles gibt.

Was, Warum? Die meisten Bildverarbeitungs-, Numerik-, Such/Sortier-algorithmen lassen sich z.B. total einfach parallelisieren, ohne irgendwelchen Sprach-Schnickschnack. Warum braucht ihr da immer ne funktionale Programmiersprache mit was auch immer?

1.) Es ist einfacher, das Problem funktional mit einer parallelen Variante von map zu spezifizieren. Auch paralleles Quicksort etc. sieht fast genauso aus, wie die normale Variante. Sowas nennt man Abstraktion. Um Parallelitaet muss sich nicht mehr explizit gekuemmert werden.
2.) FFT ist nicht trivial parallelisierbar, genauso wenig das numerische Loesen einer Differentialgleichung. Beim Traversieren von Graphen muss man auch aufpassen, wenn man keine Flaschenhaelse einbauen will.
3.) Alle trivialen Faelle sind uninteressant, da sie in jeder Sprache einfach sind. Man braucht Unterstuetzung fuer alle nicht-trivialen.

Ach, bla bla schon wieder, wir hatten doch schon festgestellt, dass man auch mit funktionalen Sprachen noch selber denken muss und nicht alles automatisch geschenkt bekommt. http://www.c-plusplus.net/forum/viewtopic-var-t-is-266720.html

Ich würde auf "klassisches" OOP verzichten. Dieser Versuch, alles in Klassen und Interfaces zu packen, klappt halt nicht immer bzw. macht die ganze Welt fürchterlich. Es gibt manchmal viel schönere Konzepte wie algebraische Datentypen und Pattern Matching in funktionalen Sprachen.
Allerdings finde ich Sprachen wie Haskell manchmal auch nicht so ganz toll, gerade weil es manchmal richtig schön und effizient ist, etwas imperativ zu schreiben.

Ein Haskell-C-Remix wäre interessant

Zeus

Ich find sowas aber viel schöner als C mit Haskell vermixt

module app:
	type firstBox -> typedef(Box<int>);
	type secondBox -> typedef(Box<int>);

	type Box -> class<T>(T):
	end;

	func show(void <- box :: firstBox):
		//...
	end;

	func show(void <- box :: secondBox):
		//...
	end;

	func main(void <- void):
		var secretbox := secondBox();
		show(box := secretbox);
	end;
end;

knivil

isklar schrieb:

Ach, bla bla schon wieder, wir hatten doch schon festgestellt, dass man auch mit funktionalen Sprachen noch selber denken muss und nicht alles automatisch geschenkt bekommt

Sinnleere Aussage. Nichts passiert automatisch.

sie nicht allein geeignet alle Algorithmen einfach und elegant zu formulieren

Was sind alle, kannst du Beispiele anfuehren oder ueberhaupt Argumente bringen? Sonst ist diese Aussage einfach nur ein Allgemeinplatz.

[quote="volkard"]

Was ich mir davon verspreche ist: Zum Beispiel wenn man eine Sprache wie C++ hat, die kein foreach hat, aber andere Sprachen mit foreach zu Recht erblühen, kann man foreach nachrüsten, einfach eine geschickte Definition aus der Open-Source-Gemeinde inkludieren, und muß nicht 0x Jahre warten, bis ein neuer Standard kommt.

[quote]

foreach heißt in C++ for_each und ist in #include <algorithm> zu finden.

Zooonk schrieb:

volkard schrieb:

Was ich mir davon verspreche ist: Zum Beispiel wenn man eine Sprache wie C++ hat, die kein foreach hat, aber andere Sprachen mit foreach zu Recht erblühen, kann man foreach nachrüsten, einfach eine geschickte Definition aus der Open-Source-Gemeinde inkludieren, und muß nicht 0x Jahre warten, bis ein neuer Standard kommt.

foreach heißt in C++ for_each und ist in #include <algorithm> zu finden.

Die foreach der anderen Sprachen machen for-schleifen einfacher, so ähnlich wie boost foreach und nicht so nen scheiß wie algorithm for_each.

Was soll denn die foreach besser machen als algo for_each ?

Ich kann nur von meiner Seite aus sagen, seit ich "Die C++ Programiersprache" von B.S. gelesen habe, habe ich einen ganz anderen Blick auf die Container/Iteratoren sowie Alogos, als auch vieles andere von C++ geworfen.

Viele "Verbesserungen" von Frameworks sind oft nur bedingt besser, bzw wenn man sich mal richtig durch die STL gewurschtelt hat erkennt man erst die Stärke.

volkard

Zooonk, Du hast ja sowas von keine Ahnung.
Mach erstmal das mit for_each:

//std::vector<Boot*> boote;
//...
for each (Boot* b in boote)
   if(foo(b->getMass() || bar(b)){
      b->burn();

void tutBischen(boot &mux){if(irgendwas)mux.peng();}

std::list<boote> paddel;

for_each(paddel.beginn(),paddel.end(),tutBischen);

-e
-n