Discussion :

[Madmac]

Non, non, c'est clairement la version 3. C'est dit dans le message #1 et ça se confirme ici :

J'en faisais la remarque parce qu'au niveau des librairies, c'est assez bordéliques. Certaines sont disponibles en 2 et pas en 3. Et visé-versa. Et en plus, il y a des profs d'université qui vont devoir se mettre à jour.

Les calculatrices programmables sont des atouts pour l'apprentissage de la programmation et de l'algorithmique. Plusieurs calculatrices compatibles Python existent aujourd'hui:

• Numworks: https://www.numworks.com/fr/
• Casio FX90+E à flasher: https://www.casio-education.fr/artic...20GRAPH%2090+E
• TI83 Premium CE dès 2019: https://education.ti.com/fr/products...-83-premium-ce

Imposer Python comme langage dans le programme du lycée forcera les fabricants à migrer vers un langage commun.

Le langage le plus logique pour une calculatrice reste le LISP. Attend-toi à la payer plus chère cette calculatrice avec python.

Ça, ça m'interpelle par contre... d'un coté, on a une volonté de typer (depuis Python 3.6, c'est possible) et de l'autre une volonté de ne pas typer... faudra que je potasse

Réponse courte: Non !

Non avons ce débat au sujet du noyau de Ruby. Et nous somme arrivé à une solution qui permet de s'en passer: Des fonctions de validations pour tester les primitives. Et c'est quelque chose qui est redondant si le langage possède Regexp. En plus dans un langage pure-objet, les classes sont un substituts pour les types. Et pour un langage comme le C++, les déclarations de types pour les variables sont redondantes, des fonctions avec des paramètres typées sont suffisant.

À moins d'être un programmeur bouillon, il n'y que les entrées qui méritent une vérification. Comme j'ai l'habitude de dire: Si on a des pommes à l'entrée, les chances d'avoir du jus de tomates à la sortie sont nul.

Pour apprendre la programmation, le Pascal et le Lisp était la meilleure école.

[Bktero]

J'en faisais la remarque parce qu'au niveau des librairies, c'est assez bordéliques. Certaines sont disponibles en 2 et pas en 3. Et visé-versa. Et en plus, il y a des profs d'université qui vont devoir se mettre à jour

Ca commence franchement à se normaliser
Voir par exemple : http://py3readiness.org/
Ou même l'ancien Wall of Shame qui était majoritairement rouge quand j'ai commencé Python en 2012 : https://python3wos.appspot.com/

C'est quand même incroyable de voir à quel point le terme "inférence de type" a été détourné. A l'origine, il s'agissait d'une vraie fonctionnalité consistant à calculer l'ensemble maximal des types d'une expression ou d'un programme, dans un langage à typage polymorphe (https://en.wikipedia.org/wiki/Hindle...er_type_system). Aujourd'hui, on utilise ce terme à tord et à travers dès qu'un langage propose un sucre syntaxique pour déduire bêtement un type à partir d'une valeur de retour. Le C++ a au moins l'honnêteté de parler de déduction de type et non d'inférence (https://isocpp.org/wiki/faq/cpp11-language#auto).

En même temps quand tu lis Wikipédia :

Type inference refers to the automatic detection of the data type of an expression in a programming language.

Il faut peut-être admettre que cet terme évolue avec le temps

[Invité]

En même temps quand tu lis Wikipédia :

Type inference refers to the automatic detection of the data type of an expression in a programming language.

Il faut peut-être admettre que cet terme évolue avec le temps

En même temps, quand tu lis 2 phrases plus loin :

The majority of them use a simple form of type inference, while especially those ones who use the Hindley-Milner type system provide a more complete type inference

Il faut peut-être admettre que ce terme évolue avec le marketing à 2 balles

[Pyramidev]

Et pour un langage comme le C++, les déclarations de types pour les variables sont redondantes, des fonctions avec des paramètres typées sont suffisant.

Faux. Exemple :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Déclarations :
int foo();
ClasseDerivee& bar();
 
// Utilisation :
void baz() {
    auto          var1 = foo(); // var1 est de type int.
    const auto    var2 = foo(); // var2 est de type const int. On a besoin d'écrire const.
    auto&         var3 = bar(); // var3 est de type ClasseDerivee&.
    ClasseDeBase& var4 = bar(); // var4 est de type ClasseDeBase&. On a besoin d'écrire le type tout entier.
    ...
}

[Madmac]

Faux. Exemple :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Déclarations :
int foo();
ClasseDerivee& bar();
 
// Utilisation :
void baz() {
    auto          var1 = foo(); // var1 est de type int.
    const auto    var2 = foo(); // var2 est de type const int. On a besoin d'écrire const.
    auto&         var3 = bar(); // var3 est de type ClasseDerivee&.
    ClasseDeBase& var4 = bar(); // var4 est de type ClasseDeBase&. On a besoin d'écrire le type tout entier.
    ...
}

Bien tu es arrivé avec le pire contre-argument possible. Les valeurs de tes variables sont systématiquement du même type que la valeurs de retour de la fonction. Donc la déclaration est totalement inutile puisque tu n'as qu'à identifier ce que donne ces fonctions. Et dans tous les cas, tu obtiens un pointeur sur une adresse mémoire.

C'est assez culotté de dire que c'est impossible, quand les programmeurs de LISP, Prolog, Scheme arrivent à le faire depuis au moins depuis 4 décennies.