Haskell

GPC

ertes schrieb:

Programmiersprachen sind eben auch Religionen, wie dieser Flamewar hier beweist (und nein, ich schließe mich da nicht aus).

Man muss ja schon ein ziemlich armer Hund sein, wenn man sich ein Werkzeug zur Religion hochjubelt *renn und duck*

Na ja, Haskell ist ja zur Zeit der Mocca Latte unter den Programmiersprachen und man kommt kaum dran vorbei, weil sich so viele dran aufgeilen Auch ich fand Haskell von vielen Konzepten her echt interessant und es hat auch meine tägliche Arbeit mit C# positiv beeinflusst Ich denke es wird am Ende aber darauf hinauslaufen, dass imperative Sprachen die guten Teile von Haskell (speziell denke ich an Typklassen) abkupfern.

maximAL schrieb:

Man kann es durchaus als Vorteil betrachten, wenn sich die übliche "Ich kann nur C++/Java/C#" Gruppe gar nicht erst bewirbt. Bei einem Haskell-Programmierer kannst du fast immer davon ausgehen, das er einigermaßen was drauf hat, schon allein weil er sich sonst nie mit so einer "exotischen" Sprachen beschäftigen würde.

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Kann das mal einer möglichst elegant in Haskel schreiben?

#include <string>
#include <iostream>
#include <ctime>

int main()
{
	int maxNr = 12;
    srand(time(0));
	int geld = 100;
	bool ende = false;
	while ( !ende ) {
		int setzen = 0;
		do {
			std::cout << "\nSie haben " << geld << " Geld. Wieviel wollen Sie setzen? ";
			std::cin >> setzen;
		} while (setzen <= 0 || setzen > geld );

		int zahl = 0;
		std::cout << "Auf welche Zahl wollen Sie setzen (1-" << maxNr << ")? ";
		std::cin >> zahl;

		int wurf = 1 + rand() % maxNr;
		std::cout << wurf << " wurde geworfen.\n";
		if ( wurf == zahl ) {
			geld += setzen * 10;
		}
		else {
			geld -= setzen;
		}

		if ( geld > 0 )	{
			std::string weiter;
			std::cout << "Sie haben " << geld << " Geld. Wollen Sie weiterspielen (j/n)? ";
			std::cin >> weiter;
			ende = weiter == "n";
		}
		else {
			ende = true;
		}
	}
	std::cout << "\nSie haben " << geld << " Geld. Gratulation! ;-)\n";
    return 0;
}

Bashar

GPC schrieb:

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Das tut ja nicht jeder, der sich C++-Programmierer nennt. Die wenigsten, schätze ich.

GPC

Bashar schrieb:

GPC schrieb:

Wer die Komplexität und die Fallstricke von C++ bändigt, der hat auch Eier aus Stahl

Das tut ja nicht jeder, der sich C++-Programmierer nennt. Die wenigsten, schätze ich.

Ja, aber es gilt für jede wichtigere Sprache, dass es einen großen "Mittleklasse"-pool gibt und dann eine kleinere Gruppe von Leuten, die richtig gut damit umgehen können

Bashar

Ob es Visual Basic Gurus gibt? Das ist doch Perlen vor die Säue.

audacia

Und wenn jetzt alle Haskell anfangen? Säue vor die Perlen?

otze

Irgendwer schrieb:

Ohne grundlegende algebraische Kenntnisse sind viele Konstrukte in Haskell IMO äußerst schwierig zu verstehen.

Welche denn? Monaden etwa? Wie bereits oben geschrieben, kann man von einem Programmierer allerdings auch grundlegende algebraische Kenntnisse erwarten.

Das Buch mit dem Ich Haskell programmieren lernen wollte "Introduction to functional progrmaming using Haskell" war das einzige Programmierbuch jemals, in dem sich der Autor genötigt fühlte zu beweisen, dass zwei Ausdrücke das identische Ergebnis bildeten. Nur war der eine Ausdruck 10x schneller, war aber nicht mehr wirklich gut von der Semantik her verständlich. Und der Beweis war auch meiner Erinnerung nach nichttrivial.

Ich weiß nicht, ob eine Sprache so toll ist, in der man bei bestimmten Codeschnipseln den Beweis als Kommentar drüber packen muss.

Nur war der eine Ausdruck 10x schneller, war aber nicht mehr wirklich gut von der Semantik her verständlich.

Selbst in C++ ist es häufig der Fall, dass die naive Implementierung nicht die schnellste ist. Schnellere Implementierungen werden dann häufig etwas komplizierter und sollten dann kommentiert werden.

Und der Beweis war auch meiner Erinnerung nach nichttrivial.

Sonst hätte er ihn wohl nicht erklärt, oder?

knivil

Welche denn? Monaden etwa? Wie bereits oben geschrieben, kann man von einem Programmierer allerdings auch grundlegende algebraische Kenntnisse erwarten.

Kategorientheorie wird an den seltensten Universitaeten im Fach Informatik gelehrt. Nein, dieses Wissen kann nicht vorausgesetzt werden.

