wilk a écrit 1245 commentaires

Python en lui-même n'a aucune date de péremption, c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ? Si quelque chose t'en empêche ce sera les composants du système, les librairies en C qu'il utilise etc. Mais pas le langage lui-même.

Pour ce qui est du courage des développeurs pour suivre les upgrades du langage, rassure toi c'est trivial dans la grande majorité des cas. Surtout, c'est ridicule par rapport aux problèmes de compatibilités extérieurs (libs, système, bdd, utilisateurs...)

Je suis tout à fait d'accord, tout ce que l'on peut vérifier automatiquement est toujours bénéfique, si j'ai bien compris dialyzer est un peu l'équivalent de pylint ?
Je n'apprécie pas quand c'est au détriment de la lisibilité du code ou que cela m'empêche de profiter du côté dynamique du langage. Pour revenir au langage idéal, qu'il devine tout seul les erreurs de type quand il le peu et ce sera très bien mais qu'il ne m'oblige pas à lui mâcher le travail. Je ne me plaint pas que python sache vérifier la syntaxe avant l'exécution (j'utilise vimflakes par ex).

Je n'ai pas d'historique de code qui me vient comme ça à montrer (je ne fais que du dev spécifique), mais j'ai regardé, honnêtement j'ai quelques cas d'erreurs de types qui reviennent, string/unicode et float/Decimal. Mais même dans ces cas bien souvent le compilateur n'aurait rien vu car les données arrivent d'un sgbd...

Pour ce qui est de projets réels, professionnellement je suis passé par C et Java avant Python, et au début je n'y croyait pas non plus, mais maintenant, sur plusieurs années, sur parfois des programmes exactement identiques (réécrits), le temps de maintenance est drastiquement réduit. Pour mon usage c'est le langage idéal.

Par contre si ce n'était pas pour le boulot et donc des contraintes de rendement, je préfèrerai le C pour son côté plus proche du système.

GLMF ce n'est pas une secte ou un parti politique, c'est un ensemble de personnes qui écrivent sur ce qu'ils font avec GNU/Linux.

En l'occurrence ils se mettent à dire ce qu'ils ne font plus avec GNU/Linux !

Python est d’une lenteur effroyable…

Tu as essayé pypy ?

Sur un algo de calcul d'itinéraires j'ai un gain d'un facteur 10 !

Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.

Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème. Du reste c'est plus pour aider le compilateur que le développeur, sinon on obligerait à nommer les arguments en appel de fonction par exemple c'est une erreur beaucoup plus commune et qui passe tranquillement la compilation.

Par ex ma_fonction(int a, int b), si on inverse a et b le compilateur n'y verra rien. Si a est censé être plus petit que b il n'y verra rien non plus. En python si on applique la règle d'être explicite on écrira ma_fonction(plus_petit, plus_grand) et on appellera toujours en nommant les paramètres ma_fonction(plus_petit=.., plus_grand=...), c'est beaucoup plus sûr et surtout ça s'adresse au développeur, pas au compilateur. Le compilateur lui il se débrouille très bien tout seul, il n'y a qu'à voir les prouesses de pypy.

C'est important les humains qui changent les api justement...

L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.

Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.

Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)

On parle d'auto-hébergement quand la personne (physique ou morale) gère elle-même le fonctionnement au jour le jour d'une infrastructure qui est dans le même bâtiment qu'elle

On dit quoi quand la personne gère elle-même le fonctionnement mais pas forcément dans le même bâtiment ? Parce que c'est quand même le sujet... Sauf erreur, Denis parle d'exim vs gmail, pas tant d'exim sur adsl vs gmail.
On peut facilement passer d'un hébergement adsl vers un hébergement dédié si on a des soucis de disponibilité matériel, sans pour autant remettre en cause ce qui nous concerne avant tout, la partir logiciel. Comme la partie logicielle est facilement redondante et cryptable le soucis des données est bien moindre.

On a bien compris, pour toi les mails ne sont plus ton affaire, tu les sous-traite à un prestataire de service, comme tu prendrai un taxi au lieu de ta voiture que tu répare toi-même. Et donc tu te fout pas mal de savoir si la voiture du taxi est réparable ou pas ni si le chauffeur note dans son carnet où tu te rends et à quelle heure. Mais dans ce cas ce qu'on ne voit pas c'est qu'est-ce que ça peut bien faire dans un journal qui traite de la mécanique à faire soit-même ?

Si on trouve que gérer ses mails soit-même est une perte de temps, on ne va perdre son temps à lire des journaux comme linux mag non plus. Lorsqu'on fait le choix de gérer ses mails généralement c'est qu'on a une bonne raison. Le temps et la difficulté sont secondaires dans ce cas.

On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...

La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...

Il faut plutôt se demander pourquoi un logiciel serait non libre. Quel est l'intérêt d'un logiciel non libre ? Le projet GNU a démarré parce que Richard a demandé un bout de code à un copain et que pour la première fois il le lui a refusé.

Aujourd'hui on peut changer la roue de son vélo tout seul et on peut s'échanger des recettes de cuisine, si demain on m'empêche de le faire, je vais râler, est-ce que j'ai besoin de me justifier ? de m'appuyer sur une philosophie ? de savoir peser le pour et le contre de telle variation ?

Donc le mois prochain tu nous fais un gros titre "Comment se débarrasser de gmail" et t'es pardonné. Sinon on appelle nos potes anonymous et on t'inonde de mails 8-D

