wilk a écrit 1168 commentaires

Autocompletion pour les langages trop verbeux [...]

Ca n'est absolument pas une faiblesse du langage, au contraire, c'est la nature du langage qui permet d'obtenir une autocomplétion intuitive

Simplement, plus il y a du texte à taper plus ça devient indispensable. En python je n'utilise jamais d'autocompletion (je pourrai), en java tout le temps... C'est juste une constatation, quand je programmais en Java j'avais besoin d'un ide le plus sophistiqué possible, en python j'utilise vim avec très peu de plugins et pourtant c'est pour exactement les mêmes programmes (réécris). Par contre je ne pourrai pas utiliser Python sans un ide avec l'auto-indentation.

quand on choisit une plateforme de développement, on prends en compte le langage et les outils.

L'ide est souvent là pour compenser les faiblesses du langage. Autocompletion pour les langages trop verbeux, auto indentation pour python, correction de syntaxe à la volée pour syntaxe trop $;]}, accès rapide à la doc quand c'est pas intuitif...

Est-ce qu'il est prévu de pouvoir utiliser le webmail seul ?

ton programme prend 10 minutes à se lancer

Déjà là ça commence mal...

Je me pose également une question existentielle. Pourquoi les développeurs donnent tant d'importance aux erreurs de typage lorsqu'ils en sont protégés et non ceux qui devraient en être les victimes ? Pour ma part, non plus, la seule fois que je me souvienne d'avoir été embêté avec des erreurs de typage c'est quand je suis passé en unicode. Mis à part ça je ne me souviens pas que ça m'ait posé de problème, quelqu'en soit le langage.

Il faut maintenant regarder du côté de PyPy si on a besoin de performance pure du langage (ce qui est rarement le cas). Les résultats sont considérables dans certains domaines et ça continue à progresser sans arrêt.
Sur un programme de calcul d'itinéraire on a eu un facteur supérieur à 10 sans changer une ligne de code !
Ce qui est marrant dans ce projet c'est qu'au départ le programme était écrit en C, il était trop lent et trop complexe, il a été réécrit en Python pour servir de prototype avec d'autres algorithmes. Résultat le prototype est allé 10x plus vite qu'en C car la facilité de programmation à permis de se concentrer sur l'algo, on l'a gardé comme ça en prod pour faciliter la maintenance (qui est finalement nulle). On a été tenté de le transcrire en Java mais des tests sur le même genre d'algo n'ont montré qu'un gain très faible pour une complexité bien supérieure.

http://speed.pypy.org/

Une durée longue de release est à double tranchant. D'un côté ça limite le nombre d'upgrade mais d'un autre côté ça les rends plus difficiles, avec d'avantages de changements d'un seul coup. Inversement des releases fréquentes limitent le nombre de changements pour chacune et les rends plus simples, parfois insignifiantes. Je me souviens encore de la migration où on est passé d'exim3 à 4 apache 1 à 2 et iso8859 à utf8 ! une horreur ! En revanche de la lenny à la squeeze pour moi ça a été insignifiant.

Bof c'est plutôt un compliment dans le cas d'une migration, ça signifie qu'elle est réussie !

De quelles possibilités tu parles ? Comment est géré la purge du cache par ex ?

L'authentification de l'utilisateur était gérée en javascript + cookies non ?

Ta calculatrice, quand tu tapes 1/2, elle répond quoi ? Et bien maintenant Python répond pareil.

Dans ce cas ça n'est pas des flottants qu'il faudrait utiliser mais des décimaux.

Ma calculatrice ne m'indique pas

In [2]: 2+.4
Out[2]: 2.3999999999999999

Et textile ? Peut-être pas pour les commentaires, mais pour les dépêches ça pourrait être appréciable.

NGINX n'est pas fait que pour les sites avec fort traffic, il est également particulièrement adapté aux petites configs genre serveurs virtuels. C'est peut-être de cette "mode" qu'il s'agit. C'est à dire de passer d'hébergements mutualisés avec php à des hébergement sur serveurs virtuels et des applis web en mode proxy pour utiliser autre chose que du php.

Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.

Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.

