ggins a écrit 18 commentaires

Comme je le disais, si cela fait partie des choix controversés du BDFL, ça n'est pas pour rien! Bref, c'est avant tout une question de goût et de sensibilité (donc un sujet très polarisant).

Je conseillerais à ceux qui veulent découvrir python de ne pas s'arrêter à cela: l'emploi de "self" est peut être lourd, l'indentation est certainement pénible (mais on s'y fait très rapidement) etc etc...
Pourtant, il y a plein de subtilités et de choix dans le langage qui permettent d'écrire des scritps sympa en très peu de lignes (les méthodes XXX, les list comprehensions, les generator expressions etc... cf le tuto officiel), sans parler de sa bibliothèque ("batteries included") répondant à la plupart des besoins courants.

Je me suis mal exprimé. L'argument "self" n'est évidemment pas indispensable. Si je me rappelle bien, il s'agit d'un de ces fameux choix contreversés de Guido Van Rossum (comme par exemple le fait que l'indentation soit significative).

L'exemple que je prend sert à surtout voir le genre de considérations "esthétiques" (homogénéité?) qui ont probablement été prises en compte pour imposer une telle construction.

En fait, c'est parce qu'en python les classes comme les fonctions sont des objects de premier ordre. Voici un exemple qui peut justifier l'utilisation de self (d'ailleurs, self n'est qu'une convention, tu peux utiliser n'importe quel autre nom pour ton premier argument):

class Plop(object):
    def __init__(self):
            print self

def print_me(x):
    print x

Plop.print_me = print_me

a = Plop()

a.print_me()

Ce genre de fonctionalité permet de faire des choses complètement non maintenables, ou alors sert de base pour faire des trucs plutôt chouettes

Mon propos porte sur des considérations pragmatiques, je ne discute pas sur des propriétés théoriques.

Je m'explique: ca n'est donc pas la peine d'essayer de coller des définitions théoriques sur les termes que j'emplois comme tu t'escrimes à le faire, tu ne comprendras effectivement pas ce que j'écris (je n'utilise pas "complexité" au sens "complexité algorithmique", "complet" n'a rien à voir avec "NP-complet" ou autres choses, quant à "puissance" ça aurait dû te mettre sur la voie car je ne suis pas au courant d'une telle définition)

Mon opinion est que d'un point de vue pragmatique Java possède un meilleur rapport complexité/puissance que C++ entre autres parce qu'il moins expressif (élimination des fonctionnalités ésothériques ou trop difficiles à maitriser) tout en répondant aux besoins de conception d'une application. Au risque de sembler lourd, je rappelle que je parle de qualités désirables dans un contexte industriel, pour lequel il faut tenir compte de certains paramètres que j'ai déjà mentionnés

Je crois que certains chez LibreOffice aimeraient redéfinir/réduire les dépendances sur java. Ca n'est pas très clair si c'est parce que java c'est Oracle ou si c'est pour des raisons de performances (c'est probablement un peu pour les deux). Certains voudraient même remplacer toutes les boîtes de dialogues qui sont codées en java.
En tout cas, ça montre bien que l'utilisation d'une JVM n'est pas toujours adéquate, par exemple quand on doit cohabitater avec du runtime externe...

Qu'est ce qui n'est pas spécifié en c++? C'est une vrai question, je veux bien te croire, et ce serai intéressant d'avoir plus d'infos

Concernant cette question j'ai déjà donnés des exemples, d'ailleurs tu les cites toi-même dans ton post :-)

La je suis plus sceptique. Qu'est ce que la complexité d'un langage?
Est ce que tu veux dire que entre java et C++ un est plus puissant que l'autre?
Qu'est ce que la cohérence d'une grammaire?
Qu'est ce que les analyseurs syntaxiques Java font de mieux et qu'est ce qui manque à la spec de C++ pour en faire autant? (cette dernière question rejoins le paragraphe précédent).

Complexité d'un langage: tu as souvent de bon indices en rerdant la taille sa spécification, de sa grammaire. Sans parler du nombre de possibilités offertes par un langage. Car il ne faut pas oublier que chaque fois que tu introduis de nouvelles constructions, il faut qu'il n'y ait pas de conflits avec les fonctionnalités existantes.

Qu'est ce qui manque à la spec de C++ pour en faire autant?
Hmm, url
"C++ grammar is ambiguous, context-dependent and potentially requires infinite lookahead to resolve some ambiguities"

tu balances pleins d'affirmations ambiguës qui veulent pas dire grand chose.

Ca n'est pas parce que tu ne comprends pas ce que j'écris que ça ne veut rien dire ;-)

Un langage incompatible qui coupe toute compatibilité avec son prédécesseur.

Ce fut une des grandes réussites et un des fardeaux les plus lourds du C++: d'un côté, il put s'imposer par ce biais, de l'autre... je n'ai pas besoin de t'expliquer ce qu'est devenu ce langage (indice: un fouilli de fonctionalités alambiquées, favorisant l'apparition de gourus et de devs comprenant à moitié ce qu'ils font - ce qui est courant dans l'industrie). Java aussi paye un tribut à la compatibilité ascendante (qui a dit generics?). Je trouve cela tout à fait normal, mais comme il part sur des bases plus saines (le C++ avait montré ce qu'il ne fallait pas faire), ça se passe mieux.

Tellement fantastique qu'aucun logiciel de bureautique courant ne l'utilise

C'est tout à fait exact, C++ était là avant, ça serait stupide de tout réimplémenter, et de plus la jvm impose des contraintes qui font que ça n'est pas toujours pertinent de l'utiliser. Heureusement d'ailleurs, sinon cela signifierait que le couple java/jvm est la solution universelle!

Ce n'est pas pour autant que je veux le voir à toutes les sauces sur mon bureau.

Sur mon bureau, moi je veux juste des applications qui répondent à mon besoin avec les performances adéquates, quel que soit le langage utilisé pour les coder. Par contre, dans un contexte industriel (gros logiciels, équipes de programmeurs avec des niveaux hétérogènes), et sous réserve bien sûr que les contraintes imposées par la jvm soit acceptables, je n'hésite pas.

Pour moi, Java (le langage) est une version industrielle du C++

• java possède une spécification complète: tout est spécifié de la taille des types à la stratégie de chargement des modules, en passant par la gestion de la mémoire (initialisations) et les considérations sur l'éxécution concurrente.

• java possède un meilleur rapport compléxité/puissance: l'ensemble des fonctionnalités fournies par le langage a été soigneusement sélectionné. La grammaire est cohérente. Pas étonnant dès lors qu'on ait des outils d'analyse statique et des IDEs un cran au dessus de ce dont dispose en C++ (firebug est un bon exemple de ce qu'on peut obtenir quand on a un langage analysable et complètement spécifié)

