[Python/Scheme] The Adventures of a Pythonista in Schemeland

[shinya]

Per chi non conoscesse l'argomento, le "avventure" sono una serie di articoli di Michele Simionato che esplorano la programmazione funzionale in scheme partendo da un background differente (python, appunto).
L'autore è brillante e acuto e la lettura è piacevole ed illuminante, anche se richiede ovviamente un pò d'impegno da parte del lettore (gli argomenti non sono banalissimi). Le linko dato che sono state finalmente raccolte in un corpus ragionato.
Buon divertimento

http://www.phyast.pitt.edu/~micheles/scheme/

Sono disponibili anche in pdf: http://www.phyast.pitt.edu/~micheles...Schemeland.pdf

[cdimauro]

Il materiale è tantissimo: mi ci vorrà un bel po' per "digerirlo" tutto, pur avendo studiato piacevolmente (ai tempi) Scheme all'università.
Ma le opinioni e le esperienze di Michele meritano sicuramente di essere studiate.

Comunque con gli occhi di oggi per quanto mi riguarda rimane un grande, grosso "problema":

http://shootout.alioth.debian.org/de...=mzscheme&id=1

http://shootout.alioth.debian.org/de...ng=python&id=2

[shinya]

Originariamente inviato da cdimauro

Comunque con gli occhi di oggi per quanto mi riguarda rimane un grande, grosso "problema":
http://shootout.alioth.debian.org/de...=mzscheme&id=1
http://shootout.alioth.debian.org/de...ng=python&id=2

Umh... non so se l'ho capita. Il problema è che python è più lento?

[javaboy]

Originariamente inviato da shinya

Umh... non so se l'ho capita. Il problema è che python è più lento?

Forse si riferisce al numero di righe di codice.

[cdimauro]

No, mi riferivo alla leggibilità del codice: trovo Python di gran lunga migliore rispetto a Scheme (e ai linguaggi funzionali in generale) da questo punto di vista.

Ovviamente è una questione di gusti personali.

[marco.r]

A me piacciono poco entrambe le versioni, in quella python tutto quel bit-shifting confonde non poco la lettura, e forse era meglio fattorizzarlo in un paio di funzioni.

[cdimauro]

Nemmeno a me piacciono, ma ho scelto questo esempio perché non è né troppo semplice né troppo lungo. Mi serviva per mettere in evidenza come già con codice un po' più complicato la differenza in termini di leggibilità risulta marcata, sebbene, come giustamente hai affermato, il codice si poteva migliorare.

Le scelte fatte penso siano figlie di un compromesso fra "complicazione" e velocità di esecuzione.

[javaboy]

Nel tempo libero sto studiando scheme/lisp.

Sto cominciando a capire il perchè di affermazioni come queste:
http://lispers.org/

[||ElChE||88]

Originariamente inviato da javaboy

Nel tempo libero sto studiando scheme/lisp.

Sto cominciando a capire il perchè di affermazioni come queste:
http://lispers.org/

Si ma alcune...

“Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.”

[javaboy]

Originariamente inviato da ||ElChE||88

Si ma alcune...

“Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.”

Concordo!
Questa affermazione è fuori di testa. Pascal è un linguaggio estremamente semplice ed elegante, c++ certamente NO ma nella sua nicchia non ha rivali.
Perl oltre ad essere orribile può essere rimpiazzato in ogni situazione da linguaggi estremamente migliori come Ruby o Python.

[marco.r]

Originariamente inviato da javaboy

Concordo!
Questa affermazione è fuori di testa. Pascal è un linguaggio estremamente semplice ed elegante, c++ certamente NO ma nella sua nicchia non ha rivali.
Perl oltre ad essere orribile può essere rimpiazzato in ogni situazione da linguaggi estremamente migliori come Ruby o Python.

