Moonz a écrit 3542 commentaires

C'est un problème de distrib. L'effort de packaging n'a jamais abouti pour Java. Retire le boulot des distribs en python et t'as le même problème.

Toutes les distribs se foirent pour bien intégrer Java. Deux hypothèses :

1. Toutes les distribs sont incompétentes
2. Java est, de par son design, bien plus complexe (pour ne pas dire impossible) à intégrer correctement.

Étrangement, j’ai tendance à pencher pour (2)

Retire le boulot des distribs en python et t'as le même problème.

Je crois que tu ne comprends pas la différence entre le PYTHONPATH et le classpath (ou alors j’ai loupé un truc énorme).

En Python, je configure un PYTHONPATH, une bonne fois pour toutes, pour tous mes projets et toutes mes dépendances. C’est à dire que c’est une seule fois lors de l’installation du système.

En Java, je dois tripatouiller mon classpath à chaque dépendance de chaque projet.

C’est pour ça que l’écosystème Java est si difficile à bien packager, et qu’il nécessite des outils complexes pour gérer les dépendances.

Si tu te poses ces questions là. Files apprendre Java avant de vouloir utiliser hibernate.

Mais je pense connaître assez Java pour avoir une réponse, qui est : « soit tu gères ton classpath à la main pour chaque projet (ce qui, on en convient tous, est un peu ridicule), soit tu utilises un outil genre maven. Tu n’as pas d’équivalent du PYTHONPATH ». Si je pose la question, c’est parce que j’espère me tromper, parce que cette approche ne me convient pas du tout. Maintenant, tu sembles confirmer que ma réponse semble la bonne ici :

Si tu as 3 notions de Java tu sais que tout ce que tu as besoin c'est des .class dans ton classpath.

(sinon, je crois que je vais m’arrêter là : ça dégénère en troll, et j’aime pas les trolls, quand j’expose mes points de vue c’est pour avoir des réponses du genre celles de CrEv ou rom1dep, c’est à dire ce qui se fait, pas ce qu’il est théoriquement possible de faire. Oui, je me doute que je peux théoriquement éviter maven et gérer mes deps et mon classpath à la main, mais ce qui m’intéresse moi, c’est est-il possible, et comment, l’éviter en pratique)

À partir d’une pauvre courbe, qui descend, qui monte, ils vont vous échafauder une théorie aussi improbable qu’une carabistouille bien fignolée.

C’est une maladie malheureusement bien répandue dans les milieux universitaires/intellectuels. J’appelle ça l’intellectualisme : essayer de rationnaliser, d’intellectualiser le moindre fait banal (je ne parle même plus du fait divers journalistique ici, je parle des remarques anodines de tous les jours). Une blague sur les arabes ? Tu es un raciste en puissance. Une blague sur les belges ? Tu es un xénophobe en puissance. Un lapsus lors d’une discussion politique ? Révélateur du lavage de cerveau opéré par les médias qui opèrent au plus profond de ton subconscient.

Le plus étonnant est la capacité de personnes aux capacités intellectuelles indéniables de pondre des barres de bullshit absolument effarantes qui fait rechercher la caméra cachée à toute personne dotée d’un strict minimum de décence et de bon sens.

Le plus impressionnant dans tout ça est l’effet d’entraînement : certains groupes semblent tout à fait étrangers à ce phénomène, tandis que dans d’autre, cela prend des proportions réellement alarmantes. Si jamais vous commencez à voir autour de vous ce genre de rationnalisation débridée, méfiez vous : ça semble contagieux.

Et le stade terminal, c’est ça : http://www.chss.iup.edu/rhoch/ClassPages/Thought%20and%20Philosophy/Readings/Week9_GIS_Society/kwan_FeministGIS_2002.pdf — où l’on apprend que l’appareil photo est outil représentatif de la domination masculine sur le monde – (les mouvements féministes, spécialement aux US, semblent particulièrement affectés). Je crois que si on me laissait le choix entre la lobotomie et un tel état mental permanent, je préférerai la lobotomie. Mais je soupçonne qu’un minimum de bonne hygiène mentale suffit à se préserver de ce fléau.

• en Java en le mettant dans ton classpath