C'est un langage robuste, cohérent, utilisable par des personnes de niveaux plus ou moins hétérogènes: un langage taillé pour les entreprises, suffisamment proche du C++ pout séduire la population des dév déjà présente à l'époque, sans toutes les incohérences et les manques qui caractérisent ce dernier.

Java (le langage) est ce qu'aurait dû être le C++

Ceci dit, en ce qui concerne java, son succès me semble essentiellement dû à deux autres facteurs:

• l'existence ( C++ [:haha]), la richesse, et la haute qualité de sa bibliothèque standard. Je ne parle même pas de la documentation qui je le rappelle comprend les références (javadoc), les tutoriels, et les documents expliquant comment tel composant est censé être utilisé etc..

• la JVM. Comme le langage, elle est spécifiée (modèle mémoire, execution concurrente etc..), elle est particulièrement performante vues les fonctionnalité qui doivent être supportées (là-bas au fond, arrêtez de râler sur le GC!). Elle a été faite avec Java en ligne de mire mais elle est en réalité indépendante du langage - seul le byte code compte. Depuis quelques temps, on voit d'ailleurs apparaître pas mal de petits nouveaux (scala, clojure, groovy etc..) A votre avis, pourquoi les concepteurs choisissent la JVM pour les implémenter? On rajoutera à cela que via la JVM, ces langages peuvent intéragir avec du code java, récupérant d'un coup l'accès à toutes les fonctionnalités offertes par la lib standard!

Bref, Java a été un grand pas en avant du point de vue informatique industrielle (pour des petits/moyens projets avec des devs compétent, c'est moins remarquable), mais ce qui restera sera probablement c'est la JVM et la lib standard

* mercurial: plus facile d'accès, moins intimidant, on peut tout de suite commencer. On sent vraiment le côté user-friendly voulu par les auteurs. De la très bonne documentation, entre le wiki, le hgbook [http://hgbook.red-bean.com], et des tutoriels du type [http://hginit.com]

* git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]

C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.

Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.

Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.

Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)

En complément de l'article, voilà une success story qui se passe dans la division supercomputing de la NASA. Même si officiellement linux n'est pas l'OS de référence, en pratique il est bien présent!

http://www.gentoo.org/news/en/gwn/20051205-newsletter.xml#do(...)

Un des problèmes du C++ est comme tu le fais remarquer dans ton article est que l'ordre d'initialisation des données globales n'est pas défini par la norme.
En particulier, si tu stockes ton singleton comme une donnée statique de Manager::get, tu tombes pile dans ce cas de figure.
C'est pour cela qu'en général, on recommande de stocker un singleton sur le tas et de l'instancier à la volée la première fois qu'on le récupère. De cette manière, on ne court pas le risque de ne pas pouvoir l'initialiser parce qu'il a par exemple besoin qu'un autre singleton soit déjà instancié.
De plus, placer le constructeur en protected reste tout aussi "safe" et de cette manière tu te reserves le droit de disposer d'un autre singleton d'un type dérivé de Manager.

