Discussion :

[petitours]

Si le typage peut être forcé alors c'est une grande nouvelle.
pas de typage tu peux apprendre plus facilement (quoi que...)
typage impératif = tu bosses sérieusement avec le garde fou le plus élémentaire

[SurferIX]

Si le typage peut être forcé alors c'est une grande nouvelle.
pas de typage tu peux apprendre plus facilement (quoi que...)
typage impératif = tu bosses sérieusement avec le garde fou le plus élémentaire

C'est pourquoi l'ADA n'a jamais décollé : tout doit être typé et borné. Même un entier quand tu le veux tu dois préciser ses bornes !
Bien sûr je le regrette amèrement, mais l'être humain est ce qu'il est et il préfère tout à l'arrache et vite plutôt que tout bien, et propre...

http://www.ada2012.org/

Ada 2012 is the next generation of the world’s premier programming language for engineering safe, secure and reliable software.

Bah oui. Là c'est sur on n'est pas en Php où on peut faire "olivier" + 6 * "coca" et ne pas avoir même un seul warning !

Ada aujourd'hui

Ada est le plus avancé des langages orientés objet

Ada 2012 est un véritable langage industriel qui conserve les avantages des versions précédentes tout en offrant un support aux besoins d'aujourd'hui : héritage, interfaces, parallélisme, exécution distribuée, compatibilité avec les bibliothèques et les standards du marché.

[petitours]

Préciser les bornes d'une variable c'est sans doute un peu excessif...

La "facilité" qu'apporte l'absence de typage est sans doute favorable à l'apprentissage mais mais il n'est pas possible de faire des choses qui marchent bien sans un peu de rigueur sur les types, ça nous pète à la tronche bien avant ! Le copilo devine...devine...devine....devine...et bam il n'arrive plus à deviner le truc que l'on a codé il y a 1 an (et là va trouver le bug...)

[martopioche]

Tous les langages faiblement typés permettent de faire plus facilement de la merde

Yep, et avec Python, on peut vite le faire. Mais si on se retrouve avec un logiciel de m…, ce n'est pas le stagiaire le problème mais le responsable qualité.

et avec le temps ils évoluent tous dans le même sens : on en arrive systématiquement à "il faut typer les paramètres, il faut pouvoir faire des constantes non modifiables, etc.". Tu verras que tous les langages haut niveau finissent par tendre vers les "idéaux" que sont C++ et Java. Et paradoxalement... ce sont les langages les plus difficiles et les moins agréables à appréhender !

C'est vrai pour les langages "commerciaux" qui doivent s'imposer par le volume. C'est ce que j'apprécie avec Python, quand je vois qu'un dev "standard" s'inquiète de la conséquence d'une erreur d'indentation, ne reste dans la communauté que les devs compétents, les autres continuent Java…

[martopioche]

La "facilité" qu'apporte l'absence de typage est sans doute favorable à l'apprentissage mais mais il n'est pas possible de faire des choses qui marchent bien sans un peu de rigueur sur les types, ça nous pète à la tronche bien avant ! Le copilo devine...devine...devine....devine...et bam il n'arrive plus à deviner le truc que l'on a codé il y a 1 an (et là va trouver le bug...)

Sauf qu'en ce qui concerne Python, il y a bien présence de types, Python est un langage fortement typé…*C'est la confusion classique du néophyte entre "typage fort" et "être déclaratif"… Et donc ça tombe bien, Python est très rigoureux sur les types.

[dourouc05]

Fortement typé, oui, mais avec du "duck typing" : quand on appelle une méthode, l'interpréteur cherche juste à savoir si l'objet la possède, pas s'il a la bonne interface… ce qui n'est pas toujours la même chose.

[martopioche]

Fortement typé, oui, mais avec du "duck typing" : quand on appelle une méthode, l'interpréteur cherche juste à savoir si l'objet la possède, pas s'il a la bonne interface… ce qui n'est pas toujours la même chose.

On peut même dire que les notions de fortement/faiblement typé et duck typing et interfaces n'ont strictement rien à voir, en effet.

[Alexandre13]

Bonjour,

Merci pour l'article mais j'aurais apprécié une argumentation sur le pourquoi... Ces experts expliquent-ils leurs point de vu?

Du reste, R est un langage de niche, développé pour et par des statisticiens. Son rôle premier n'est pas du faire du développement, mais de l'analyse. Du coup, on se doute que les performances n'ont pas été la préoccupation centrale lors du développement et c'est sans doute là qqch de rédhibitoire pour un développeur. Pour un statisticien en revanche, ça n'est pas trop gênant, surtout qu'avec de bonnes pratiques (pré-allocation de mémoire, vectorisation...), les fonctions de packages compilées en C, et les packages qui permettent la parallélisation des calculs, il y a quand même de quoi optimiser le temps de calcul... Pour du one-shot, c'est vraiment pas un souci.

