flan a écrit 1865 commentaires

Je suis souvent tombé sur du code libre vraiment pourri ou sans aucune documentation et ce, même sur de gros projets (genre Hadoop il y a quelques années, maintenant je regarde un peu moins le code), quasiment toutes les fonctions avaient TBD (To Be Documented) comme seule doc…
Par contre, je suis aussi souvent tombé sur du code libre plutôt bien fichu. Là où ça pêche quand même pas mal, c'est la doc, même si le code en soi est propre. Mais ça se comprend, le temps est limité pour tout le monde, et c'est dur de demander de multiplier par deux (voire davantage) le temps de développement juste pour ajouter une doc qui a de fortes chances de ne servir à rien.

En entreprise, ça va dépendre de plein de choses : si la boîte a une culture de qualité (et qu'elle a compris l'intérêt de faire un code propre), si les développeurs sont suffisamment geeks pour aimer le code propre, etc.
J'ai pas mal d'échos dans un sens comme dans l'autre ; bon, ok, pour le code pondu par la majeure partie des SSII, les échos vont tous dans le même sens :D

Je vote pour Python 3 également. Après, on peut se contenter de Python 3.3, voire 3.2 (seule version 3 dispo sur Debian Wheezy, par exemple).

Personnellement, je ne peux qu'encourager de passer par un ORM (SQLAlchemy).

Ça demande un investissement un peu plus grand au début, mais ça se révèle en général un gain de temps très important sur le reste : tu vas plus vite pour coder tes requêtes, la gestion des connexions va se faire de façon transparente, et surtout tu pourras passer d'un moteur à l'autre sans souci. Accessoirement, ça permet de rejeter la sécurité sur l'ORM, sachant qu'il s'en occupera de toute façon bien mieux que toi (sauf si tu es spécialiste du sujet).

Je parlais de ReactOS qui en est à ajouter le support de l'USB.

