Re: Langage d'enseignement (Was: Python)

Wykaaa a écrit :
> Bruno Desthuilliers a écrit :
>> 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.
> 
> Encore une fois, tu lies trop typage statique et erreur de programmation.

Moi, non. Je constate juste, pour la ènième fois, que contrairement à un 
ce qu'affirme un certain discours de façon quasi-idéologique, le typage 
statique n'empêche pas les erreurs à l'exécution, et que par conséquent 
la critique du typage dynamique sur cette base ne tient pas la route.

> Pour la fusée, voir plus bas...

>>>>
>>>> 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...
> 
> Tu IIRC bien :-), mais en l'occurrence, le corps des  nombres réels (IR 
> hein, à ne pas confondre avec float ou double) possèdent bien les 
> opérations + et * mais ses valeurs sont dans l'intervalle ouvert 
> ]-00,+00[, alors...

> Ceci dit, en ADA, on sait se débrouiller pour faire un type dont les 
> valeurs respectent l'intervalle de arccos, qu'une exception soit levée 
> au cas ou la valeur n'est pas dans l'intervalle et que le code de 
> récupération de l'exception fasse ce qu'il faut.
>>
>>> (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.
> 
> Le problème était surtout que Ariane 5 ne se comporte pas comme Ariane 4 
> au décollage. Ariane 4 a un V0 (vitesse par rapport au sol) de quasiment 
> zéro (elle décolle verticalement) alors que Ariane 5 s'incline 
> rapidement pour bénéficier de la force de Coriolis (enfin les effets 
> accélérateur) car elle est plus lourde que son ancêtre. Mais le module 
> logiciel de navigation de Ariane 5 a été repris intégralement de celui 
> de Ariane 4.


> Le résultat est que le module logiciel, quand il a vu un V0 très 
> différent de celui attendu, a cherché à corriger la trajectoire (pour 
> que la fusée reste verticale). Sur le film du décollage, on voit 
> d'ailleurs, juste avant la désintégration, la fusée se redresser. Elle 
> était en pleine accélération et sa structure n'a donc pas résisté à la 
> correction de trajectoire.
> C'est donc un défaut d'intégration logiciel/matériel (les procédures de 
> tests d'intégration n'ont pas été toutes respectées par le sous-traitant).

Qui disait dans un post précédent:

"""
Le typage statique contribue surtout à augmenter la qualité de facteurs 
comme l'évolutivité, la maintenabilité, la réutilisabilité, 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.
"""

Oui, je sais, ce n'est pas exactement le même mode de réutilisation. 
Mais justement, ça démontre bien, encore une fois, qu'on ne peut régler 
   des problèmes essentiellement humains avec des solutions purement 
technologiques.