Antoine a écrit 5722 commentaires

a.out c'est juste le nom de l'exécutable produit par défaut, en quoi est-ce "obsolète" ??

De ce que j'ai lu, la musique est différente avec InnoDB. Et MyISAM a tellement d'autres limitations que je ne suis pas super motivé pour l'utiliser.

Certes, il faut se familiariser avec ces limitations. Il faudrait faire des tests de performance poussés sur MyISAM vs. InnoDB vs. autre chose pour voir dans quel cas le jeu en vaut la chandelle.

et qui peut surprendre parce que ce n'est pas dans l'ordre naturel des choses

Mouais, je ne savais pas que les SGBD avaient à voir avec un quelconque « ordre naturel » :-)
Qu'il y ait des idiomes utiles voire recommandés, je ne le nie pas, mais on peut très bien vivre sans, de même que Postgres (ou un autre SGBD) peut très bien vivre sans laisser le choix de 5 (4 ? 6 ? j'ai arrêté de suivre) moteurs de stockage différents.

Pour rester dans le psy, je trouve assez culotté d'appeler "americanparano" le nom d'un blog antiaméricanisme primaire avec un bouquin à vendre.

Ah, "antiaméricanisme primaire"... l'anathème qui tue toute discussion. Marrant, si tu lisais le bouquin - dont quelques extraits sont dispos sur le blog -, tu verrais que sa réflexion (certes pas vraiment pro-américaniste, y a pas de doute là-dessus) est loin d'être aussi "primaire" que les dix lignes de réflexion dont tu nous gratifies :-)

D'ailleurs, l'auteur en question - cet "antiaméricain primaire" - ayant passé plusieurs années de sa vie aux USA, il doit être totalement masochiste. Enfin bref.

Ouais, il est monté à l'envers des français, la preuve, il a réussi à se faire élire

Résultat d'une communication extrêmement habile et d'une opposition extrêmement médiocre. Sarkozy n'est pas en place depuis un an, et il vient de tomber à 47% d'opinions favorables. Chirac, bien qu'élu par défaut contre Le Pen et usé par un premier septennat, a résisté beaucoup plus longtemps.

http://fr.news.yahoo.com/afp/20080120/tpl-politique-gouverne(...)

Oui, pas comme tes trolls :-)

Rigolo. Apparemment il y a un groupe de fanboys anti-MySQL qui ne supporte pas qu'on mette en doute leurs préjugés et qui s'échinent à voter contre les messages qui leur déplaisent :-))

> Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

Ah bon ? Je serais curieux d'entendre une justification.
Par exemple, une table hash a des opérations en O(1) temps amorti, ce qui donne un O(n) pour extraire les éléments uniques d'un ensemble, même s'il n'est pas trié a priori.

La réponse de Jürg (le développeur principal) à tout ajout de syntax est clair, ce qui n'est pas utilisé pour du C#, ne doit pas l'être pour du Vala (j'ai perdu le lien).

Voilà qui promet une grande évolutivité :-))

Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C

La vraie question, c'est de savoir à quoi ça sert.

Si Vala (resp. C++) permet de programmer plus sûrement et plus rapidement qu'en C, et qu'il génère du code rapide et compact comme du C, alors il n'y a aucun intérêt à appeler une méthode Vala (resp. C++) depuis du code C plutôt que de directement faire du Vala (resp. C++).

C'est exactement ce qui se passe pour KDE : en pratique tout le monde se fout que les kdelibs ne soient pas facilement invocables en C. Faire du C/gobject plutôt que n'importe quel langage orienté objet dès l'origine, faut être sérieusement maso.

Vala a une syntaxe C#-like, ce qui n'est pas très loin d'une syntaxe Java-like...

Pour info on n'utilise cette structure que rarement car l'intérêt en est limité (juste pour des questions de performances).

C'est ça les "TreeNode#" dans ton programme ?