Bruno, tu as démontré que tu pouvais faire faire beaucoup mieux que la plupart des boites spécialisées. En tant que vieux briscard de la prog, je suis impressionné et je te tire mon chapeau pour cette mise en production.

Moi c'est le scrolling d'un commentaire nouveau à l'autre qui me donne le mal de mer...

Autrement dit il faut aller voir le code ?

Je préfère pouvoir importer à l'aide d'une API d'une part pour pouvoir comprendre l'outil et aussi parce que j'ai fait beaucoup de spécifs qui en ont besoin (par exemple de la réplication agence/siege, prise de commande à distance etc.) et j'aimerai bien voir ce que ça donnerait avec openerp.

J'ai également un peu de mal avec la doc développeur (que je n'ai fait que survoler je l'avoue). Par exemple pour commencer j'aimerai importer des données clients, produits, devis, factures etc... Je pensais utiliser xml-rpc, mais où se trouve la liste des fonctions accessibles ? Sinon je pensais taper dans la base postgresql, mais je ne trouve pas non plus de description des tables...

Je viens de voir ça passer dans les annonces

https://launchpad.net/pyexiv2

Merci de t'être intéressé à mon code ! Je viens de l'essayer, sauf erreur ton code est beaucoup plus rapide avec pypy mais moins avec cpython ou psyco. Tu confirmes ?

ton code
cpython 124s
pypy 13s
psyco 4s

le mien
cpython 86s
pypy 107s
psyco 1s

J'ai testé sur un petit algo qui recherche les différentes possibilités de déplacement d'un cheval sur un damier sans repasser par la même case... Je ne sais pas si c'est très clair, ça donne par ex sur un damier 3x3

147
6X2
385

J'ai écrit le code pour python, c, php, java et différentes variations python.

Avec pypy1.4 il n'y a quasiment pas de différence avec cpython, en revanche il y a énormément de différence avec psyco... (de 3m contre 2s), je trouve curieux que ce genre de code n'ait pas été plus optimisé, il faudra que je leur en parle...
http://hg.flibuste.net/libre/games/cheval/file

En revanche je viens d'essayer sur petit programme de calcul d'itinéraires (un vrai programme en prod), c'est impressionnant, le résultat est similaire qu'avec psyco, le rapport est de 1 à 100 ! C'est très prometteur.

Ruby est un langage bien plus fun que Python : je pense que la communauté Python est trop sérieuse

En tant que développeur en Python pour le boulot, je confirme tout à fait ton point de vue. J'ai justement choisi Python pour aller droit au but sans me laisser distraire. Pour les loisirs ou r&d ça m'ennuierait sûrement.

Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

Le typage est un critère de maintenabilité ? Pour un compilateur peut-être, pour un humain c'est déjà moins sûr.

C'est plutôt la concision et la clarté du code qui compte. (cf l'étude d'IBM qui fait un rapprochement tout bête entre le nombre de lignes et le nombre de bugs).

La disponibilité d'un IDE potable me semble aussi un minimum si on veut que les développeurs se concentrent plus sur le fond que la forme (autocomplétion, refactoring, affichage des erreurs à la volée)

De la même manière, plus le code va être concis, explicite et clair, moins l'ide va avoir d'importance.

Oui, c'est un casse tête quand il y a beaucoup de parties dynamiques...

Une solution que j'utilise maintenant, en complément, c'est de générer (à la volée toujours) un certain nombre de données dans des fichiers html ou json qui sont appelés en javascript/ajax.

Même question pour la base de données. Est-ce un choix technique ou une préférence personnelle ?

Si mes souvenirs sont bon, la version actuelle avec templeet utilisait (je ne sais pas si c'est toujours le cas) la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj. Personnellement j'utilise ce système très souvent, avec nginx et une appli en proxy (python) c'est redoutablement simple et efficace.

Quel système de cache est utilisé dans cette nouvelle version (et qui devrait rendre caduque les questions sur la rapidité du langage...) ?