NG Programmiersprache?

*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

Und mit Lambda wird das mal nen Einzeiler

std::for_each(boote->begin(), boote->end(), [](Boot &b) -> void { if (foo(b->getMass() || bar(b)) b->burn(); }); [/cpp]

SideWinder

Gefällt euch hier die Lambda-Syntax (in diesem Fall) wirklich besser als die foreach-Schleife?

MfG SideWinder

std::for_each(boote->begin(), boote->end(), [&boote](Boot &b) { if (foo(b->getMass() || bar(b)) b->burn(); });

Vielleicht so (Korrektur). Keine Ahnung, kanns ja nicht testen.

SideWinder schrieb:

Gefällt euch hier die Lambda-Syntax (in diesem Fall) wirklich besser als die foreach-Schleife?

MfG SideWinder

Nein, aber zumindest reduziert man im Prinzip überflüssige Funktionen

Mit entsprechend schönen Syntax Highlighting (einfacher zu lesen), würde ich aber evtl. auf den Geschmack kommen.

Sollte es das nicht geben, so empfinde ich die Foreach als sinniger und natürlich lesbarer.

Habs mal ausprobiert, aber ist trotz Highlighting net sooo viel besser:
http://pastehtml.com/view/1a6ht3y.html

Eventuell hab ich auch einfach keine guten Farben ausgesucht usw.