Sprachwahl im Linux-Magazin

[audax]

Das Linux-Magazin hat in der Ausgabe 10/2008 renommierten Vertretern von Programmiersprachen zwei Aufgaben gestellt. Der resultierende Code macht anschaulich, wie Könner in Perl, Java oder Python Probleme lösen, und was die Stärken exotischer Sprachen wie Lisp und Smalltalk sind.

Das Linux-Magazin hatte die Aufgabenstellung bewusst offen formuliert, damit die Sprach-Experten frei für kreative Lösungen waren.

Nun sind Sie, die Leser an der Reihe: Wer kennt noch weitere Python-Kniffe? Wer kann die Java-Lösung kürzen oder die Perl-Variante effizienter gestalten? Welche anderen Programmiersprachen lösen das Problem vielleicht noch eleganter?

Schreiben Sie uns! Die Redaktion begutachtet alle bis zum 30 September unter redaktion@linux-magazin.de eingereichten Programme und prämiert die drei kreativsten Lösungen mit je einem Fachbuch. Die Einsendungen verlinken wir auf Linux-Magazin Online.

http://www.linux-magazin.de/online_artikel/sprachwahl

Nun ist die Python Lösung absolut unter aller Kanone.

Hier mal die von mir halbwegs geflickte Version:
http://paste.pocoo.org/show/84230

Lasst uns mal was ordentliches bauen und einschicken!

€dit:
Wow. die zweite Java Lösung braucht dafür 290 Zeilen Oo

[mkesper]

Ich finde das mit der Python-Version der Fußnotensortierung eine Sauerei.
Den Autoren hätte doch eine Testdatei in der richtigen Größe zur Verfügung stehen müssen.
Jetzt sieht es so aus, als ob entweder Python oder Leute, die mit Python entwickeln, nichts können.
Hier hat der Autor vermutlich auch nur mit so einem Schnipsel wie in deinem Paste getestet, die Datei mit 55 MB konnte dann nicht mehr verarbeitet werden (wobei mich das ehrlich gesagt wundert).

[Käptn Haddock]

Jo, mich würd auch interessieren woran das liegt, Hab leider keine Testdatei in entsprechender Grösse.
Muß man da im Download-Code wirklich die Einrückung rekonstruieren oder bin ich nur zu blöd den richtigen Editor (vim) zu benutzen?

Gruß Uwe

[BlackJack]

@audax: Deine Lösung ist keine weil `set()` ungeordnet ist, wenn das funktioniert, ist das reiner Zufall.

Meine Python-Lösung ist auch deutlich länger als deren, aber ich setze auch auf Klassen und habe keine Angst die Funktionalität auf mehr Funktionen/Methoden zu verteilen.

@mkallas: Woher weisst Du das mit dem 55 MB Text? Steht das nur im Heft, oder kann man das auch im Netz nachlesen? Steht da auch woran es genau scheitert? Ich könnte mir zum Beispiel vorstellen, dass `nodups()` 'ne fiese Laufzeit (quadratisch) hat bei wirklich vielen Referenzen. Insbesondere sollte es bei den Fussnoten eigentlich keine Duplikate geben.

[Leonidas]

Irgendwie werde ich aus dem Artikel nicht schlau, denn dort stehen keine Ergebnisse oder Auswertungen.

[n4p]

Ging ja auch soweit ich das verstanden habe eher um die ideelen Stärken der einzelnen Sprachen bzw. wie diese an Problemstellungen ran gehen. Zumindest im Online-Artikel steht ja, dass es weder um Codelänge noch um Laufzeit ging.

[Leonidas]

Mal gucken, mit Pyparsing könnte das Parsen vermutlich ziemlich gut aussehen

[audax]

@audax: Deine Lösung ist keine weil `set()` ungeordnet ist, wenn das funktioniert, ist das reiner Zufall.

Auch wieder wahr...war gestern ein wenig spät

[Y0Gi]

Ging ja auch soweit ich das verstanden habe eher um die ideelen Stärken der einzelnen Sprachen bzw. wie diese an Problemstellungen ran gehen. Zumindest im Online-Artikel steht ja, dass es weder um Codelänge noch um Laufzeit ging.

Für'n bisschen Textmangling sind diverse agile Sprachen in der Ecke Perl, PHP, Python, Ruby usw. gut geeignet, ist es doch einer der Schwerpunkte.

[audax]

so, mal die "offizielle"-Python Lösung in ordneltich, diesmal funktionierst aber
http://paste.pocoo.org/show/84275

[EyDu]

@audax: Das Hinzufügen von Elementen in "m" innerhalb des Generators (in der unique-Funktion) halte ich für etwas ungelungen. Das mag zwar schön kurz sein, aber ich fände das hier viel eindeutiger:

Code: Alles auswählen

def unique(iterable):
    m = set()
    for x in iterable:
        if x in m:
            yield x
        else:
            m.add(x)