Bref, je pense que la question se pose maintenant car les librairies ont considérablement fait évoluer les possibilités de R, jusqu'à l'amener sur le terrain de Python j'imagine. Je reste encore dubitatif sur les capacités de Python à réaliser les analyses stats fait sous R (glm, nlm, ...), mais j'ignore tout de python (c'est une question de bonne foi, pas du troll). Du reste, dans le cadre d'une application à but scientifique, faire appel à des scripts R pour faire qq calculs dont les résultats sont repris par l'interface (codée en ce que vous voulez) n'est-il pas un fonctionnement viable?

Du reste, avant de me dire que je vais passé du R au Python, je préfère attendre un peu de voir ce que donne Julia (pour les curieux : https://bioinfo-fr.net/julia-le-successeur-de-r). Apparemment côté performance ça met la tannée à Python et j'ai l'impression que la syntaxe est beaucoup plus proche...

P.S : je ne trouve pas que la doc de R soit calamiteuse. Elle est précise côté scientifique, même si au début c'est opaque, on s'y fait et c'est en fait très synthétique... On s'attend juste à ce que vous soyez au fait des paramètres nécessaires à la réalisation de la fonction que vous souhaitez employez. C'est moins vrai pour les fonctions importées depuis d'autre langages où on vous renvoi sur la doc officielle, notamment pour ce qui est de la transcription en R. Bref, là ça ne dépend de ceux qui ont fait le package... Mais on entend peut être qqch de différent par "documentation".

[petitours]

J'ai relu hier soir sur le typage pour me clarifier les idées et essayer de sortir de mes démons subjectifs éventuels et je n'ai trouvé que des choses qui confirment ce que j'en avais compris.
On nous explique que dans ce cas (typage dynamique), le typage est vérifié à l'exécution alors qu'il est vérifié à la compilation avec un typage statique.

Le typage dynamique permet de coder plus facilement (on ne se préoccupe pas du typage) mais
1) on est plus lent, parce que les informations de typage sont gérées tout au long de l’exécution
2) on DOIT tester tous les cas et branches possibles de l'application pour détecter une erreur de typage. Et ça par expérience (de débutant) du VB6 ça peut nous péter à la figure très longtemps après avoir codé le bug. Alors OK un bon programmeur va de toute manière tester toutes ses branches () mais avoir le risque de laisser passer un truc aussi basique qu'une erreur de typage c'est super dommage et que l'on ne parle pas de simplicité !

Le typage statique ne permet pas de coder en se déchargeant les neuronnes du choix des types mais
1) Il ne laissera rien passer à la compilation (même en typage faible comme le C)
2) ça explique en partie sa performance si je comprends ce qui est dit...

Bref en ce qui me concerne je trouve qu'une erreur de typage est un truc archi basique qui devrait être rendu impossible au moment de la programmation. Le typage dynamique ne le permet pas et j'aime pas .
Mais si python a(ou va avoir) des équivalents (en mieux) au explicit de VB6 alors c'est top on ne parle plus de ce problème .

Après ceci s'ajoute à l'inconfort de la syntaxe pour moi mais je suis débutant python et je vais surement m'y habituer ; même si je pratique régulièrement VB(A) je code surtout en C et c# actuellement, notamment avec de belles accolades bien claires !

C'est vrai pour les langages "commerciaux" qui doivent s'imposer par le volume. C'est ce que j'apprécie avec Python, quand je vois qu'un dev "standard" s'inquiète de la conséquence d'une erreur d'indentation, ne reste dans la communauté que les devs compétents, les autres continuent Java…

Là je me sens visé
Mais un dev compétent n'est ps obligé d'être mazo et d'aimer le risque d'erreur, le manque de clareté ou autres absence d'aide ergonomique... j'ai du mal à comprendre l'argumentaire là. Ce qui est sensé être lisible ou bien foutu n'a pas de raison de l'être différemment pour un bon ou un mauvais.

Dans le cas de python je pense qu'une grande partie de son succès est lié à sa simplicité d'apprentissage qui fait que les gens commencent avec.... et continuent puisque on est jamais aussi confortable et performant qu'avec e que l'on connait déjà (c'est vrai dans tous les domaines ça). La syntaxe par indentation n'est pas forcément une gène pour débuter... le typage dynamique est un avantage pour débuter.