Et c’est un problème pour moi : en Python, je n’ai pas besoin de toucher à mon PYTHONPATH, ma distrib le fait pour moi. En C, je n’ai pas besoin de toucher à mon LD_LIBRARY_PATH, ma distrib le fait pour moi. Par contre, en Java, non seulement le classpath n’est pas défini par la distrib, mais il est en plus spécifique à : mon package, la version de la lib installée (je met à jour fubar-1.2.3.jar en fubar-1.2.4.jar ? je dois mettre à jour le classpath de tous mes projets qui utilisent fubar). D’où mon scepticisme sur la possibilité de se passer de systèmes de gestion que je trouve pénibles genre maven.

Maintenant si tu prends comme exemple un hello world, je me demande bien quelle idée tu as eu de sortir Maven alors qu'un cp suffit

J’ai suivi un des premiers tutoriels mis en avant pour lift. Je lis rarement les docs spécifiques AVANT d’avoir suivi le tutoriel générique…

mais ça répond à un vrai besoin

Je n’ai vu aucun tutoriel Ruby on Rails qui me demande de prendre en main un truc genre Maven

Je n’ai vu aucun tutoriel Django qui me demande de prendre en main un truc genre Maven

Je n’ai vu aucun tutoriel web.go qui me demande de prendre en main un truc genre Maven

Je n’ai vu aucun tutoriel node.js qui me demande de prendre en main un truc genre Maven

Je n’ai vu aucun tutoriel Symfony qui me demande de prendre en main un truc genre Maven

Par contre, le premier tutoriel lift sur lequel je tombe, je me mange du Maven. Soit je n’ai pas de chance (ça arrive hein : ma première approche avec Gentoo, ça a été quand les dépôts officiels étaient cassés. Forcément, après ça, j’ai eu une très mauvaise première impression de la distrib, alors qu’après utilisation, si les dépôts sont cassés deux jours par an, c’est un grand max…), je suis tombé sur un tutoriel mal fait (mais pourquoi était-il mis en avant dans ce cas ? j’ai pas été chercher sur un site obscur, mais sur le site officiel…), soit Maven est une quasi-nécessité en Java (comme make et assimilés en C : tu peux toujours faire à la main, bien sûr, mais ce n’est clairement pas la méthode conseillée). Quand je dis : « j’aime pas scala parce que j’aime pas Maven », ça veut pas dire que je suis prêt à faire le boulot de Maven à coups de script bash, ça veut dire que je ne veux pas que toute la machinerie gérée par Maven soit un étape obligatoire pour pouvoir utiliser le langage (et utiliser au delà du hello world, hein ;)). Que maven soit possible, soit utile pour certains, évidemment que je n’ai aucun problème avec ça.

Pourquoi cherches-tu des excuses ?

Je ne cherche pas d’excuse. J’explique pourquoi j’ai éliminé scala de ma liste des possibles : parce que le premier tutoriel m’a fait bouffer trop de maven à mon goût, et parce que mes connaissances de l’environnement de dev Java me fait fortement suspecter que faire un projet Java sans Maven, c’est comme faire un projet en C sans make : une horreur encore pire que le mal (et comme, dans le cas de maven, je n’ai déjà pas le dit mal…)

Maintenant, les questions du genre « je veux de l’hibernate, c’est toujours aussi simple sans maven ? », elles ne sont pas rhétoriques : rom1dep m’a montré que j’avais tort sur l’obligation de maven pour le « hello world ». Il est possible qu’avec sa suggestion « Play! », il s’avère que j’aie aussi tort pour du HTTP. Si j’ai franchement tort pour toute lib externe que je pourrai avoir, crois-moi que je serai heureux : Go ne m’a toujours pas convaincu pour le web (beaucoup trop de perte d’expressivité relativement à rails ou même PHP à mon goût), et si ce qui me bloque l’utilisation de scala dans ce domaine (nommément : maven) est une erreur d’appréciation de ma part, crois bien que j’en serai le premier ravi.

et la complexité de l'écosystème java se résume ici à :

Heureux de le savoir. Il manque plus qu’à ce qu’ils le mettent en valeur dans la documentation, parce que la dernière fois que j’avais essayé, après m’être battu pendant une demi heure avec un maven qui voulait pas marcher (Dieu seul sait pourquoi), j’ai abandonné.

Je veux faire un hello world en HTTP (si mes souvenirs sont bons, c’est sur jetty que maven se vautrait), ça se résume aussi à ça ? Je veux un toolkit graphique, ça se résume aussi à ça ? Je veux une lib externe (hibernate ?), ça se résume aussi à ça ?

.(), parce qu’il faut déjà comprendre la notion de typage ;)

