barmic a écrit 10455 commentaires

Les premiers à blâmer sont les politiques eux-mêmes

Sans vouloir dire qu'ils n'ont aucun tord, ça semble bien plaire à leurs électeurs vu que c'est publique et que ça fait des dizaines d'années qu'on revote pour eux.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Ouuuuuh les sacro saint impôts ! Dans quel monde vivrait-on si demain les gens cessaient de payer les impôts et se mettaient a produire des crypto monnaies équilibrés?

Sans route, sans écoles, sans hôpital, sans médecin, sans police, sans magistrat/juge, etc

Les ultralibéraux, c'est tous les même, sont les derniers à payer, mais les premiers à utiliser les résultats.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Sincèrement les fuites de capitaux légales ou non, on en a trop connu, trop entendue parler pour ne pas être blasé. Ça donne vraiment l'impression qu'à partie d'une certaine sommes que ce soit un particulier ou une entreprise, il y a quelque chose de louche voir de véreux, une arnaque (de l'état ou autre) et un paradis fiscal quelque part.

Sincèrement c'est déontologiquement compliqué pour notre président dont 2 ministres ont sciemment fraudé le fisc, de dire que c'est vraiment pas bien.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

L'un empêche pas l'autre, mais tu montre bien cette idée de "si je vole la communauté je ne vole pas les membres de cette communauté". Ces entreprises et voleurs en col blanc qui ne "font de mal" à personne, mais qui profitent de tes investissements sans te reverser de contrepartie sont un vrai problème.

La question de la gestion des données personnelles, de la délocalisation, des conditions de travail de leur employés, de la pollution qu'ils produisent,… c'est orthogonal. Le fait qu'il soit mauvais dans un domaine n'a pas à cacher les autres domaines.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Au sujet de mojolicius et dancer, comme PSGI ils sont bien mais ils n'ont rien apportés, il s'agit presque de portage en perl de framework existant (ça n'enlève rien à leur qualité, j'aime beaucoup dancer par exemple).

Ce n'est pas non plus un langage qui "fait sérieux" (il suffit de voir les petites blagues par-ci par-là dans la doc officielle). C'est un langage qui a été pensé pour être pratique et efficace pour le programmeur, pas pour être élégant, et, ça, ce sera toujours une barrière à sa popularité.

Je doute que les gars qui ont fait fabric, on quelque chose à faire de tout ça.

C'est assez vrai, mais je ne vois pas trop en quoi c'est un problème, c'est même plutôt une bonne chose.

Alors oui ça a de bons cotés, mais évoluer c'est vraiment important. Déjà ça fait de la publicité, mais on ne programme plus aujourd'hui comme on le faisait il y a 10 ans. En plus c'est pas comme si perl était dénué de défauts (comme tout langage).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Derrière le troll, il y a tout de même une vrai problématique. Aujourd'hui perl n'a pas le vent en poupe et moi qui personnellement aime bien le langage je penne à donner une killer feature ou une killer app qui serait sortie il y a moins de quelques années (les regex, Moose, POE, DBI ou Regexp::Assemble sont excellents mais ne sont plus tout jeunes). Les 2 gros "concurrents" python et ruby ont fait parler d'eux pour l'un pour (entre autre) fabric, glance et django et l'autre pour (entre autre) puppet, rail et capistrano.

AMHA perl souffre de plusieurs choses :

• les utilisateurs de perl sont peut être moins versé dans le "hé regardez, j'ai eu une idée et je l'ai codé sur le coin d'une table !"
• le langage est resté figé un certain temps avant la version 5.10 et semble avoir eu des problèmes depuis (ils ont viré given/when !)
• même si perl6 n'est pas le même langage les 2 se font de l'ombre l'un l'autre. Le commun des mortels :
  • ne sait pas que c'est un langage différent
  • ne connait pas le status actuel de perl6 (ou en est rakudo ?)

et perl 5 semble presque être en mode maintenance. Une grosse partie des nouveautés sont des idées de perl6 portées.

C'est pourtant un sacré langage qui fait pleins de choses très bien. C'est dommage qu'il manque d'une dynamique. Personnellement j'ai découvert le langage à travers les perles de mongueurs dans GLMF et ça donnait envie de voir des choses se faire en quelques dizaines de lignes.

Sincèrement si vous aimez perl, si vous utilisez perl, n'hésitez pas à partager votre enthousiasme pour ce langage c'est à mon avis la seule chose qui lui manque.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Un solveur de dépendances n'est pas aussi simple que vous semblez le croire…

Sauf que ce n'est pas ce dont il était question. Il n'était pas question de faire de la résolution de dépendance, mais de faire une inversion de dépendance (note moi je réponds à "On sait deja sur quels libs s'appuient chaque paquet, il suffit d'inverser la liste"). Pour faire ça tu prend la représentation de ton graphe (le graphe est connu et limité ce graphe), tu inverse tous les arcs et tu fait la résolution de dépendance. Ce n'est pas simple, mais tu as un super outil pour le faire qui s'appelle apt qui le fait déjà.

Encore une fois il n'est pas de problématique générale, mais d'une utilisation précise qui est déjà adressée par les outils Debian (cf la sous commande rdepend d'APT). Et non pas de résolution d'un 3SAT bien poilus.

MANCOOSI fait des choses très bien j'en suis sûr mais pour ce qui est de l'inversion de dépendance, soit ils ont déjà résolu le problème soit c'est un problème qui était résolu avant.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je ne sais pas ce que fait MANCOOSI, mais lancer un rdepend sur l'ensemble des paquets Debian, c'est probablement long, mais pas vraiment insurmontable. Si c'est vraiment ça, je trouve dommage que l'UE dépense beaucoup d'argent là dedans.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

on travaille sur la dernière partie, l'interface utilisateur

Je voudrais pas vous décourager, mais AMHA c'est le gros du boulot et de ce que j'ai pu voir rapidement, il y a encore pas mal de choses qui vont être impactant pour votre backend et votre modèle de données.

En effet, pour le moment il me semble que vos formulaires se résument grosso modo à une série de question-réponse avec pleins de types de valeurs possibles. Si c'est bien le cas il manque toute la partie dynamique d'un questionnaire. C'est dommage d'avoir a écrire des question de la forme "Si vous avez répondu oui à tel question, […]". Ça peut par exemple être fait avec des conditions d'affichage pour chaque question.

Plus que des données géographiques ça me semble être une fonctionnalité assez cruciale.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

En faisant tout ça dans les règles, optimiser coûte cher.

Je ne pense pas qu'il ai plus de quelques projets dans le monde qui se permettent ce genre de choses.

Les règles que tu donne n'ont aucun sens sans les prérequis suivant :

• avoir une campagne de benchmark sérieuse (en soit c'est déjà assez compliqué, très couteux et ça prend un temps fou)
• avoir un logiciel, inutile de prouver une optimisation si le logiciel n'est pas prouvé ("hé je te garanti que ça fonctionne maintenant comme ça fonctionnait avant sans savoir si ça fonctionnait bien avant !")

Je ne vois vraiment pas comment des projets pourraient investir autant dans la performance alors qu'il y a si peu de projet qui investissent la moité dans la correction de leur logiciel.

D'ailleurs la valeur ajouté est tout de même limité. Il faut cibler une plateforme cible (sinon la complexité explose) et être sûr de gagner au moins un minimum de performance (investir des sommes folles pour gagner un temps non mesurables n'a pas de sens) et s'assurer que le gain ne pourrait pas être obtenu avec un coût moindre en investissant dans la plateforme cible.

Bref AMHA tout ça est plus théorique qu'autre chose. Je ne vois pas vraiment de cas qui réunirait toutes ces hypothèses (peut être quelques projets critiques dans l'aéronavale ou l'aérospatial).

ce n’est pas évident

Doux euphémisme, je pense que démontrer qu'un programme s'arrête n'est pas évident non plus.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Le problème c'est probablement qu'elle était mal faite, parce que c'est ce qu'il font pour toute leur application portable.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Les solutions que j'ai listées sont les plus connues, mais la liste n'est pas exhaustive. Il y a d'autres méthodes pour améliorer la sécurité. Par exemple OpenBSD n'a pas eu besoin d'artifice sophistiqué pour lancer Xorg en simple utilisateur.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Oui mais ça veut dire qu'il faut sortir le IsEvent ailleurs donc au final on ne fait que déplacer le problème.

On le rend testable ! Et on si pour les nombres pairs ça paraît trivial sortir les concepts métier me semble une bonne pratique.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

je préfère nommer la ligne entière : la lisibilité est nettement meilleure, pour tout le monde.

Alors en fait pour moi, non. Se contenter de sortir la lambda et la nommer ça permet de la réutiliser ailleurs (parce que normalement ta lambda a un sens "métier") et ça permet de garder une forme générique pour le filtrage plutôt que de multiplier les helpers qui ont très peu de valeur ajouté et qui ne respectent pas forcément tous la même convention de nommage (toi tu l'appel copy_even_numbers, mais ton voisin l'aurait peut être appelé keep_even).

Donc personnellement à réduire encore j'écrirais plutôt une méthode qui prend un prédicat et 2 vecteurs ou un prédicat, un vecteur et un itérateur. Ça permet d'écrire bien moins de code avec une grosse ré-utilisabilité et d'avoir toujours la même manière de faire la même chose partout dans ton code.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Sauf la première (que j'écrirais sur 2 lignes) ce n'est pas de l'opérateur ternaire.

C'est une forme qu'on retrouve souvent en perl et en shell. Je trouve personnellement le foo(bar) or die; plutôt joli, mais je comprends ton point de vu.

j’ai connu l’excès inverse

Pour moi interdire { |toto| ... } c'est déjà verser dans l'excès (de la même manière qu'interdire les compréhension de liste en python).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

retour implicites (trop souffert avec perl surement)

Je ne me souviens plus d'où il y en a en perl, mais ça vient surtout des langages fonctionnels comme haskel, personnellement je trouve ça très propre. Justement ta forme et la compréhension de liste de python ne sont pas DRY du tout (tout à fait inutilement et piégeux AMHA).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Maintenant, replace la dans un contexte, à savoir, au milieu d’autres structure du même type, peut-être dans une boucle, bref. J’estime être pas mauvais en C++, je travaille avec quotidiennement, j’ai l’habitude d’en lire, et pourtant, quand j’écris du code, j’évite ce genre de trucs.

AMHA le problème vient plus de la taille de la ligne (c++ n'est pas aussi concis qu'on voudrait le croire) et à ta place je pense que je nommerais le prédicat et une ligne de cette forme :

std::copy_if(v2.begin(), v2.end(), std::back_inserter(v1), isEvent);

Bizarrement on passe sous la barre des 80 colonnes et on gagne en lisibilité.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

select me semble pourtant clair. Tu préfèrerais filter ou grepcomme en perl ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Je déteste cette forme !

int a;
if(mafonction(b, c)) {
    a = 4;
}
else {
    a = mafonction2(b + c);
}

Elle n'est vraiment pas lisible car beaucoup trop longue !
C'est peut être bien parce qu'elle est constitué d'instruction triviale, mais la forme déconstruite fait perdre tout son sens au code (en fait il ne le perd pas c'est juste caché dans un océan d'instructions).

Si vraiment cette forme ne te convient pas (tu vois je ne relève même pas la mauvaise fois de ta forme sans espace et avec des noms de méthodes qui n'ont pas de sens) :

int a = !mafonction(b,c) ? mafonction2(b + c)
                         : 4;

Je préfèrerais toujours écrire :

int aValue(int b, int c) {
    int a;
    if(mafonction(b, c)) {
        a = 4;
    }
    else {
        a = mafonction2(b + c);
    }
    return a;
}

// ce qui donne à la lecture quelque chose de bien plus concis
int a = aValue(b, c);

Bien sûr le aValue doit avoir un sens métier. L'énorme avantage c'est :

• a est initialisé dès sa création donc on peut le déclarer const
• on voit que tout ce code sert à initialiser a, on voit immédiatement que sa valeur dépend de b et de c
• en principe je me permet d'utiliser la forme ternaire dans une méthode pour qu'elle n'est qu'une seule ligne parce que la méthode est courte et que le nom de la méthode plus la documentation de celle-ci vont enlever tout ambiguïté

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas.

Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.

Après, les goûts et les couleurs…

Non ce que tu décris me semble vraiment plus proche de la compétence. La maitrise d'un langage passe par la maitrises de ses constructions de bases (pour notre exemple c'est une structure de contrôle). C'est comme si tu disais que les langages qui ne mettent pas de $ devant les identifiants de variables sont illisibles. C'est pas une question de goût c'est la maitrise du langage donné.

Tu tires des conclusions un peu trop rapides et va largement au-delà de ce que j’ai dit.

Pourtant tu interdit certaines boucles et certaines autres constructions pour des raisons de lisibilité. On est loin, très loin, de parties du C++ comme la programmation par template.

plus concise mais dont la lecture n’est pas intuitive

selectedIds = ids.select { |id| id.even? }

"Les identifiants sélectionnés sont, parmis les identifiants, ceux qui sont paires". Je ne vois pas ce qui perturbe. Le { | | ... } quand tu viens d'un autre langage ça surprend si tu découvre et après 2h c'est assimilé, soit tu ne découvre pas.

Comme toujours sur un sujet subjectif comme la « lisibilité »

C'est ce que je dis, il faut savoir pour qui on écris le code. Mais je doute que se limiter autant dans l'usage d'un langage soit pertinent ailleurs que dans l'éducation.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Personnellement, oui.

Alors tu devrais éviter les phrases à rallonge avec une foule de propositions comme :

Mais ça n’est pas qu’une histoire de non-francophones, je pense simplement qu’il est inutile de faire compliqué pour la clarté, quand on est fatigué, les handicapés mentaux, et effectivement les non-francophones.

C'est plus pénalisant qu'une question de vocabulaire pour le lecteur.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai jamais compris ce qu'il y avais de compliqué dans cet opérateur (dispo dans à peu près tous les langages), comme dans le ou exclusif ou l'opération de pre/postincrément. J'ai l'impression que ce n'est vraiment pas rationnel, c'est plus de la peur qu'autre chose.

Pour l'opérateur ternaire, je m'en sert allègrement :

• quand tout est court ou que je peux avoir une forme propre (c'est à dire quand la seconde valeur peut aller sur une nouvelle ligne en alignant le : avec le ?)
• qu'il me permet d'avoir une valeur const/final sans avoir à créer une méthode pour ça
• quand il permet de se rapproche de valeur par défaut

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Disons que j’évite l’emploi de formes trop littéraires

Oui mais là on parle d'une construction de base du langage. Pas d'une forme trop littéraire. A comparer c'est plus proche du participe passé que d'une allitération.

En fait je trouve qu'éviter cette construction en ruby c'est même plus dangereux qu'autre chose, parce que c'est très utilisé. Trop pour faire l'impasse dessus. Elle n'a vraiment rien de bien compliquée ce n'est que de la syntaxe.

Au final, je trouve ta comparaison très pertinente, même si on n’y voit pas la même chose :).

Donc tu écris ton code pour quelqu'un qui ne connaît pas le langage. C'est ton choix, mais c'est très risqué de s'imaginer que "n'importe qui" (=> quelqu'un qui ne comprend pas le langage) va aller bidouiller le code (sans forcément y comprendre quelque chose).

Ça peut paraître élitiste, mais tu place la barre tellement bas… Comme si tu interdisais les boucles while de peur quelqu'un inverse la condition.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Est peut-être clair pour toi qui connaît bien ruby

La lisibilité dépend évidement de celui qui lis. AMHA un code est généralement écris pour quelqu'un qui sait lire le langage en question.

Quand tu écris français cherche-tu a limiter ton vocabulaire et à utiliser des phrases courtes et simples pour faciliter la vie des non-francophones ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

J'ai jamais eu à me plaindre de brasero (que je n'utilise plus).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)