C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions escomme objets à part entière.
Ce que je voulais signaler c'est qu'il vaut mieux utiliser des conventions explicites en enrichissant la syntaxe lorsque c'est nécessaire plutôt que de faire confiance à des idiomes du langage qui sont sujets aux défaillances humaines.
un programmeur inexpérimenté qui veut implémenter le do while sera tenté de mettre en place un truc du genre:
bloc_code1
while(cond):
... bloc_code1
au lieu de la construction montrée plus while 1:.
Il augmentera les chances d'erreur puisqu'il devra resynchroniser bloc_code1 dans les 2 références alors qu'il peut en fait n'en utiliser qu'une seule avec la construction while 1:
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
Je ne cherche pas à démontrer que Java ou un langage typé statique est plus concis qu'un langage dynamique. Je montre simplement que le gain de productivité pour le prototypage et le dev est perdu en maintenance puisque le code produit par les premiers est de meilleure qualité et que le client s'expose à moins de déconvenues (cf. mon post plus bas) http://linuxfr.org/comments/785080.html#785080
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Python a le typage fort et le GC.
Je voulais dire typage statique.
Pourquoi se passer d'une précaution supplémentaire. Le GC en est une autre et il servait d'exemple.
Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).
Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.
Les 2 l'implémentent avec des libs ou au travers des annotations.
Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès.
...
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)
Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects. Il vaut mieux se palucher une fonction de doc de 15 lignes pour découvrir dedans que les attributs sont protégés plutôt que le langage te l'explicite. Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance. Rajoutes à ca qu'il faut documenter les exceptions que tu peux lever, les types de paramètres attendus si tu fais des traitements particuliers (ex de la somme des éléments d'une liste d'entiers). Tu peux aussi rajouter des assert qui ne sont vérifiés qu'à l'exécution et ne te protègent tjs pas des cas non prévus. Autant faire confiance au typage statique.
Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes ....nformaticiens" à la chaîne dans l'optique de baisser les coûts.
On peut aussi dire que Java permet d'entreprendre des projets de plus grande envergure puisque les sources d'erreurs humaines qui ne sont as toujours dues à l'incompétence que tu insinues sont évitées.
Les développeurs du projet communautaire Apache sont-ils des victimes de ce taylorisme d'entreprises ?
Ca n'a pas forcément à voir avec la compétence des développeurs. Le même développeur devra être encore plus vigilant avec son code Python et perdra tout le temps gagné au prototypage à verrouiller son code. Ce point ne peut-être amélioré pour une langage dynamique alors que le codeur Java peut se reposer sur son IDE pour gagner en productivité.
En plus le monde Java dispose maintenant d'un langage dynamique avec une syntaxe à la Java et basé sur l'API Java Groovy. La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Ce que je voulais signaler c'est qu'il vaut mieux utiliser des conventions explicites en enrichissant la syntaxe lorsque c'est nécessaire plutôt que de faire confiance à des idiomes du langage qui sont sujets aux défaillances humaines.
un programmeur inexpérimenté qui veut implémenter le do while sera tenté de mettre en place un truc du genre:
bloc_code1
while(cond):
... bloc_code1
au lieu de la construction montrée plus while 1:.
Il augmentera les chances d'erreur puisqu'il devra resynchroniser bloc_code1 dans les 2 références alors qu'il peut en fait n'en utiliser qu'une seule avec la construction while 1:
Je ne cherche pas à démontrer que Java ou un langage typé statique est plus concis qu'un langage dynamique. Je montre simplement que le gain de productivité pour le prototypage et le dev est perdu en maintenance puisque le code produit par les premiers est de meilleure qualité et que le client s'expose à moins de déconvenues (cf. mon post plus bas) http://linuxfr.org/comments/785080.html#785080
Je voulais dire typage statique.
Pourquoi se passer d'une précaution supplémentaire. Le GC en est une autre et il servait d'exemple.
Les 2 l'implémentent avec des libs ou au travers des annotations.
Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects. Il vaut mieux se palucher une fonction de doc de 15 lignes pour découvrir dedans que les attributs sont protégés plutôt que le langage te l'explicite. Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance. Rajoutes à ca qu'il faut documenter les exceptions que tu peux lever, les types de paramètres attendus si tu fais des traitements particuliers (ex de la somme des éléments d'une liste d'entiers). Tu peux aussi rajouter des assert qui ne sont vérifiés qu'à l'exécution et ne te protègent tjs pas des cas non prévus. Autant faire confiance au typage statique.
On peut aussi dire que Java permet d'entreprendre des projets de plus grande envergure puisque les sources d'erreurs humaines qui ne sont as toujours dues à l'incompétence que tu insinues sont évitées.
Les développeurs du projet communautaire Apache sont-ils des victimes de ce taylorisme d'entreprises ?
Ca n'a pas forcément à voir avec la compétence des développeurs. Le même développeur devra être encore plus vigilant avec son code Python et perdra tout le temps gagné au prototypage à verrouiller son code. Ce point ne peut-être amélioré pour une langage dynamique alors que le codeur Java peut se reposer sur son IDE pour gagner en productivité.
En plus le monde Java dispose maintenant d'un langage dynamique avec une syntaxe à la Java et basé sur l'API Java Groovy. La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.