Sauf que le revenu de l’État français, ce n’est pas le PIB, à moins de décréter le communisme et que tout ce qui est sur le territoire appartient à l’État.

Keynes s'oppose aux économistes néoclassiques du 19ème siècle qui adhèrent à la loi de Say. Celle-ci postule qu'il n'existe pas de marchés désequilibrés à long terme

La notion d’équilibre de marché n’existait même pas à l’époque de Say…

Sans mot clef "func", comment tu fais des fonctions anonymes ?

Mais d'ailleurs, dans quelle mesure Go peut utiliser des dll/so classiques ?

Avec pkg-config (tu peux aussi préciser les ldflags et cflags à la main, mais plus chiant) :

// #cgo pkg-config: libxml-2.0
// #include <libxml/parser.h>
import "C"

Tu peux ensuite appeler C.xmlWhatever()

Il me semble aussi que Swig supporte Go, mais j'ai jamais essayé.

Go introduit, grosso-modo, relativement au C, deux nouveaux mots clefs (defer, go) et trois opérateurs (:=, <-, .()) par rapport au C. Si tu as maîtrisé la lecture de code Perl, je crois pas que quatre nouveautés soient insurmontables :)

• quid des librairies ?

L’interfaçage avec le C est absolument trivial : C.printf(C.CString("Hello, world !"))

Idem, on dirait qu'un ingé de chez google était jaloux devant les specs de scala et a voulu faire le sien en moins beau et beaucoup plus verbeux

Encore une fois, tu oublies l’élément « simplicité » du cahier des charges. Scala c’est beau, mais il faut avoir fait des études assez poussées pour comprendre ce que fait le compilateur derrière ton dos (chose qu’on explicitement voulu éviter les devs de Go).

Plus prosaïquement (la raison pour laquelle je ne l’utilise pas), tu te manges aussi la complexité de l’écosystème Java, avec Scala : un runtime pas des plus légers/intégré/simple (Go, il te pond un exécutable lié statiquement, un scp et c’est déployé), un environnement de dev bien lourd (maven ? eclipse ? non merci).

et les perfs c'est pas ça apparemment…

Ça dépend tu compares avec quoi.

La plupart des projets que je fais en Go aujourd’hui, je les aurai fait en Python hier. C’est un gain de performances vraiment appréciable.

Bon, on reprend, vu que j'ai pas été assez clair, apparemment :

Expressivité : Python > Go > C
Performances : C > Go > Python

C’est un compromis entre les deux. Encore une fois, le but c’est d’être presque aussi efficace que le C (pas aussi efficace), et presque aussi expressif que le python (pas aussi expressif).

Tu cherches rarement les performances pures. Tu cherches toujours un compromis performance/expressivité. L’intérêt de Go aujourd’hui, c’est son placement sur l’axe qui le rend intéressant.

C’est toujours plus rapide que Python.

Un langage comme Scheme (et ses multiples implémentations) est un concurrent sérieux.

Tu compares un langage impératif et un langage fonctionnel. Je ne veux pas rentrer dans le troll fonctionnel/impératif, mais pour faire court, force est de constater que tout le monde ne se retrouve pas forcément dans ce style.

