Pour des petites quantités de données, une base SQL s'en tirera toujours. Par contre quand ça commence à grossir, ça peut faire très mal...
Peut-être pour des cas bien particuliers, je doute que l'on puisse généraliser comme ça (c'est un FUD !). Est-ce qu'il y a par exemple des benchs couchdb vs postgresql avec insertions atomiques, quelques contrôles d'intégrités, d'unicité et validité des données (une date est bien une date), le tout pendant qu'il y a des requêtes en lecture en parallèle ?
Sur le site de couchdb c'est assez clair : What it is Not : A replacement for relational databases.
Rien que le passage obligatoire par json ça ne doit pas être gratuit sur de grandes quantités de données. Si on prend une date par ex, j'imagine que c'est stocké en texte ? Qu'en est-il de l'occupation disque et mémoire ?
Autant je peux imaginer l'intérêt d'un tel système sur un cluster pour fournir des documents très différents en lecture seule, autant pour des données genre facturation je doute, surtout sur un grand nombre de données...
Je me souviens surtout des versions 4.x. Par contre il faut préciser que c'était le résultat qui était assez fiable, jamais l'éditeur (mais c'était tellement naturel qu'un éditeur plante qu'on n'y faisait pas plus attention que ça, comme tu dis, le ctr-s était de rigueur !)
En tout cas, je peux confirmer qu'avec VI + python, si on comprend également les temps de maintenance, y a pas photo, le gain de temps de dev est énorme face à windev. Je me souviens d'avoir participé à une formation sur apisoft xcs, c'était assez rigolo de voir les autres batailler pour arriver à lancer des fonctions sur oracle puis essayer d'afficher le résultat ! Le formateur entrain d'expliquer qu'il était indispensable d'utiliser je ne sais pas combien de couches. Pendant qu'en quelques lignes de python+cx_oracle je lançais les requêtes en question avec le résultat affiché instantanément... Ha oui, mais en console c'est pas du jeu, le client tout ça... Pas de problème, avec reportlab, une dizaine de ligne de code plus tard je sortais un pdf :-)
Windev est sorti à l'époque où il y avait un tas d'applications à passer de dos à windows. Il n'y avait pas beaucoup d'outils à l'époque et les développeurs n'étaient pas formés pour. Windev est très bien tombé. En plus les premières versions étaient assez fiables et novatrices, le développement était effectivement très rapide, même sans utiliser le RAD. Access aussi a cartonné à cette époque.
La diffusion des programmes ne demandait pas de licence, le cout était donc dérisoire pour une boite de dev.
Ensuite ils ont péniblement continué sur leur lancée, on ne peut pas leur enlever ça, ils ont un certain mérite quand même (presque 20 ans, et la boite 25 ans).
Aujourd'hui, effectivement avec les outils libres qu'on a, ça n'a plus beaucoup d'intérêt, surtout qu'ils ont un peu raté le virage web.
Je viens de faire un test en aveugle, café turc vs cafetière italienne. Même café, même dose de café, même dose d'eau, même tasse, pas de sucre.
Le résultat est vraiment différent, avec l'italienne, le café est plus amère et acide. J'ai pas d'expresso sous la main...
J'ai fait ça, en spécif gestion de prod pour 3 boites, c'est du python, interface web, sur base de données oracle/access (à cause d'un lien avec apisoft), mais facilement portable sur postgresql (que j'utilise d'habitude).
Pour la licence du produit lui-même, je suis pas tout seul à en décider et vu que c'est du spécif la question ne s'est jamais vraiment posée. Donc à voir avec ce que tu recherche exactement...
Pour des petites tasses, une cuillère à café de café, bombée. Je met une cuillère à café non bombée de sucre pour deux tasses. Bien sûr pour l'eau il suffit de mettre la quantité des tasses voulues. Je met tout en même temps, mais on peut aussi faire caraméliser le sucre avant de rajouter l'eau, pareil pour le café...
On prend une casserole, de préférence fine et allongée. On met l'eau, le café (le plus fin qu'on trouve) et le sucre, on chauffe (pas trop fort) jusqu'à ce que ça mousse. Juste avant que ça ne déborde on la retire du feu. On peut la remettre 2 ou 3 fois suivant les gouts.
Si ça bout trop vite, par exemple en camping où on ne peut pas régler le feu, il suffit soit de tenir la casserole à bonne distance, soit de remuer à la cuillère pendant la chauffe (si on tourne longtemps ça va donner un gout encore différent, intéressant).
Ensuite avant de servir on tapote la casserole pour faire descendre le marc. Pour ceux qui n'aiment pas avoir à manger en même temps on peut servir à travers une passoire fine.
Et tant qu'à rester libre, on achète du café zapatiste sans passer par les circuit commerciaux.
Comme en ligne de commande, les avantages sont multiples. Très léger et permet une infinité de variations possibles (quantité et choix de café, durée de chauffe...)
* Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
* Execution performance has improved by 15-70%, depending on benchmark.
* Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
* Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
* Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
* Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.
Python peut être extrêmement rapide avec psyco. La difficulté est qu'il ne suffit pas d'importer psyco, il faut aussi adapter son code pour en profiter réellement. Un code optimisé pour python seul ne le sera pas forcément pour python+psyco et inversement. C'est un peu comme en Java, si on fait gaffe on peut obtenir un code proche de la vitesse du C mais si on ne fait pas gaffe ça peut être catastrophique. Je ne sais pas ce qu'il en est avec ruby...
Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
Nous sommes quelques uns à traduire en ce moment le bouquin de mercurial, les premiers chapitres sont fait, tu peux aller voir http://belaran.eu/hgbook-fr-SNAPSHOT/read/
Le premier chapitre parle justement du choix d'un gestionnaire de sources
Au niveau impressionnant il y a également, shedskin, qui vient de sortir en 0.2 et qui compile (sous certaines conditions) un programme python en c++. http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
En python, les parenthèses ont priorité sur l'indentation, il est donc tout à fait possible de choisir son indentation au sein d'un appel de fonction, de l'écriture d'une chaine, de tests etc.
Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)
Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
Mais on en revient à ma remarque précédente que java est plutôt fait pour des projets d'une certaine taille et pas pour du quick and dirty.
Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
10000 est un choix arbitraire pour ne compiler que le code très utilisé et ne pas pénaliser le démarrage et la mémoire.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
Psyco vient de sortir. Pour l'instant il n'y a pas encore beaucoup d'info (support des générateurs), mais Christian Tismer, nouveau mainteneur (payé), promet une renaissance du projet !
Personne n'a trop parlé de l'appli, mais ça me semble important aussi. Vous ne trouvez pas curieux qu'un erp engendre autant de requêtes ?
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
Je crois que la sortie de cette version 3.1 est le signal pour montrer que la branche 3 est mure et que le portage des modules peut commencer sans crainte.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
Je me suis amusé à coder le problème des parcours de chevaux aux échecs qui doivent remplir une grille, en utilisant un code le plus semblable possible (sans utiliser les librairies spécifiques des différentes langages).
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
[^] # Re: Question bête
Posté par wilk . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
Peut-être pour des cas bien particuliers, je doute que l'on puisse généraliser comme ça (c'est un FUD !). Est-ce qu'il y a par exemple des benchs couchdb vs postgresql avec insertions atomiques, quelques contrôles d'intégrités, d'unicité et validité des données (une date est bien une date), le tout pendant qu'il y a des requêtes en lecture en parallèle ?
Sur le site de couchdb c'est assez clair : What it is Not : A replacement for relational databases.
Rien que le passage obligatoire par json ça ne doit pas être gratuit sur de grandes quantités de données. Si on prend une date par ex, j'imagine que c'est stocké en texte ? Qu'en est-il de l'occupation disque et mémoire ?
Autant je peux imaginer l'intérêt d'un tel système sur un cluster pour fournir des documents très différents en lecture seule, autant pour des données genre facturation je doute, surtout sur un grand nombre de données...
[^] # Re: Question bête
Posté par wilk . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
[^] # Re: Au siècle dernier...
Posté par wilk . En réponse au message Causes initiales du succès de Windev. Évalué à 2.
En tout cas, je peux confirmer qu'avec VI + python, si on comprend également les temps de maintenance, y a pas photo, le gain de temps de dev est énorme face à windev. Je me souviens d'avoir participé à une formation sur apisoft xcs, c'était assez rigolo de voir les autres batailler pour arriver à lancer des fonctions sur oracle puis essayer d'afficher le résultat ! Le formateur entrain d'expliquer qu'il était indispensable d'utiliser je ne sais pas combien de couches. Pendant qu'en quelques lignes de python+cx_oracle je lançais les requêtes en question avec le résultat affiché instantanément... Ha oui, mais en console c'est pas du jeu, le client tout ça... Pas de problème, avec reportlab, une dizaine de ligne de code plus tard je sortais un pdf :-)
# Au siècle dernier...
Posté par wilk . En réponse au message Causes initiales du succès de Windev. Évalué à 1.
La diffusion des programmes ne demandait pas de licence, le cout était donc dérisoire pour une boite de dev.
Ensuite ils ont péniblement continué sur leur lancée, on ne peut pas leur enlever ça, ils ont un certain mérite quand même (presque 20 ans, et la boite 25 ans).
Aujourd'hui, effectivement avec les outils libres qu'on a, ça n'a plus beaucoup d'intérêt, surtout qu'ils ont un peu raté le virage web.
[^] # Re: Typage statique/dynamique
Posté par wilk . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 1.
[^] # Re: En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 1.
Le résultat est vraiment différent, avec l'italienne, le café est plus amère et acide. J'ai pas d'expresso sous la main...
# libre, gratuit ou basé sur le libre ?
Posté par wilk . En réponse au message Gestion de temps du personnel. Évalué à 1.
Pour la licence du produit lui-même, je suis pas tout seul à en décider et vu que c'est du spécif la question ne s'est jamais vraiment posée. Donc à voir avec ce que tu recherche exactement...
[^] # Re: En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 1.
[^] # Re: En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 2.
# En ligne de commande : le café Turc
Posté par wilk . En réponse à la dépêche Nespresso attaque Chacun son café. Évalué à 10.
Si ça bout trop vite, par exemple en camping où on ne peut pas régler le feu, il suffit soit de tenir la casserole à bonne distance, soit de remuer à la cuillère pendant la chauffe (si on tourne longtemps ça va donner un gout encore différent, intéressant).
Ensuite avant de servir on tapote la casserole pour faire descendre le marc. Pour ceux qui n'aiment pas avoir à manger en même temps on peut servir à travers une passoire fine.
Et tant qu'à rester libre, on achète du café zapatiste sans passer par les circuit commerciaux.
Comme en ligne de commande, les avantages sont multiples. Très léger et permet une infinité de variations possibles (quantité et choix de café, durée de chauffe...)
[^] # Re: Depuis le début
Posté par wilk . En réponse à la dépêche Proposition de moratoire de plusieurs années sur le coeur du langage Python. Évalué à 1.
http://code.google.com/p/unladen-swallow/wiki/Release2009Q3
* Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
* Execution performance has improved by 15-70%, depending on benchmark.
* Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
* Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
* Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
* Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.
Et sur le blog de pypy les résultats annoncés sont pour le moins impressionnants...
http://morepypy.blogspot.com/
[^] # Re: Depuis le début
Posté par wilk . En réponse à la dépêche Proposition de moratoire de plusieurs années sur le coeur du langage Python. Évalué à 1.
Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
# hgbook en français
Posté par wilk . En réponse au message A la recherche du meilleur outil .... Évalué à 2.
Le premier chapitre parle justement du choix d'un gestionnaire de sources
[^] # Re: Psyco V2
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
http://code.google.com/p/shedskin/ sur des petits bout de programme j'ai réussi à obtenir un gain de 2x par rapport à psyco (j'en ferai un petit journal) !
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 4.
Par exemple pour effectuer une requête, je fait souvent quelque chose comme ça (des tirets à la place des espaces)
query('select mon champ'
- - - - - - 'from matable'
- - - - - - 'where macondition'
- - - - - - 'order by montri',
- - - - - - - - - monparam1='cecicela',
- - - - - - - - - monparam2='etci')
Pourquoi vouloir associer systématiquement quick et dirty ? L'exemple que l'on a cité montre que l'on peut faire plus long et plus sale en même temps ! Effectivement Perl est compact au détriment de la lisibilité, mais ce n'est pas une généralité. En python on a du quick and clean ! Je comprend que ce ne soit pas évident, comme tu dis, en java on a plutôt tendance à en rajouter pour que ce soit plus clair. On a besoin d'un commentaire pour dire que là, attention, on va ouvrir un fichier...
En parlant de reprise de code, j'ai réécrit en python toutes les applis que j'avais faites en java et C. Le résultat est simplement un code beaucoup plus concis, plus clair et beaucoup plus facile à maintenir. Mais ce qui est important à noter c'est que j'ai pu garder exactement les même architectures. Globalement les application ont donc conservées ni plus ni moins la même complexité.
Par contre, par la suite, le temps gagné sur le code lui-même (ou plutôt plus perdu en saisie, en jonglage avec l'éditeur, en scrolling de l'écran, en tonne de doc à lire...), permet de se concentrer d'avantage sur l'architecture et de l'améliorer. C'est pour cette raison que l'on y gagne d'autant plus sur des applis particulièrement complexes (c'est pas vraiment la taille qui joue sur la maintenance).
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
Au contraire ! Autant passer 5 minutes au lieu de 2 sur un petit programme ce n'est pas gênant, autant passer 5 mois au lieu de 2 sur un gros ça commence à l'être...
Pareil pour la taille du code, 5 lignes au lieu de 2 ça ne change pas grand chose, 5000 au lieu de 2000 ça commence à être dirty. 5 go de ram au lieu de 2 etc etc...
[^] # Re: Ça me brule les lèvres...
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
# Psyco V2
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 3.
http://mail.python.org/pipermail/python-announce-list/2009-J(...)
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 4.
[^] # Re: mysql=oracle donc poubelle
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
Donc btrfs >= oracle
[^] # Re: ton ERP
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
[^] # Re: Quand switcher ?
Posté par wilk . En réponse à la dépêche Python arrive en version 3.1. Évalué à 5.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
[^] # Re: Ça passe très bien :)t
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
c 5s
gcj 7s
java 7s
python2.5 + psyco 18s
python2.5 303s
java est extrêmement performant s'il est utilisé comme du C. On retrouve ces résultats sur http://shootout.alioth.debian.org/
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.