Eh bien, cher Gniarf, tu es le bienvenu pour proposer un remplaçant avec les mêmes fonctionnalités et la procédure de migration qui va bien. Vas-y, on t'écoute :)

En tout cas ce n'est pas un pays d'extreme droite au sens francais qui signifie plus ou moins "nationaliste, raciste et populiste". C'est juste economiquement que le pays est bien plus a droite que la France.

Juste économiquement ??
Certes le racisme n'y est pas institué en doctrine officielle, mais c'est quand même un pays où un bon paquet de noirs passent une partie de leur vie en prison, où il y a un racisme latent et persistant dans beaucoup d'Etats du Sud (j'imagine que tu as vu passer cette affaire qui a fait gros bruit, où des enfants noirs ont été menacés parce qu'ils avait osé s'asseoir à l'école sous un arbre qui était jusque là réservé aux enfants blancs...).
Côté nationalisme il suffit de voir ce qu'a subi la France (en insultes, en menaces diverses et variées) du jour où elle a osé ne pas être d'accord avec eux au Conseil de Sécurité, c'est carrément délirant.

(j'évite de discuter le terme de populisme qui est beaucoup trop galvaudé, notamment par les médias dominants)

Ca ne fait pas forcément des USA un pays « d'extrême-droite » (les classifications ont très vite leurs limites), mais réac, buté et cocardier, oui.

Voici sinon un article plus intelligent et plus riche sur le sujet :-)
http://americanparano.blog.fr/2008/01/12/piqure_de_rappel~35(...)

DISTINCT est un tri.

Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques. D'ailleurs il est parfaitement possible d'extraire les éléments uniques d'un ensemble sur lequel n'existe pas de relation d'ordre, c'est-à-dire sur lequel il est impossible de faire un tri.

Par ailleurs un index sur une table MyISAM est déjà trié par construction, puisque c'est un b-tree.

Faire une somme a également un coût.

D'une part ce n'est pas une somme, c'est un décompte, de l'autre cela n'a pas de coût si l'information est déjà stockée par le moteur sous-jacent. Par exemple COUNT(*) sur une table MyISAM retourne immédiatement.

il y a quelques chances que ton index possède une contrainte UNIQUE

Relis l'exemple original avant de dire n'importe quoi. On ne met pas de contrainte UNIQUE sur le numéro de forum associé à un message...

Je vais te laisser troller dans ton coin, tu es là visiblement pour casser du MySQL sans même être capable de comprendre quelques notions d'algorithmique de base (comme : DISTINCT n'est pas un tri), la discussion n'a pas grand intérêt.

Tant que personne ne porte SPIP dans un autre langage que PHP, Libroscope n'a pas trop le choix :-)

utiliser une fonction d'agrégat (COUNT) sur une opération de tri des résultats d'une requête (DISTINCT)

DISTINCT n'est pas un tri. Si la colonne est un index, COUNT DISTINCT va simplement compter le nombre de clés dans l'index, ce qui normalement est très rapide (avec MyISAM en tout cas - fais un EXPLAIN SELECT pour t'en convaincre). Si ça ne te plaît pas, je m'en fous et tu peux continuer à te marrer en refusant de voir la réalité en face :-))

Le contournement poussif d'une limitation absurde propre à MySQL

Très drôle. Si MySQL permet de faire rapidement un COUNT(DISTINCT mon_index) alors que ses concurrents imposent d'utiliser un trigger pour mettre en cache la valeur en question, ce n'est pas MySQL qui impose un "contournement poussif".

Il me semble urgent d'en rire.

Tourner sept fois sa langue dans sa bouche avant d'intervenir me semble plus approprié dans ton cas.

Tu as le droit de t'esclaffer bruyamment, mais mettre un trigger sans raison valable c'est faire de l'optimisation prématurée, et aussi rendre ta BD plus difficile à gérer puisque plus compliquée.
Après chacun est maître de ses propres développements et a le droit de concevoir des usines à gaz si ça lui chante :-)

