LanX-+2008-12-13 12:34:44--

Es ist Schwachsinn im Hinblick auf P6 nicht mehr "foreach" zu schreiben!

weils nichts kostet. (man spart sogar);

Ich weiß nicht, wie brennend das euch interessiert - aber ich möchte Perl 6 nicht lernen, bevor es die Sprache gibt bzw. bevor ich in Perl 5 ausgelernt habe.
Mal schaun, wer schneller ist.

Perl5 (mit aller Magie) auslernen, bedeutet einen Port für biologische Hirn installieren...

Ich wette mal das Perl6 schneller realisiert ist!

@Lan-X, Lichtkind: Ihr bringt LISP und Smalltalk durcheinander! Aktuell halte ich Factor (http://factorcode.org/) und F# bzw. auch Haskell für einen Blick wert, wenn man über den Tellerrand schauen möchte. Pythonista scheinen den Besenstil im Kreuz zu haben, aber ein interaktiver Interpreter und Introspektion sind schon schöne Werkzeuge beim entwickeln. Wobei murphy jetzt darauf hinweisen darf, das REPL bei Scheme schon lange normal ist.

factor verfolge ich schon fast von begin weil der typ auch einen editor geschrieben hat den ich auch mal benutzte :)

Gast+2008-12-13 21:34:48--

@Lan-X, Lichtkind: Ihr bringt LISP und Smalltalk durcheinander!

unwahrscheinlich, mein Betriebssystem heißt Emacs ; )


BTW: Kann man davon ausgehen das Haskell alles kann was LISP kann, ohne dass die Klammer-Tasten brüchig werden?

LanX-+2008-12-13 22:19:09--

unwahrscheinlich, mein Betriebssystem heißt Emacs ; )

nun ja, aber Seaside ist nunmal eine Smalltalk-Applikation und keine LISP Anwendung. Und der gute merlyn beschäftigt sich viel mit Seaside ...

LanX-+2008-12-13 22:19:09--

BTW: Kann man davon ausgehen das Haskell alles kann was LISP kann, ohne dass die Klammer-Tasten brüchig werden?

In meinem Fall: Ja! Aber ob das allgemeingültig ist, kann ich nicht sagen. Ich kratze nur an der Oberfläche ...

Gast+2008-12-13 23:00:28--

nun ja, aber Seaside ist nunmal eine Smalltalk-Applikation und keine LISP Anwendung. Und der gute merlyn beschäftigt sich viel mit Seaside ...

Ups, tatsächlich verwechselt!

Gast+2008-12-13 21:34:48--

[...] Aktuell halte ich Factor (http://factorcode.org/) und F# bzw. auch Haskell für einen Blick wert, wenn man über den Tellerrand schauen möchte.

Factor finde ich auch ganz nett, vor allem wegen seines Objektmodelles. Etwas ähnliches habe ich auch mal zum Spaß in Scheme nachgebaut ;-) [1]

Quote

[...] ein interaktiver Interpreter und Introspektion sind schon schöne Werkzeuge beim entwickeln. Wobei murphy jetzt darauf hinweisen darf, das REPL bei Scheme schon lange normal ist.

Ja, so eine interaktive Kommandozeile ist schon praktisch – sowohl zum schnellen Testen als auch zum Beispiel zur Kontrolle von Serverprozessen. Es ist etwas Schade, dass der Perlinterpreter das nicht hat, denn eigentlich dürfte es nicht allzu schwer einzubauen sein.

Weiß jemand ob Perl 6 eine REPL bekommen soll?

LanX-+2008-12-13 22:19:09--

[...] BTW: Kann man davon ausgehen das Haskell alles kann was LISP kann, ohne dass die Klammer-Tasten brüchig werden?

Klar, beide Sprachen sind turingvollständig, also prinzipiell äquivalent ;-)