Tu veux dire que Denis, non seulement ne se serait pas aperçu qu'en comparant Exim à Gmail il comparait un moteur avec une carrosserie mais qu'en plus il ne se serait pas aperçu qu'il lançait un énorme troll ?
Vu la qualité de ce qu'il a déjà fait auparavant, il sait très bien ce qu'il fait, et c'est justement ça qui est choquant. Qu'un admin cède à la facilité au détriment de ses convictions, c'est humain, mais qu'il s'en vante et incite les autres à faire pareil c'est pitoyable.

Il faudrait mettre ce journal en dépêche pour faire contre-poids !

L'abattement forfaitaire de 34% identique pour tous, faut avouer ça nous arrange particulièrement (nous informaticiens)... Pour d'autres professions les frais sont généralement énormes la première année (le matériel) sans pour autant justifier d'être au réel (surtout la première année)...

A l'époque du forfait on ne jouait pas forcément la bidouille. Le truc c'est que les impôts avaient l'habitude des professions courantes mais pas des nôtres, donc il trouvait nos frais ridicules, c'est pour ça que ce n'était pas difficile de faire baisser les bénéfices.

J'ai bien vu que le CFE était calculé d'une étrange manière. Ce que je voulais rappeler c'est qu'avant ce statut celui qui ne touchait rien c'était plus proche de 3500 € que 350 € !

En tout cas aujourd'hui, AE + logiciel libre c'est vraiment le duo gagnant pour démarrer. Profitez-en !

L'AE ne paye pas ce qu'il doit justement puisqu'il n'y a aucune prise en compte des frais, le pourcentage est encore plus arbitraire... Au forfait il y avait au moins une chance.

La CFE c'est peanuts par rapport à ce qu'était le plancher de charges.

Les ptits jeunes, peut-être n'avez-vous pas connu le régime du "forfait", "c'était mieux avant"tm, voilà comment ça se passait concrètement. Une fois par an je prenais rendez-vous avec l'inspecteur des impôts, je lui montrai combien j'avais gagné dans l'année, je lui disais si j'avais fait des dépenses particulières et ensemble on définissait un bénéfice à la louche ! Mais alors une louche, une vraie, parfois le résultat frisait avec le zéro alors que je vivais (modestement) de ça !
Mais mais mais, il n'y avait pas le statut AE, du coup un plancher s'appliquait aux charges, assez dissuasif pour démarrer.

Pour tes frais oui, c'est bien de récupérer la tva...
J'ai vu sur ton blog que tu conseillais la tva simplifiée, je ne trouve pas que ça soit si simplifié que ça, il faut verser des acomptes et c'est régularisé à la fin de l'année, si on n'a pas des revenus très réguliers d'une année sur l'autre on est en déséquilibre... En revanche à la tva réelle on paye tous les mois sur les opérations du mois, c'est beaucoup plus simple, ça se rapproche même plus du statut AE, le formulaire à remplir est vraiment simple.

D'après un ami contrôleur d'assurance. Pour les autodidactes, et je pense qu'on n'est nombreux dans ce cas autour des LL, en cas de pépin important on sera toujours considéré comme fautif d'avoir fait une prestation dont on n'a pas les compétences (pas le diplôme)... Les licences libres sont bien pour ça car elles dégagent entièrement la responsabilité du développeur. Il faut facturer la "mise à disposition" et non pas la "mise en place" par ex. Pour de l'admin sys c'est plus difficile, c'est une bonne idée de faire payer le client directement au fournisseur mais ça n'est vraiment pas pratique...

Pour info l'inscription AGA il faut la faire avant fin mai de l'année en cours. Ca veut dire qu'un auto-entrepreneur susceptible de dépasser après mai à tout intérêt à s'inscrire au cas ou...

Quel problème pour la TVA puisque tu ne la facture pas ? Par contre il faut bien que tes clients comprennent que le jour où tu changera de statut il faudra que tu la leur facture en plus ! Si c'est des entreprises ça ne posera aucun problème par contre pour les particulier oui...

Comment tu fait pour les serveurs que tu loue ? vu que tu ne peux pas les passer en charge, est-ce que tu fait payer tes clients directement à ton fournisseur ?

C'est l'intégration de code (dans du xml) tout court qui n'est pas aisée ! De fait, dès que le code dépasse 2 lignes généralement il est dans un fichier à part. Au pire il est dans les balises script et il a plutôt intérêt à être correctement indenté, que ce soit indispensable ou non.

Pour le bug tracker c'est pareil ?

Si plusieurs personnes mettent leur branche en ligne il y aura plusieurs wiki simultanés à synchroniser par la suite ? En tout cas l'idée est intéressante car on fait souvent des aller-retour entre un wiki en ligne et la doc, ça mériterait d'être expérimenté sur d'autres dvcs.

Comment on modifie le wiki et le bug tracker ? Sur leur site je ne vois pas la possibilité en ligne, est-ce qu'il faut passer par une branche et éditer sur cette branche hors ligne comme on le fait en éditant le fichier todo ou une page de doc sur un projet classique ?

C'est dans le log final que ça change, au lieu d'avoir p1 p2 merge p3 p4 merge p5 p6 merge j'aurai p1 p2 p3 p4 p5 p6 merge

A priori je ne cherche pas à réécrire l'historique... J'utilise rebase, pour rester synchro avec la branche principale sans avoir à faire des merges à tout bout de champ (hg pull --rebase va récupérer ce qui me manque de la branche principale et remettre mes patchs à la fin). Eventuellement j'utilise rebase --collapse pour regrouper mes patchs en un seul avant de tout renvoyer sur la principale.

Je vois qu'il y a une extension histedit http://mercurial.selenic.com/wiki/HisteditExtension qui a l'air de se rapprocher du rebase git mais je ne l'ai jamais utilisée.