(soit dit en passant, le moindre des respects quand on répond à un thread est d'exprimer ses idées en français au lieu de se contenter d'un lien vers un message humoristique)

Il faut éviter la fiction de l'« outil de développement de rêve » : de même qu'il n'y a pas de silver bullet technique (i.e. ce n'est pas en adoptant tel nouveau paradigme qu'on résout tous les problèmes), il n'y a pas d'outil miracle qui élimine tous les soucis de la programmation. La programmation est par construction une activité intellectuellement complexe et elle le restera.

De mon côté ce qui me plaît c'est d'avoir de petits outils légers et souples. Comme je vis dans le monde Python je choisirai mes exemples dans ce monde-là :
- un interpréteur interactif avec complétion des symboles locaux
- une commande help() dans ce même interpréteur interactif qui fonctionne sur n'importe quel objet
- un exécutable "pydoc" qui fait la même chose que le help() suscité, mais depuis bash (exemple : "pydoc unittest")
- la possibilité d'écrire simplement, et d'exécuter tout aussi simplement des tests unitaires (comme avec nose ou py.test)
- la possibilité de faire rapidement des packages ou bibliothèques, avec gestion de certaines métadonnées de base (setuptools)
- la possibilité d'installer facilement des bibliothèques ou outils packagés avec l'outil sus-mentionné (easy_install qui lit les métadonnées depuis http://pypi.python.org/ )
- des conventions saines définies par le langage, par exemple pour les exceptions
- des fonctions intégrées à la bibliothèque standard, pour faire du logging par exemple, voire du profiling

Certains, selon leur goût, ajouteront probablement un debugger intégré. Ne pas devoir recompiler (faire un build séparé) pour avoir la possibilité de debugger est certainement un très gros plus.

Le tout est d'avoir un environnement habitable et, comme dans une maison, cela veut dire combiner de multiples éléments de mobilier bien conçus, et non chercher la solution ultime (l'analogie originale est de Joel Spolsky je crois).

bref, il me semble qu'on fonce dans la bull 2.0

MySQL existe depuis beaucoup plus longtemps que Facebook et a un "business" sérieux et robuste. Je ne vois pas trop le rapport avec le Web 2.0, même si le prix d'acquisition est peut-être élevé.

mais le produit final est moins rapide que c'il est developpez en C d'il y a 5 ans

Sauf que ton produit final écrit en C par le même genre de développeur médiocre aurait pris beaucoup plus de temps à développer, serait perclus de fuites de mémoire, de débordements de tampons, de plantages aléatoires, etc.

Aujourd'hui, Java et MySQL ne font pas bon ménage

Pauvres petits chéris Javaïstes, ah lala.

c'est lutter avec des détails obscurs de configuration du type (extrait de la doc du driver jdbc mysql)

Ca n'a pas l'air si « obscur » que ça vu que c'est clairement documenté dans l'extrait que tu as cité. En même temps, c'est vrai que les fichiers de config de MySQL sont pas en XML, on comprend que ça puisse dérouter :-)

Si on imagine un forum avec des topics et des messages. On pose un trigger sur la table messages pour mettre à jour le nombre de messages dans un forum.

Si le forum_id dans la table messages est un index, le COUNT(DISTINCT forum_id) sera très rapide, donc ton trigger n'a pas grand intérêt.

Justement, si tu dois te taire pour avoir l'autorisation d'utiliser le logiciel, c'est un restriction des libertés normalement fournies par un logiciel libre.

Je ne sais pas si elles manquent d'air, mais en tout cas elles en brassent.

Une des possibilités c'est d'améliorer OpenOffice.org Base en intégrant les outils MySQL.

Ca vaut bien au moins 1 milliard de dollars ça, surtout qu'ils ont sûrement pas des ingénieurs compétents pour déployer un MySQL chez Sun.

Ou alors ils veulent réécrire MySQL en Java.

Dépêche bien intentionnée mais il y a quelques fautes malheureuses sur le nom du projet, c'est BOOOoop's et non BOOop's (il manque un Oo).