Autor genötigt fühlte zu beweisen, dass zwei Ausdrücke das identische Ergebnis bildeten

Nein, es drueckt ein wesentliches Feature von Haskell aus. Korrektheit von Programmen kann bewiesen werden.

volkard

knivil schrieb:

Autor genötigt fühlte zu beweisen, dass zwei Ausdrücke das identische Ergebnis bildeten

Nein, es drueckt ein wesentliches Feature von Haskell aus. Korrektheit von Programmen kann bewiesen werden.

Echt?
Das wäre supi. Dann könnte ich ja ungelöste mathematische Probleme nach Haskell übersetzen und dort beweisen. Genial! Ich liebe Haskell und den Fanclub.

Nein, dieses Wissen kann nicht vorausgesetzt werden.

Man muss die Kategorientheorie nicht verstehen um Monaden schreiben und verwenden zu können. Siehe auch: You could have invented monads
Solche Aussagen wie deine sind es, die dazu führen, dass funktionale Sprachen von den meisten als rein akademische Forschungssprachen verstanden werden.

Das wäre supi. Dann könnte ich ja ungelöste mathematische Probleme nach Haskell übersetzen und dort beweisen. Genial! Ich liebe Haskell und den Fanclub.

knivil

@Irgendwer: Ich kenne die meisten Artikel. Um Monaden zu benutzten, braucht man sie vielleicht nicht verstehen. Aehnliches gilt auch fuer Templates. Ich kann die Container der STL benutzen. Will ich aber Templates darueber hinaus einsetzen, muss ich sie verstehen.

Solche Aussagen wie deine sind es, die dazu führen, dass funktionale Sprachen von den meisten als rein akademische Forschungssprachen verstanden werden.

Bullshit! Der Schritt von Monaden in Haskell auf alle funktionalen Sprachen ist sehr gross.

@volkard: Bullshit! Ich habe nicht von allen Programmen gesprochen.

volkard

knivil schrieb:

Nein, es drueckt ein wesentliches Feature von Haskell aus. Korrektheit von Programmen kann bewiesen werden.

Lies das nochmal genau durch. So, wie es da steht, sprichst Du von allen Programmen. Und das ist Quatsch.

Manche Programme können auch in anderen Sprachen bewiesen werden. Das ist also nicht der Vorteil. Abgesehen davon, daß die Flieger abtürzen, weil die Spezifikation falsch war, nicht das Programm. Du könntest höchstens herausarbeiten, daß manche Programme in Haskell leichter automatisch bewiesen werden können.

Benutzt Du automatisierte Programmbeweiser?

GPC

Bashar schrieb:

Ob es Visual Basic Gurus gibt? Das ist doch Perlen vor die Säue.

Klar gibt's auch VB6 Gurus, warum auch nicht. Die werden halt immer weniger, weil es seitens MS keinen Suppport mehr für VB6 gibt und auf .NET die meisten C# anstatt VB.NET nutzen.
VB6 ist halt furchtbar verbose und es fehlen (inzwischen) im Mainstream angekommene Dinge wie Lambdas, Generics/Templates etc, aber es war ja auch als RAD-Tool für GUI bzw. COM ausgelegt und da hat es nicht ohne Grund massive Erfolge gefeiert.

knivil

Gut, dann korrigiere ich mich: Nicht alle koennen auf Korrektheit geprueft werden. Tools wie http://vimeo.com/6687266 habe ich bereits ausprobiert. HLint wird auch konsequent benutzt. Desweiteren ist automatisches Beweisen und Typinferenz eng verbunden: Theorems for free!, d.h. jedes System mit Typinferenz ist schon ein Theorembeweiser.Verifying Haskell Programs Using Constructive Type Theory sieht auch sehr interessant aus.

volkard

Daraus schließe ich, daß es auch kein wesentliches Feature von Haskell ist.

knivil

volkard schrieb:

Daraus schließe ich, daß es auch kein wesentliches Feature von Haskell ist.

Definiere wesentlich!

volkard

knivil schrieb:

Definiere wesentlich!

Na, Du betreibst Haskell nicht, weil Du damit Programme beweisen kannst, sondern weil es hübsch und so elegant ist und einfach Spaß macht.

knivil

Doch, ich moechte mir sicher sein, dass Programme korrekt sind. Dazu reicht mir meist Testen nicht aus bzw. Testen wird unnoetig, wenn ich die Korrektheit beweisen kann. Natuerlich mache ich das nicht fuer jedes Programm/Funktion. Selbstverstaendlich ist das nicht der einzige Grund. Eleganz und Einfachheit spielen auch alle eine Rolle. Diese Eigenschaften haben alle einen gemeinsamen Ursprung: programmierte Mathematik. Zwar bieten andere Sprachen das auch, aber besitzen nicht alle Features von Haskell.

volkard

Ich glaube Dir nicht, daß Du öfters mal Programme oder Funktionen beweist, und deswegen Haskell einsetzt.