• [^] # Re: Performance

    Posté par . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 3.

    Oui mais tu réponds à une comparaison entre C++ et python. Donner un exemple pourquoi pas venir dire que le langage foobar lui il est mieux, c'est hors sujet.

    Ce n'est pas vraiment hors-sujet à mon avis. Philippe Fremy répond à rewind en postant une vidéo d'une de ses conférences sur le typage statique en python. Le slide de conclusion est :

    Conclusion :

    • Type annotation is powerful to bug finder. Use it !
    • Type annotation is also good way to document your code.
    • Feedback from developpers using type annoation: "It rocks !"
    • Some python dynamic constructs are difficult to verify statically

    Là où c'est déjà étrange, c'est que dans sa réponse il laisse entendre que rewind cherche à troller, alors que c'est justement ces avantages du typage statique que rewind et chimrod ont cherchait à mettre en avant.

    Ensuite, oui cela relève d'une plus grande sûreté que le recours aux tests unitaires. Quand on pousse jusqu'aux systèmes à types dépéndants, non seulement on ne fait plus de tests unitaires mais en plus on obtient une sûreté que ne pourront jamais atteindre ces derniers : un test peut montrer l'existence d'un bug (dans le respect à la spécification) mais jamais son absence.

    Typer son code permet effectivement de le documenter (point 2 du slide de conclusion) car le langage de types est un langage formel d'écriture de spécification du code, et permet donc d'exprimer en partie ce que doit faire la fonction. D'où mon point précédent, avec des types dépendants on peut totalement spécifier formellement le code et donc vérifier qu'il est conforme à sa spécification.

    Pour le typage structurel, on peut tout à fait faire cela statiquement et sans écrire d'annotation. Quelques exemples issues de la conférence de Philippe Fremy :

    (* voir à la 20ème minute *)
    (* cas d'un bug détecter statiquement *)
    class a ?step_init = object
     val step = step_init
     method get_step = step_init + 1
    end;;
    Error: This expression has type 'a option
     but an expression was expected of type int
    (* première solution on teste la valeur de l'attribut [step] *)
    class a ?step_init () = object
     val step = step_init
     method get_step = match step with None -> 0 | Some step-> step + 1
    end;;
    class a :
     ?step_init:int ->
     unit -> object val step : int option method get_step : int end
    (* deuxième solution, on initialise avec une valeur par défaut *)
    class a ?(step_init = 0) () = object
     val step = step_init
     method get_step = step + 1 end;;
    class a :
     ?step_init:int -> unit -> object val step : int method get_step : int end
    (* pour le typage structurel, voire autour de la 30ème minute *)
    let validate form data = form#validate data;;
    val validate : < validate : 'a -> 'b; .. > -> 'a -> 'b = <fun>

    Enfin, pour ce qui est des objets et du typage structurel, la façon dont ils sont globalement utilisés en pratique cela en fait surtout des modules du pauvre. En OCaml on utilisera plutôt des modules, en Haskell des type classes, en Rust des traits et en C++ des template.

    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.