On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
<pythonnews@nospam.jmbc.fr> wrote:
> En quoi donc d'aucuns supposent-ils que le typage statique est un
> avantage ?

Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie
ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu
vas voir comment tu vas te faire déchirer... Je me suis désabonné du
groupe rien que pour ça...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
<pythonnews@nospam.jmbc.fr> wrote:
> En quoi donc d'aucuns supposent-ils que le typage statique est un
> avantage ?

Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie
ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu
vas voir comment tu vas te faire déchirer... Je me suis désabonné du
groupe rien que pour ça...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

MC a écrit :
> Salut !
>
>> 0 or 1? My compromise of 0.5
>
> ;o) ça pourrait déboucher sur un nouveau concept de langage...
>
En logique floue par exemple...

Nicolas

MC a écrit :
> Salut !
>
>> 0 or 1? My compromise of 0.5
>
> ;o) ça pourrait déboucher sur un nouveau concept de langage...
>
En logique floue par exemple...

Nicolas

> En quoi donc d'aucuns supposent-ils que le typage statique est un
> avantage ?

Ben, par qu'avec un typage statique, tu peux vérifier toutes les affectations les comparaisons... au niveau de la compilation. Avec du typage dynamique tu n'est jamais sûr que ça ne se plantera pas car il faudrait tester toutes les combinaisons possibles lors d'un test. Ce qui n'est pas toujours facile.

Nicolas
PS : J'ai pas dit que je suis d'accord avec cet argumentation.

> En quoi donc d'aucuns supposent-ils que le typage statique est un
> avantage ?

Ben, par qu'avec un typage statique, tu peux vérifier toutes les affectations les comparaisons... au niveau de la compilation. Avec du typage dynamique tu n'est jamais sûr que ça ne se plantera pas car il faudrait tester toutes les combinaisons possibles lors d'un test. Ce qui n'est pas toujours facile.

Nicolas
PS : J'ai pas dit que je suis d'accord avec cet argumentation.

NicolasP a écrit :
> Bruno Desthuilliers a écrit :
>> NicolasP a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> NicolasP a écrit :
(snip)
>>>>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>>>>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>>>>
>>>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent
>>>> pas à l'exercice ?
>>>>
>>> Je ne connais pas ces langages. Comme il a été dit précédemment, le C
>>> est le langage le plus "universel". Même si ce n'est pas toujours le
>>> plus adapté, on peut tout faire avec.
>>
>> Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
>> point de salut" ?
>>
> Effectivement, il y l'assembleur qui est l'arme absolue.

Ce n'est pas vraiment à ça que je pensais !-)

(snip)

> Ce que je veux dire, c'est que on trouve toujours (ou presque) un
> compilateur C pour un micro donné. Ce qui n'est pas le cas les autres
> langages.

Ok sur ce point.

> Et le C est tellement bas niveau (on pourrait presque dire que
> c'est une surcouche de l'assembleur)

En ce qui me concerne, tu peux virer le conditionnel !-)

> que l'on peut générer du code pour
> tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256
> octets de RAM. A part l'assembleur et le C, je ne connais pas de langage
> adapté.

Et ce n'est pas moi qui saurait te dire si ADA, OCaml ou autres peuvent
rentrer là dedans.

> Et surtout, je ne connais pas d'autre langage qui possède un
> compilateur conçu pour mon micro.
> Attention, je n'ai pas dit que le C est le langage idéal ou le plus
> universel

Ah, si, ça tu l'a dit - regarde un peu plus haut !-)

> ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un
> compilateur C à se mettre sous la main.
> Et dans certains cas particuliers, genre temps réel dur, en C tout est
> sous contrôle.

Si tu bypasse l'OS (ce qui implique qu'il y en ait un)...

> Avec d'autres langages (y compris C++), on ne maitrise
> pas tout.

Là, ça sort de ma (maigre) compétence.

> Nicolas

NicolasP a écrit :
> Bruno Desthuilliers a écrit :
>> NicolasP a écrit :
>>> Bruno Desthuilliers a écrit :
>>>> NicolasP a écrit :
(snip)
>>>>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>>>>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>>>>
>>>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent
>>>> pas à l'exercice ?
>>>>
>>> Je ne connais pas ces langages. Comme il a été dit précédemment, le C
>>> est le langage le plus "universel". Même si ce n'est pas toujours le
>>> plus adapté, on peut tout faire avec.
>>
>> Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
>> point de salut" ?
>>
> Effectivement, il y l'assembleur qui est l'arme absolue.