Quell'affermazione e' del 2001 circa e va considerata in quel contesto. All'epoca Python era ancora giovane visto che era appena arrivato alla versione 2 (i.e. appena introdotti garbage collector decente e unicode).
Ruby era conosciuto praticamente solo in Giappone.
In compenso Perl era considerato il linguaggio per la programmazione web per eccellenza. (PHP arrivera' solo qualche anno dopo)

[||ElChE||88]

Originariamente inviato da marco.r

In compenso Perl era considerato il linguaggio per la programmazione web per eccellenza. (PHP arrivera' solo qualche anno dopo)

Anche se ai tempi non c'erano alternative non cambia il fatto che è/era un linguaggio orribile.
E resta comunque la cazzata sul Pascal...

[marco.r]

Originariamente inviato da ||ElChE||88

Anche se ai tempi non c'erano alternative non cambia il fatto che è/era un linguaggio orribile.
E resta comunque la cazzata sul Pascal...

Ripeto, l'affermazione va contestualizzata.
Ecco una spiegazione un po' piu' lunga che da Paul Graham (l'autore della suddetta citazione) in http://www.paulgraham.com/icad.html che permette di capire meglio come era python nel 2002.

As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.

(That's incremented by, not plus. An accumulator has to accumulate.)

In Common Lisp this would be

(defun foo (n) (lambda (i) (incf n i)))

and in Perl 5,

sub foo { my ($n) = @_; sub {$n += shift} }

which has more elements than the Lisp version because you have to extract parameters manually in Perl.

...

If you try to translate the Lisp/Perl/Smalltalk/Javascript code into Python you run into some limitations. Because Python doesn't fully support lexical variables, you have to create a data structure to hold the value of n. And although Python does have a function data type, there is no literal representation for one (unless the body is only a single expression) so you need to create a named function to return. This is what you end up with:

def foo(n):
    s = [n]
    def bar(i):
        s[0] += i
        return s[0]
    return bar

Python users might legitimately ask why they can't just write

def foo(n):
    return lambda i: return n += i

or even

def foo(n):
    lambda i: n += i

and my guess is that they probably will, one day. (But if they don't want to wait for Python to evolve the rest of the way into Lisp, they could always just...)

In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) by defining a class with one method and a field to replace each variable from an enclosing scope. This makes the programmer do the kind of code analysis that would be done by the compiler in a language with full support for lexical scope, and it won't work if more than one function refers to the same variable, but it is enough in simple cases like this.

Python experts seem to agree that this is the preferred way to solve the problem in Python, writing either

def foo(n):
    class acc:
        def __init__(self, s):
            self.s = s 
        def inc(self, i):
            self.s += i
            return self.s
    return acc(n).inc

or

class foo:
    def __init__(self, n): 
        self.n = n
    def __call__(self, i):
        self.n += i
        return self.n

I include these because I wouldn't want Python advocates to say I was misrepresenting the language, but both seem to me more complex than the first version. You're doing the same thing, setting up a separate place to hold the accumulator; it's just a field in an object instead of the head of a list. And the use of these special, reserved field names, especially __call__, seems a bit of a hack.

[||ElChE||88]

Originariamente inviato da marco.r

Ripeto, l'affermazione va contestualizzata.

A quei tempi Perl era orribile senza alternative migliori, ora invece è orribile con alternative migliori. Alternative o no resta comunque orribile.
E poi nella sua affermazione non dice che Perl è il miglior linguaggio per la programmazione web (affermazione che a quei tempi sarebbe stata vera), ma dice che Perl è un buon linguaggio di programmazione.

PS:

sub foo { my ($n) = @_; sub {$n += shift} }

[cdimauro]

Originariamente inviato da marco.r

Ripeto, l'affermazione va contestualizzata.
Ecco una spiegazione un po' piu' lunga che da Paul Graham (l'autore della suddetta citazione) in http://www.paulgraham.com/icad.html che permette di capire meglio come era python nel 2002.

Permettimi: non si può giudicare un linguaggio di programmazione da UNA sola caratteristica che gli manca, e per la quale sono necessari dei workaround "poco eleganti".

Carattistica tipica di linguaggi funzionali (e Python non ha questa pretesa, mi pare), e che non ti cambia la vita (anche se l'accesso alle variabili "non locali" è stato introdotto con Python 3.0; ma certamente non passerò a questa versione per le "nonlocal", quanto per altre cose ben più utili ).

Detto poi da uno che fa affermazioni che lasciano il tempo che trovano sulla programmazione oggetti...

Quanto a PERL, anche se permette di sfruttare quella caratteristica, basti vedere il codice prodotto per "apprezzarlo". Penso sia in assoluto il linguaggio di programmazione più brutto che sia mai stato concepito da mente (perversa) umana.