Ich würde sagen, die größten Unterschiede neben der Syntax sind, dass Haskell tatsächlich pur funktional ist und alle Seiteneffekte, wie zum Beispiel I/O, in Monaden gekapselt werden müssen, während Lisp Seiteneffekte in klassischer Form kennt, sowie dass die großen Lispdialekte (Common Lisp und Scheme) standardmäßig eager evaluation benutzen und Haskell lazy evaluation, was für eine pur funktionale Sprache natürlich nur folgerichtig ist und schließlich dass Haskell statisch und stark typisiert ist, während Lisp im allgemeinen dynamisch typisiert ist.

Da ich bisher nur ein einziges statisches Typensystem gesehen habe, bei dem ich nicht ganz schnell an die Grenzen der Ausdrucksmöglichkeiten gestoßen bin [2], tendiere ich dazu, dynamische Typisierung trotz der Laufzeitkosten lieber zu mögen. Und auch wenn ich versuche, mit wenig Mutationen zu programmieren, finde ich es doch praktisch auch gelegentlich mal Variablenzuweisungen verwenden zu können, weshalb ich ein Lisp einer pur funktionalen Sprache vorziehe. Auch diese beiden Punkte sind aber ganz klar Geschmacksfragen.

[1] modds
[2] damit meine ich das von Scala

murphy+2008-12-14 03:09:10--

Weiß jemand ob Perl 6 eine REPL bekommen soll?

es gibt zumindest ein Projekt für Perl5 Devel::REPL (mit Moose realisiert :)

Und ich weiß jetzt nicht was ihr bei Introspection für Ansprüche habt, sowas wie Methoden automatisch expandiert zu bekommen? Da gäbe es glaube ich Devel::PerlySense für emacs! (noch nicht getestet, und eigentlich können auch andere Editoren die API nutzen)

murphy+2008-12-14 03:09:10--

Da ich bisher nur ein einziges statisches Typensystem gesehen habe, bei dem ich nicht ganz schnell an die Grenzen der Ausdrucksmöglichkeiten gestoßen bin [2], tendiere ich dazu, dynamische Typisierung trotz der Laufzeitkosten lieber zu mögen.

laut -> Joost kommen einige LISP-Dialekte deutlich näher an C ran als Perl!

Hmm, Haskell sieht aber in Benchmarks besser aus als alle Lisp Dialekte...

LanX-+2008-12-14 04:54:37--

murphy+2008-12-14 03:09:10--

Weiss jemand ob Perl 6 eine REPL bekommen soll?

es gibt zumindest ein Projekt fu:r Perl5 Devel::REPL (mit Moose realisiert :)

Cool, muss ich mir unbedingt mal anschauen :-)

Quote

laut -> Joost kommen einige LISP-Dialekte deutlich na:her an C ran als Perl!

Hmm, Haskell sieht aber in Benchmarks besser aus als alle Lisp Dialekte...

Das kommt immer darauf an, wer die Benchmarks macht, was man genau testet, und was man beweisen will ;-)

Im allgemeinen designt ja niemand eine Programmiersprache absichtlich so, dass sie besonders langsam ist. Aber es ist auch kaum moeglich, ein Laufzeitsystem so zu bauen, dass es fuer jedes Problem optimal schnell ist. Folglich finden sich fuer jede Sprache Probleme, die damit besonders rasch loesbar sind, aber auch solche, die nur mit Aufwand effizient umgesetzt werden koennen.

Gerade ein Benchmark wie der Programming Language Shootout ist eigentlich nicht so aussagekraeftig, da hier die Implementationen der verschiedenen Problemloesungen fuer verschiedene Sprachen von voellig unterschiedlichen Programmierern kommen und auch sehr unterschiedliche Qualitaet haben.

Und im Endeffekt laeuft's natuerlich immer darauf hinaus, dass ein Mensch, der Assemblercode schreibt, und einen Profiler zur Hand hat, garantiert den schnelleren / kleineren / besseren Code als jeder Compiler ohne echte KI produziert, wenn er nur genug Zeit dafuer hat - die interessante Frage ist also eigentlich, wieviel Ausfuehrungsgeschwidigkeit man bereit ist, fuer gesparte Entwicklungszeit, Wartbarkeit und geschonte Nerven zu opfern. Und da waeren wir dann schon wieder bei den Geschmacksfragen, ueber die man ja bekanntlich nicht streiten kann ;-)