Ce n'est pas vraiment à ça que je pensais !-)

(snip)

> Ce que je veux dire, c'est que on trouve toujours (ou presque) un
> compilateur C pour un micro donné. Ce qui n'est pas le cas les autres
> langages.

Ok sur ce point.

> Et le C est tellement bas niveau (on pourrait presque dire que
> c'est une surcouche de l'assembleur)

En ce qui me concerne, tu peux virer le conditionnel !-)

> que l'on peut générer du code pour
> tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256
> octets de RAM. A part l'assembleur et le C, je ne connais pas de langage
> adapté.

Et ce n'est pas moi qui saurait te dire si ADA, OCaml ou autres peuvent
rentrer là dedans.

> Et surtout, je ne connais pas d'autre langage qui possède un
> compilateur conçu pour mon micro.
> Attention, je n'ai pas dit que le C est le langage idéal ou le plus
> universel

Ah, si, ça tu l'a dit - regarde un peu plus haut !-)

> ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un
> compilateur C à se mettre sous la main.
> Et dans certains cas particuliers, genre temps réel dur, en C tout est
> sous contrôle.

Si tu bypasse l'OS (ce qui implique qu'il y en ait un)...

> Avec d'autres langages (y compris C++), on ne maitrise
> pas tout.

Là, ça sort de ma (maigre) compétence.

> Nicolas

Eric Brunel a écrit :
> On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
> <pythonnews@nospam.jmbc.fr> wrote:
>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>> avantage ?
>
> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
> désabonné du groupe rien que pour ça...

Non, non, c'est juste parce que je n'ai pas compris.
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...

Eric Brunel a écrit :
> On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
> <pythonnews@nospam.jmbc.fr> wrote:
>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>> avantage ?
>
> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
> désabonné du groupe rien que pour ça...

Non, non, c'est juste parce que je n'ai pas compris.
En fait, je ne suis pas sûr de savoir ce que c'est que le typage statique...

jean-michel bain-cornu a écrit :
> Eric Brunel a écrit :
>> On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
>> <pythonnews@nospam.jmbc.fr> wrote:
>>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>>> avantage ?
>>
>> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
>> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
>> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
>> désabonné du groupe rien que pour ça...
>
> Non, non, c'est juste parce que je n'ai pas compris.
> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
> statique...

Heu... c'est de l'humour, là ? Ou tu es sérieux ?

Dans le second cas, à toutes fins utiles, et en résumant/simplifiant
outrageusement[1] : typage statique = vérification du typage à la
compilation, en fonction soit des déclarations de types dans le code
(typage statique déclaratif, cas le plus courant, cf C, C++, pascal,
ADA, Java etc), soit en fonction de types génériques déduits par le
compilateur de l'utilisation effective (inférence de type, plus rare,
essentiellement OCaml, Haskell & co).

La raison première de la chose est de permettre au compilo d'effectuer
certaines optimisations. Ce qui est un avantage indéniable du point de
vue des performances.