Je ne comprend vraiment pas cet acharnement contre les possesseurs de 4x4... Comme tu l'auras deviné, je suis l'heureux propriétaire d'une Porshe Cayenne, mon salaire d'architecte J2EE me permettant de m'octroyer ce petit plaisir. Et NON, JE N'AI PAS HONTE DE CELA!
D'abord, pour cette énième évocation du mythe d'une pseudo compensation phallique, c'est n'importe quoi (en tout cas en ce qui me concerne). Je m'étonne que tu ne mettes en avant que ce douteux argument d'individu aigri et jaloux tout en occultant la multitude d'avantages lié aux jeeps: sécurité, design, puissance etc etc... Sans parler du respect de l'environnement! Et oui... si tu réflechissais un petit peu, tu comprendrais que le prix élevé de tels véhicules les reserve (1) à des gens suffisemment riches donc éduqués pour comprendre les enjeux écologiques (2) à une minorité possédant des revenus élevés (=> peu de personnes). Après cette démonstration, Je pense que je n'ai plus à attendre de réponse de ta part.. A bon entendeur....

Soit dit en passant, est ce que quelqu'un sait si les admins de tuxfamily.org auraient par exemple prévu de permettre aux responsables des sites qu'ils hébergeaient de publier une nouvelle adresse?
Ca pourrait être sympa de savoir ce qu'est devenu tel ou tel site, non?
(exemple: slackware.tuxfamily.com => .... ?)

Tu ne devrais pas oublier non plus de toucher au copy-constructor si tu ne veux pas que ton compteur d'instance commence à délirer.
Le copy-constructor fourni par le compilo par defaut n'effectue en effet qu'une une copie bit à bit sans modifier ledit compteur.
Ok, j'arrive un peu tard sur le sujet, et tu es peut-être (probablement?) déjà au courant, m'enfin....

Non, bien sûr.
Je comprend tout à fait, que les gens refusent d'utiliser latex pour rédiger leur document.
Oui c'est un super outil, oui on obtient des documents de qualité pourvu qu'on s'en donne la peine, oui une fois qu'on le maîtrise ça va vite, oui latex est typiquement le genre d'outil adapté à la rédaction d'une thèse.
Cependant, comme tous les outils bien puissants, latex nécessite un plus ou moins gros investissement initial avant de commencer à obtenir des résultats adéquats.
Il est donc tout à fait légitime qu'il y ait une bonne quantité d'individus qui sont plus intéressés par le sujet sur lequel ils travaillent que par les outils qu'ils utilisent pour rédiger leur rapport.

Sans parler du fait que latex est comme word un outil. L'administration semble rechercher un standard, pas un logiciel. En l'occurrence les .doc qui sont en quelque sorte un standard de fait. (oui, je sais, demander des .doc cela revient quasiment à demander l'utilisation de word).

Plutôt que de pousser latex en avant, il serait préférable d'essayer de leur demander de promouvoir un format de fichier ouvert que les gens peuvent facilement générer. (non, pas .tex. Quoique!)

Oui mais pas vraiment en fait.

Quelqu'un de plus informé que moi pourra peut-être confirmer mais il me semble que freecraft est un moteur de jeu RTS.
En ce qui concerne les graphismes, ils me semble que les joueurs ayant acheté WCII pouvaient récupérer ces derniers et les utiliser avec. Les graphismes de bases (je crois qu'il y en a plusieurs) sont plutôt à des années lumière de ceux de Blizzard.
D'un autre côté, c'est vrai que les concepteurs de freecraft ne se sont jamais cachés de s'inspirer de WCII....

Ceci dit, j'ai du mal effectivement à comprendre en quoi un tout cela ferait de l'ombre à ce jeu. Ca doit faire longtemps que les ptits gars de chez Blizzard sont rentrés dans leurs frais et que les ventes portent surtout sur WCIII.
Si ça se trouve, il devait y avoir là-bas un type en charge de tout ce qui était juridique, qui devait s'emm** royalement et qui a décidé de prouver son "utilité" en trouvant un truc à faire. Parce que, comme je le répète, je ne vois pas la logique derrière tout ça

Hmf, ça me fait penser à Jordy tout ça: on prend une gamine, une musique répétitive et abrutissante, on colle des paroles débiles qui ne dépareillent pas et hop, on se fait un chti clip bien cheap.

Pour M6, l'investissement est proche de 0. Et quand on voit le succès qu'a eu en son temps Nana Mouscouri avec sa chanson "quand tu chantes" (dont je vous rappelle l'intégralité des paroles: "quand tu chantes, quand tu chantes, quand tu chantes c'est bien" ), c'est vrai que Tessa peut potentiellement faire un tube!

C'est un sujet qui a l'air très intéressant.. Mais pourquoi a t il été placé dans la catégorie Star War qui contient d'autres articles comme "envoyer son e-cvs à Georges Lucas", au lieu de le mettre dans la catégorie technologie???
Bon, c'est vrai que le petit icone avec le X-Wing donne tout de suite plus envie de s'intéresser à l'article, mais ça ressemble un peu à un technique pour attirer les lecteurs potentiels! ;)