Re: Langage d'enseignement (Was: Python)

On 8 avr, 01:56, Wykaaa <wyk...@yahoo.fr> wrote:
> bruno desthuilliers a écrit :
>
> > On 7 avr, 21:12, Wykaaa <wyk...@yahoo.fr> wrote:
> > (snip)
> >> C'est très orienté Caml, OCaml (ce qui devrait plaire à Bruno...)
>
> > Dans les
> > cousins, y a aussi Haskell, auquel je m'étais intéressé pour voir à
> > quoi pouvait ressembler un langage fonctionnel 'pur', mais là non
> > plus, je n'ai pas été au delà d'une "découverte" du langage. Un jour
> > peut-être...
>
> Haskell ça vaut vraiment le coup, mais je doute que cela te serve dans
> ton boulot.

Directement, pas forcément, mais ça je m'en fiche totalement. Ce qui
compte, c'est en quoi ça étends mes horizons. Et puis bon, avec cette
logique là, je n'aurais pas pris la peine d'apprendre Python, qui est
pourtant une des compétences qui m'a valu mes derniers boulots.

>  Quand tu vois comment la recherche des nombres premiers
> (Crible d'Eratosthènes) se programme dans ce langage, c'est magnifique :
>
> primes = sieve [ 2.. ]
>    where
>    sieve (p:x) = p : sieve [ n | n <- x, n `mod` p > 0 ]
>
> En Python :
>
> def eratosthenes(n):
>
>      all = []
>      prime = 1

A part être incrémentée dans la boucle, cette variable ne sert à rien.

>      print 1, 2,

La version Haskell retourne une valeur, pourquoi ne pas en faire de
même ici ?

>      i = 3
>      while (i <= n):

>          if  i not in all:
>              print i,
>              prime += 1
>              j = i
>              while (j <= (n / i)):
>                  all.append(i * j)
>                  j += 1
>          i += 2
>      print

Soit c'est antédiluvien, soit celui qui a pondu ça ne connait pas
Python. En tout état de cause, un dev qui me pond ça, c'est poubelle
et interdiction de pondre une ligne de code en plus avant d'avoir
appris le langage.

Voilà une version un poil plus propre, avec évaluation paresseuse, et
qui m'a pris environ 1'30'' à pondre. Je n'ai pas vérifié la
correction de l'algo, mais là je décline toute responsabilité puisque
c'est le même...

def era2(n):
    all = []
    yield 1
    yield 2

    for i in xrange(3, n+1, 2):
        if i not in all:
            yield i
            all.extend( i * j for j in xrange(i, (n / i) + 1))

print " ".join(map(str, era2(50)))
1 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47

Si j'ai le temps, je verrais dans quelle mesure on peut le recoder
plus intelligement.

> Ces exemples sont tirés de :http://www.scriptol.org/crible.php

Auquel j'irai jeter un oeil, mais avec un a priori très négatif.

(snip)

> Et cette page, tu la connais (comparaison de langages dont Python, Ruby,
> PHP, C++, Java, etc.) ?http://www.jvoegele.com/software/langcomp.html

Le mec qui a pondu ça ferait mieux d'apprendre de quoi il cause, ça
lui éviterait de se ridiculiser. Ok, allons-y:

"Object-Orientation  	Hybrid"

Toujours la même légende urbaine comme quoi Ruby serait "pur objet" et
pas Python, hein ? Bon, petit rappel, Python est orienté objet depuis
(au moins) la première release publique (la 0.91 si ma méoire est
bonne) en 1990. En l'état actuel, *tout* ce que tu peux trouver à la
droite d'une assignation est un objet. Les classes sont des objets,
les fonctions sont des objets, les modules sont des objets, même le
putain de byte-code des fonctions est exposé comme un objet. A part -
comme en Smalltalk - implémeter les messages comme des objets et les
structures de contrôle en tant que message, je vois mal comment faire
plus objet.

"Higher Order Functions 	Lambda Expressions"

Ca veut dire quoi, ça ? L'instruction (très mal nommée) lambda génère
un objet fonction parfaitement ordinaire, ce n'est qu'un sucre
syntaxique pour des petites fonctions qui ne justifient pas une
définition séparée.  Pour le reste, une fonction Python est un objet,
donc un citoyen parfaitement ordinaire.

"Garbage Collection  	Reference Counting"

Ca fait plusieurs années déjà que le comptage de référence est doublé
d'un GC capable de détecter les cycles.

"Uniform Access     No"

Si, et depuis toujours. Aux débuts en implémentant la méthode
__getattr__(self, name), et depuis plusieurs années via le protocole
descripteur - le plus souvent en utilisant le type 'property', qui
implémente ce protocole.

"Class Variables / Methods  	No"

Les variables de classe ont toujours été supportées, les méthodes de
classe le sont depuis longtemps - si mon souvenir est bon depuis la
2.0 ou 2.1, en tous cas une version antérieure à la rédaction de ce
document. A noter également que les classmethods Python, contrairement
aux méthodes "static" de Java, recoivent l'objet classe en premier
argument. Il existe aussi des staticmethods en Python, mais leur
emploi est rarissime puisque Python n'impose pas de tout caser dans
des classes, que ça ait un sens ou non.

"Access Control  	Name Mangling"

Le name mangling (effectué sur les attributs préfixés d'un double
underscore) n'a pas pour vocation d'interdire l'accès à l'attribut,
mais de protéger un attribut essentiel d'une classe de base d'une
surcharge accidentelle. Le "contrôle d'accès" en Python se fait sur la
base d'une simple convention: un attribut préfixé d'un underscore
relève de l'implémentation, donc si vous y touchez, c'est votre
problème, on vous aura prévenu. Dans la pratique, ça marche
remarquablement bien.

Je note par contre que le garçon ne mentionne nulle part les
métaclasses...

Si tu te bases sur des exemples et comparatifs pareils, pas de
surprise que tu ai une mauvaise image de Python. Franchement, tu
ferais mieux d'apprendre le langage et de te faire ta propre idée par
toi-même.