Et s'ils dépêchaient quelqu'un pour venir faire le test chez toi et à leur frais ?
Quelqu'un m'a dit que maintenant c'etait le cas chez free. Ils ne te facturent le déplacement que si le pb est chez eux.
Maintenant je vois mal comment Mme Dujneu pourra vérifier l'origine du pb et faire valoir ses droits.
Bref il ya du progrès, maintenant les techniciens Free se deplacent ... à tes frais.
Oui parce que si c'est la faute à personne, ton compte il est bien débité automatiquement pour un service non rendu et là bizarrement y'a pas souvent des pbs.
Un jour je me suis fait prélévé automatiquement le télephone de quelqu'un d'autre par ce qu'il s'étaient planté d'un chiffre sur leur no d'abonnement. J'ai bataillé 2 heures au télephone à expliquer aux secrétaire de la compta comment retrouver le bon débiteur dans leur base de données afin de prouver ma bonne foi (même montant avec un chiffre différent).
Je vous epargne mes mésaventures avec Free parce que je compte en faire un roman qui sera édité chez O'Railleries.
Plus malin tu appelle depuis un autre tele le service pour t'abonner. vu que c'est les même gugusse qui répondent à la hotline (ils sont 2 pour se coltiner le boulot chez free, faudrait pas remettre en cause leur bô business modèle avec de la QoS) il te répond ou te passe directement son poteu.
Tu es blogueur ?
Tu gagnes le droit de payer pour assister à une conférence sur le Web 3 et accessoirement de te te faire lobotomiser par les participants à la campagne des partis politiques en vue des présidentielles.
Oui t'as raison sur ce coup là. J'aurais pas du parler d'Object juste de int.
Reste que l'argument initial est quand même valable.
Le fait que le dev python sera quand même tenté d'utiliser des listes d'objets de types différent sans s'apercevoir qu'une liste d'entier est attendue parce que la fonction intermédiaire le masque.
Le dev Java sera prévenu et s'il ne bidouille pas sa liste(caste vers Object puis downcast), y'a pas de pbs.
Pour le fait que tu es limité à des int (cf. ton post sur les ontologies) tu as quand même les types paramétrés.
Mais c'est vrai que si tu veux utiliser des listes d'objets hétérogènes tu t'exposes aux mêmes risques qu'avec les langages dynamiques , la verbosité en plus.
La sécurité est à ce prix. Ca coûte toujours moins cher que 2 jours d'indisponibilité chez le client. Chacun ses priorités.Perdre un client ou se faire plaisir.
Ah oui et quand on intègre des composants extérieurs (c'est quand même la base de ton argumentation sur le typage statique), on a vachement la maîtrise des classes et interfaces.
S'il s'agit de composants développé à l'extérieur on doit adapter mais au moins on maîtrise ce qu'on fait.
Et l'adaptateur ne fait pas partie des design pattern du Gof pour rien.
Par contre si il s'agit de composant développé en interne mais appelé depuis un autre module, il faut juste une bonne conception.
ceci dit, tu as réussi à placer "approche descendante", chapeau :-)).
Relis mon exemple,c'est bien appelé depuis l'extérieur mais refusera de compiler avec un tableau d'Object en paramètres. Il devra donc le transformer en tableau de int et aura donc anticipé le pb.
Avec du python tu construis ta liste sans faire au fait qu'elle peut contenir des chaînes. Quand ca pète en prod tu cherches dans l'urgence et merde j'ai oublié de transformer les objets de ma liste en en entiers avant l'appel.
Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.
sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable) ou que tu utilises des type paramétrés (templates).En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces).
C'est vrai que C++ permet la surcharge des opérateurs à la différence de Java. Ca a ses avantages mais c'est complexe à mettre en oeuvre.
En pratique on ne récrit jamais de code Python en C, sauf parfois quelques bouts très critiques.
En pratique on modélise son application et on génère le squelette décode à partir de ça et on le complète.
Je citais ca à titre d'exemple pour montre que l'approche était possible avec Java. Groovy étant plus proche de Java que jython ou jRuby.
Bon j'me marrais bien avec vous mais là j'vais m'pieuter
Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.
Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre. Dons c'est à la compil que tu détecte le pb.
Ben non, tu ne dois pas te coltiner l'arbre de dépendances, puisque l'effet souhaité pour la plupart des exceptions est d'arrêter totalement le
...
C'est tout le contraire.
Le but du jeu c'est justement que chaque bloc appelant intercepte l'exception à son niveau pour libérer des ressources qu'il a ouvert( fichier ouvert, connection à une db,..) et relance aux niveau supérieur.
En plus si tu ne l'intercepte pas à un moment donne tu sors du programme. Donc il faut bien faire le tri entre les exceptions qui te permettre de retrouver un état stable et celles qui sont irrécupérables.
Je ne savais pas que python était une norme.Mes compliments
Ce qui ne l'empêche pas WSGI d'être de plus en plus implémenté :
Si j'ai bien compris, il y a autant d'implémentations que de framework..
javax.serlvet dispose d'une implémentation standard.
Vivement que wsgi fasse parie intégrante de la standard library :)
Bon c'est pas mal, il reste encore un peu de travail pour obtenir une spec aussi complète que JEE (EJB, RMI, ....)
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.
Evidemment, tu me sors unr erreur qui ne peut être détectée qu'à l'exécution.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.
Maintenant observe le code suivant:
l=range(35)
>>> def sum(l):
... j=0
... for i in l:
... j=j+i
... return j
...
>>> a=sum(l)
>>> sum(range(35))
595
Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4, in sum
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.
Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.
Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.
Les SSII poussent à l'infogérance et à l'outsourcing pour récupérer des marchés et les DSI les mettent en concurrence pour baisser les coûts.
Mais bon c'est quand même bien le Syntec qui faisait du lobbying pour le contrat de projet afin d'avoir des esclaves jetables à volonté qui se retrouvent à la charge du contribuable en inter-projet.
On ne parlera pas des SSII qui font leur business avec l'offshore et autre nearshore.
Faut dire que la directive Bolkenstein qui est maintenant passée n'a pas tenu toutes ses promesses sur le principe d'origine donc ca les embêtent un peu de payer leurs untermenschen au tarif local.
Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.
Si mais tu ne le découvres pas à l'execution en prod
Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.
Tout a fait la logique se décrit avec 2 propositions. (non p et p=>q si mes souvenirs sont exacts)
On a juste créé 3 autres fonctions loqiques (et, ou et ou exclusif) pour faire affreux et pas pour du tout pour simplifier l'ecriture des propositions.
en python on a pas besoin du do while
while 1:
...
if(cond):
break
est beaucoup plus "joli"
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
pas élegant peut-être pas mais cohérent sûrement.
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.
Le problème a résoudre est que je cherche le mot clé protected et non private.
La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Tu devrais peut-être te remettre au C
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Ca c'est de l'argumentaire.
Je ne relèverai même pas sur l'incompétence.
J'avais acheté un beau kiss avec une carte ethernet, il y a 5 ans de ça.
On m'avait dit à l'époque que c'était une super marque parce qu'il sortaient des firmwares régulièrement et qu'ils étaient européens, la qualité toussa.
Ca fait 5 ans que j'attend les mises à jour pour pouvoir lire mes Xvid. Il y a bien des nouveaux firmware une fois par an mais c'est juste des maj du GUI sous Windows ou de l'interface de connexions aux Webradios.
Je ne te parle pas des DVDs qui freezent.
Du coup je l'ai refilé à mes mômes et j'ai racheté un bon lecteur DVD au supermarché du coin qui me lit tout au ptit poil.
[^] # Re: Position courageuse
Posté par golum . En réponse au journal Affligeant [Mort d'un enfant]. Évalué à 3.
[^] # Re: La récente GPLisation de Java
Posté par golum . En réponse au journal Looking Glass 3D en version 1.0 !. Évalué à 6.
http://linuxfr.org/comments/783982.html#783982
http://linuxfr.org/comments/774039.html#774039
http://linuxfr.org/comments/786960.html
...
Bizarremment, leur sens de l'humour s'emousse lorsqu'on leur renvoie la pareille
http://linuxfr.org/comments/784398.html
[^] # Re: echange de freebox ?
Posté par golum . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 2.
Quelqu'un m'a dit que maintenant c'etait le cas chez free. Ils ne te facturent le déplacement que si le pb est chez eux.
Maintenant je vois mal comment Mme Dujneu pourra vérifier l'origine du pb et faire valoir ses droits.
Bref il ya du progrès, maintenant les techniciens Free se deplacent ... à tes frais.
[^] # Re: Tappez pas !
Posté par golum . En réponse au journal Pourquoi je n'aime pas Ubuntu.. Évalué à 3.
[^] # Re: Tappez pas !
Posté par golum . En réponse au journal Pourquoi je n'aime pas Ubuntu.. Évalué à 2.
Dayssu je suis :D
[^] # Re: Faut pas etre plus royaliste que le Roi
Posté par golum . En réponse au journal Pourquoi je n'aime pas Ubuntu.. Évalué à 2.
Ben oui ca s'appelle la BSD :o)
[^] # Re: pas tout compris
Posté par golum . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 9.
[^] # Re: Bon, je l'ai pas vu cité
Posté par golum . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 8.
Un jour je me suis fait prélévé automatiquement le télephone de quelqu'un d'autre par ce qu'il s'étaient planté d'un chiffre sur leur no d'abonnement. J'ai bataillé 2 heures au télephone à expliquer aux secrétaire de la compta comment retrouver le bon débiteur dans leur base de données afin de prouver ma bonne foi (même montant avec un chiffre différent).
Je vous epargne mes mésaventures avec Free parce que je compte en faire un roman qui sera édité chez O'Railleries.
Bref pas un pour racheter l'autre.
[^] # Re: pas tout compris
Posté par golum . En réponse au journal Free n'est pas prêt pour assumer le téléphone. Évalué à 5.
PS: c'est du vécu.
[^] # Re: ...
Posté par golum . En réponse au journal Pourquoi je n'aime pas Ubuntu.. Évalué à 7.
[^] # Re: Et ?
Posté par golum . En réponse au journal Vous êtes l'Homme de l'année. Évalué à 3.
Tu gagnes le droit de payer pour assister à une conférence sur le Web 3 et accessoirement de te te faire lobotomiser par les participants à la campagne des partis politiques en vue des présidentielles.
http://www.betapolitique.fr/spip.php?article0041
http://nicolas.barcet.com/drupal/node/99
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Reste que l'argument initial est quand même valable.
Le fait que le dev python sera quand même tenté d'utiliser des listes d'objets de types différent sans s'apercevoir qu'une liste d'entier est attendue parce que la fonction intermédiaire le masque.
Le dev Java sera prévenu et s'il ne bidouille pas sa liste(caste vers Object puis downcast), y'a pas de pbs.
Pour le fait que tu es limité à des int (cf. ton post sur les ontologies) tu as quand même les types paramétrés.
Mais c'est vrai que si tu veux utiliser des listes d'objets hétérogènes tu t'exposes aux mêmes risques qu'avec les langages dynamiques , la verbosité en plus.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
S'il s'agit de composants développé à l'extérieur on doit adapter mais au moins on maîtrise ce qu'on fait.
Et l'adaptateur ne fait pas partie des design pattern du Gof pour rien.
Par contre si il s'agit de composant développé en interne mais appelé depuis un autre module, il faut juste une bonne conception.
Toi aussi ... le business loto :D
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Avec du python tu construis ta liste sans faire au fait qu'elle peut contenir des chaînes. Quand ca pète en prod tu cherches dans l'urgence et merde j'ai oublié de transformer les objets de ma liste en en entiers avant l'appel.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable) ou que tu utilises des type paramétrés (templates).En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces).
C'est vrai que C++ permet la surcharge des opérateurs à la différence de Java. Ca a ses avantages mais c'est complexe à mettre en oeuvre.
En pratique on modélise son application et on génère le squelette décode à partir de ça et on le complète.
Je citais ca à titre d'exemple pour montre que l'approche était possible avec Java. Groovy étant plus proche de Java que jython ou jRuby.
Bon j'me marrais bien avec vous mais là j'vais m'pieuter
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre. Dons c'est à la compil que tu détecte le pb.
C'est tout le contraire.
Le but du jeu c'est justement que chaque bloc appelant intercepte l'exception à son niveau pour libérer des ressources qu'il a ouvert( fichier ouvert, connection à une db,..) et relance aux niveau supérieur.
En plus si tu ne l'intercepte pas à un moment donne tu sors du programme. Donc il faut bien faire le tri entre les exceptions qui te permettre de retrouver un état stable et celles qui sont irrécupérables.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Je ne savais pas que python était une norme.Mes compliments
Si j'ai bien compris, il y a autant d'implémentations que de framework..
javax.serlvet dispose d'une implémentation standard.
Vivement que wsgi fasse parie intégrante de la standard library :)
Bon c'est pas mal, il reste encore un peu de travail pour obtenir une spec aussi complète que JEE (EJB, RMI, ....)
[^] # 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.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
La fac, ca remonte à quelques années pour moi.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.
Maintenant observe le code suivant:
Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod
Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.
Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.
Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.
[^] # Re: Mouais
Posté par golum . En réponse au journal Un quart des développeurs ne testent jamais leurs programmes.. Évalué à 3.
Les SSII poussent à l'infogérance et à l'outsourcing pour récupérer des marchés et les DSI les mettent en concurrence pour baisser les coûts.
Mais bon c'est quand même bien le Syntec qui faisait du lobbying pour le contrat de projet afin d'avoir des esclaves jetables à volonté qui se retrouvent à la charge du contribuable en inter-projet.
On ne parlera pas des SSII qui font leur business avec l'offshore et autre nearshore.
Faut dire que la directive Bolkenstein qui est maintenant passée n'a pas tenu toutes ses promesses sur le principe d'origine donc ca les embêtent un peu de payer leurs untermenschen au tarif local.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
http://www.python.org/dev/peps/pep-0333/
"Status = Draft"
:D
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Si mais tu ne le découvres pas à l'execution en prod
Tout a fait la logique se décrit avec 2 propositions. (non p et p=>q si mes souvenirs sont exacts)
On a juste créé 3 autres fonctions loqiques (et, ou et ou exclusif) pour faire affreux et pas pour du tout pour simplifier l'ecriture des propositions.
en python on a pas besoin du do while
while 1:
...
if(cond):
break
est beaucoup plus "joli"
pas élegant peut-être pas mais cohérent sûrement.
http://docs.python.org/tut/node11.html#SECTION00115100000000(...)
"This is depth-first, left-to-right"
Faudra qu'ils remettent à jour leur doc alors
Le problème a résoudre est que je cherche le mot clé protected et non private.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Tu devrais peut-être te remettre au C
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Ca c'est de l'argumentaire.
Je ne relèverai même pas sur l'incompétence.
[^] # Re: Excellente nouvelle
Posté par golum . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Python founit un module de refactoring pas trop mal fait qui peut être intégré dans pas mal d'IDE
http://bicyclerepair.sourceforge.net/
D'ailleur un IDE assez sympatoche le propose (pyQT)
http://www.die-offenbachs.de/detlev/eric.html
[^] # Re: Kiss
Posté par golum . En réponse au journal Chaine hifi avec disque dur. Évalué à 4.
J'avais acheté un beau kiss avec une carte ethernet, il y a 5 ans de ça.
On m'avait dit à l'époque que c'était une super marque parce qu'il sortaient des firmwares régulièrement et qu'ils étaient européens, la qualité toussa.
Ca fait 5 ans que j'attend les mises à jour pour pouvoir lire mes Xvid. Il y a bien des nouveaux firmware une fois par an mais c'est juste des maj du GUI sous Windows ou de l'interface de connexions aux Webradios.
Je ne te parle pas des DVDs qui freezent.
Du coup je l'ai refilé à mes mômes et j'ai racheté un bon lecteur DVD au supermarché du coin qui me lit tout au ptit poil.