Cortado comme alternative à Flash ? Flash fait quand même un peu plus que simple lecteur vidéo embarqué...
Flash est à ma connaissance le seul outil de programmation qui permet de faire simplement de la capture audio et vidéo (webcam / microphone), du streaming et de la restitution multi-plateformes. Il suffit littéralement de quelques lignes de code. De plus le binaire est petit (un à deux mégas pour la machine virtuelle plus les bibliothèques toutes entières) et se lance rapidement.
Il est possible de faire du logiciel libre avec et autour de Flash (il y a même une communauté dédiée : http://osflash.org/ ), bien que Flash soit propriétaire. Mais le gros problème avec Flash est la fermeture de certains formats, protocoles et codecs. Adobe a intérêt à ouvrir ses specs, la concurrence étant grandissante.
Donc la ou cortado peut faire son chemin c'est en proposant du contenu de qualité. Merci le format Théora :)
Flash décode VP6 et H263 en standard. S'il y a des problèmes de qualité ce n'est pas lié au lecteur Flash, mais aux options choisies pour la compression vidéo. La bande passante, ce n'est pas donné, donc on compresse au maximum.
Bref c'est un document qui fait plaisir à lire (enfin parcourir pour l'instant) car il insiste beaucoup sur l'ouverture et la pérénité des formats.
C'est surtout byzantin. On force l'utilisateur à utiliser des formats différentes selon qu'il s'agit de "présenter" ou d'"'échanger", on impose même le TIFF pour les "images sans perte" alors que le PNG est recommandé à d'autres endroits (et le PNG n'est pas sans perte peut-être).
Je plains les gens qui devront appliquer ces recommandations débiles. Ce n'est pas demain que les employés du service public aimeront en choeur l'informatique.
Est-ce qu'on va se taper dans Linuxfr chaque annonce de nouveauté de chaque logiciel mineur soutenu par une entreprise ? Les gens qui utilisent LibreSource savent où trouver l'info sur les nouvelles versions, les autres n'ont rien à battre que "LibreSource Community 2.1 intègre Subversion".
Je crois que tu as un problème manifeste pour comprendre que les statistiques sont un outil de décision politique.
On ne fait pas des statistiques au hasard, pour s'amuser.
Dana Hilliot, quand il évoque la filiation entre le logiciel libre et la culture libre (filiation évidente mais non exclusive, faut pas déconner non plus), parle de la nécessité de « tuer le père ».
Hein ??
Pour qu'il y ait filiation, il faut qu'il y ait paternité. Or jamais personne dans le logiciel libre n'a dit "voilà, il faut étendre le principe du LL à la musique, alors on va inventer des licences non-commerciales". Le LL n'a pas enfanté ces licences (je poursuis l'analogie dans ses derniers retranchements, hein), et si les tenants du NC/ND veulent se réclamer du logiciel libre, il va falloir qu'ils soient un peu plus convaincants.
Mais c'est sûr que ce serait dommage de ne plus pouvoir orner son discours de références mythologiques ou psychanalytiques à deux balles.
Ils ont donc préféré garder la version Java qui offre au final on a une classe intégrée, relativement performante et surtout indépendante de l'architecture.
C'est marrant, Python a aussi une classe intégrée, indépendante de l'architecture et en plus elle est trois plus rapide que Java. http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
(et évidemment, c'est beaucoup plus concis et lisible en Python)
Il avait travaillé avec Mélanie Clément-Fontaine sur la traduction ou l'adaptation de la GPL au droit français. Il aura fallu attendre Cecill pour que ce soit concrétisé.
Il est totalement malhonnête de prétendre que la licence CeCILL est la concrétisation de ce boulot, ni Mélanie Clément-Fontaine, ni Eben Moglen, ni la FSF n'y ayant participé.
D'ailleurs la CeCILL ne ressemble nullement à ce que pourrait être une traduction, plus ou moins littérale, de la GPL.
Ce test est sensé comparer les perf de 2 langages.
Un langage n'a pas d'intérêt sans bibliothèques. Quand on utilise un langage, on n'a rien à branler que les bibliothèques sous-jacentes soient optimisées en C, assembleur ou Javascript.
Donc je répète : si les bibliothèques disponibles pour Java ne sont pas au niveau de celles disponibles pour C, tant pis pour Java.
le terme copyleft en remplacement de copyright ne semble pourtant pas poser de problème pour comprendre ? :-)
"copyleft" peut être compris par "le droit de copie est laissé à l'utilisateur" (left comme participe passé et non comme nom commun). "gauche" en français ne laisse pas cette possibilité, voilà pourquoi c'est une traduction assez... gauche ;)
Toute la question, c'est donc de savoir si en adoptant les stratégies 2 et 3,
Non, la question est simplement de savoir quelle stratégie est légale.
Si la stratégie 1 est illégale, et que les tribunaux font respecter la loi, alors les constructeurs vont devoir se standardiser sur les stratégies restantes (celles qui permettent d'acheter un ordi sans OS).
La loi, quand elle est appliquée, prime sur tout argument commercial
Il devra donc le transformer en tableau de int et aura donc anticipé le pb.
"Anticipé" comment ça ? Si tu ne sais pas avant l'exécution qu'il y aura une chaîne de caractères parmi ces Object, l'erreur ne sera levée qu'à l'exécution.
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.
Heu, il n'y a toujours pas de différence avec un cast dynamique qui foirerait à l'exécution... Juste que dans un cas, il y a un test de type, alors que dans l'autre il y a un test structurel (présence d'une méthode).
sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable)
Oui, donc pour chaque méthode "toto" susceptible d'être appelée dans une fonction somme_toto(), tu vas définir une interface ITotoable que chaque classe ayant la méthode "toto" devra implémenter pour être utilisable dans somme_toto().
Hélas, un jour tu tombes sur une classe écrite par une autre personne, qui a bien implémenté une méthode toto(), mais sans référence à l'interface ITotoable. En effet, si "toto" est une notion connue bien d'informatique, ITotoable est de ton invention (et la communauté Java en étant à la standardisation de IFooBarable, il y a encore 5342 interfaces triviales à standardiser avant d'arriver à ITotoable... damned).
Alors là tu es bien marri pour utiliser sa classe dans ta fonction somme_toto() : tu dois écrire un adapteur pour renvoyer, à partir d'une instance de sa classe, une instance implémentant l'interface ITotoable et qui ne fera que wrapper l'instance originale.
Ce qui fait beaucoup de code, comment dire, un peu inutile. Tout ça parce que le typage dynamique, c'est mal (tm).
En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces)
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.
(ceci dit, tu as réussi à placer "approche descendante", chapeau :-)).
Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre.
Heu, en général quand on fait ce genre d'erreur c'est que la chaîne provient de l'extérieur, pas qu'on a ajouté des guillemets par erreur dans le source. Du coup le compilateur ne voit qu'un Object et il ne peut que déférer la résolution du cast à l'exécution.
Je ne savais pas que python était une norme.Mes compliments
Ma remarque renvoyait à "Status: Draft", pas à l'hypothèse d'un Python normalisé par l'IETF. :-)
Si j'ai bien compris, il y a autant d'implémentations que de framework..
WSGI est une API de communication entre serveurs Web et frameworks/applications. Je ne vois pas pourquoi il devrait y avoir une implémentation unique, l'intérêt de standardiser une API étant précisément de permettre la diversité des implémentations.
Ceci dit il y a bel et bien une "implémentation de référence" dans la lib standard. http://docs.python.org/lib/module-wsgiref.html
("wsgiref is a reference implementation of the WSGI specification that can be used to add WSGI support to a web server or framework." : c'est donc surtout un jeu de fonctions pour se faciliter la tâche)
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.
Heu... la convention de documentation par excellence, c'est le langage naturel (l'anglais de préférence). Si la lib que tu utilises est documentée en islandais ou pas documentée du tout, le mot-clé "protected" ne va pas t'apporter grand'chose.
Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance.
L'humain est inconstant mais il est capable de faire passer des idées qu'un langage formel ne permet en général pas (ou alors au prix d'une lourdeur énorme : tu peux toujours créer des "ontologies" et coder ta doc en RDF (et qui débugge la doc ? :-)).
Bref, il est délicat de savoir où situer la frontière entre les deux. La distinction typage statique / typage dynamique relève aussi en partie de cette frontière (en partie seulement, cf. ci-dessous).
Autant faire confiance au typage statique.
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.
Apparemment certains langages (Haskell ?) ont un typage structurel, c'est-à-dire une sorte de duck typing à la compilation, où la vérification des arguments consiste à tester qu'ils supportent les bonnes opérations (et non pas qu'ils sont instances d'un type donné). Qu'on me corrige si je me trompe, mais ça me semble une version plus intéressante du typage statique.
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.
En pratique on ne réécrit jamais de code Python en C, sauf parfois quelques bouts très critiques.
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).
Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.
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.
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 programme (ou la branche concernée), pas d'effectuer un traitement de réparation spécifique. Il y a peu d'erreurs qui soient rattrapables correctement.
C'est justement l'intérêt des exceptions par rapport à l'utilisation de valeurs de retour que de pouvoir se propager automatiquement jusqu'au toplevel, au lieu de devoir les propager à la main.
C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions comme objets à part entière.
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
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.
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.
Le problème a résoudre est que je cherche le mot clé protected et non private.
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. Un langage de programmation n'est pas un OS (quoiqu'au début, on nous prédisait littéralement que Java deviendrait l'OS ; j'imagine que dans cette optique il fallait garantir programmatiquement la protection des accès à chaque composant...).
En d'autres termes :
- soit ta méthode est privée et tu la préfixes par un underscore, la signification étant évidente
- 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 ?)
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
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 impératifs pour le forcer à faire les choses correctement. C'est pour ça que c'est un langage très rigide et très verbeux.
Il ne faut pas croire aux fables de l'informatique d'entreprise : si Java s'est imposé en entreprise, ce n'est pas simplement parce qu'il y a un GC et un typage fort...
Java fait croire qu'il permet de tayloriser le travail de programmation, et donc de former des "informaticiens" à la chaîne dans l'optique de baisser les coûts. Evidemment en pratique un programmeur compétent est toujours nécessaire pour faire du bon code ; et un programmeur compétent est en général au moins aussi productif en Python (ou Ruby, etc.) qu'en Java. Hum.
La complétion et l'aide au code est à mon avis fondamental...
Ce sont des choses gérées par l'interpréteur Python.
Après c'est une question de méthodes de travail : en Java on aime avoir un énorme IDE tout-en-un, en Python l'interpréteur interactif fournit la possibilité d'explorer les modules (y compris la documentation) et de tester des bouts de code à la volée.
Mais dire que Python ne fournit pas de possibilités d'introspection, de parcours de modules, c'est au mieux de l'ignorance.
(et il y a certainement des IDE qui intègrent la ligne de commande Python)
Du coup certains ont implémenté les interfaces dans des libs non standard.
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.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
Au fait, je ne sais pas ce qui a pu te faire arriver à la conclusion que l'héritage multiple de Python se fait en profondeur d'abord :
>>> class A(object): pass
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(B, C): pass
...
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
Ceci dit quand on se retrouve avec un graphe d'héritage suffisamment compliqué pour que les relations de précédence ne soient pas triviales, c'est un signe de mauvaise conception. Surtout si on donne le même nom à des méthodes à différents endroits du graphe, avec des sémantiques différentes.
Tu n'as pas d'attributs ou de méthodes protégées.
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.
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.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
C'est effectivement élégant parce que cela implique qu'une méthode est l'équivalent d'une fonction.
Le langage est ainsi plus orthogonal, et il n'y a pas de variable au statut particulier ou magique (comme "this").
(oui, en Java il n'y a pas de fonctions proprement dites, du coup pour compenser il y a des "méthodes" statiques, qui ne sont des méthodes que sur le plan syntaxique et non sémantique, comme c'est rigolo)
Si des langages comme Java n'imposent pas de devoir taper "self", ils imposent de taper systématiquement "private", "public" et toute une inflation délirante de mots-clés, enfin bref...
Je suis a peu prêt sûr (vu comment Google respecte les dits standards) que ce code ne génère pas quelques chose de standard. Et là ça ne choque personne.
Sur Linuxfr il y a des standards de pensée à respecter. (*)
Quand on parle de Microsoft, insinuer que c'est le diable, farci d'arrière-pensées ignominieuses, et que ça plante tout le temps (même si on n'a jamais testé le logiciel en question pour vérifier qu'effectivement, ça plante).
Quand on parle de Google, ce sont les bienfaiteurs du Web, inventeurs de tas d'applis sympas, ils sont donc au-dessus des remarques mesquines qu'on n'hésite pas à infliger à d'autres.
Quant au W3C, c'est Dieu lui-même, toucher à un cheveu d'un standard adoubé par le W3C est forcément une preuve d'obscurantisme indécrottable et probablement mal intentionné (même si XHTML est critiqué par nombre de défenseurs du W3C, hein).
(*) pas que sur Linuxfr d'ailleurs, on retrouve les mêmes comportements sur beaucoup de blogs vénérés ici, comme Standblog & co.
# "Alternative du Flash Player"
Posté par Antoine . En réponse à la dépêche Itheora, un habillage pour Cortado. Évalué à 3.
Flash est à ma connaissance le seul outil de programmation qui permet de faire simplement de la capture audio et vidéo (webcam / microphone), du streaming et de la restitution multi-plateformes. Il suffit littéralement de quelques lignes de code. De plus le binaire est petit (un à deux mégas pour la machine virtuelle plus les bibliothèques toutes entières) et se lance rapidement.
Il est possible de faire du logiciel libre avec et autour de Flash (il y a même une communauté dédiée : http://osflash.org/ ), bien que Flash soit propriétaire. Mais le gros problème avec Flash est la fermeture de certains formats, protocoles et codecs. Adobe a intérêt à ouvrir ses specs, la concurrence étant grandissante.
[^] # Re: problème...
Posté par Antoine . En réponse à la dépêche Itheora, un habillage pour Cortado. Évalué à 4.
Flash décode VP6 et H263 en standard. S'il y a des problèmes de qualité ce n'est pas lié au lecteur Flash, mais aux options choisies pour la compression vidéo. La bande passante, ce n'est pas donné, donc on compresse au maximum.
[^] # Re: Très interressant !
Posté par Antoine . En réponse à la dépêche Retard inquiétant du RGI. Qui est-ce qui le bloque ?. Évalué à 0.
C'est surtout byzantin. On force l'utilisateur à utiliser des formats différentes selon qu'il s'agit de "présenter" ou d'"'échanger", on impose même le TIFF pour les "images sans perte" alors que le PNG est recommandé à d'autres endroits (et le PNG n'est pas sans perte peut-être).
Je plains les gens qui devront appliquer ces recommandations débiles. Ce n'est pas demain que les employés du service public aimeront en choeur l'informatique.
# pollution
Posté par Antoine . En réponse à la dépêche LibreSource Community 2.1 intègre Subversion.. Évalué à -1.
[^] # Re: discrimination positive
Posté par Antoine . En réponse au journal La Cnil dérive.... Évalué à 4.
On ne fait pas des statistiques au hasard, pour s'amuser.
[^] # Re: "Musique libre"
Posté par Antoine . En réponse à la dépêche Qu'est ce que la musique libre a de commun avec le logiciel libre ?. Évalué à 1.
Hein ??
Pour qu'il y ait filiation, il faut qu'il y ait paternité. Or jamais personne dans le logiciel libre n'a dit "voilà, il faut étendre le principe du LL à la musique, alors on va inventer des licences non-commerciales". Le LL n'a pas enfanté ces licences (je poursuis l'analogie dans ses derniers retranchements, hein), et si les tenants du NC/ND veulent se réclamer du logiciel libre, il va falloir qu'ils soient un peu plus convaincants.
Mais c'est sûr que ce serait dommage de ne plus pouvoir orner son discours de références mythologiques ou psychanalytiques à deux balles.
[^] # Re: mon avis
Posté par Antoine . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 3.
C'est marrant, Python a aussi une classe intégrée, indépendante de l'architecture et en plus elle est trois plus rapide que Java.
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
(et évidemment, c'est beaucoup plus concis et lisible en Python)
Bon, mais merci pour la discussion.
[^] # FUD pro-CeCILL
Posté par Antoine . En réponse à la dépêche Keynote d'Eben Moglen à « Solutions Linux 2007 ». Évalué à 6.
Il est totalement malhonnête de prétendre que la licence CeCILL est la concrétisation de ce boulot, ni Mélanie Clément-Fontaine, ni Eben Moglen, ni la FSF n'y ayant participé.
D'ailleurs la CeCILL ne ressemble nullement à ce que pourrait être une traduction, plus ou moins littérale, de la GPL.
[^] # Re: mon avis
Posté par Antoine . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 4.
Un langage n'a pas d'intérêt sans bibliothèques. Quand on utilise un langage, on n'a rien à branler que les bibliothèques sous-jacentes soient optimisées en C, assembleur ou Javascript.
Donc je répète : si les bibliothèques disponibles pour Java ne sont pas au niveau de celles disponibles pour C, tant pis pour Java.
[^] # Re: mon avis
Posté par Antoine . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Utiliser une bibliothèque, c'est de la triche ?
Java n'a qu'à utiliser GMP au lieu de réinventer la roue...
[^] # Re: En ces temps de campagne...
Posté par Antoine . En réponse à la dépêche Naissance de « Gauche d'Auteurs ». Évalué à 3.
"copyleft" peut être compris par "le droit de copie est laissé à l'utilisateur" (left comme participe passé et non comme nom commun). "gauche" en français ne laisse pas cette possibilité, voilà pourquoi c'est une traduction assez... gauche ;)
[^] # Re: ca sert à rien
Posté par Antoine . En réponse à la dépêche L'UFC Que Choisir contre la vente liée. Évalué à 4.
Ce qui est amusant, c'est cette façon de passer beaucoup de temps à discuter (de façon véhémente) un sujet dont tu te tapes totalement. :)
[^] # Re: Le problème
Posté par Antoine . En réponse à la dépêche L'UFC Que Choisir contre la vente liée. Évalué à 3.
Non, la question est simplement de savoir quelle stratégie est légale.
Si la stratégie 1 est illégale, et que les tribunaux font respecter la loi, alors les constructeurs vont devoir se standardiser sur les stratégies restantes (celles qui permettent d'acheter un ordi sans OS).
La loi, quand elle est appliquée, prime sur tout argument commercial
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
"Anticipé" comment ça ? Si tu ne sais pas avant l'exécution qu'il y aura une chaîne de caractères parmi ces Object, l'erreur ne sera levée qu'à l'exécution.
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.
Heu, il n'y a toujours pas de différence avec un cast dynamique qui foirerait à l'exécution... Juste que dans un cas, il y a un test de type, alors que dans l'autre il y a un test structurel (présence d'une méthode).
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Oui, donc pour chaque méthode "toto" susceptible d'être appelée dans une fonction somme_toto(), tu vas définir une interface ITotoable que chaque classe ayant la méthode "toto" devra implémenter pour être utilisable dans somme_toto().
Hélas, un jour tu tombes sur une classe écrite par une autre personne, qui a bien implémenté une méthode toto(), mais sans référence à l'interface ITotoable. En effet, si "toto" est une notion connue bien d'informatique, ITotoable est de ton invention (et la communauté Java en étant à la standardisation de IFooBarable, il y a encore 5342 interfaces triviales à standardiser avant d'arriver à ITotoable... damned).
Alors là tu es bien marri pour utiliser sa classe dans ta fonction somme_toto() : tu dois écrire un adapteur pour renvoyer, à partir d'une instance de sa classe, une instance implémentant l'interface ITotoable et qui ne fera que wrapper l'instance originale.
Ce qui fait beaucoup de code, comment dire, un peu inutile. Tout ça parce que le typage dynamique, c'est mal (tm).
En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces)
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.
(ceci dit, tu as réussi à placer "approche descendante", chapeau :-)).
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Heu, en général quand on fait ce genre d'erreur c'est que la chaîne provient de l'extérieur, pas qu'on a ajouté des guillemets par erreur dans le source. Du coup le compilateur ne voit qu'un Object et il ne peut que déférer la résolution du cast à l'exécution.
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
Ma remarque renvoyait à "Status: Draft", pas à l'hypothèse d'un Python normalisé par l'IETF. :-)
Si j'ai bien compris, il y a autant d'implémentations que de framework..
WSGI est une API de communication entre serveurs Web et frameworks/applications. Je ne vois pas pourquoi il devrait y avoir une implémentation unique, l'intérêt de standardiser une API étant précisément de permettre la diversité des implémentations.
Ceci dit il y a bel et bien une "implémentation de référence" dans la lib standard.
http://docs.python.org/lib/module-wsgiref.html
("wsgiref is a reference implementation of the WSGI specification that can be used to add WSGI support to a web server or framework." : c'est donc surtout un jeu de fonctions pour se faciliter la tâche)
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Heu... la convention de documentation par excellence, c'est le langage naturel (l'anglais de préférence). Si la lib que tu utilises est documentée en islandais ou pas documentée du tout, le mot-clé "protected" ne va pas t'apporter grand'chose.
Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance.
L'humain est inconstant mais il est capable de faire passer des idées qu'un langage formel ne permet en général pas (ou alors au prix d'une lourdeur énorme : tu peux toujours créer des "ontologies" et coder ta doc en RDF (et qui débugge la doc ? :-)).
Bref, il est délicat de savoir où situer la frontière entre les deux. La distinction typage statique / typage dynamique relève aussi en partie de cette frontière (en partie seulement, cf. ci-dessous).
Autant faire confiance au typage statique.
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.
Apparemment certains langages (Haskell ?) ont un typage structurel, c'est-à-dire une sorte de duck typing à la compilation, où la vérification des arguments consiste à tester qu'ils supportent les bonnes opérations (et non pas qu'ils sont instances d'un type donné). Qu'on me corrige si je me trompe, mais ça me semble une version plus intéressante du typage statique.
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.
En pratique on ne réécrit jamais de code Python en C, sauf parfois quelques bouts très critiques.
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.
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.
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 programme (ou la branche concernée), pas d'effectuer un traitement de réparation spécifique. Il y a peu d'erreurs qui soient rattrapables correctement.
C'est justement l'intérêt des exceptions par rapport à l'utilisation de valeurs de retour que de pouvoir se propager automatiquement jusqu'au toplevel, au lieu de devoir les propager à la main.
[^] # Re: Excellente nouvelle
Posté par Antoine . 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"
Oui, comme beaucoup de RFCs de l'IETF...
Ce qui ne l'empêche pas WSGI d'être de plus en plus implémenté :
- liste de frameworks :
http://wsgi.org/wsgi/Frameworks
- liste de serveurs :
http://wsgi.org/wsgi/Servers
- liste d'applications :
http://wsgi.org/wsgi/Applications
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 3.
C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions comme objets à part entière.
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
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.
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.
Le problème a résoudre est que je cherche le mot clé protected et non private.
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. Un langage de programmation n'est pas un OS (quoiqu'au début, on nous prédisait littéralement que Java deviendrait l'OS ; j'imagine que dans cette optique il fallait garantir programmatiquement la protection des accès à chaque composant...).
En d'autres termes :
- soit ta méthode est privée et tu la préfixes par un underscore, la signification étant évidente
- 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 ?)
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
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 impératifs pour le forcer à faire les choses correctement. C'est pour ça que c'est un langage très rigide et très verbeux.
Il ne faut pas croire aux fables de l'informatique d'entreprise : si Java s'est imposé en entreprise, ce n'est pas simplement parce qu'il y a un GC et un typage fort...
Java fait croire qu'il permet de tayloriser le travail de programmation, et donc de former des "informaticiens" à la chaîne dans l'optique de baisser les coûts. Evidemment en pratique un programmeur compétent est toujours nécessaire pour faire du bon code ; et un programmeur compétent est en général au moins aussi productif en Python (ou Ruby, etc.) qu'en Java. Hum.
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Ce sont des choses gérées par l'interpréteur Python.
Après c'est une question de méthodes de travail : en Java on aime avoir un énorme IDE tout-en-un, en Python l'interpréteur interactif fournit la possibilité d'explorer les modules (y compris la documentation) et de tester des bouts de code à la volée.
Mais dire que Python ne fournit pas de possibilités d'introspection, de parcours de modules, c'est au mieux de l'ignorance.
(et il y a certainement des IDE qui intègrent la ligne de commande Python)
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 1.
Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.
pas de libs standard équivalente aux servlets, aucune spécification commune
Python Web Server Gateway Interface
http://www.python.org/dev/peps/pep-0333/
Du coup certains ont implémenté les interfaces dans des libs non standard.
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.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
Au fait, je ne sais pas ce qui a pu te faire arriver à la conclusion que l'héritage multiple de Python se fait en profondeur d'abord :
>>> class A(object): pass
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(B, C): pass
...
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
Ceci dit quand on se retrouve avec un graphe d'héritage suffisamment compliqué pour que les relations de précédence ne soient pas triviales, c'est un signe de mauvaise conception. Surtout si on donne le même nom à des méthodes à différents endroits du graphe, avec des sémantiques différentes.
Tu n'as pas d'attributs ou de méthodes protégées.
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.
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.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
C'est effectivement élégant parce que cela implique qu'une méthode est l'équivalent d'une fonction.
Le langage est ainsi plus orthogonal, et il n'y a pas de variable au statut particulier ou magique (comme "this").
(oui, en Java il n'y a pas de fonctions proprement dites, du coup pour compenser il y a des "méthodes" statiques, qui ne sont des méthodes que sur le plan syntaxique et non sémantique, comme c'est rigolo)
Si des langages comme Java n'imposent pas de devoir taper "self", ils imposent de taper systématiquement "private", "public" et toute une inflation délirante de mots-clés, enfin bref...
[^] # Re: GWTSAPU...
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 4.
Sur Linuxfr il y a des standards de pensée à respecter. (*)
Quand on parle de Microsoft, insinuer que c'est le diable, farci d'arrière-pensées ignominieuses, et que ça plante tout le temps (même si on n'a jamais testé le logiciel en question pour vérifier qu'effectivement, ça plante).
Quand on parle de Google, ce sont les bienfaiteurs du Web, inventeurs de tas d'applis sympas, ils sont donc au-dessus des remarques mesquines qu'on n'hésite pas à infliger à d'autres.
Quant au W3C, c'est Dieu lui-même, toucher à un cheveu d'un standard adoubé par le W3C est forcément une preuve d'obscurantisme indécrottable et probablement mal intentionné (même si XHTML est critiqué par nombre de défenseurs du W3C, hein).
(*) pas que sur Linuxfr d'ailleurs, on retrouve les mêmes comportements sur beaucoup de blogs vénérés ici, comme Standblog & co.
[^] # Re: Mise à jour
Posté par Antoine . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 5.
Il y en a même qui pensent que pour échapper au C le mieux est de passer à Java :-)