Sonst sieht es aber wirklich hübsch aus.

[audax]

Und hier mal meine Art, das zu machen:
http://paste.pocoo.org/show/84287

Läuft bei der Testdatei bei mir in ordentlichen 17s.

Die Orginallösung läuft gar nicht damit

€dit:
hatte Schöheitsfehler drinne
http://paste.pocoo.org/show/84290

[audax]

@audax: Das Hinzufügen von Elementen in "m" innerhalb des Generators (in der unique-Funktion) halte ich für etwas ungelungen. Das mag zwar schön kurz sein, aber ich fände das hier viel eindeutiger:
[...]

Code: Alles auswählen

def unique(iterable):
    m = set()
    for x in iterable:
        if x not in m:
            m.add(x)
            yield x
            

sorum isses

Btw:
Was findet ihr besser: foo(iterable) oder foo(itr) ?

[lunar]

@mkallas: Woher weisst Du das mit dem 55 MB Text? Steht das nur im Heft, oder kann man das auch im Netz nachlesen? Steht da auch woran es genau scheitert?

Im Artikel heißt es, dass es knallt, weil Python die Daten en block liest, anstatt wie alle anderen Implementierungen zeilenweise.

[BlackJack]

@audax: `iterable`.

@lunar: Es "kracht" ja gar nicht, das Original läuft halt einfach nur *ewig* ohne dabei nennenswert Speicherzuwachs zu zeigen. Ich denke es ist die `nodups()` mit der Quadratischen Laufzeit. Die Schleife innerhalb von `new.__contains__()` in Zeile 20 schaut sich bei 'sample4.txt' insgesamt schlappe ~199 *Milliarden* Elemente an. Das dauert halt ein *wenig*.

Meine Lösung liefert nach 10 Sekunden dass hier:

Code: Alles auswählen

bj@s8n:~$ python forum2.py < sample4.txt
Error: undefined footnote 958378

Im Text kommt '[958378]' vor, aber es gibt keine Fussnote mit der Nummer. Hat jetzt mein Programm versagt, weil es darauf prüft, oder ist das ein Fehler in den Eingabedaten?

[EyDu]

sorum isses

Ah ja, da habe ich wohl das not übersehen Und jetzt weiss ich auch wieder, warum ich immer ein if/then/else benutze und es nicht mit "or" nachbaue

[lunar]

@lunar: Es "kracht" ja gar nicht, das Original läuft halt einfach nur *ewig* ohne dabei nennenswert Speicherzuwachs zu zeigen. Ich denke es ist die `nodups()` mit der Quadratischen Laufzeit. Die Schleife innerhalb von `new.__contains__()` in Zeile 20 schaut sich bei 'sample4.txt' insgesamt schlappe ~199 *Milliarden* Elemente an.

Ich habe nur zitiert, was im Linux Magazin stand.

Meine Lösung liefert nach 10 Sekunden dass hier

Kann man sich die irgendwo ansehen?

Im Text kommt '[958378]' vor, aber es gibt keine Fussnote mit der Nummer. Hat jetzt mein Programm versagt, weil es darauf prüft, oder ist das ein Fehler in den Eingabedaten?

Nimmt man die existierenden Implementierungen als Referenz, dann hat dein Programm versagt. Die ignorieren solche nicht-existenten Fußnoten.

Ach ja, nur so nebenbei: Bei sowas ruft das LinMag üblicherweise Leser dazu auf, eigene Vorschläge einzusenden. Das ist diesmal nicht anders, wer sich berufen fühlt, kann seine Lösung an redaktion@linux-magazin.de schicken. Die drei kreativsten Lösung werden mit einem "Fachbuch" prämiert (allerdings natürlich nicht Python exklusiv). Selbst wenn man das nicht unbedingt gewinnt, so besteht ja noch die Möglichkeit, der Welt zu zeigen, dass man die Sache auch anständig implementieren kann, da das Linux Magazin auch Leserbriefe abdruckt.

[BlackJack]

@audax: Dein Skript macht's genau falsch herum: Du nummerierst die Referenzen im Text fortlaufend von 1 an und die Fussnoten sind nicht numerisch aufsteigend. Das sollen sie aber soweit ich das verstanden habe, und die anderen implementiert haben, auf jeden Fall sein. Macht auch mehr Sinn wenn man beim Lesen den Text zu einer Referenz sucht.

@lunar: Meine Lösung kann man noch nirgends sehen. Ich trau mich nicht.

[audax]

ich hätte gerne ne Referenzlösungsdatei zum diffen.

Alle machen was anderes Oo

[BlackJack]

@audax: Also die Perl und die Python-Lösung machen hier das gleiche: http://paste.pocoo.org/show/84300/

Und das macht auch wesentlich mehr Sinn als Deine Lösung. Wenn man 100te Fussnoten hat und Du die Referenzen durch nummerierst, anstatt die Fussnoten zu sortieren, ist dem Leser überhaupt nicht geholfen.