« et la radio qui veut te passer achète ton CD. »
et doit te payer des droits, et comme les radios ont pas que ça à faire elles payent un forfait à la SACEM pour passer les musiques qu'elles veulent (du moment que c'est des musiques gérés par eux).
Mais admetons que tu t'arranges avec une radio ou que tu offres la diffusion gratuite. Le bistrotier qui a une radio et des hauts-parleurs un peu partout dans son bar paye des trucs à la SACEM pour diffuser éventuellement tes musiques (que la SACEM ne gère pas).
De plus, la « juste » contribution financière qui te reviens pour la copie privée de tes CD est prélevé et reversé la SACEM et toi t'en verra pas un centime d'euro.
Du moins c'est ce que j'ai entendu dire et ça me parait pas si invraissembleble que ça que la SACEM noyaute tout le système des droits patrimoniaux des uvres mulicales.
Archimède, le magazine scientifique et technique d'Arte, pas de la 5ème :).
Une très bonne emission du temps où je redardais la TV (je sais même pas elle(Archimède pas la télé) existe encore de nos jours).
Je me souviens avoir vu cet « épisode »-là, moi aussi
C'est génial les brevets logiciels, les situations qu'ils entrainent sont tellement sur-réalistes que ça serait vraiment dommage de pas les avoir chez nous !
Encore une fois j'espère que nos députés sauront choisir la voix du divertissemment malgrès les rapports préchi-préchas est le spamming de gens du métier (qui défendent leur billes, c'est bien connu, au mépris de l'humour). :)
C'est quoi ce Skynet dont j'ai choppé plusieurs allusions de ci, de là ? Parce que sur ce problème là, Google est pas mon ami (à moins qu'il soit dans le coup lui aussi !)
C'est du figaro que je parlais puisque parmis les deux journaux, seul celui-ci me donne parfois envi de vomir. Ok, c'est vrai qu'a la relecture c'est pas clair[*] je m'excuse.
[*] et puis les vas et viens vers les nots de bas de commentaire donne le tournis :)
Le figaro et l'humanité sont pas vraiment objectifs, mais au moins quand via google news je tombe sur des articles de l'un ou de l'autre. J'ai currieusement jamais eu envi de vomir avec un article de l'humanité.[*]
Sinon, l'express est de quel coté ? Il est souvent cité par google news.
[*] je suis tombé une fois sur un article disant en gros que « c'est une honte, José Bové ce vandale piloté par des anarchistes étrangers a eu sa peine de prison ferme réduite alors que dans le même temps des honètes chefs d'entreprise se contentant de détourner des fonds n'ont pas droit aux même égards de la part de la justice. ». J'ai vraiment cru à un troll.
Si tu donnes de la viande à manger à une vache par ce principe
class Nouriture {}
class Viande extends Nouriture {}
class Herbe extends Nouriture {}
class Animal { void mange(Nouriture) }
class Vache extends Animal { void mange(Herbe) }
Animal margueritte = new Vache
Viande farine_animale = new Viande
margueritte.mange(farine_animale)
le verificateur de types laissera passer mais lors de l'exécution tu auras une erreur de type. Si tu faisais la même chose avec des casts tu aurais aussi une erreur de type de toute façon.
PS: c'est pas interdit de plusser les gens qui passent du temps a essayer d'expliquer des choses (même si c'est parfois obscur) :)
>>- pas de réflexivité
>Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités >(si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).
D'une part il ne faut jamais mélanger implémentation et langages. La réflexivité est une torture à compiler en natif, avec une marchine virtuelle cela ne devient que très très difficile et peu efficace. Mais j'ai bien précisé que je ne parlait que du langage et pas de son implémentation.
Le langage Java est le même qui est utilisé par les compilateurs natifs (tel gcc) et la machine virtuelle peut faire tourner du byte-code qui ne provient pas d'un programme en Java (SmartEiffel peut produire du byte code JVM). Le langage Java n'est pas lié à la JVM.
Ensuite, que Java ne fasse pas de réflexivité c'est pas non plus la fin du monde. C'est déjà vachement bien qu'on aie l'introspection je trouve.
Pour conclure, rien n'empeche que le gestionnaire de sécurité soit en read-only et qu'il vérifie les modifications apportés au système.
>>- pas de fonctions lambda :) ;
>Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface >java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object >o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou >anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() >par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.
Arg !
Je savais pas ça. C'est terriblement lourd comme système. Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux. Sans compter que d'une part pour que le typage accepte ça il faut faire des coercition à tout va et d'autre par ce n'est plus la classe d'origine qui est responsable des ses comparaisons mais un autre classe.
Un solution simple pour faire ça serait quelque chose du genre :
creer une méthode par comparaison dans la classe.
class Persone
{
int compare_by_name() {...}
int compare_by_age() {...}
}
le container possédant une méthode de tri qui necessite une méthode de comparaions
class Container
{
void sort_using(Function comparator) {...}
}
D'une part il me semble que c'est faisable avec l'introspection Java et d'autre part Java aurait à y gagner en spécifiant ce genre de trucs correctement (SmartEiffel fait ça de façon originale et plutot pas mal) et pas par des stratagèmes qui pervertissent notre belle jeunesse !
>Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la >rapidité d'écriture et encore).
méthode coué, hein ?
>>- pas de contrats
>Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests >des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux >exemples sous la main de codeurs non propres, je les imaginent mal utiliser les >contrats).
Les contrats publics sont construits lors de la spécification en même temps que l'interface. En plus de les écrire sur un bout de parier ou dans un graphe UML tu les ajoute dans ton code.
Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.
Les contrats c'est fait pour faire des trucs carrés avec un accord entre plusieurs entités (entre classes, entre développeurs, entre donneur d'ordre et fournisseur). D'ailleurs le nom n'est pas annodin.
> Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible
> (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est
> cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.
C'était un exemple simple pour comprendre mais c'est raté il me semble :-/
C'est un sujet un peut compliqué. Si on comprend bien les notions Objet c'est relativement facile à comprendre (mais plus dur à expliquer malheureusement pour moi).
Je me place dans un modèle conceptuel qui n'a rien à voire avec l'implémentation (l'implémentation et la compilation efficace est un autre sujet, certes lié, mais qui n'a rien à voire) ni avec la syntaxe Java (car la syntaxe est addapté au comportement). En parlant d'introspection à la Java tu te limites au modèle Java qui forcément n'est pas addapté aux concepts étrangers à Java.
Il faut savoir que la covariance ne change en rien le concept de spécialisation (héritage) ni de sous-classage. Par contre elle pose un problème avec la théorie des types qui est incompatible avec la covariance bien qu'il fut montré que c'est la théorie des types qui n'est pas addapté à la réalité (pour preuve l'existence du cas particulier des coercitions (cast)).
Les règles de typage que respecte Java (en parti car Java n'est pas cohérent) est celle utilisé par presque tous les langages de programmation fortement typés.
Tu emplois le mot « remplace ». deux sens possible pour un tel mot :
1- redéfinition : une fonction toto qui a un comportement dans une classe A aquiert un comportement particulier (et spécialisé) dans une sous-classe B. Le polymorphisme marche.
exemple :
A v
v = new B
v.toto
bien que toto soit appelée sur un objet de type statique A, c'est la fonction B::toto qui est exécuté car le type dynamique de v sera B.
2- surcharge statique : une fonction toto qui a un comportement dans une class A est écrasée par une autre foction toto dans une sous-classe B. Les deux fonctions toto n'ont rien en commun si ce n'est le nom. Le polymorphisme ne marche pas.
dans l'exemple précedent, c'est la fonction A::toto qui serait appelée.
Ces deux définition de « remplacement » sont indépendante du modèle de variance du langage (puisque je n'ai pas parlé de paramètres).
Maintenant un cas concret. En Java on doit écrire quelque chose du genre
class Animal {
void mange(Nouriture n);
}
class Carnassier {
void mange(Nouriture n) {
Animal a;
a = (Animal)n; // je sais plus comment on fait les casts en Java :p
// le reste
}
avec la covariance on aurait
class Animal {
void mange(Nouriture n);
}
class Carnassier {
void mange(Animal a) {
// le reste
}
Tout chose étant égale par ailleurs.
Quel est l'interet ?
- autospécification des paramètres ;
- plus besoin de cast ;
- pas besoin de se trainer une signature qui n'a presque plus rien à voire avec son utilisation dans une petite petite sous-classe.
Limitation : la surcharge statique devient impossible. Mais c'est pas un mal car il n'y a plus ambiguité entre redéfinition et surcharge statique : le modèle est plus clair. (la surcharge statique est souvent décriée).
Remarque, la covariance du type de retour n'est pas non plus incluse dans Java malgrè que :
- la covariance du type de retour est compatible avec la théorie des types (si si) ;
- le cout d'implémentation dans langage à héritage simple est négligeable. D'ailleurs en C++ cette coraviance est dans la norme mais peu de compilo l'implémentent car le coût est sans commune mesure en héritage multiple. Au dernières nouvelles g++ nous sortait un message d'excuse :)
Erreur, je l'ai fait :)
Mais pas avec les &toto;[1] avec le caractère insécable latin-1 qui va bien[2]. Bon, c'est vrai que j'aurais du vérifier si templeet prenait correctement ce caractère. :)
[1] il me semble que l'on peut normalement écrire « à » ou « à » comme on peut écrire « » ou « ». sauf que rien ne distingue ' ' de ' '. Sauf éventuellement dans vim voire dans certaines polices ou le ' ' est plut petit que le ' '. :)
[2] J'ai configuer xkb pour que AltGr + Espace fasse un espace inséquable. J'ai pas trouvé de moyen plus propre pour insérer un caractère inséquable de façon naturelle.
La nouriture et le logment devrait être un droit également. Car même sans culture on peut vivre.
Par contre la culture est immaterielle et il serait éventuellement bien plus facile de distribuer des la culture à tout le monde que de la nouriture ou des logements.
« La Guilde pratiquait la démocratie ultime. Nul besoin d'intéligence, de position sociale, de beauté ni de charisme pour s'offrire ses services. Il fallait seulement de l'argent, ce qui, à la différence du reste, était à la porté de tout le monde. Saut des pauves, évidemment, mais il y a toujours des indécrotables. » -- T. Pratchett, Le père Porcher
Bien qu'il faudrait dire « bien que »[*], certains auteurs l'emploient (Loti, Daudet, France, Gide...). Et il est seulement recomandé dans le Grévisse et dans Le dictionnaire des difficultés de Larousse.
[*] c'est bien gentil de raler sur le français mais si tu utilises "" à la place de «» ça fait pas sérieux. :)
>- pas de covariance (enfin si dans les tableaux) ;
Le covariance est le fait de faire varier le types des paramètres (ecriture et lecture) dans le même sens que l'héritage.
exemple (en pseudo code) :
class Animal {
void mange(Nouriture);
}
class Vache extends Animal {
void mange(Herbe);
}
>- pas de réflexivité (seulement de l'introspection) ;
L'introspection c'est pourvoir « lire » les infos structurelles du langage (exemple parcourir les méthodes d'une classe).
La réflexivité c'est pouvoir « modifier » les infos structurelles du langage (exemple modifier une méthode d'une classe)
>- pas de fonctions lambda :) ;
ce sont des fonctions anonymes crées à la demande. Une des nombreuses utilités est de pouvoir avoir une méthode de comparaison ad-hoc pour faire des tris, des itérateurs, etc. en fait ce que j'apelle « lamda » regroupe plutot les fermeture et autres blocs mais le principe à la base est globalement le même.
>- pas de contrats.
C'est le fait d'écrire les contraintes de fonctionnement requis dans le code plutôt que dans la doc. Le programme pouvant alors s'auto-vérifier dans les phases de débug.
exemple grossier pour comprendre
class A {
int toto;
void set_toto(int t)
require t > 0
{ toto = t }
ensure t = toto
}
ici la fonction set_toto exprime que son paramètre doit être positif et que le résultat de son action sera de rentre l'attribut toto egal à t.
L'interet de ce genre de chose est de faciliter le developpement et de séparer interface et implémentation.
« Personnellement le langage me convient (question d'habitude,j'ai été élevé au C). »
est-ce une raison pour ne pas chercher les limites du langage ? est-ce une raison pour ne par chercher, ne serait-ce que par curiosité, comment dépasser ces limites ?
J'ai également été élevé au C, c'est pas pour autant je n'essaye pas de porter un regard critique (certains diront « de critique ») sur les langages que j'étudie.
« Le fait d'avoir des noms longs ne me dérange pas, je trouve même que c'est un avantage, si on s'en sert bien on arrive à avoir du code très facilement relisible et reprenable. ... »
Oui mais ya souvent de l'abus, il suffit d'une chaine avec 3 ou 4 envois de messages, un peu d'indentation et on dépasse les 80 caractères. Question lisibilité c'est pas forcément ce qu'on fait de mieux.
Je reconnais que ce point est faible. et puis on a le complettement automatique et de grands écrans.
« Pour info, c'est quoi tes langages préférés, ou plutot, est-ce que tu connais un langage qui correspond à ce que tu décris plus haut ? »
J'en ai pas, je me contente de critiquer comme un vieux raleur. :)
Eiffel : un langage grandiose et largement en avance sur son temps au niveau des concepts (c'est un peu comme si linux 2.6 était sorti en même temps de DOS 3.0). Malheureusement il est verbeux et tros rigoureux pour une utilisation comme la mienne. Mais en entreprise il roxor d'après des gens. Son principal défaut : les boucles sont vraiment nulles (for, while, etc.)
Ruby : un langage de script tout objet bien qu'étant le contraire d'Eiffel. Proche de SmallTalk il gère les lambas de façon élégantes. Son défaut : héritage multiple remplacé par des mixins, c'est pas si grave vu qu'il est a typage dynamique (c'est juste lourd parfois).
CLOS : (Comon (LISt Processing) Object System). Il faut aimer les parenthèses. J'ai jamais accroché au LISP mais ya des gens qui aiment. Point fort : selection multiple (en gros tous les arguments d'un appel de méthode sont les receveurs).
OCaml : plusieurs fois j'ai essayé de m'y mettre sérieusement mais à chaque fois je me suis évanoui en lisant la syntaxe (et pourtant je connais BrainFuck et GOTO++ donc niveau syntaxe je me pensais blindé).
J'avais pas envie de faire une liste mais puisque deux personnes insistent :
Pous les griefs syntaxiques et génie logiciel :
- syntaxe souvent lourde (noms longs, points virgules, redondance de l'écriture) ;
- pas de moyen simples de faire des blocs débug ou des assertions ;
- héritages ancestraux (case, break).
Pour les griefs plus spécifiques :
- tout n'est pas objet (types primitifs, tableaux) ;
- héritage simple (non, le sous-typage multiple ne suffit pas dans tous les cas) ;
- les attributs statiques ne sont pas des attributs de classes ;
- distinction entre méthodes et attributs (pas homogène, oblige à creer des accesseurs) ;
- protections instables (cas complexes de protection difficiles à prévoir, surtout que la norme change parfois et que la JVM ne suit pas toujours la norme) ;
- types de retour invariants (étrange non ?) ;
- les tableaux ne se comportent pas comme des classes (contravariants vs invariants) ;
- pas de généricité (ok, ça va arriver un jour).
Pour finir sur les trucs optionnels :
- pas de covariance (enfin si dans les tableaux) ;
- pas de réflexivité (seulement de l'introspection) ;
- pas de fonctions lambda :) ;
- pas de contrats.
Bon, bien sûr je sens qu'il va y avoir des gens pour raler sur ma liste (c'est normal) mais j'espère juste qu'il n'y aura pas trop de monde pour déformer/inventer mes propos.
N'oubliez par que Java c'est entre autre :
- un language ;
- une bibliothèque énorme ;
- une machine virtuelle ;
- un modèle de sécurité.
Je ne parle que du premier point et je troive domage que pour avoir les 3 points suivants on soit obligé de se farcir un lagage comme Java.
Java est sans doute une très bonne plateforme de développement avec une bibliothèque de base très imposante et standard. De plus sa popularité fait que l'expérience, les outils et les personnes compétentes ne manquent pas.
Malheureusement, le langage Java est une honte. Ben sûr en venant du monde C en ne conaissant que la gestion des concepts objets (mal-)traités par C++, on a souvent l'impression que Java est plus clair, plus simple, plus logique (plus hortogonal quoi) mais l'effet est trompeur. D'ailleurs, je fut également duppé :).
Java né en 1991 avait déjà plus de 5 ans de retard sur la compréhension des concepts objets. C'est franchement domage, avec un environement pareil et la popularité du Java, même auprès des dessideurs pressés (surtout auprès ?), qu'est ce que ça aurait été si le jangage Java avait été un bon langage !
ben, { 1 (-1/2;sqr(3)/2) (-1/2;-sqr(3)/2) } c'est vrai dans C. La réponse de Google est vraie dans R. Je vois pas où est le pb (à la limite ils auraient dû préciser).
[^] # Re: Pour ceux qui sauraient pas
Posté par MrTout (site web personnel) . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 3.
et doit te payer des droits, et comme les radios ont pas que ça à faire elles payent un forfait à la SACEM pour passer les musiques qu'elles veulent (du moment que c'est des musiques gérés par eux).
Mais admetons que tu t'arranges avec une radio ou que tu offres la diffusion gratuite. Le bistrotier qui a une radio et des hauts-parleurs un peu partout dans son bar paye des trucs à la SACEM pour diffuser éventuellement tes musiques (que la SACEM ne gère pas).
De plus, la « juste » contribution financière qui te reviens pour la copie privée de tes CD est prélevé et reversé la SACEM et toi t'en verra pas un centime d'euro.
Du moins c'est ce que j'ai entendu dire et ça me parait pas si invraissembleble que ça que la SACEM noyaute tout le système des droits patrimoniaux des uvres mulicales.
[^] # Re: c'est mal l'OMC ?
Posté par MrTout (site web personnel) . En réponse au journal c'est mal l'OMC ?. Évalué à 1.
En fait Aristote a bien fait d'arreter la physique et de se consacrer à l'informatique. :)
[^] # Re: creer un parti... bonne chance
Posté par MrTout (site web personnel) . En réponse à la dépêche Manifestation contre les brevets logiciels à Bruxelles, mercredi 27 août. Évalué à 4.
Une très bonne emission du temps où je redardais la TV (je sais même pas elle(Archimède pas la télé) existe encore de nos jours).
Je me souviens avoir vu cet « épisode »-là, moi aussi
# Re: De la bétise des brevets logiciels
Posté par MrTout (site web personnel) . En réponse au journal De la bétise des brevets logiciels. Évalué à 6.
Encore une fois j'espère que nos députés sauront choisir la voix du divertissemment malgrès les rapports préchi-préchas est le spamming de gens du métier (qui défendent leur billes, c'est bien connu, au mépris de l'humour). :)
[^] # Re: Boum! ce soir à 21h ?
Posté par MrTout (site web personnel) . En réponse au journal Boum! ce soir à 21h ?. Évalué à 1.
http://www.google.com/search?q=Skynet(...)
[^] # Re: c'est mal l'OMC ?
Posté par MrTout (site web personnel) . En réponse au journal c'est mal l'OMC ?. Évalué à 1.
[*] et puis les vas et viens vers les nots de bas de commentaire donne le tournis :)
[^] # Re: Fermez votre site !!
Posté par MrTout (site web personnel) . En réponse au journal Fermez votre site !!. Évalué à 1.
[^] # Re: c'est mal l'OMC ?
Posté par MrTout (site web personnel) . En réponse au journal c'est mal l'OMC ?. Évalué à 1.
Sinon, l'express est de quel coté ? Il est souvent cité par google news.
[*] je suis tombé une fois sur un article disant en gros que « c'est une honte, José Bové ce vandale piloté par des anarchistes étrangers a eu sa peine de prison ferme réduite alors que dans le même temps des honètes chefs d'entreprise se contentant de détourner des fonds n'ont pas droit aux même égards de la part de la justice. ». J'ai vraiment cru à un troll.
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 1.
class Nouriture {}
class Viande extends Nouriture {}
class Herbe extends Nouriture {}
class Animal { void mange(Nouriture) }
class Vache extends Animal { void mange(Herbe) }
Animal margueritte = new Vache
Viande farine_animale = new Viande
margueritte.mange(farine_animale)
le verificateur de types laissera passer mais lors de l'exécution tu auras une erreur de type. Si tu faisais la même chose avec des casts tu aurais aussi une erreur de type de toute façon.
PS: c'est pas interdit de plusser les gens qui passent du temps a essayer d'expliquer des choses (même si c'est parfois obscur) :)
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 2.
>Ce choix a été fait pour simplifier la machine virtuelle et pour des raisons de sécurités >(si tu as le droit de modifier les classes de sécurités ou les classloaders, t'es mal).
D'une part il ne faut jamais mélanger implémentation et langages. La réflexivité est une torture à compiler en natif, avec une marchine virtuelle cela ne devient que très très difficile et peu efficace. Mais j'ai bien précisé que je ne parlait que du langage et pas de son implémentation.
Le langage Java est le même qui est utilisé par les compilateurs natifs (tel gcc) et la machine virtuelle peut faire tourner du byte-code qui ne provient pas d'un programme en Java (SmartEiffel peut produire du byte code JVM). Le langage Java n'est pas lié à la JVM.
Ensuite, que Java ne fasse pas de réflexivité c'est pas non plus la fin du monde. C'est déjà vachement bien qu'on aie l'introspection je trouve.
Pour conclure, rien n'empeche que le gestionnaire de sécurité soit en read-only et qu'il vérifie les modifications apportés au système.
>>- pas de fonctions lambda :) ;
>Ces fonctions sont émulés par les objets et les interfaces. exemple : l'interface >java.util.Comparator qui définit une méthode public int compareTo(Object o1, Object >o2). Tu crées une classe implémentant Comparator (de type inner, toplevel ou >anonyme) avec ta méthode de tri et tu la passe à la méthode voulue (Arrays.sort() >par ex). Ca marche pareil avec les Iterator, les Enumeration, etc.
Arg !
Je savais pas ça. C'est terriblement lourd comme système. Forcer la création d'une classe avec une méthode particulière pour charque fonction de comparaison est monstrueux. Sans compter que d'une part pour que le typage accepte ça il faut faire des coercition à tout va et d'autre par ce n'est plus la classe d'origine qui est responsable des ses comparaisons mais un autre classe.
Un solution simple pour faire ça serait quelque chose du genre :
creer une méthode par comparaison dans la classe.
class Persone
{
int compare_by_name() {...}
int compare_by_age() {...}
}
le container possédant une méthode de tri qui necessite une méthode de comparaions
class Container
{
void sort_using(Function comparator) {...}
}
D'une part il me semble que c'est faisable avec l'introspection Java et d'autre part Java aurait à y gagner en spécifiant ce genre de trucs correctement (SmartEiffel fait ça de façon originale et plutot pas mal) et pas par des stratagèmes qui pervertissent notre belle jeunesse !
>Je trouve que ça a l'avantage de clarifier le language (au détriment peut-etre de la >rapidité d'écriture et encore).
méthode coué, hein ?
>>- pas de contrats
>Conceptuellement, je suis d'accord, c'est un gros manque. Mais qui va coder les tests >des contrats dans ses classes à part ceux qui font des choses carrées ? (j'ai deux >exemples sous la main de codeurs non propres, je les imaginent mal utiliser les >contrats).
Les contrats publics sont construits lors de la spécification en même temps que l'interface. En plus de les écrire sur un bout de parier ou dans un graphe UML tu les ajoute dans ton code.
Si tes codeurs non propres sont incapable d'utiliser les contrats, je les vois mal utiliser l'autodocumentation, les commentaires ou les assertions.
Les contrats c'est fait pour faire des trucs carrés avec un accord entre plusieurs entités (entre classes, entre développeurs, entre donneur d'ordre et fournisseur). D'ailleurs le nom n'est pas annodin.
> Pour ce qui est des noms longs, ça a l'avantage d'etre lisible et compréhensible
> (compare strftime() et DateFormat.format()). L'inconvénient, je le reconnais, c'est
> cette lignes des 80 colonnes qu'on atteint voire franchit allègrement.
c'est pour ça qu'il y à un juste milieu entre
p "hello world"
et
system.out.screen.display.string.print_ended_with_a_new_line("hello word");
:p
Le but pas d'avoir des noms longs ou des noms courts mais des noms explicites !
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 2.
C'est un sujet un peut compliqué. Si on comprend bien les notions Objet c'est relativement facile à comprendre (mais plus dur à expliquer malheureusement pour moi).
Je me place dans un modèle conceptuel qui n'a rien à voire avec l'implémentation (l'implémentation et la compilation efficace est un autre sujet, certes lié, mais qui n'a rien à voire) ni avec la syntaxe Java (car la syntaxe est addapté au comportement). En parlant d'introspection à la Java tu te limites au modèle Java qui forcément n'est pas addapté aux concepts étrangers à Java.
Il faut savoir que la covariance ne change en rien le concept de spécialisation (héritage) ni de sous-classage. Par contre elle pose un problème avec la théorie des types qui est incompatible avec la covariance bien qu'il fut montré que c'est la théorie des types qui n'est pas addapté à la réalité (pour preuve l'existence du cas particulier des coercitions (cast)).
Les règles de typage que respecte Java (en parti car Java n'est pas cohérent) est celle utilisé par presque tous les langages de programmation fortement typés.
Tu emplois le mot « remplace ». deux sens possible pour un tel mot :
1- redéfinition : une fonction toto qui a un comportement dans une classe A aquiert un comportement particulier (et spécialisé) dans une sous-classe B. Le polymorphisme marche.
exemple :
A v
v = new B
v.toto
bien que toto soit appelée sur un objet de type statique A, c'est la fonction B::toto qui est exécuté car le type dynamique de v sera B.
2- surcharge statique : une fonction toto qui a un comportement dans une class A est écrasée par une autre foction toto dans une sous-classe B. Les deux fonctions toto n'ont rien en commun si ce n'est le nom. Le polymorphisme ne marche pas.
dans l'exemple précedent, c'est la fonction A::toto qui serait appelée.
Ces deux définition de « remplacement » sont indépendante du modèle de variance du langage (puisque je n'ai pas parlé de paramètres).
Maintenant un cas concret. En Java on doit écrire quelque chose du genre
class Animal {
void mange(Nouriture n);
}
class Carnassier {
void mange(Nouriture n) {
Animal a;
a = (Animal)n; // je sais plus comment on fait les casts en Java :p
// le reste
}
avec la covariance on aurait
class Animal {
void mange(Nouriture n);
}
class Carnassier {
void mange(Animal a) {
// le reste
}
Tout chose étant égale par ailleurs.
Quel est l'interet ?
- autospécification des paramètres ;
- plus besoin de cast ;
- pas besoin de se trainer une signature qui n'a presque plus rien à voire avec son utilisation dans une petite petite sous-classe.
Limitation : la surcharge statique devient impossible. Mais c'est pas un mal car il n'y a plus ambiguité entre redéfinition et surcharge statique : le modèle est plus clair. (la surcharge statique est souvent décriée).
Remarque, la covariance du type de retour n'est pas non plus incluse dans Java malgrè que :
- la covariance du type de retour est compatible avec la théorie des types (si si) ;
- le cout d'implémentation dans langage à héritage simple est négligeable. D'ailleurs en C++ cette coraviance est dans la norme mais peu de compilo l'implémentent car le coût est sans commune mesure en héritage multiple. Au dernières nouvelles g++ nous sortait un message d'excuse :)
[^] # Re: Pour ceux qui sauraient pas
Posté par MrTout (site web personnel) . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 1.
[^] # Re: Un virus crash le réseau de surveillance d'une centrale nucléaire
Posté par MrTout (site web personnel) . En réponse au journal Un virus crash le réseau de surveillance d'une centrale nucléaire. Évalué à 2.
Mais pas avec les &toto;[1] avec le caractère insécable latin-1 qui va bien[2]. Bon, c'est vrai que j'aurais du vérifier si templeet prenait correctement ce caractère. :)
[1] il me semble que l'on peut normalement écrire « à » ou « à » comme on peut écrire « » ou « ». sauf que rien ne distingue ' ' de ' '. Sauf éventuellement dans vim voire dans certaines polices ou le ' ' est plut petit que le ' '. :)
[2] J'ai configuer xkb pour que AltGr + Espace fasse un espace inséquable. J'ai pas trouvé de moyen plus propre pour insérer un caractère inséquable de façon naturelle.
[^] # Re: Pour ceux qui sauraient pas
Posté par MrTout (site web personnel) . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 3.
Par contre la culture est immaterielle et il serait éventuellement bien plus facile de distribuer des la culture à tout le monde que de la nouriture ou des logements.
« La Guilde pratiquait la démocratie ultime. Nul besoin d'intéligence, de position sociale, de beauté ni de charisme pour s'offrire ses services. Il fallait seulement de l'argent, ce qui, à la différence du reste, était à la porté de tout le monde. Saut des pauves, évidemment, mais il y a toujours des indécrotables. » -- T. Pratchett, Le père Porcher
[^] # Re: Un virus crash le réseau de surveillance d'une centrale nucléaire
Posté par MrTout (site web personnel) . En réponse au journal Un virus crash le réseau de surveillance d'une centrale nucléaire. Évalué à 3.
[*] c'est bien gentil de raler sur le français mais si tu utilises "" à la place de «» ça fait pas sérieux. :)
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 4.
Le covariance est le fait de faire varier le types des paramètres (ecriture et lecture) dans le même sens que l'héritage.
exemple (en pseudo code) :
class Animal {
void mange(Nouriture);
}
class Vache extends Animal {
void mange(Herbe);
}
>- pas de réflexivité (seulement de l'introspection) ;
L'introspection c'est pourvoir « lire » les infos structurelles du langage (exemple parcourir les méthodes d'une classe).
La réflexivité c'est pouvoir « modifier » les infos structurelles du langage (exemple modifier une méthode d'une classe)
>- pas de fonctions lambda :) ;
ce sont des fonctions anonymes crées à la demande. Une des nombreuses utilités est de pouvoir avoir une méthode de comparaison ad-hoc pour faire des tris, des itérateurs, etc. en fait ce que j'apelle « lamda » regroupe plutot les fermeture et autres blocs mais le principe à la base est globalement le même.
>- pas de contrats.
C'est le fait d'écrire les contraintes de fonctionnement requis dans le code plutôt que dans la doc. Le programme pouvant alors s'auto-vérifier dans les phases de débug.
exemple grossier pour comprendre
class A {
int toto;
void set_toto(int t)
require t > 0
{ toto = t }
ensure t = toto
}
ici la fonction set_toto exprime que son paramètre doit être positif et que le résultat de son action sera de rentre l'attribut toto egal à t.
L'interet de ce genre de chose est de faciliter le developpement et de séparer interface et implémentation.
« Personnellement le langage me convient (question d'habitude,j'ai été élevé au C). »
est-ce une raison pour ne pas chercher les limites du langage ? est-ce une raison pour ne par chercher, ne serait-ce que par curiosité, comment dépasser ces limites ?
J'ai également été élevé au C, c'est pas pour autant je n'essaye pas de porter un regard critique (certains diront « de critique ») sur les langages que j'étudie.
« Le fait d'avoir des noms longs ne me dérange pas, je trouve même que c'est un avantage, si on s'en sert bien on arrive à avoir du code très facilement relisible et reprenable. ... »
Oui mais ya souvent de l'abus, il suffit d'une chaine avec 3 ou 4 envois de messages, un peu d'indentation et on dépasse les 80 caractères. Question lisibilité c'est pas forcément ce qu'on fait de mieux.
Je reconnais que ce point est faible. et puis on a le complettement automatique et de grands écrans.
« Pour info, c'est quoi tes langages préférés, ou plutot, est-ce que tu connais un langage qui correspond à ce que tu décris plus haut ? »
J'en ai pas, je me contente de critiquer comme un vieux raleur. :)
Eiffel : un langage grandiose et largement en avance sur son temps au niveau des concepts (c'est un peu comme si linux 2.6 était sorti en même temps de DOS 3.0). Malheureusement il est verbeux et tros rigoureux pour une utilisation comme la mienne. Mais en entreprise il roxor d'après des gens. Son principal défaut : les boucles sont vraiment nulles (for, while, etc.)
Ruby : un langage de script tout objet bien qu'étant le contraire d'Eiffel. Proche de SmallTalk il gère les lambas de façon élégantes. Son défaut : héritage multiple remplacé par des mixins, c'est pas si grave vu qu'il est a typage dynamique (c'est juste lourd parfois).
CLOS : (Comon (LISt Processing) Object System). Il faut aimer les parenthèses. J'ai jamais accroché au LISP mais ya des gens qui aiment. Point fort : selection multiple (en gros tous les arguments d'un appel de méthode sont les receveurs).
OCaml : plusieurs fois j'ai essayé de m'y mettre sérieusement mais à chaque fois je me suis évanoui en lisant la syntaxe (et pourtant je connais BrainFuck et GOTO++ donc niveau syntaxe je me pensais blindé).
En ce moment je bosse en Eiffel pour mon travail.
[^] # Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 6.
Pous les griefs syntaxiques et génie logiciel :
- syntaxe souvent lourde (noms longs, points virgules, redondance de l'écriture) ;
- pas de moyen simples de faire des blocs débug ou des assertions ;
- héritages ancestraux (case, break).
Pour les griefs plus spécifiques :
- tout n'est pas objet (types primitifs, tableaux) ;
- héritage simple (non, le sous-typage multiple ne suffit pas dans tous les cas) ;
- les attributs statiques ne sont pas des attributs de classes ;
- distinction entre méthodes et attributs (pas homogène, oblige à creer des accesseurs) ;
- protections instables (cas complexes de protection difficiles à prévoir, surtout que la norme change parfois et que la JVM ne suit pas toujours la norme) ;
- types de retour invariants (étrange non ?) ;
- les tableaux ne se comportent pas comme des classes (contravariants vs invariants) ;
- pas de généricité (ok, ça va arriver un jour).
Pour finir sur les trucs optionnels :
- pas de covariance (enfin si dans les tableaux) ;
- pas de réflexivité (seulement de l'introspection) ;
- pas de fonctions lambda :) ;
- pas de contrats.
Bon, bien sûr je sens qu'il va y avoir des gens pour raler sur ma liste (c'est normal) mais j'espère juste qu'il n'y aura pas trop de monde pour déformer/inventer mes propos.
N'oubliez par que Java c'est entre autre :
- un language ;
- une bibliothèque énorme ;
- une machine virtuelle ;
- un modèle de sécurité.
Je ne parle que du premier point et je troive domage que pour avoir les 3 points suivants on soit obligé de se farcir un lagage comme Java.
# Re: Java et Linux
Posté par MrTout (site web personnel) . En réponse au journal Java et Linux. Évalué à 0.
Malheureusement, le langage Java est une honte. Ben sûr en venant du monde C en ne conaissant que la gestion des concepts objets (mal-)traités par C++, on a souvent l'impression que Java est plus clair, plus simple, plus logique (plus hortogonal quoi) mais l'effet est trompeur. D'ailleurs, je fut également duppé :).
Java né en 1991 avait déjà plus de 5 ans de retard sur la compréhension des concepts objets. C'est franchement domage, avec un environement pareil et la popularité du Java, même auprès des dessideurs pressés (surtout auprès ?), qu'est ce que ça aurait été si le jangage Java avait été un bon langage !
[^] # Re: La calculatrice Google : un peu faux quoi...
Posté par MrTout (site web personnel) . En réponse à la dépêche La calculatrice Google. Évalué à 1.
[^] # Re: xMule
Posté par MrTout (site web personnel) . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 3.
http://www.disctronics.co.uk/technology/cdbasics/cd_books.htm(...)
voire
http://www.wikipedia.org/wiki/Red_Book(...)
[^] # Re: xMule
Posté par MrTout (site web personnel) . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 1.
http://mldonkey.berlios.de/(...)
[^] # Re: MeeKKro$oft, ca pue...
Posté par MrTout (site web personnel) . En réponse au journal MeeKKro$oft, ca pue.... Évalué à 1.
Moi je l'ai pas encore eu, mais il parrait que, comme la varicelle, c'est plus grave quand on l'a une fois adulte.
[^] # Re: Première page !!
Posté par MrTout (site web personnel) . En réponse à la dépêche SCO La suite du retour de la fin du début ..... Évalué à 2.
http://linuxfr.org/~anonyme/(...) ?
--> []
[^] # Re: MeeKKro$oft, ca pue...
Posté par MrTout (site web personnel) . En réponse au journal MeeKKro$oft, ca pue.... Évalué à 2.
De toute façon cette personne ne semble pas être à son coup d'essai : http://linuxfr.org/~Corsica/(...)
# Re: Theorie du chaos
Posté par MrTout (site web personnel) . En réponse au journal Theorie du chaos. Évalué à 6.