NG Programmiersprache?

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

volkard

Zooonk schrieb:

void tutBischen(boot &mux){if(irgendwas)mux.peng();}
std::list<boote> paddel;
for_each(paddel.beginn(),paddel.end(),tutBischen);

Naja, Dein Beispiel tut ja schon wetwas Ähnliches. Schade, daß Du nicht in der Lage warst, bei der Sache zu bleiben.
Und man sieht, daß Du die Schleife zerlegen mußt in den Körper, den Du vor der aktuellen Funktion als Funktion definieren mußt und den Schleifenkopf, der in der aktuellen Funktion steht, selten weniger als 10 Zeilen entfernt. Dieses Auseinanderrupfen ist duch häßlich. Also ist Bedarf da für ein richtiges foreach.
Und wehe, es ist was zu ändern.

//Oh, es reicht, nur ein Boot anzuzünden

for each (Boot* b in boote) 
   if(foo(b->getMass() || bar(b)){ 
      b->burn();
      break;
   }

Und Du mußt jetzt was machen? Ein Prädikat schreiben und find/if/burn machen?

find muß nicht sein , jedes Objekt wird übergeben welches if durchläuft.

Du hast natürlich insofern recht das das unübersichtlich aussehen kann.

Andererseits kann man das natürlich für verschiedene Listen benutzen, in dem Fall für den gleichen <Typ>.

Je nach Fall auch in ein struct packen und operator() überladen.

Bei öfter gebräuchlichen templates erstellen und passende in einen header packen mit Namespace. Dann wird es wieder übersichtlich.

Mir ist folgendes eingefallen:

forever
{
 static int i = 0;
 ++i;

 break(i > 5); // if (i > 5) break;
}

[cpp]

void testBurn(Boot &b){
if(foo(b->getMass() || bar(b)){
b->burn();
}//if
}//testBurn

std::vector<Boot*> boote;

for_each(boote->begin(),boote->end(),testBurn);

[cpp]

Nochmal mit boote