flan a écrit 1830 commentaires

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

j'avais compris le contraire : des conteneurs Docker classiques qui tournent sur du Windows.

ta vision des choses est correcte quand chaque couche est bien isolée et que tu peux la remplacer sans affecter les autres couches.
C'est le cas en réseau avec les couches les plus basses : tu peux changer ton Ethernet par du Wifi sans affecter les logiciels.

En revanche, le RAID, les volumes logiques et le système de fichiers doivent savoir comment chacun fonctionne pour avoir des performances correctes (c'est d'ailleurs pour ça que les cartes RAID matérielles sont déconseillées avec ZFS). Un SSD, un RAID matériel ou un disque SATA classique (la couche la plus basse) ne demanderont pas les mêmes choses au système de fichiers (la couche la plus haute) pour être performants.
Peut-être que le LVM aura aussi envie de connaître l'état des systèmes de fichiers pour faire ses volumes logiques (avec les fichiers creux qui ont une taille réelle plus petite que celle affichée ou les données dédupliquées, les fichiers compressés, les anciennes versions de fichier, la taille réellement utilisée n'est plus la même que celle théoriquement utilisée).

Accessoirement, on peut considérer que l'ensemble des trois forme une seule couche. En tant qu'utilisateur, ça ne me choque pas plus que ça d'avoir un seul logiciel qui se débrouille pour prendre mes disques durs et me découper ça en une série de partitions, en mettant du LVM ou du RAID s'il veut.

Le lien entre JVM et Java est quand même très légèrement plus fort que celui entre IEEE754 et C. La JVM a été pensée pour le Java (et Java a été pensé pour fonctionner sur la JVM), IEEE754 n'a pas été pensé spécialement pour le C, le C n'a pas été pensé pour IEEE-754 (et fonctionne sur des processeurs qui ne sont pas compatibles IEEE754).
Si tu veux être compatible Java (un des buts est de réutiliser des libs Java), tu es obligé d'être compatible JVM. S'ils n'avaient pas besoin de cette compatibilité Java, ils n'auraient pas eu de problème avec la JVM…

Ce que j'ai décrit n'est qu'un des aspects où on aboutit à vrai bug au runtime, mais il y a régulièrement des petits trucs qui ne s'expliquent que grâce au Java (notamment la gestion des types primitifs Java) et qui ne devraient pas expliquer si Scala n'était pas compatible Java.

Et quand tu utilises la lib standard Java, tu te retrouves avec une doc en… Java (surprenant ! ), avec des exemples en Java bien orientés objet comme il faut.

Si c'est comme Scala, c'est un inconvénient pour moi.
On se retrouve avec deux langages à connaître au lieu d'un seul si on veut comprendre ce qui se passe et utiliser la lib standard.
exemple tout bête : en Scala, tout objet hérite du type Any. Plus exactement, presque tout le monde hérite de AnyRef qui hérite de Any, sauf les int/float (eln fait les types primitifs de Java) qui héritent de AnyVal qui hérite de Any. Rien de très choquant là-dedans quand on connaît Java. Ça, c'est la théorie. Maintenant, si on veut faire un Array de Any et mettre dedans des String et des int, pas de souci d'après le système de types… sauf que ça casse à l'exécution pour un problème de type, alors que la grande promesse de Scala est de résoudre tous les problèmes de type à la compilation.
Normal : sous le capot on a un type primitif de Java qui ne se caste pas bien comme un objet Java.

Maintenant, ce problème ne devrait pas exister en Scala, et il est indispensable de connaître des subtilités de Java pour comprendre le comportement de Scala.
Quant à la lib standard, c'est en fait essentiellement celle de Java, donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.

La dédup est la déduplication. Le système de fichiers se rend compte tout seul que deux blocs (qui appartiennent probablement à deux fichiers différents) sont identiques. Du coup, il n'en stocke qu'un exemplaire. Quand tu n'as que des fichiers différents c'est bien sûr totalement inutile, mais quand tu stockes beaucoup de VM (par exemple), avec chacune un OS complet, tu as autant de copies du même fichier que de VM. Là ça peut apporter un gros gain de place.

Tu peux assez facilement créer des formulaires avec une interface graphique. C'est le cas avec Wordpress pour les formulaires de contact : tu as une grosse dizaine de briques de base (ligne de texte, date, courriel, heure, bloc de texte, choix de valeurs, …) que tu choisis pour créer ton formulaire personnalisé et qui est validé automatiquement.
Certes, ça ne plaira pas à 100% des gens, mais peut-être à 95% (voire davantage).

Je ne comprends pas pourquoi utiliser un framework signifie utiliser 150 000 dépendances. Quand tu utilises Django en Python, tu installes Django… et c'est tout. (bon, ok, il faut probablement rajouter gunicorn ou un équivalent).
Rien n'oblige à installer beaucoup plus de dépendances, je pense que s'il est fréquent d'avoir quelques dépendances supplémentaires, le nombre de dépendances à avoir est beaucoup plus faible avec Django qu'avec bower.

Autre projet : PY14, pour convertir du Python en C++ 14 (https://github.com/lukasmartinelli/py14/blob/master/README.md)
Le projet n'a pas l'air encore très abouti, cependant.

(perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons…),

Quand tu travailles sur un réseau déconnecté, tu prends goût aux .deb/.rpm, voire aux .tar.gz quand ça reste correct.

ou alors il aime bien recommencer à zéro quand il trouve que son code actuel n'est pas terrible (attitude quand même assez fréquente)