Re: Langage d'enseignement (Was: Python)

Wykaaa a écrit :
> Matthieu Villeneuve a écrit :
>> Wykaaa wrote:
>>> Matthieu Villeneuve a écrit :
>>>> Wykaaa wrote:
>>>>> Je te garantis que l'appli en question n'aurait pas pu utiliser le
>>>>> typage dynamique (avionique militaire)
>>>> C'est intéressant, pouvez-vous expliquer un peu pourquoi ?
>>>>
>>> Dans des applications de ce type, il est hors de question qu'une simple
>>> erreur de typage se traduise par un arrêt du programme à l'exécution.
>>
>> Je suis d'accord, mais pourquoi faire une différence entre erreurs de
>> typage et autres erreurs de programmation, pour lesquelles le typage
>> statique ne donne pas de solution ? Il me semble que quel que soit le
>> langage utilisé, l'application ne sera jamais utilisée si elle ne passe
>> pas une batterie exhaustive de tests. Et que ces tests couvrent tous
>> les scenarii possibles, incluant ceux qui pourraient provoquer une
>> erreur de typage.
> 
> Voir ma réponse à Bruno dans ce même fil (en particulier sur les tests).
> 
> Enfin, je répète lier systématiquement typage statique et détection 
> d'erreur de programmation est une vue très étroite des bénéfices du 
> typage statique et que ce n'est même pas son but principal.

Ah ? Tiens, il me semblait que tu avais affirmé plus haut que l'intérêt 
premier du typage statique était la correction du typage ?-)

> Le typage statique contribue surtout à augmenter la qualité de facteurs 
> comme l'évolutivité, la maintenabilité, la réutilisabilité,

Mouarf. Dans mon expérience, c'est exactement ce que le typage statique 
déclaratif à la Java rend inutilement compliqué (et donc plus sujet à 
erreur), et c'est précisément une des raisons pour lesquelles j'apprécie 
le typage dynamique.

> car on aura 
> des erreurs de compilation sur les types quand on déplacera un module ou 
> du code hors de son contexte sans avoir pris les précautions nécessaires.

Mouais... On a beau dire, on crashe des fusées quand même.

>>
>> Au passage, un compilateur pour un langage à typage statique n'est en
>> général capable de vérifier qu'un ensemble très réduit de conditions,
>> et laisse passer énormément d'erreurs de typage (dès que la définition
>> d'un type valide ne correspond pas exactement au découpage visible par
>> le compilateur). Par exemple, le calcul d'un arccos d'une valeur hors
>> de l'intervalle [-1, 1], l'utilisation d'un objet dans un état 
>> incorrect, etc. etc.
>>
> Le calcul d'une valeur en dehors d'un certain intervalle ne relève pas 
> forcément du typage

IIRC, selon certaines théories, un type est défini par un ensemble de 
valeurs et les opérations sur ces valeurs...

> (cf. fusée Ariane 5 programmée en ADA, l'un des 
> langages à plus fort typage statique).

Le problème était, en l'occurrence et s'il me souvient bien, à la 
combinaison d'un integer overflow ET de la désactivation de la gestion 
d'erreur dans cette partie du code.

> L'utilisation d'un objet dans un état incorrect non plus. Ce genre de 
> problème se prévient (je ne dis pas qu'il est totalement résolu par, 
> hein ?) par les méthodes de la programmation sûre.
> A ce propos, voici un petit guide pour le langage C :
> ftp://ftp.laas.fr/pub/ii/matthieu/c-superflu/c-superflu.pdf