flan a écrit 1865 commentaires

J'espère qu'un portable fait largement moins de 20 W au repos, vu que mon ordi fixe fait dans les 10 W, avec un Intel Core 2 Duo + 8Go de RAM et un SSD (et il fonctionne 24H/24 depuis 2009).

tu as raison, j'aurais pu préciser que Darwin en soi n'avait strictement aucun intérêt :)

OS X n'est pas une distrib BSD, ce n'est d'ailleurs même pas un noyau BSD. Autour du noyau XNU/Mach se trouvent pas mal d'outils d'origine BSD (la gestion des drivers, au moins au début vu que je ne sais pas si c'est toujours le cas), mais le noyau n'est pas le même.

En (très) gros, tu as l'empilement
OS X = (Cocoa|Quartz|..) + Darwin
Darwin = outils maison + outils BSD + XNU/Mach
Darwin est complètement open-source et est un OS complet que tu peux installer (mais sans interface graphique intéressante)

Pour avoir assisté à quelques congrès d'info (parfois très théorique, parfois très appliquée), j'ai vu beaucoup de Mac (voire une écrasante majorité) et beaucoup d'écrans affichaient un terminal sous une forme quelconque.
De mon côté, si je n'avais pas de terminal, l'option "Mac" ne serait même pas envisageable.

Plutôt GNU/Windows, non ?

Oui, c'est sûr que find est vraiment l'argument clef qui va faire basculer les gens d'OS X à Windows :)

(sinon, je ne m'étais jamais rendu compte qu'installer une autre version de Python était plus compliquée que de télécharger le .dmg et de cliquer quelques fois sur OK).

Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.

Il faut donc analyser la qualité de chaque dépendance. Ça prend du temps, surtout quand on voit les absurdités montrées plus haut (franchement, qui penserait que vérifier qu'un objet est un entier positif demande 3 dépendances ?!?). Faire ce travail pour quelques projets ne me pose pas de problème particulier, le faire pour plusieurs centaines m'en pose beaucoup plus.

A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

Oui, c'est la théorie. Ça implique de faire confiance à toutes tes dépendances. On peut trouver du bon et du moins bon dans tous les langages ; mais encore une fois plus tu as de dépendances différentes, plus tu as de chances de retrouver avec une dépendance foireuse dont une sous-dépendance te posera problème.
C'est beaucoup plus facile de faire confiance à 3-4 personnes qu'à 300 ou 400. À nouveau, le problème n'est pas qualitatif mais quantitatif.

C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

Oui, nous sommes d'accord. Tu peux faire du mauvais ou du bon code avec n'importe quel langage. En théorie, du moins. En pratique, la qualité moyenne (je ne parle pas de toi spécifiquement !) varie fortement d'un langage à l'autre.

Oui, mais via un outil maison pour appliquer stdeb sur toutes les dépendances avec d'éventuels patches.

C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

Tu ne peux pas pousser à fond cet argument sans le vider de sa substance. Le problème n'est d'avoir des dépendances et un graphe de dépendance quelconque. Le problème est d'avoir beaucoup de dépendances et un graphe de dépendance compliqué.
Si tu as dix dépendances qui n'ont quasiment pas de dépendance, il est humainement possible de s'en occuper.

Si tu as cent dépendances qui ont chacune un graphe de dépendance complexe (tu augmentes fortement la probabilité qu'il y ait un problème dans une dépendance de dépendance de dépendance, dans un code que tu ne maîtrises absolument pas), ce n'est plus humainement possible de s'en occuper.

Ce n'est pas un problème de qualité, c'est un problème de quantité. Et en pratique, ce problème arrive avec JS, pas avec Python.

Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
* chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).

* ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.

Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.

Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.

Je ne suis pas du tout d'accord. On se retrouve immédiatement avec des graphes de dépendances énormes et le moindre projet n'est plus du tout maintenable : quand tu as une dizaine de dépendances, tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible), tu connais leur licence, tu peux avoir un ensemble à peu près cohérent, tu limites les doublons de code.

Avec le JS, le moindre projet va dépendre de centaines de développeurs indépendants qui mettent leur code à jour chacun de son côté, avec des licences potentiellement exotiques, qui peuvent ajouter des bugs et affecter en cascades d'autres dépendances intermédiaires, etc.
Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

Il suffit de prendre le code "compilé" (le bytecode généré à la première exécution) :)

On pourrait croire que left-pad est un exemple qui sort de l'ordinaire… mais en JS, non, malheureusement.

http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/

There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s it’s entire 1 line of code:

return toString.call(arr) == '[object Array]';

There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
A fresh install of the Babel package includes 41,000 files
A blank jspm/npm-based app template now starts with 28,000+ files

Mais comment une lib qui fait quelque chose d'aussi compliqué que vérifier qu'un objet est un entier positif ou nul peut-elle avoir 3 dépendances ? C'est simple :