(cela dit, le support correct de l'USB est bien plus récent, me semble-t-il)

Ils en sont à ajouter le support de l'USB… Autant dire qu'il ne sera pas utilisable en prod avant quelques années, quand les gens auront choisi de rester définitivement sous XP ou de passer à un OS plus moderne (Windows ou autre).

C'est un peu facile de toujours se reposer sur « c'est installé par défaut, ce n'est pas de notre faute ».

Pour les logiciels, Firefox avait réussi à bien décoller (30% du marché) alors qu'IE était installé par défaut, maintenant Chrome est passé devant et IE se retrouve derrière.

Et même sur les OS, de mémoire, aux États-Unis, Mac OS X était en gros à 2% en 2003 et est maintenant à 10% (ordis de bureau uniquement). Comme quoi, c'est possible de faire changer les habitudes.

Bof. Apple a réussi à bien reprendre pied sur le marché, sans même être compatible Windows (ça n'a été le cas qu'en 2006 de mémoire, avec Bootcamp).

Évidemment, c'est mieux d'être root. Mais ce n'est pas critique pour faire tout ce dont tu parles.

2) l'impact d'un virus sur le système (ne corrompt que le profile de l'utilisateur, pas le système)

La formulation est curieuse : ça ne corrompt que ce qu'il y a de plus important, et ça ne touche pas à ce dont on se moque.
Pour un ordi perso, le profil de l'utilisateur est la seule chose d'importance, le reste on s'en moque (la donne est différente pour un serveur, évidemment).

Tiens, aurais-tu un lien avec des exemples de code source de la pile graphique d'iOS ? Ou balances-tu ça complètement au hasard ?

Sinon, la bonne raison est que tout simplement un flat design n'empêche pas d'utiliser des effets graphiques un peu complexes, comme un flou gaussien (très gourmand alors que cela semble tout bête).

Bof. Apparemment, l'interface d'iOS 7 est un exemple de flat design, et pourtant elle est bien plus gourmande en ressources graphiques que l'interface d'iOS 6.

C'est surtout que sans rien faire, tu as grâce à bootstrap un site web à peu près présentable, et beaucoup de personnes s'arrêtent là.
En théorie, il faudrait plutôt prendre Bootstrap comme la CSS par défaut, à partir de laquelle tu vas faire ton design.

Je suis tout à fait d'accord, un type statique manque quand même un peu.

Ça me ferait penser à un truc sympa en Objective-C (que je ne connais pas spécialement, aussi j'espère ne pas raconter trop de bêtise) : on peut faire à la fois du typage statique ou du typage dynamique (en disant que l'objet est de classe Object sans préciser outre mesure).

Malheureusement, les annotations Python 3 ne sont pas destinées à ça (plutôt pour de l'aide au typage pour les IDE)

Non, pas forcément. Tu peux avoir uniquement les fichiers .pyc, sans les .py.

Même sans regarder la responsabilité légale, on peut très bien ne pas avoir envie d'aider ces comportements illégaux.

Et imaginez que la valeur de π change !

Non, Google ne maîtrise pas toute la chaîne, vu qu'ils ne sont pas FAI (sauf de façon anecdotique).

Sauf que manifestement, leur métier ne rapporte rien, et que l'offre de service rapporte beaucoup plus.

C'est un problème assez global à l'informatique actuelle : ceux qui gagnent de l'argent (les vendeurs de service : Facebook/Google/…) ne sont pas ceux qui ont les plus grosses dépenses (ceux qui font le matériel et l'infrastructure). Apple est un cas à part, dans la mesure où ils maîtrisent une bonne partie de la chaîne (service + matériel), et qu'ils font partie des rares à gagner vraiment de l'argent sur le matériel.

Mais en pratique, il y aura souvent un moment où la constante sera utilisée une seconde fois, ou un moment où elle sera modifiée.

Mais je ne vois pas en quoi ça complique le code, n'importe quel IDE digne de ce nom sait afficher facilement la valeur d'une constante si tu as un doute.

Sans passer par là, une simple constante définie dans un fichier regroupant toutes les constantes.
Par expérience, laisser des constantes en dur dans le code finit toujours par avoir un effet négatif.

Je note quand même dans un coin, ça a l'air pas mal.

Étant sur Mac, je regrette vraiment l'absence d'équivalent à iCloud, qui offre beaucoup de services sans rien avoir à configurer. Du coup, je m'en passe, en attendant de trouver mon bonheur à installer chez moi…

Bien sûr, il y a plein de choses que tu peux toujours faire en t'attachant un bras dans le dos. Mais ce n'est jamais une bonne idée de s'enlever des moyens d'action de ce genre.

Accessoirement, le bitcoin supprime par sa nature-même une possibilité pour l'État de choisir sa politique économique, vu qu'il n'est plus maître de sa planche à billets.

Le problème de ces trucs, ce n'est pas la motivation, c'est que les gens doivent tous aller dans la même direction pour avoir un intérêt à coopérer. C'est viable à petite échelle car c'est envisageable de trouver 10-15 personnes voulant faire la même chose et d'exclure du groupe tous ceux qui ne veulent pas faire la même chose.

En revanche, le passage à l'échelle n'est pas envisageable car tu trouveras toujours des gens qui ont des buts antagonistes (évidemment, c'est un peu plus subtil, les intérêts peuvent se rejoindre sur certains points, diverger fortement sur d'autres, etc.).
Du coup, pour passer à l'échelle, soit tu les exclus (mais dans ce cas, tu ne passeras jamais à l'échelle), soit tu les convertis de gré ou de force.

Ce n'est pas pour rien qu'on parlait de l'Homme Nouveau Soviétique : pour que le communisme fonctionne, il fallait changer l'Homme ; avec un homme possédant un libre arbitre et une volonté propre, tu auras forcément des volontés contradictoires. D'un certain point de vue, ça ne serait pas drôle si ce n'était pas le cas (et on se retrouverait dans une des nombreuses fictions évoquant le sujet).

« Par exemple, un mécanisme très très connu de nos amis les sociologues, c'est la coopération : si les gens coopèrent, tout marche mieux. »

Pas besoin d'être sociologue pour comprendre cette évidence, ce n'est pas pour rien que l'expression « tirer à hue et à dia » existe. Mais encore faut-il que les gens aient intérêt à coopérer, ce qui en revanche n'est pas évident (cf. le classique dilemme du prisonnier).