(tout (le (monde (n'est (pas (fan)))))))

Personnellement c'est un langage que je trouve séduisant, mais son apprentissage vaut-il vraiment le coup ?

C’est l’avantage de Go : tu connais le C, tu connais Go. Son apprentissage est quasi-immédiat pour un dev C (Go, c’est du C avec un peu de sucre syntaxique (:=, interfaces, go, defer) et un GC).

Alors, quel est l'intérêt profond de Go ?

Go, fondamentalement, est à mi-chemin entre Python et C.
- Si le cahier des charges de ton projet te dirige vers le C pour des contraintes de « légèreté » (en terme d’infrastructure de runtime nécessaire, d’utilisation mémoire, que sais-je), alors Go pourrait être un bon candidat : proche du C sur ces points, il a l’avantage d’une meilleure expressivité.
- Si le cahier des charges de ton projet te dirige vers un langage interprété pour des contraintes de rapidité de développement, alors Go pourrait être un bon candidat : presque aussi expressif que Python, il est généralement bien plus performant.

Bref, l’intérêt profond de Go, c’est d’être « presque » aussi performant que le C en étant « presque » aussi expressif que Python.

D’un autre côté, étant à mi-chemin, tu perds aussi un peu des bons côtés des deux : côté C, le GC pourrait être un point bloquant ; côté Python, outre l’écosystème bien plus réduit, la méta-programmation est bien plus pénible en Go, et le typage statique limite parfois l’expressivité comparativement à ce qu’on pourrait retrouver dans un langage à typage dynamique (je pense par exemple aux collections, dont la gestion peut être parfois frustrante, ou à l’impossibilité d’un équivalent du type tuple en Python)

Ça te demande rien du tout, si ça tombe dans le domaine public Wikimedia se fera une joie de te fournir l’infrastructure (oui, je sais, il la paient cette infrastructure, mais il y a peu de chance qu’ils doivent augmenter leurs capacités pour un millier de bouquins).

Damned, je suis démasqué.

Mais bon, savoir que ce n’est pas un claquage du poil de la main, c’est rassurant. C’est que ça pourrait être dangereux ce truc.

A ma connaissance, c'est exactement l'inverse: déployer une application sur Windows est facile, il suffit de faire un installeur et il y a pas mal d'outil pour en faire des biens. Il est aussi assez facile d'embarquer toutes les libs dont tu as besoin.

C’est pas du déploiement ça, le déploiement c’est « je veux mettre mon soft sur 200 machines ». Tu vas faire clic-clic 200 fois, avec ton installeur ?

quel format d'empaquetage utilisé ?
comment m'assurer que toutes les libs dont j'ai besoin sont présentes dans la version où j'en ai besoin, pour le 86 distribitions Linux et 23 versions de chacune de ces distributions

J’ose espérer que tu n’as pas installé 86 distributions dans 23 versions différentes sur ton parc de machines. Si c’est le cas, le déploiement d’une application est, je le crains, le dernier de tes soucis.

pour sauvegarder les données de l'utilisateur, il faut bidouiller pour créer un répertoire dans le HOME de l'utilisateur mais tu es obligé de développer vachement de code "à la con" pour gérer plein de cas particuliers.

Pareil, dans un contexte où on parle de « déploiement », ton HOME c’est un NFS/Samba que tu peux gérer de manière centralisée pour tous les utilisateurs.

Et maintenant, quid de Mac OS ? Je me pose la même question, facilité de déploiement…

Pareil que Linux, grosso-modo. Les logiciels sont distribués en .pkg, qui est juste une grosse archive qui contient binaire, lib partagées et données.

https://bugs.freedesktop.org/show_bug.cgi?id=44466

la présence optionnelle des ; : c'est con, soit on les rend obligatoire, soit on les enlève complètement, là on est le cul entre deux chaises

Même choix que Ruby, Lua, Python, CoffeeScript. À ton avis, pourquoi tous ces langages ont fait ce choix ?

1. Tous les concepteurs de langage de la terre sont des abrutis
2. Il y a une bonne raison derrière

les tailles de tableaux situés avant le type et non après : ça rend extrêmement désagréable la lecture, je trouve

Ça permet de clarifier grandement char *foo[3] (tableau de 3 char* ou pointeur sur un tableau de 3 char ?).

Wine + D3D + 64bits ne font pas bon ménage en ce moment (au hasard)

Mais ça signifie aussi que les croisades ne sont pas incompatibles avec le christianisme en général (sinon ce serait incompatible avec le catholicisme romain en particulier).

Perso noscript me bloquait les fonts externes.

Et purtant, tu es capble de lire ce mesage.

chmod 600 .config/weboob ça a quoi de moins bien qu’un keyring ?

C’est du Python. Tu ajoutes

import httplib
httplib.HTTPConnection.debuglevel = 1

et tu peux voir toutes les requêtes HTTP faites par Weboob, et s’il se connecte à hack.weboob.com, tu peux te poser des questions.

J’ai pas testé, mais tu devrais pouvoir faire ça aussi :

import socket as oldsock
class socket:
    def connect(self, *addr):
        print "Connecting to ", addr
        return old_connect(self, *addr)
old_connect = oldsock.socket.connect
oldsock.socket.connect = msock.connect

En jouant sur PYTHONPATH tu devrais même pouvoir faire ton propre socket.py qui fasse ça plus proprement.

Sinon, tu as aussi d’autres solutions du genre https://github.com/sloonz/utils/blob/master/bin/tcproxy + tsocks (tcproxy 12345, puis tu configure tsocks pour passer en SOCKS 4 sur le port 12345)