var passAll = require('101/pass-all')
var isPositive = require('is-positive')
var isInteger = require('is-integer')
module.exports = passAll(isPositive, isInteger)

Avec Debian, tu peux fournir un paquet différent mais qui remplit exactement le même rôle.

Par exemple, tu peux avoir "JVM" en dépendance, et cette dépendance peut aussi bien être fournie par la JVM d'Oracle qu'OpenJDK (oui, je sais, c'est plus ou moins la même chose maintenant) ou toute autre JVM.

Pour reprendre ton exemple : les éléments clipsés reviennent moins chers que des éléments vissés.
Faire du « jetable » coûte la plupart du temps nettement moins cher. De la même façon, s'ils garantissent un objet pour deux ans, ils vont le faire juste assez solide pour qu'il tienne deux ans et ne mettront pas un centime de plus pour qu'il tienne plus longtemps. Après, rien n'empêche le gouvernement d'augmenter les garanties légales minimales.

Mine de rien, les clients décident très largement du marché. S'ils continuaient à acheter des choses qui durent et réparables, je suis persuadé que les constructeurs ne fabriqueraient que du solide réparable.

De plus, certaines machines disposent déjà de lest amovible, ce qui est largement suffisant (et peut-être encore plus pratique que de l'eau à remplir).

Je me demande quelle sera la version de l'USB dans 50 ans, et s'il sera toujours compatible avec de l'USB 3.0.

pourquoi donc ? si ça utilise le framework Cocoa, doit y avoir beaucoup de boulot pour convertir l'ensemble.

Apparemment, le plugin Swift est dispo : https://blog.jetbrains.com/clion/2015/12/clion-1-5-eap-opens-dive-deep-into-directories-control-swift-and-more/
Et même si CLion n'est ni libre, ni gratuit, ça ne l'empêche pas d'être utilisable. Peut-être que ça suffit pour toi à le disqualifier d'office, mais manifestement ça n'arrête pas tout le monde (comme les différents outils de Jetbrains de façon générale).
Certes il n'y a pas d'outils de création de GUI (c'est effectivement dommage et c'est général aux outils Jetbrains, à ma connaissance), mais je ne pense pas que ça soit tellement éliminatoire : pas mal de langages n'ont pas de tels outils (ou n'en ont eu que tardivement) et ont quand même eu du succès.

A priori, CLion (un IDE utilisable sous Linux) va permettre d'utiliser du Swift. C'est toujours ça de pris !

J'attends de voir un peu ce qui se passe, mais j'envisage de tester le Swift (j'hésite encore avec le Go) dans quelques mois pour un projet (un serveur particulier) maintenant que ça fonctionne sous Linux.

Ça peut aussi avoir son importance en fonction de qui c'est qui fait l'administration du projet. Tu peut avoir une entreprise qui t'explique que leur compétence interne (ou leur presta) c'est la base X, qu'ils ont déjà un cluster et qu'ils maîtrisent parfaitement ça (voir qu'ils ont un partenariat avec l'éditeur de cette base) et que si tu leur impose d'utiliser ta base ça va probablement pas coller.

Ça va être pareil avec toutes les technos de ta solution. Tu fais du Windows et ils ne connaissent que Linux (ou inversement) ? ça ne va pas coller.
Tu fais du Java et ils ne font que du PHP ? ça ne va pas coller.
Tu ne connais que login/password pour l'authentification et ils ne font que du Kerberos ? ça ne va pas coller.
Ton appli web ne fonctionne que sur Chrome alors qu'ils sont encore sous IE 6 ? ça ne va pas coller.

Bien sûr, dans plein de cas (par exemple Redmine), les accès SQL seront assez simples et ça n'a pas beaucoup d'intérêt d'avoir une forte adhérence à un logiciel en particulier. Pour contre, quand ça a un intérêt, je ne vois pas pourquoi il faudrait s'en passer.
Que dire d'ailleurs de Cassandra, MongoDB, … ? Pour le coup, ils ne sont absolument pas remplaçables.

Le compilateur sera LLVM qui est essentiellement un truc d'Apple (pour se débarrasser de GCC) et qui est réutilisé à toutes les sauces maintenant.

Si, il apporte la cible visée de façon très explicite : ils veulent concilier performances et simplicité d'écriture, donc plus ou moins le même créneau que Go.

Ça montre clairement que ce n'est pas un langage de script lent mais super rapide à écrire, ou un langage super performant mais dont la simplicité aurait été sacrifiée. Je trouve que c'est plutôt un bon résumé (et pas besoin de mettre tous les langages de la terre, ce n'est pas une comparaison avec eux).

J'ai l'impression que ce qui est fait dans la VM vagrant y ressemble pas mal :

sudo apt-get --assume-yes install clang
curl -O https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
tar zxf swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
echo "export PATH=/home/vagrant/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/bin:\"${PATH}\"" >> .profile