Accessoirement, ça peut, dans certains cas, permettre de détecter à la
compil certaines erreurs (potentielles) de type. Ce qui n'est pas un
avantage si important AMHA compte tenu de la complexité (et donc des
rsiques d'erreurs) et de la rigidité que ça peut induire.

[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
d'accord sur la théorie, et je ne suis en aucun cas un des ces
"spécialistes".

jean-michel bain-cornu a écrit :
> Eric Brunel a écrit :
>> On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu
>> <pythonnews@nospam.jmbc.fr> wrote:
>>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>>> avantage ?
>>
>> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
>> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
>> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
>> désabonné du groupe rien que pour ça...
>
> Non, non, c'est juste parce que je n'ai pas compris.
> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
> statique...

Heu... c'est de l'humour, là ? Ou tu es sérieux ?

Dans le second cas, à toutes fins utiles, et en résumant/simplifiant
outrageusement[1] : typage statique = vérification du typage à la
compilation, en fonction soit des déclarations de types dans le code
(typage statique déclaratif, cas le plus courant, cf C, C++, pascal,
ADA, Java etc), soit en fonction de types génériques déduits par le
compilateur de l'utilisation effective (inférence de type, plus rare,
essentiellement OCaml, Haskell & co).

La raison première de la chose est de permettre au compilo d'effectuer
certaines optimisations. Ce qui est un avantage indéniable du point de
vue des performances.

Accessoirement, ça peut, dans certains cas, permettre de détecter à la
compil certaines erreurs (potentielles) de type. Ce qui n'est pas un
avantage si important AMHA compte tenu de la complexité (et donc des
rsiques d'erreurs) et de la rigidité que ça peut induire.

[1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
d'accord sur la théorie, et je ne suis en aucun cas un des ces
"spécialistes".

>> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
>> statique...
>
> Heu... c'est de l'humour, là ? Ou tu es sérieux ?
>
J'étais sérieux hélas.
>
> [1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
> d'accord sur la théorie, et je ne suis en aucun cas un des ces
> "spécialistes".
C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage
statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
phase de compilation explicite ?

>> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
>> statique...
>
> Heu... c'est de l'humour, là ? Ou tu es sérieux ?
>
J'étais sérieux hélas.
>
> [1] je n'ai jamais vu deux "spécialistes" des systèmes de typage tomber
> d'accord sur la théorie, et je ne suis en aucun cas un des ces
> "spécialistes".
C'est aussi mon problème.
Quand on code i=1 en python, fait-on du typage statique, du typage
statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
phase de compilation explicite ?

Le 1 octobre 2007 à 09:58, Eric Brunel a dit :

> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
> désabonné du groupe rien que pour ça...

Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour
ce que j'en ai vu, ce groupe est mort...


Pour le reste j'ai bien l'impression de ne pas avoir été compris (où
alors c'était à cause du vendredi) mais bien qu'ayant d'excellents
souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que
ruby et RoR d'ailleurs) à mon boulot.

Le seul problème c'est que le chef veut bien de tout ce qu'on lui
propose seulement il revient toujours nous demander si on ne peut pas
« lui faire un exe » pour distribuer à ses clients.

On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne
fait pas sérieux » au contraire d'un .exe.
Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou
du hta pour mes collègues) sous forme d'un package « exe »... Pfff (
--
Sébastien Kirche

Le 1 octobre 2007 à 09:58, Eric Brunel a dit :

> Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
> compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
> de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
> désabonné du groupe rien que pour ça...

Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour
ce que j'en ai vu, ce groupe est mort...


Pour le reste j'ai bien l'impression de ne pas avoir été compris (où
alors c'était à cause du vendredi) mais bien qu'ayant d'excellents
souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que
ruby et RoR d'ailleurs) à mon boulot.

Le seul problème c'est que le chef veut bien de tout ce qu'on lui
propose seulement il revient toujours nous demander si on ne peut pas
« lui faire un exe » pour distribuer à ses clients.

On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne
fait pas sérieux » au contraire d'un .exe.
Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou
du hta pour mes collègues) sous forme d'un package « exe »... Pfff (
--
Sébastien Kirche

jean-michel bain-cornu a écrit :
>>> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
>>> statique...
>>
>> Heu... c'est de l'humour, là ? Ou tu es sérieux ?
>>
> J'étais sérieux hélas.
>>
>> [1] je n'ai jamais vu deux "spécialistes" des systèmes de typage
>> tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces
>> "spécialistes".
> C'est aussi mon problème.
> Quand on code i=1 en python, fait-on du typage statique, du typage
> statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
> phase de compilation explicite ?

Le fait que la phase de compilation soit explicite ou non n'y change
rien - d'ailleurs, tu peux explicitement compiler tes sources Python.

En ce qui concerne Python, le typage est tout à fait dynamique. Il n'y a
ni déclaration de type (pour les variables/attributs et les paramètres
de fonction), ni inférence. La vérification a lieu à l'exécution, et se
résume le plus souvent à tenter d'utiliser l'objet, et à lancer une
exception s'il n'a pas les attributs (ce qui en Python inclue les
méthodes) attendus.

Pour du typage statique déclaratif, regarde du côté de Java, C, C++, C#,
Ada, Pascal etc... Dans tous ces langages, tu dois déclarer le type des
variables, le type des arguments et le type des fonctions (c'est à dire
le type des valeurs qu'elles retournent). Ce qui, en POO, est une
douleur anale majeure, puisque le même mécanisme (l'héritage) sert aussi
bien pour l'implémentation que pour le typage, ce qui implique que le
fait, pour un objet, d'implémenter effectivement un certain protocole ne
suffit pas à le rendre substituable à un objet du type attendu. Ce qui
nuit quelque peu à la généricité...

jean-michel bain-cornu a écrit :
>>> En fait, je ne suis pas sûr de savoir ce que c'est que le typage
>>> statique...
>>
>> Heu... c'est de l'humour, là ? Ou tu es sérieux ?
>>
> J'étais sérieux hélas.
>>
>> [1] je n'ai jamais vu deux "spécialistes" des systèmes de typage
>> tomber d'accord sur la théorie, et je ne suis en aucun cas un des ces
>> "spécialistes".
> C'est aussi mon problème.
> Quand on code i=1 en python, fait-on du typage statique, du typage
> statique implicite, ou du typage dynamique du fait qu'il n'y a pas de
> phase de compilation explicite ?

Le fait que la phase de compilation soit explicite ou non n'y change
rien - d'ailleurs, tu peux explicitement compiler tes sources Python.

En ce qui concerne Python, le typage est tout à fait dynamique. Il n'y a
ni déclaration de type (pour les variables/attributs et les paramètres
de fonction), ni inférence. La vérification a lieu à l'exécution, et se
résume le plus souvent à tenter d'utiliser l'objet, et à lancer une
exception s'il n'a pas les attributs (ce qui en Python inclue les
méthodes) attendus.

Pour du typage statique déclaratif, regarde du côté de Java, C, C++, C#,
Ada, Pascal etc... Dans tous ces langages, tu dois déclarer le type des
variables, le type des arguments et le type des fonctions (c'est à dire
le type des valeurs qu'elles retournent). Ce qui, en POO, est une
douleur anale majeure, puisque le même mécanisme (l'héritage) sert aussi
bien pour l'implémentation que pour le typage, ce qui implique que le
fait, pour un objet, d'implémenter effectivement un certain protocole ne
suffit pas à le rendre substituable à un objet du type attendu. Ce qui
nuit quelque peu à la généricité...

NicolasP a écrit :
>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>> avantage ?
>
>
> Ben, par qu'avec un typage statique, tu peux vérifier toutes les
> affectations les comparaisons... au niveau de la compilation.

C'est pour ça qu'il y a des runtimeError dans pas mal de langages
"objets" (hem) à typage statique déclaratif (cherchez l'erreur).
Lesquelles runtimeError apparaissent généralement lors d'un downcast
foireux.

> Avec du
> typage dynamique tu n'est jamais sûr que ça ne se plantera pas

Avec du typage statique non plus.

> car il
> faudrait tester toutes les combinaisons possibles lors d'un test. Ce qui
> n'est pas toujours facile.

Au moins, avec le typage dynamique, on vit en dehors de l'illusion que
"ça ne peut pas arriver" - idem d'ailleurs pour des langages à typage
certes statique, mais tellement faible qu'il est évident qu'il est là
pour le compilo, pas pour (enfin, contre...) le programmeur.

> Nicolas
> PS : J'ai pas dit que je suis d'accord avec cet argumentation.

Moi non plus !-)

NicolasP a écrit :
>> En quoi donc d'aucuns supposent-ils que le typage statique est un
>> avantage ?
>
>
> Ben, par qu'avec un typage statique, tu peux vérifier toutes les
> affectations les comparaisons... au niveau de la compilation.

C'est pour ça qu'il y a des runtimeError dans pas mal de langages
"objets" (hem) à typage statique déclaratif (cherchez l'erreur).
Lesquelles runtimeError apparaissent généralement lors d'un downcast
foireux.

> Avec du
> typage dynamique tu n'est jamais sûr que ça ne se plantera pas

Avec du typage statique non plus.

> car il
> faudrait tester toutes les combinaisons possibles lors d'un test. Ce qui
> n'est pas toujours facile.

Au moins, avec le typage dynamique, on vit en dehors de l'illusion que
"ça ne peut pas arriver" - idem d'ailleurs pour des langages à typage
certes statique, mais tellement faible qu'il est évident qu'il est là
pour le compilo, pas pour (enfin, contre...) le programmeur.

> Nicolas
> PS : J'ai pas dit que je suis d'accord avec cet argumentation.

Moi non plus !-)

Sébastien Kirche a écrit :
> Le 1 octobre 2007 à 09:58, Eric Brunel a dit :
>
>
>>Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
>>compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
>>de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
>>désabonné du groupe rien que pour ça...
>
>
> Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour
> ce que j'en ai vu, ce groupe est mort...

presque autant que f.c.objet et f.c.l.lisp

>
> Pour le reste j'ai bien l'impression de ne pas avoir été compris (où
> alors c'était à cause du vendredi)

Mééé non !

Enfin... Un peu, mais pas seulement !-)

Plus sérieusement, et avec tout le respect que j'ai pour ADA (et pour
toi), le fait est qu'*aucun* système n'est à l'abri d'une erreur,
généralement - mais pas toujours - humaine. Et que les erreurs de
typage, outre qu'elles ne constituent qu'une petite part des erreurs
possibles et sont généralement les plus simples à détecter (et
corriger), ont tendance (d'après mon expérience du moins, et ça peut
s'expliquer) à être *moins* courantes dans les langages à typage
dynamique ou à inférence de type.

> mais bien qu'ayant d'excellents
> souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que
> ruby et RoR d'ailleurs) à mon boulot.
>
> Le seul problème c'est que le chef veut bien de tout ce qu'on lui
> propose seulement il revient toujours nous demander si on ne peut pas
> « lui faire un exe » pour distribuer à ses clients.
>
> On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne
> fait pas sérieux » au contraire d'un .exe.

Bin oué...

> Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou
> du hta pour mes collègues) sous forme d'un package « exe »... Pfff (

py2exe ?

<troll-du-lundi cible='mc'>
Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
sur des machines équipées d'un système d'exploitation !-)
</troll-du-lundi>

Sébastien Kirche a écrit :
> Le 1 octobre 2007 à 09:58, Eric Brunel a dit :
>
>
>>Tu dis ça parce que tu as l'habitude d'être entre gens de bonne
>>compagnie ici... Va sur fr.comp.developpement et essaie de leur parler
>>de Python, tu vas voir comment tu vas te faire déchirer... Je me suis
>>désabonné du groupe rien que pour ça...
>
>
> Je m'y suis abonné depuis peu à cause d'une discussion redirigée et pour
> ce que j'en ai vu, ce groupe est mort...

presque autant que f.c.objet et f.c.l.lisp

>
> Pour le reste j'ai bien l'impression de ne pas avoir été compris (où
> alors c'était à cause du vendredi)

Mééé non !

Enfin... Un peu, mais pas seulement !-)

Plus sérieusement, et avec tout le respect que j'ai pour ADA (et pour
toi), le fait est qu'*aucun* système n'est à l'abri d'une erreur,
généralement - mais pas toujours - humaine. Et que les erreurs de
typage, outre qu'elles ne constituent qu'une petite part des erreurs
possibles et sont généralement les plus simples à détecter (et
corriger), ont tendance (d'après mon expérience du moins, et ça peut
s'expliquer) à être *moins* courantes dans les langages à typage
dynamique ou à inférence de type.

> mais bien qu'ayant d'excellents
> souvenirs d'Ada je suis ravi d'avoir pu introduire python (ainsi que
> ruby et RoR d'ailleurs) à mon boulot.
>
> Le seul problème c'est que le chef veut bien de tout ce qu'on lui
> propose seulement il revient toujours nous demander si on ne peut pas
> « lui faire un exe » pour distribuer à ses clients.
>
> On dirait bien que dans l'esprit de beaucoup de gens les scripts « ça ne
> fait pas sérieux » au contraire d'un .exe.

Bin oué...

> Du coup il faut toujours ruser pour distribuer du python (ou du perl, ou
> du hta pour mes collègues) sous forme d'un package « exe »... Pfff (

py2exe ?

<troll-du-lundi cible='mc'>
Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
sur des machines équipées d'un système d'exploitation !-)
</troll-du-lundi>

le 01.10.2007 20:24 Bruno Desthuilliers a écrit:

>
> <troll-du-lundi cible='mc'>
> Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
> sur des machines équipées d'un système d'exploitation !-)
VMS ?? ;-)
> </troll-du-lundi>

le 01.10.2007 20:24 Bruno Desthuilliers a écrit:

>
> <troll-du-lundi cible='mc'>
> Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
> sur des machines équipées d'un système d'exploitation !-)
VMS ?? ;-)
> </troll-du-lundi>

>> <troll-du-lundi cible='mc'>
>> Enfin bon, je dis ça mais perso je m'en fout un peu, je ne déploie que
>> sur des machines équipées d'un système d'exploitation !-)
> VMS ?? ;-)
>> </troll-du-lundi>
>

Oui, Vindows Mci Systems...