Sortie d'une première version stable de Go

Posté par  (site web personnel) . Édité par Nÿco. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
48
9
avr.
2012
Golang

Go est un langage de programmation généraliste, sous licence BSD, à typage statique, disposant d'un ramasse-miettes et de facilités pour gérer la concurrence. Ses avantages sont d'être concis et expressif, de compiler très rapidement et de proposer les performances d'un langage compilé avec la souplesse d'un langage interprété.

Après deux ans et demi de développement, la première version stable du langage Go, nommée Go 1, est sortie. Elle vise à apporter de la stabilité sur les prochaines années pour les utilisateurs du langage, mais aussi pour les auteurs, qui vont ainsi pouvoir écrire des livres dont les exemples et explications continueront d'être valables bien après leur sortie. En particulier, cela implique une compatibilité garantie de tout programme écrit avec la version 1.0 vers toutes les versions 1.x.

Notons que le langage a fortement évolué depuis les premières annonces et que son positionnement a également été revu. Par exemple, Go était initialement vendu comme un langage de programmation système mais il est maintenant décrit comme un langage généraliste, ce qui correspond mieux à l'utilisation qui peut en être faite. Autre changement, Go était au départ un projet de Google mais il n'y a plus, aujourd'hui, de mention de Google sur la page d'accueil du site officiel. Cela ne veut pas dire que Google se désintéresse de Go (pour preuve, il est utilisé pour des composants critiques comme vitess pour Youtube) mais que les auteurs du langage souhaitent mettre en avant la communauté qui s'est construite autour du langage.

Des binaires pour Go 1 sont fournis sur le site officiel pour Linux, FreeBSD, Mac OS X et Windows au cas où votre distribution ne fournirait pas encore de paquets officiels.

NdM : merci à Xavier Claude pour la rédaction d'une dépêche sur le même sujet qui a été intégrée à celle-ci.

Hello World

Vous n'échapperez pas au traditionnel Hello world du langage :

package main

import "fmt"

func main() {
    fmt.Println("Hello world")
}

Outil go

Un outil, go, vient avec le langage et permet de faire de nombreuses actions :

  • compiler du code source : go build hello.go
  • compiler le code et exécuter la version ainsi compilée : go run hello.go
  • générer la documentation d'un module avec go doc
  • lancer les tests avec go test
  • installer un module : go get github.com/bmizerany/pat
  • reformater le code source d'un programme avec go fmt (c'est une manière particulièrement astucieuse d'éviter les discussions sans fin sur le style à adopter sur un programme : il suffit de lancer go fmt sur son code pour qu'il soit formaté selon les bonnes pratiques)
  • etc.

UTF-8

Deux des personnes à l'origine du projet ne sont autres que Rob Pike et Ken Thompson, les inventeurs de l'encodage UTF-8. Il est donc naturel que l'encodage par défaut en Go soit l'UTF-8. Cela s'applique notamment pour le nom des variables, même si, dans la pratique, les développeurs se limitent très largement aux caractères ASCII.

Goroutines et canaux

Go offre un mécanisme pour mettre en œuvre de la concurrence appelé goroutine : ce sont des contextes légers d'exécution. Une goroutine est créée en plaçant le mot-clé go devant l'appel d'une fonction et le langage va ensuite multiplexer les goroutines sur des threads. Cela permet ainsi à un programme Go d'utiliser tous les cœurs d'un CPU.

Un des motto de Go est « Share memory by communicating, don't communicate by sharing memory », que l'on peut traduire par « Partager la mémoire en communiquant, ne pas communiquer en partageant la mémoire ». En pratique, cela veut dire qu'il vaut mieux éviter d'avoir un espace mémoire commun à plusieurs goroutines qui serait protégé par un mutex (même si le langage le permet), mais de privilégier une communication explicite entre les goroutines. Go met à notre disposition pour cela les canaux.

Voici par exemple une go bomb, qui marche de manière similaire à une fork bomb, créant des goroutines jusqu'à saturation des ressources du système :

package main

import "fmt"

func main() {
    c := make(chan bool)
    go func() {
        count := 0
        for <- c {
            count++
            fmt.Println(count)
        }
    }()
    bomb(c)
}

func bomb(tick chan bool) {
    for {
        tick <- true
        go bomb(tick)
    }
}

Pour compter le nombre de goroutines lancées, ce programme utilise un canal qui permet à une goroutine particulière d'incrémenter le compteur. Si on lance ce programme, on pourra constater qu'il permet de créer plusieurs centaines de milliers de goroutines avant d'être tué par le noyau quand toute la mémoire aura été consommée.

Polémique sur la gestion de la mémoire

Le ramasse-miette utilisé par l'implémentation actuelle de Go est conservatif (par opposition à précis, conservative vs precise en anglais). Cela veut dire qu'il peut « oublier » de libérer certaines zones mémoires. Certaines personnes ont rencontré des problèmes en 32 bits où des entiers peuvent être mal interprétés par le ramasse-miettes comme des pointeurs pouvant conduire à des fuites de mémoire. Dans la mesure du possible, il est recommandé d'utiliser du 64 bits pour éviter ces problèmes (le risque de confusion est extrêmement plus faible). Les développeurs de Go vont travailler sur ce problème mais le ramasse-miettes est un sujet qui demande du temps et il faut donc s'attendre à une évolution progressive sur le long-terme pour ce point.

Aller plus loin

  • # 2 petites précisions

    Posté par  . Évalué à 9.

    1. Je suis la ml Go depuis depuis pas mal de temps déjà et elle est très active. C'est assez impressionnant de voir un langage aussi jeune avec une telle communauté (sur les différentes mls de langages que j'ai pu fréquenter, seule la ml Python principale est plus active).

    2. Le problème de mémoire semble aussi se produire sur 64 bits.

    Après pas mal de tests de langages ces derniers mois, je pense que je vais partir sur le duo Python + Go (avec un peu de Lua par ci par la).

    • [^] # Re: 2 petites précisions

      Posté par  . Évalué à 7.

      Après pas mal de tests de langages ces derniers mois, je pense que je vais partir sur le duo Python + Go (avec un peu de Lua par ci par la).

      Pour faire quoi ? Pourquoi ? Y a t'il un pont entre ces deux langages ?

      Personnellement je trouvais la syntaxe pas terrible (d'un point de vu pratique), mais depuis quelques jours je l'utilise et on s'y retrouve très bien.

      Il me semble que c'est un langage qui a le mérite de donner un coup de jeune à l'impératif/structuré qu'on a toujours tendance à voir par le C avec ses spécificités bas niveau (gestion manuelle de la mémoire, typage simple voir simpliste, bibliothèque standard réduite, etc).

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

    • [^] # Re: 2 petites précisions

      Posté par  . Évalué à 3.

      Une autre précision pendant qu'on y est, le lien vers le wiki fedoraproject.org est obsolète, la feature a été abandonné depuis.
      Pas de paquets à jour pour go, chose que je regrette mais je manque cruellement de temps pour m'en occuper. :(

  • # bientôt...

    Posté par  . Évalué à 10.

    Vivement le Go 2, pour le retour du goto

  • # Intérêt

    Posté par  (site web personnel) . Évalué à 9.

    Bonjour,

    Je vais évidemment poser la sempiternelle question : quel intérêt ?

    C'est une vraie question, hein ! Pas une affirmation déguisée en question.

    Voilà, go est présenté comme un langage compilé avec les avantages de l'interprété intégrant la gestion de la concurrence.

    Problèmes actuels :

    • Ramasse-miette … à la ramasse.
    • J'ai lu ici et là que s'il compile vite, il n'est pas très rapide.
    • Les bibliothèques manquent, forcément.

    Bon, il n'est pas difficile de trouver des langages interprétés qui peuvent être compilés, ni qui gèrent la concurrence, et qui disposent de bonnes bibliothèques, d'un bon ramasse-miette et sont rapides.

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

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

    Cette assemblage compilé / concurrence / "style" interprété est-il vraiment original et suffisant pour faire la différence ?

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

    • [^] # Re: Intérêt

      Posté par  . Évalué à -1.

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

      ça dépends de si il devient successful ou pas.

    • [^] # Re: Intérêt

      Posté par  . Évalué à 9.

      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)

      • [^] # Re: Intérêt

        Posté par  (site web personnel) . Évalué à 5.

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

        Apparemment Go est moins performant que Java: http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Intérêt

          Posté par  . Évalué à 10.

          Tu veux dire que Go est lent?

        • [^] # Re: Intérêt

          Posté par  (site web personnel) . Évalué à 1.

          Je pense que ça va s'améliorer avec les prochaines versions. Là on parle de Go qui a débuté en 2007 par rapport à Java qui a débuté en 1995. Java était affreusement lent au début et ça s'est grandement amélioré au fil des années.

          • [^] # Re: Intérêt

            Posté par  (site web personnel) . Évalué à 4.

            Dans ce cas quel intérêt d'utiliser go aujourd'hui?

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Intérêt

              Posté par  (site web personnel) . Évalué à 7.

              De profiter des améliorations de performances futures :-)

              Non plus sérieusement, Go a tout un tas d'éléments intéressants : les goroutine, la modélisation par interface plutôt que par héritage, …

            • [^] # Re: Intérêt

              Posté par  . Évalué à 5.

              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.

        • [^] # Re: Intérêt

          Posté par  . Évalué à 1.

          Il n’y a quand même pas que la vitesse qui compte.
          Sinon, il faut absolument que tu passes au Fortran, comme le démontre ton lien.

        • [^] # Re: Intérêt

          Posté par  . Évalué à 4.

          C’est toujours plus rapide que Python.

    • [^] # Re: Intérêt

      Posté par  . Évalué à 9.

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

      Cette assemblage compilé / concurrence / "style" interprété est-il vraiment original et suffisant pour faire la différence ?

      Je ne suis pas un expert du Go, mais j’attends vraiment beaucoup de ce langage.
      Parce qu’il abolit, comme le dit sa présentation, le choix qu’on avait à faire entre un langage moderne, simple et lisible comme Python ou Ruby et un langage compilé, rapide, mais illisible comme le C++. Il n’y a pas à gérer les makefiles. De plus, il produit des binaires pour Linux, Windows et Mac OS.

      Connaissant le C, j’avais bien essayé de mettre au C++, mais après des années de PHP et de Python, je trouvais ça vraiment pénible. Difficile de trouver plus affreux à mes yeux.

      La syntaxe de Go n’est pas nécessairement celle que j’aurais choisie, mais elle a le mérite d’être quand même assez claire, et surtout de ne pas permettre toutes les conneries du C++.

      Donc, oui, Go est un langage jeune qui manque encore de certaines choses, mais je suis très confiant en son potentiel. Je m’y mettrai certainement quand on trouvera un bon choix de bouquins, ce qui ne saurait tarder.

      • [^] # Re: Intérêt

        Posté par  . Évalué à 3.

        Connaissant le C, j’avais bien essayé de mettre au C++, mais après des années de PHP et de Python, je trouvais ça vraiment pénible. Difficile de trouver plus affreux à mes yeux.

        De mon côté, après avoir été habitué à OCaml, C et C++, j'ai essayé de me mettre au Sage (c'est du Python mutant pour faire des maths). Ben je préfère encore les std::tr1::unordered_map<std::string, int>::const_iterator à la syntaxe illisible et au typage non-explicite du Python.

      • [^] # Re: Intérêt

        Posté par  . Évalué à 3.

        Connaissant le C, j’avais bien essayé de mettre au C++, mais après des années de PHP et de Python, je trouvais ça vraiment pénible.

        Ce qui manque au C++, c'est un IDE performant comme l'est eclipse pour Java. Les développements seraient bien plus simplifiés.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Intérêt

          Posté par  (Mastodon) . Évalué à 9.

          Genre un truc comme Visual Studio ?

          • [^] # Re: Intérêt

            Posté par  . Évalué à 3.

            La dernière fois que je l'ai essayé, j'ai été très déçu, on m'en avait dit énormément de bien et je ne l'ai pas trouvé très pratique.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Intérêt

            Posté par  (site web personnel) . Évalué à 3.

            ou comme eclipse CDT?

            • [^] # Re: Intérêt

              Posté par  . Évalué à 4.

              C'est très loin d'être aussi performant que l'équivalent pour le développement Java.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Intérêt

          Posté par  . Évalué à 10.

          Ce qui manque au C++, c'est un IDE performant comme l'est eclipse pour Java.

          Genre un Vim ou Emacs où on a rajouté des malloc(rand()); un peu partout ?

          • [^] # Re: Intérêt

            Posté par  . Évalué à 4.

            J'ai déjà fait tourner sans problème eclipse et jboss en même temps pour développer une appli, alors niveau consommation mémoire, ça tient bien. Par contre, ça l'avantage de la refactorisation (y compris des noms de fichiers), l'autocomplétion contextuelle (y compris pour les méthodes à implémenter)…

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Intérêt

          Posté par  (site web personnel) . Évalué à 2.

          Ce qui manque au C++, c'est un IDE performant comme l'est eclipse pour Java.

          Ca tombe bien Eclipse permet de faire du C++! Tu as aussi Qt Creator en plus léger.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Intérêt

            Posté par  . Évalué à 8.

            Ben eclipse avec le C++, c'est loin d'être ça, c'est fort buggé: avec certains projets je n'ai pas trouvé le moyen de compilé sans lancer (le bouton "compile" reste grisé et impossible de définir des cibles), quand il y a des erreurs et qu'elles sont corrigées, il faut attendre la prochaine compilation pour que les marques d'erreurs disparaissent, il manque des warnings pour des erreurs classiques (genre: il semble que vous n'avez pas définit cette méthode). Si on modifie le .h, le .cpp n'est pas modifié en conséquence (et inversément). Les includes ne sont pas ajoutés automatiquement non plus.

            Qtcreator, c'est ce que j'utilise en ce moment (parce qu'il gère bien mieux cmake et le debbugage marche super bien) mais le refactoring n'est pas top ni la modification .h/.cpp.

            Celui que je trouve le plus prometteur, c'est Kdevelop mais les derniers tests que j'ai fais m'ont montré qu'il était encore un peu trop buggé

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Intérêt

          Posté par  . Évalué à 2.

          On ne peut certes pas encore le qualifier de performant, mais anjuta est un IDE prometteur.

          • [^] # Re: Intérêt

            Posté par  (site web personnel, Mastodon) . Évalué à 10.

            Le seul problème d'Anjuta, c'est que ça fait déjà 13 ans qu'il est prometteur :(

            • [^] # Re: Intérêt

              Posté par  . Évalué à 3.

              Sauf que maintenant c'est un projet GNOME, ce qui peut permettre d'améliorer les choses. Et puis le développement a été assez aventureux au cours de son histoire, avec des fusions, des ré-écritures, des portages,… Les choses semblent s'être calmées maintenant.

              • [^] # Re: Intérêt

                Posté par  . Évalué à 10.

                Sauf que maintenant c'est un projet GNOME, ce qui peut permettre d'améliorer les choses.

                J'ai ri !

                • [^] # Re: Intérêt

                  Posté par  . Évalué à 0.

                  Je commence à être lassé de cet anti-gnomisme primaire. Ce n'est même pas du troll, ça ne se renouvelle pas, c'est toujours pareils, et c'est même pas drôle.
                  Le troll est un art dont manifestement sur DLFP beaucoup de maîtrisent pas les arcanes.

                  Petits exemples de trolls entre amis :

                  • Bah oui, d'ici peu, ils vont recorder anjuta en javascript/CSS, pour lui donner plus de poids…en mémoire.
                  • Bah oui, comme ça ils vont pouvoir reprendre les technos de Qt creator, mais différemment, parce que bon, faut pas déconner quand même. Et comme ça sera mieux, ça deviendra un standard freedeskop.
                  • Bah oui, comme ça ils enlèveront toutes les fonctionnalités compliquées. Puis comme coder c'est compliquer, ils vont supprimer le support des langages existants. Pas assez userfriendly. Ils travaillent sur une interface allégée et visuelle ou tu codes en coloriant des images de GNU et de manchots.

                  Enfin, ceci dit, je suis heureux de t'avoir fait rire, c'est toujours ça de pris/

                  • [^] # Re: Intérêt

                    Posté par  (site web personnel) . Évalué à 7.

                    Je commence à être lassé de cet anti-gnomisme primaire

                    En même temps tu l'as un peu cherché quand même…

                    Sauf que maintenant c'est un projet GNOME, ce qui peut permettre d'améliorer les choses.

                    Surtout, parler d'amélioration. A la rigueur il faut parler d'épuration.

                    Allez, dit nous plutôt en quoi Anjuta serait intéressant, cette fois. En quoi ce serait pertinent par rapport aux autres IDE.

                    • [^] # Re: Intérêt

                      Posté par  . Évalué à 5.

                      Surtout, parler d'amélioration. A la rigueur il faut parler d'épuration.

                      Non, ça c'est un point Godwin.

    • [^] # Re: Intérêt

      Posté par  . Évalué à -4.

      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 (+ quid des librairies ? et les perfs c'est pas ça apparemment…)

      • [^] # Re: Intérêt

        Posté par  . Évalué à 7.

        • 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.

      • [^] # Re: Intérêt

        Posté par  (site web personnel) . Évalué à 7.

        Scala c'est sympa, les idées sont bonnes, mais c'est horriblement complexe. La surcharge des opérateurs et quelques autres features (parenthèses optionnelles) font que j'ai souvent trouvé extrêmement difficile de lire du code d'une librairie que je n'avais pas écrite. J'ai l'impression qu'à chaque librairie je dois réapprendre un langage spécifique à la librairie.

        Rien que la bibliothèque standard est franchement pas facile à lire. Par exemple la définition des opérateurs pour la classe Map, il me faut 5 minutes pour comprendre la déclaration. La brieveté c'est sympa, mais parfois on comprends mieux avec des mots à la place d'opérateurs surchargés.
        http://www.scala-lang.org/api/current/index.html#scala.collection.Map

        Alors après, on peut faire des trucs super lisibles en Scala. Mais quand même la librairie standard abuse de la redéfinition des opérateurs, c'est pas franchement le bon exemple.

        • [^] # Re: Intérêt

          Posté par  . Évalué à 2.

          Faut pas exagérer :) scala n'est pas plus complexe ou implicite que ruby ou python, par contre il est plus carré dans la mesure où tout est typé (et c'est ça son point fort à mon sens : ça évite un joyeux bordel, qu'on aime ou pas). Après pour la lisibilité c'est une question d'habitude aussi…, mais c'est un peu le propre de ces nouveaux langages fonctionnels que de permettre de faire beaucoup de choses proprement et rapidement, et en général c'est pour ça qu'ils sont si appréciés.

          (Pour info, non je suis pas un amoureux de scala, ça m'étonnait juste que personne n'en parle étant donné que l'article commence par «langage de programmation généraliste à typage statique, disposant d'un ramasse-miettes et de facilités pour gérer la concurrence. Ses avantages sont d'être concis et expressif, de compiler très rapidement et de proposer les performances d'un langage compilé avec la souplesse d'un langage interprété.», à tout casser ça fait un mois que je m'y intéresse…)

          @Moonz: Ton argument sur la simplicité est un troll, et la complexité de l'écosystème java se résume ici à :
          dans n'importe quel fichier script.sh
          #!/bin/sh
          exec scala "$0" "$@"
          !#
          object HelloWorld {
          def main(args: Array[String]) {
          println("Hello, world! " + args.toList)
          }
          }
          HelloWorld.main(args)

          (bref, hôpital, charité toussa).

          • [^] # Re: Intérêt

            Posté par  . Évalué à -1.

            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 ?

            • [^] # Re: Intérêt

              Posté par  . Évalué à 3.

              Si tu cherches de la doc en valeur, tu peux jetter un œil à : http://www.scala-lang.org/node/166
              Sinon pour le http, ça se résume surtout au framework que tu choisis d'utiliser. Je te conseille de jetter un oeil à Play! pour qui ça se résume à :
              $ play new helloworld
              $ cd helloworld && play run

            • [^] # Re: Intérêt

              Posté par  . Évalué à 9.

              Tu mélanges un peu tout. Si tu as besoin d'une fonctionnalité non fournie par le runtime dans n'importe quel langage il va falloir mettre un dépendance à un endroit:
              - en C à l'endroit par defaut ou dans ton LD_LIBRARY_PATH
              - en Python à l'endroit par defaut ou dans ton PYTHONPATH
              - en JS, tu inclus ta lib en lui disant l'endroit où le trouver
              - en Java en le mettant dans ton classpath

              La même chose pour tous.

              Maintenant si tu veux que tes libs arrivent toutes seules au bon endroit avec la bonne version, y'a pas de magie il faut des outils pour ca:
              - en C rien. Le boulot est fait par les distros mais si tu veux un truc précis tu te paluches tout à la main
              - en Python, tu fais joujou avec pypi, les virtualenv & co
              - en JS, tu indiques le bon endroit
              - en Java, tu utilises Maven ou un de ses potes.

              Bref si tu veux pas utiliser les outils de gestion de dépendance tu peux, comme tu ferais en C. Et si tu veux les utiliser tu peux aussi.

              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, ni a quoi ca sert de comparer un workflow sur des hello world. Maven on peut critiquer la réalisation, mais ça répond à un vrai besoin. Et je connais aucun environnement où les mêmes fonctionnalités viennent gratuitement où a un coup beaucoup moins élevé.

            • [^] # Re: Intérêt

              Posté par  . Évalué à 2.

              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 ?

              Pourquoi cherches-tu des excuses ? Tu fais ce que tu veut et tu choisi le ou les langages qui te botte le plus, pas la peine de chercher à te trouver des excuses. Ce qui fait réagir c'est de présenter de mauvais arguments. Personne ne te demande d'en présenter (enfin sauf si tu dis « X ça pue »).

              maven on met peut être un peu de temps à le prendre en main (ça a était mon cas), mais une fois fait il fait son job. Un peu comme ses alternatives (make compris). Comme pour les autres on peut s'y mettre de manière progressive (ne gérer que la compilation, puis ajouter les dépendances, puis le déploiement automatique, le reporting, etc).

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

              • [^] # Re: Intérêt

                Posté par  . Évalué à 2. Dernière modification le 11 avril 2012 à 10:46.

                • 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.

                • [^] # Re: Intérêt

                  Posté par  (site web personnel) . Évalué à 7.

                  J'ai lu un peu de travers, mais quelques points tout de même.

                  Franchement, si tu ne veux pas te prendre la tête utilise Gradle et non maven (gradle lit les dép maven). C'est beaucoup plus agréable. Maven c'est bien, c'est bien pour certaines parties des dépendances, mais c'est chiant.

                  Et pour faire du http, soit tu prends un truc comme play (on va dire en gros que c'est comparable à utiliser un symfony ou rails sur le principe) soit tu fais plus léger, moins guidé, mais à la main (c'est la solution que je préfère).

                  Par exemple, voici un petit fichier gradle qui te met à dispo tout ce qu'il faut :

                  apply plugin: 'java'
apply plugin: 'application'
apply plugin: 'eclipse'

sourceCompatibility = 1.6
version = '0.1.0'

mainClassName = "main.Main"

repositories {
  mavenCentral()
}

dependencies {
  compile group: 'com.google.inject',            name: 'guice',                version: '3.0'
  compile group: 'com.google.inject.extensions', name: 'guice-assistedinject', version: '3.0'
  compile group: 'com.google.inject.extensions', name: 'guice-servlet',        version: '3.0'
  compile group: 'com.sun.jersey.contribs',      name: 'jersey-guice',         version: '1.9-ea06'
  compile group: 'org.eclipse.jetty',            name: 'jetty-server',         version: '8.0.0.M3'
  compile group: 'org.eclipse.jetty',            name: 'jetty-servlet',        version: '8.0.0.M3'
  compile group: 'com.sun.jersey',               name: 'jersey-server',        version: '1.9-ea03'
  compile group: 'com.sun.jersey',               name: 'jersey-core',          version: '1.9-ea03'
  compile group: 'com.google.code.gson',         name: 'gson',                 version: '2.1'
  compile group: 'com.google.guava',             name: 'guava',                version: '11.0.1'
  compile fileTree(dir: 'libs', include: '*.jar')
}

                  En gros :

                  • compile du java
                  • lance en tant qu'application
                  • fourni un projet eclipse
                  • utilise le dépot central de maven
                  • charge un certain nombre de dépendances, entre autre :
                    • Injection de dépendances avec Guice (nikel)
                    • Jetty comme serveur web
                    • guice, jetty, jersey pour coder simplement une appli web (sans war, sans webapp, juste de l'injection, des servlets et du REST)
                    • gson pour faire du json
                    • guava parce que c'est bien (cache par exemple)
                    • et surtout, chargement des .jar locaux, ne provenant donc pas de maven. Parfait pour mixer dépendances d'un repository et jar buildés à la main (chose que maven ne permet pas comme ça)

                  Avec une base de ce genre, tu est tranquille pour développer.

                  Et en gros ton appli se résume à ça :

                  /**
   * Run the Jetty server with a default Guice handler
   * @throws Exception Exceptions
   */
  public void run() throws Exception {
    server = new Server(port);

    ServletContextHandler sch = getDefaultContextHandler();
    sch.addEventListener(new MyServletConfig());

    server.setHandler(sch);

    server.start();
    server.join();
  }

  /**
   * @return a default servlet context handler using Guice.
   */
  private ServletContextHandler getDefaultContextHandler() {
    ServletContextHandler sch = new ServletContextHandler(ServletContextHandler.SESSIONS);
    sch.setContextPath("/");

    sch.addFilter(GuiceFilter.class, "/*", null);
    sch.addServlet(DefaultServlet.class, "/");

    return sch;
  }

                  Le problème c'est que c'est loin d'être la manière "classique" de faire en java. Beaucoup de monde est resté enfermé dans une logique JEE totalement monstrueuse, bien bourrine et surtout absolument pas agréable.
                  Avec un truc du genre du peu enfin coder "facilement" en java sans te prendre trop la tête.

                  • [^] # Re: Intérêt

                    Posté par  (site web personnel) . Évalué à 1.

                    Ta solution m'intéresse : on croirait retrouver la légèreté d'un framework python ou ruby. Aurais-tu un lien vers un exemple complet, même minimaliste façon Hello world ?

                    • [^] # Re: Intérêt

                      Posté par  (site web personnel) . Évalué à 5.

                      Non, pas sous la main. J'ai des bribes mais qui contiennent des choses en plus, notamment l'utilisation de Google Closure tools (stylesheet, compiler et surtout, templates - une merveille).

                      Par contre, pour aller un peu plus loin, voici comment déclarer des filtres, ressources REST et servlets. Cette classe correspond au MyServletConfig de l'exemple précédent.

                      public class MyServletConfig extends GuiceServletContextListener {
  @Override
  protected Injector getInjector() {
    return Guice.createInjector(new JerseyServletModule() {
      @Override
      protected void configureServlets() {
        filter("/admin/*").through(AuthFilter.class); // web filter pour protéger /admin

        serve("/index.html").with(IndexServlet.class); // un index basique (oui, je ne sert pas mon html en statique mais avec des templates soy, c'est plus rapide et plus efficace, paramétrable, toussa)

        serve("*.html).with(MyServlet.class);

        bind(GsonBodyWriter.class); // permet de sérialiser toute réponse jersey en json

        bind(User.class); // une ressource jax-rs classique
        bind(Right.class); // idem
        serve("/*").with(GuiceContainer.class); // tout ce qui est en /* et qui n'a pas déjà été matché est capté par jax-rs
      }
    });
  }
}

                      voir http://code.google.com/p/google-guice/wiki/ServletModule par exemple

                      Si jamais je trouve le temps, je collerai un petit exemple un de ces jours.

                      • [^] # Re: Intérêt

                        Posté par  (site web personnel) . Évalué à 4.

                        Allez, c'est vraiment parce que je suis de bonne humeur aujourd'hui…

                        http://www.baregit.com/crev/taist

                        Récupérer le projet par git
                        gradle run

                        http://localhost:8080/index.html http://localhost:8080/hello http://localhost:8080/hello/world

                        C'est pas hyper joli, mais c'est un projet existant auquel j'ai enlevé pas mal de trucs (notamment tout ce qui est closure) ce qui explique par exemple le module d'injecteur vide.

                        Voilou, après il "suffit" d'aller lire les docs de Google Guice et jersey en gros.

                        Ce qu'il manque pour ce soit bien dans cet exemple : un filtre gzip. Mais en général j'ai un frontal qui le fait (apache)

                        • [^] # Re: Intérêt

                          Posté par  (site web personnel) . Évalué à 1.

                          Merci !
                          Bon je dois être un boulay, je n'arrive pas à récupérer avec git.

                          • [^] # Re: Intérêt

                            Posté par  (site web personnel) . Évalué à 2.

                            Ha oui, je pense que le clone anonyme n'est simplement pas dispo…
                            Le dépôt indiqué est ouvert en read only, mais je pense qu'il te faut un compte sur baregit pour pouvoir faire le clone : http://www.baregit.com/account/register/alpha

                            Si tu peux, crée un compte, test, et dit moi si ça fonctionne.

                            • [^] # Re: Intérêt

                              Posté par  (site web personnel) . Évalué à 1.

                              J'ai crée un compte et tenté de cloner sans succès. Ça vient peut-être de moi, je débute avec Git. J'ai envoyé une demande au support, et je reviens ici pour la conclusion.

                              • [^] # Re: Intérêt

                                Posté par  (site web personnel) . Évalué à 3.

                                As-tu réussi ?

                                Si besoin, j'ai créé un miroir ici : https://github.com/CrEv/Taist
                                Pour builder, il y a besoin de builder avant Closure templates (soy) que tu pourra trouver ici : https://github.com/CrEv/closure-templates Il s'agit d'un fork du projet de Google avec juste une update de la version de Guava, histoire d'être compatible avec mon code.
                                Une fois buildé closure, pose le jar dans lib/ et tu peux faire un gradle run pour voir ce que ça donne, http://localhost:8080/hello/world te servira une page fournie par un template soy.

                                • [^] # Re: Intérêt

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Je n'ai pas eu de nouvelles de Baregit, c'est dommage, ça leur fait de la mauvaise publicité.

                                  J'ai dû ajouter l'option suivante pour compiler soy, car j'ai un environnement Java 1.7 et l'option source="1.6" demande à passer le rt.jar de l'environnement 1.6 que je n'ai pas :

                                  <compilerarg value="-Xlint:-options"/>

                                  Sinon j'ai réussi à le lancer (mais pas à stopper le serveur Jetty, je suis sous Windows Seven + cygwin). Ça marche bien. Les artéfacts téléchargés montent à 6 Mo d'espace disque, à dix mille lieues d'un repository Maven équivalent. Merci !

                                  • [^] # Re: Intérêt

                                    Posté par  (site web personnel) . Évalué à 2.

                                    Ha ben de rien.
                                    Pour arrêter jetty, moi c'est CTRL+C ;-)

                                    Ha tiens, pas testé avec java 7.

                                    En fait il n'y a pas tant de dépendances que ça surtout. Je vais rajouter progressivement les autres outils closure, mais ça reste mesuré.

                                    Bon alors, au final, facile ou non de faire du web sympa en java ?

                                    j'oubliais, si tu veux, passes moi ta modif pour le build de soy, je la rajouterai.

                                    • [^] # Re: Intérêt

                                      Posté par  (site web personnel) . Évalué à 2.

                                      Justement, Ctrl+C n'a pas marché, ni Ctrl-Break ou toute autre combinaison à laquelle j'ai pu penser.

                                      Il faudrait peut-être rajouter une cible gradle pour stopper le serveur sans avoir la main dessus.

                                      Pour la modification de soy, je t'ai envoyé un Pull Request sur GitHub.

                                      Bon, on va peut-être arrêter de spammer cette dépêche. Maintenant que tu es lancé, je t'encourage à en faire un journal ici même, ça permettra à d'autre de découvrir et de discuter dessus.

                                  • [^] # Re: Intérêt

                                    Posté par  (site web personnel) . Évalué à 2.

                                    Retour sur Baregit : le support a mis du temps à répondre, mais j'ai eu un retour ce dimanche à 12h40 :) me proposant de tester la connexion via SSH. En suivant cette piste (et une heure plus tard), j'ai compris que j'avais simplement copié la mauvaise clef SSH.
                                    Donc j'ai finalement plus cloner le repo depuis Baregit.

                                    Mea culpa, je suis un boulay. Enfin c'est comme ça qu'on apprend, et j'ai énormément appris en une semaine sur Git et les connexions SSH.

                • [^] # Re: Intérêt

                  Posté par  (site web personnel) . Évalué à 4.

                  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

                  Maven sert d'abord à compiler, c'est normal que des langages interprétés ne propose pas d'équivalent.

                  Maven gère aussi les dépendances, donc soit ces frameworks proposent un équivalent (gem pour Ruby par exemple), soit ils te laissent gérer ça à la main, ce qui est généralement un cauchemar.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Intérêt

                  Posté par  . Évalué à 6.

                  Par contre, en Java, non seulement le classpath n’est pas défini par la distrib, […]

                  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.

                  mon package, la version de la lib installée (je met à jour fubar-1.2.3.jar en fubar-1.2.4.jar

                  Pas plus qu'en python ou en C si tu utilises un répertoire unique.

                  D’où mon scepticisme sur la possibilité de se passer de systèmes de gestion que je trouve pénibles genre maven

                  Heu tu peux t'en passer si tu n'as pas ce besoin. C'est aussi con que dire que tu es sceptiques sur le fait qu'on puisse se passer des autotools.

                  Maintenant dans le vrai monde, on s'en sert par ce qu'on bosse sur des projets de 100 modules, avec interdépendance, chacun avec des dépendances externes, avec plusieurs branches de production, avec des artifacts pour chaque module et on veut pouvoir construire/tester/livrer tout ce bordel facilement et le brancher dans de l'intégration continue.

                  Par contre, le premier tutoriel lift sur lequel je tombe, je me mange du Maven. Soit je n’ai pas de chance

                  Mauvais tutorial ou simplement fais pour des gens qui vont pas se limiter au hello world. De toute facon si t'as pas besoin de Maven ne l'utilise pas.

                  ç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

                  Ca ne l'est pas. Si tu as 3 notions de Java tu sais que tout ce que tu as besoin c'est des .class dans ton classpath. Maven est uniquement un outil de build, on peut s'en passer ou le remplacer.

                  Maintenant, les questions du genre « je veux de l’hibernate, c’est toujours aussi simple sans maven ? », elles ne sont pas rhétoriques

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

                  • [^] # Re: Intérêt

                    Posté par  . Évalué à 2.

                    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)

                    • [^] # Re: Intérêt

                      Posté par  (site web personnel) . Évalué à 5.

                      Toutes les distribs se foirent pour bien intégrer Java.

                      Je ne sais pas pour les autres, mais sur Ubuntu c'est bien intégré.

                      En Python, je configure un PYTHONPATH, une bonne fois pour toutes, pour tous mes projets et toutes mes dépendances.

                      C'est une mauvaise pratique, si deux projets dépendent de la même bibliothèque, mais de 2 versions différentes, cette approche va se vautrer lamentablement.

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

                      Sauf si utilises Maven qui te télécharge les bonnes dépendances, gèrent les conflits de version, te génère ton classpath et permet de tout packager dans un seul programme.

                      Tu n’as pas d’équivalent du PYTHONPATH

                      Tu peux utiliser CLASSPATH…

                      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

                      Tu auras de toute façon besoin de compiler ton programme. Refuser d'utiliser Maven, c'est comme refuser d'utiliser une variante de make pour faire du C.

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                    • [^] # Re: Intérêt

                      Posté par  . Évalué à 4.

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

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

                      Aucune n'a autant de ressources pour Java qu'elle n'en ont pour C, C++, perl ou python ?

                      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.

                      Rien n'empêche d'avoir un gros classpath pour tout le monde, mais ce n'est pas une bonne pratique parce que c'est dépendant du système (tu contrôle moins les dépendances de ton projet) et que l'objectif du Java c'est d'être portable.

                      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.

                      Tu trouve les autotools simples ? Personnellement je préfère travailler avec maven. Bien sûr il existe des alternatives au autotools comme CMake que j'aime bien, mais ils restent relativement peu utilisés.

                      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.

                      Aucun outil ne t'enguelera si tu a des bibliothèques dans ton classpath que tu n'utilise pas. Tu peut avoir un gros classpath avec toutes tes bibliothèques, c'est quelque chose qui se faisait beaucoup avant maven. Les outils récents, par leur gestion des dépendances te permettent de ne pas avoir à utiliser un gros classpath. Encore une fois c'est ce que fait virtualenv : il te crée un PYTHONPATH réduit.

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

                      • [^] # Re: Intérêt

                        Posté par  . Évalué à 3.

                        Aucun outil ne t'enguelera si tu a des bibliothèques dans ton classpath que tu n'utilise pas. Tu peut avoir un gros classpath avec toutes tes bibliothèques, c'est quelque chose qui se faisait beaucoup avant maven

                        Pour lui donner un peu raison quand même, le temps de recherche d'une ressource dans le classpath est en O(n) ou n est le nombre de JAR dans ton classpath. L'occupation mémoire est aussi en O(n). C'est un choix de Java de ne pas imposer de hiérarchie pour les ressources mais après il faut les retrouver.

                        Il y a clairement des différences d'approche entre python et java. Chacun a ses avantages et ses inconvénients. Il faut bien comprendre comment ca marche et t'y plier. Tu ne gagnes jamais à vouloir tordre quelque chose (cf. 80% des utilisateurs de maven).

                    • [^] # Re: Intérêt

                      Posté par  . Évalué à 2.

                      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

                      J'ai du mal à suivre ce que tu cherche ? Tu ne veux pas utiliser d'outils, mais ne pas gérer les choses à la main ? (c'est une vraie question)

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

                      • [^] # Re: Intérêt

                        Posté par  . Évalué à 0.

                        Je répond juste à cette question directe pour clarifier : (oui, j’ai du mal à tenir mes propres don’t feed the troll ;))

                        Je conçois la nécessité d’un outil de compilation pour un langage compilé. Mais je veux qu’il reste simple : si, au nom de la gestion des dépendances, de l’intégration continue, ou que sais-je encore, je me retrouve avec une usine à gaz comme maven, je passe.

                        Avant l’outil go, les makefile en gros c’était

                        TARGET=test
GOFILES=test.go foo.go bar.go

                        Note : test.go peut très bien utiliser des libs, j’ai rien à déclarer dans le makefile, c’est juste que c’est de ma responsabilité de les installer avant de compiler.

                        C’est ça que je cherche. La suggestion de CrEv s’en rapproche pas mal, mais il y a toujours une gestion des dépendances. Je crains que cette gestion soit inévitable en Java, et c’est ça que j’appelle « lourdeur de l’écosystème Java » : une mini-distribution dans ma distribution.

                        • [^] # Re: Intérêt

                          Posté par  . Évalué à 5.

                          Tu n'as pas à faire de gestion de dépendance si tu n'as pas de dépendance. Dans ton exemple pour Go, il n'y en a pas. Mais c'est très rare qu'un projet n'ai pas de dépendance.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: Intérêt

                            Posté par  . Évalué à 2.

                            J’ai explicitement dit le contraire : test.go peut avoir autant de dépendances externes qu’il le veut, juste que c’est à moi de m’assurer qu’elles sont installées dans $GOROOT/lib. Exactement comme en Python quoi.

                            (ça a un peu changé avec l’outil go, mais le principe : « pas de déclaration des dépendances dans un makefile » est resté)

                            • [^] # Re: Intérêt

                              Posté par  . Évalué à 3.

                              juste que c’est à moi de m’assurer qu’elles sont installées dans $GOROOT/lib.

                              Justement, Maven permet d'éviter de te farcir la gestion des dépendances à la main (ce que tu fais en t'assurant que les dépendances sont dans le répertoire. Sans compter que c'est la merde si tu as deux projets qui dépendent de deux versions de lib différentes.

                              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Intérêt

                          Posté par  . Évalué à 3.

                          C’est ça que je cherche. La suggestion de CrEv s’en rapproche pas mal, mais il y a toujours une gestion des dépendances. Je crains que cette gestion soit inévitable en Java, et c’est ça que j’appelle « lourdeur de l’écosystème Java » : une mini-distribution dans ma distribution.

                          Eclipse et netbeans utilisent encore Ant par défaut. C'est à dire un simple langage de script portable (et moche). Ajouter une dépendance c'est ajouter un fichier .jar dans un dossier (lib/ si je ne me trompe pas). Encore une fois c'est la gestion par défaut des 2 IDEs les plus utilisés (je en sais pas pour InteliJ).

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

                        • [^] # Re: Intérêt

                          Posté par  (site web personnel) . Évalué à 3.

                          une mini-distribution dans ma distribution.

                          Alors ça c'est ce que font quasiment tous les langages aujourd'hui. cpan, gem, easy_install, pear, etc.
                          Ils font quasiment tous, par certains côtés, doublons avec le système de package de ta distrib. Idem pour go avec go get…

                          Gradle te permet ça de manière simple, notamment la dernière ligne qui te charge tous les jars d'un ou plusieurs répertoire.
                          Donc tu peux faire exactement pareil, tu n'as qu'à mettre un compile fileTree(dir: '/usr/share/java', include: '*.jar') et c'est terminé.
                          Et hop, pas besoin de gérer des dépendances maven ou autre, tu n'as qu'à poser tes jars comme tu veux.

                          Maintenant, je pense tout de même que c'est une mauvaise solution.
                          Pire, je développe en OSGi donc il m'est possible d'avoir n versions d'une même lib exécutées en même temps dans le même projet global. Et là, tu es bien obligé de gérer les dépendances.

                          Donc au final : tu veux faire un projet un peu important ? Utilise les dépendances, le format de dépendance maven par exemple, au travers de gradle c'est le plus simple.
                          Tu veux faire un petit projet ou ne pas te prendre la tête ? Copie les jars souhaités dans un répertoire quelconque (comme tu ferais avec n'importe quel langage) et utilise gradle de la manière suivante :

                          apply plugin: 'java'
apply plugin: 'application'

sourceCompatibility = 1.6
version = '0.1.0'

mainClassName = "main.Main"

dependencies {
  compile fileTree(dir: 'libs', include: '*.jar')
}

                          C'est quand même pas bien dur, c'est très lisible, il n'y a pas besoin de plus. Rien à faire de spécial, avec ça tu es comme avec la majorité des langages.
                          Tu met un répertoire src/main/java avec tes sources, src/main/resources pour tes ressources et c'est terminé.
                          gradle run et tu exécute ton main.

                          Franchement, c'est hyper simple.
                          Mais il faut sortir des sentiers classiques de java.

                          D'ailleurs, j'encourage quiconque utilisant maven à tester rien qu'une fois Gradle. Ca surclasse réellement maven.

                          • [^] # Re: Intérêt

                            Posté par  . Évalué à 3.

                            Donc tu peux faire exactement pareil, tu n'as qu'à mettre un compile fileTree(dir: '/usr/share/java', include: '*.jar') et c'est terminé.

                            Avec Apache Ant (oui c'est verbeux).

                            <classpath>
    <fileset dir="lib">
        <include name="lib**/*.jar"/>
    </fileset>
</classpath>

                            Avec maven :

                            <dependencies>
    <dependency>
        <groupId>test</groupId>
        <artifactId>test</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${basedir}/lib/test.jar</systemPath>
    </dependency>
</dependencies>

                            Je présenterais pas la méthode en buildr parce que je ne le connais pas.

                            Mais il faut sortir des sentiers classiques de java.

                            Je ne crois pas. Il y a encore une quantité énorme de projets qui n'utilisent pas les outils post-maven. Les IDE travaillent encore comme ça par défaut. Donc je ne sais pas ce que c'est les sentiers battus, mais je ne crois pas que la solution à la main soit si mal vue que ça (même si je pense qu'il n'y a pas de raison d'utiliser ces outils).

                            D'ailleurs, j'encourage quiconque utilisant maven à tester rien qu'une fois Gradle. Ca surclasse réellement maven.

                            Je n'ai pas de doute quant à la superiorité de gradle. Je n'ai pas encore pris le temps de réellement m'y pencher car, j'ai de toute manière pas le choix au boulot. Par contre il y a deux points qui me semble en retrait chez gradle :

                            • l'intégration dans les IDE : moi personnellement je m'en fout un peu mais pas forcément tout le monde (je présume que le plugin eclipse est fait pour ça, mais d'une part toute le monde ne travail pas sous eclipse, d'autre part comment se passe la synchronisation entre le build.gradle et les fichiers de projet eclipse ?)
                            • les plugins : je ne suis pas certains de trouver la même diversité de plugins gradle que pour maven

                            Dernière question, les tuto et exemple que j'ai vu étaient assez limités : peut-on travailler les fichiers en groovy (ou avec leur DSL issu de groovy) avec gradle ? Par exemple faire l'équivalent d'un sed ou d'un awk, déplacement de fichier, envoie de fichier par scp, appel d'une commande, etc ? C'est un point qui pourrait réellement rencontrer du succès là où je bosse : virer tout les scripts shell mal maitrisés et lent par un langage objet et IDE-ifié.

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

                            • [^] # Re: Intérêt

                              Posté par  (site web personnel) . Évalué à 6.

                              Oué enfin la solution maven ça n'a rien à voir. Là tu donnes une dépendance.

                              je ne sais pas ce que c'est les sentiers battus

                              Ce que je voulais dire par là c'est sortir de la manière "classique" qui vient à l'esprit de beaucoup de monde qui fait du java. Aujourd'hui, en gros, les anciens projets sont gérés en ant, certains nouveaux en maven. Maven est parfois présenté comme le messie mais c'est juste une grosse bouse en réalité et l'intégration dans eclipse des dernières versions est minable (et bourrée de régressions d'ailleurs).
                              Mais c'est comme faire du web avec java. En général les gens pensent soit JEE, JSF, etc mais c'est lourd (inutilement), chiant (très), fun (pas du tout) ou Play! (perso j'aime pas mais c'est juste perso), Grails (moins).
                              Alors qu'en choisissant trois libs tu arrive à quelque chose de réellement sympa pour du java. Mais il faut sortir de la vision classique du java, aller explorer des libs qui proviennent d'autres univers, d'inspiration autre que java.

                              Le problème de certaines remarques c'est que si tu attends que tout le monde passe à autre chose, faut pas s'étonner que ce ne soit pas le cas.

                              gradle eclipse pour avoir ton projet eclipse à jour. Ca revient à la même chose que la dernière version de m2e qui est pas foutu de mettre à jour le projet lorsqu'on modifie le pom. Maven était pas si mal que ça dans eclipse, mais la dernière version est pitoyable !

                              Quels plugins t'intéressent réellement ? Parce qu'il y a beaucoup de choses qui nécessitent un plugin en maven et qui sont déjà là en gradle.
                              Franchement, prend 1h pour lire le début de la doc de gradle, ça ne peut que te faire oublier maven.

                              Pour le dernier point j'en sais rien, pas utilisé ni cherché.

                              • [^] # Re: Intérêt

                                Posté par  . Évalué à 3.

                                Maven est parfois présenté comme le messie mais c'est juste une grosse bouse en réalité et l'intégration dans eclipse des dernières versions est minable (et bourrée de régressions d'ailleurs).

                                Tu es dur avec maven. Il a apporté des éléments très important que gradle réutilise :

                                • gestion des dépendances
                                • cycle de vie du build
                                • définition du projet déclarative

                                La lourdeur de sa syntaxe aurait du s'estomper avec la version 3 ou 3.1, mais ce ne fut pas le cas c'est dommage.

                                Je n'ai probablement pas vu d'intégration de qualité de maven dans eclipse (mais je n'ai pas regardé plus que ça). Netbeans donne une vraie claque à eclipse là dessus : tu modifie le pom => il le prend en compte, tu modifie les propriétés du projet dans netbeans => il modifie le pom (notamment pour l'ajout de dépendance).

                                En général les gens pensent soit JEE, JSF, etc mais c'est lourd (inutilement), chiant (très), fun (pas du tout) ou Play! (perso j'aime pas mais c'est juste perso), Grails (moins).

                                Personnellement, j'ai énormément de mal à me mettre à utiliser des technologies de template toutes simple après avoir touché un an à JSF. JSF n'est probablement pas ce qu'il y a de plus rapide et la courbe d'apprentissage peut paraître compliquée (simple au début, puis compliquée pour enfin redevenir simple), mais j'ai pas encore trouvé d'alternative qui me botte (et oui j'ai regardé Play!, pas encore le lien que tu as donné plus haut).

                                Le problème de certaines remarques c'est que si tu attends que tout le monde passe à autre chose, faut pas s'étonner que ce ne soit pas le cas.

                                Non, c'est pas ce que j'ai voulu dire. Ce que j'ai voulu signifier c'est :

                                Je suis nouveau dans une boite sur un projet qui a commencé bien avant que j'arrive, je n'ai pas le choix du build.

                                Les arguments pour passer à gradle qui peuvent marcher c'est :

                                • la simplicité et/ou l'intégration avec les IDE
                                • la possibilité de hiérarchiser les projets
                                • la possibilité de virer maven, ant et des scripts par un seul outil
                                • bonus : la performance de gradle (le mode deamon) peut marquer beaucoup de points

                                Quels plugins t'intéressent réellement ? Parce qu'il y a beaucoup de choses qui nécessitent un plugin en maven et qui sont déjà là en gradle.

                                On utilise par exemple :

                                <groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId

                                pour faire des wsimport. Du coup je viens de chercher ça semble possible (http://www.prait.ch/wordpress/?p=418)

                                Franchement, prend 1h pour lire le début de la doc de gradle, ça ne peut que te faire oublier maven.

                                C'est plus un week end qu'il me faudrait (je ne dois pas être très rapide).

                                Pour le dernier point j'en sais rien, pas utilisé ni cherché.

                                J'ai trouvé ça :
                                - http://gradle.org/docs/1.0-milestone-2/dsl/org.gradle.api.tasks.Exec.html
                                - http://gradle.org/docs/current/dsl/org.gradle.api.tasks.Copy.html
                                - http://gradle.org/docs/current/userguide/working_with_files.html
                                - http://gradle.org/docs/current/userguide/tutorial_this_and_that.html (ça c'est intéressant)
                                - Pour le remplacement : http://stackoverflow.com/questions/5392875/gradle-replace-text-in-jsp-using-filter

                                Bref il semble qu'il y a de quoi faire (et la documentation semble de meilleure qualité que maven).

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

                                • [^] # Re: Intérêt

                                  Posté par  (site web personnel) . Évalué à 3.

                                  Tu es dur avec maven

                                  Oui, mais c'est juste ce qui ressort de mon expérience (mais je ne viens pas du java, ceci explique sûrement cela)

                                  gestion des dépendances

                                  Oui et non. Oui car la dépendance de maven est utilisée dans gradle par exemple. Non car gradle l'étend suffisamment pour ce que soit plus intéressant de se passer de maven.

                                  cycle de vie du build

                                  Celui de maven est une plaie. Impossible de faire facilement ce qu'on veut. Associé au côté purement déclaratif il est très complexe de faire ce qu'on souhaite.

                                  Un exemple bidon : une webapp, à builder sous forme de war. Du code java et des fichiers js. Avant le packaging, compilation des fichiers js, minification, suppression des fichiers sources initiaux. En plus, modification dans certains fichiers de web-inf suivant un profile. Faire ça en maven c'est horrible voir impossible. On est alors résumé à, au mieux, utiliser ant (ce qui est absolument contraire au principe du déclaratif) ou faire un plugin maven (c'est pas bien compliqué, mais loin d'être quelque chose de logique, surtout si on doit en faire un par webapp)

                                  Concernant JSF. JSF en soit n'est pas une trop mauvaise techno. Mais c'est, à mon avis, une mauvaise approche. Pour ma part, les interfaces c'est devenu du templating puissant, facilement (très) internationalisable, qui s'exécute aussi bien côté client que serveur. Avec ça aussi facile de faire de l'ajax, que du pas ajax, qu'un mélange des deux (par exemple en utilisant history). Et fini les composants js, une interface c'est du html, du css, du js simple. Fini la majorité des composants tout fait qui ne conviennent jamais. Le template sort d'ailleurs n'importe quelle donnée (je me sert parfois des templates pour me pondre de l'xml ou du json, bien bien plus agréable que d'utiliser des documents xml par exemple). L'interface au final c'est avant tout du html pur. (bon, ça ne veut pas dire qu'on utilise jamais autre chose hein, jamais de lib). Mais la lib elle est vraiment gérée côté client, pas côté serveur.
                                  Je sais pas si c'est vraiment clair, mais en gros j'en suis totalement revenu du jsf, vaadin, etc. Même play ça ne me tente plus vraiment, je préfère vraiment ma soluce, un peu maison, beaucoup plus assemblage de composant. Je trouve ça plus pratique.

                                  Ha ben non, pas des webservices quand même ! ;-)
                                  Heureusement qu'il y a de quoi générer les wsdl (ou à partir) sans quoi ce serait vraiment horrible…

                                  Bon, sinon, maven a des choses sympa, typiquement les archetypes. Je sais pas si un équivalent existe en gradle, au pire rien n'empêche, je pense, de créer un archetype pour faire un projet gradle. Enfin faut voir. Mais dans tous les cas c'est bien ça.

                                  la simplicité et/ou l'intégration avec les IDE

                                  C'est là où gradle est bien je trouve, lorsque je modifie mon fichier gradle, au mieux un coup de gradle eclipse et c'est ok. C'est sur que ce serait mieux si c'était intégré, mais j'ai même pas cherché.

                                  la possibilité de virer maven, ant et des scripts par un seul outil

                                  C'est bien, en partie, dans cet objectif que je pense l'utiliser

                                  • [^] # Re: Intérêt

                                    Posté par  . Évalué à 3.

                                    Gradle m'a l'air très prometteur et il parvenait avant même sa première version a faire des choses pour lesquelles Maven a des bugs ouverts depuis belle lurette.

                                    Le fait d'associer la facilite de Maven pour décrire les dépendances avec la possibilité d'utiliser Groovy pour faire tout ce qui n'est pas prévue de base me semble géniale. Gradle semble faire un bras d'honneur a la préconisation pour étendre Maven: écrire un plugin.
                                    Il y a avait un plugin Groovy pour Maven mais il n'est plus maintenu.

                                    Une petit correction de vos propos: Gradle s'appuie a fond sur Ivy pour gérer les dépendances (plus puissant semblerait-il), pas du tout sur Maven.

                                    Bref parfois Maven me gave, mais quand je pense a Ant je suis de nouveau amoureux de Maven.
                                    Gradle me fait rêver. C'est vraiment a essayer.

                                    • [^] # Re: Intérêt

                                      Posté par  (site web personnel) . Évalué à 2.

                                      Une petit correction de vos propos: Gradle s'appuie a fond sur Ivy pour gérer les dépendances (plus puissant semblerait-il), pas du tout sur Maven.

                                      Ce que je voulais dire c'est que Gradle peut utiliser les dépendances de maven. Donc l'argument "on a maven pour les dépendances" ne tiens pas face à Gradle qui peut utiliser (lire, récupérer, etc) les dépendances de maven, ivy, statiques, etc.
                                      Après, je ne savais pas s'il utilise ivy ou maven en interne, je ne connais pas ivy en fait.

                                    • [^] # Re: Intérêt

                                      Posté par  . Évalué à 2.

                                      Une petit correction de vos propos: Gradle s'appuie a fond sur Ivy pour gérer les dépendances (plus puissant semblerait-il), pas du tout sur Maven.

                                      Qu'as-t'il de plus ?

                                      La question se pose aussi pour gradle. Je ne vois pas ce qu'ils peuvent ajouter de ce coté là.

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

                                  • [^] # Re: Intérêt

                                    Posté par  (site web personnel) . Évalué à 2.

                                    C'est là où gradle est bien je trouve, lorsque je modifie mon fichier gradle, au mieux un coup de gradle eclipse et c'est ok. C'est sur que ce serait mieux si c'était intégré, mais j'ai même pas cherché.

                                    Même pour les tâches non standard? Par exemple de la génération de code.

                                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Intérêt

                    Posté par  . Évalué à 1.

                    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.

                    Non, parce que pip ou easy_install (éventuellement combinés avec virtualenv) te dispensent de gérer un path à la main.

                    • [^] # Re: Intérêt

                      Posté par  . Évalué à 1.

                      Non, parce que pip ou easy_install (éventuellement combinés avec virtualenv) te dispensent de gérer un path à la main.

                      Un peu comme maven c'est ça ? Avec les outils dont tu parle on choisi d'installer tel ou tel bibliothèque et elle est disponible pour tout le monde alors qu'avec maven tu indique ce dont tu as besoin dans ton projet et ce dernier le télécharge dans un dépôt local et le rend disponible pour ce projet (donc comme le permet virtaulenv, avec une factorisation des bibliothèque dans le dépôt local qui est central (sachant que oui tu peut avoir plusieurs version d'une même biblio dans un dépôt c'est dans ton pom.xml que tu indiquera la version dont tu as besoin, si tu ne le fait pas il prendra le numéro le plus grand disponible)).

                      L'approche est peut être différentes, mais dans les faits je vois pas pourquoi l'un est considéré comme pourris alors que l'autre c'est le bien ?

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

                      • [^] # Re: Intérêt

                        Posté par  . Évalué à 1.

                        Un peu comme maven c'est ça ?

                        Je n'en sais rien, jamais utilisé. Apparemment on se plaint que maven soit compliqué, alors que les outils Python sus-cités sont simples comme bonjour.

                        • [^] # Re: Intérêt

                          Posté par  . Évalué à 3.

                          Pour moi l'un des intérêts maven sur virtualenv, c'est que tout est regroupé dans un fichier pom.xml (qui est versionné donc). Voici un exemple simple mais vrai (il y a pas de simplification) :

                          <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>fr.barmic</groupId>
  <artifactId>LinuxFR</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>LinuxFR</name>
  <url>https://linuxfr.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

                          Avec ce fichier, je décris un projet simple qui possède des dépendances. Ces dernières seront téléchargées de manière automatiques et on se retrouve facilement avec un environnement de compilation identique sur tout les postes de travail.

                          Tu peut ajouter des dépendances autant que nécessaire et tu peut ajouter des plugins qui vont faire diverses actions en fonction de tes besoins (déployer sur tel ou tel serveur).

                          Par exemple j'avais utilisé t7mp l'an dernier. Cette pages d'écris ce qu'il faut faire depuis un pom qui génère déjà un war : http://code.google.com/p/t7mp/wiki/GettingStarted

                          Il faut ajouter le pour ajouter le déploiement automatique et le pour lui dire ou chercher ce plugin.

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

                        • [^] # Re: Intérêt

                          Posté par  . Évalué à 2.

                          Ils ne font pas du tout la même chose. pip et virtual_env c'est 5% de ce que fait maven. Ils téléchargent un module .|

                          Le design et l'utilisation de Java font qu'en général on a besoin d'un peu plus. Mais écrire un équivalent à pip qui pose les artifact dans un répertoire ca doit s'écrire en quelques minutes si ca n'existe pas déjà. Après est ce que ca répond aux besoins des devs c'est une autre affaire.

                  • [^] # Re: Intérêt

                    Posté par  . Évalué à -1.

                    Pas plus qu'en python ou en C si tu utilises un répertoire unique.

                    Heu, non, en Python mon PYTHONPATH c’est /usr/lib/python2.7/site-packages avec un dossier /usr/lib/python2.7/site/packages/fubar

                    En Java, j’ai un répertoire /usr/share/java/ avec fubar-1.2.3.jar dedans, mais aussi commons-logging.jar, et une foultitude d’autre. Si je mets mon classpath à /usr/share/java il me trouvera pas fubar, je dois mettre mon classpath à /usr/share/java/fubar-1.2.3.jar:/usr/share/java/commons-logging.jar (et donc mon classpath dépend des libs utilisées par mon projet, même avec un répertoire unique, contrairement à Python)

  • # Découverte

    Posté par  . Évalué à 10.

    Pour l'adoption massive d'un nouveau langage, la richesse de la bibliothèque standard est cruciale. C'est peut-être là où l'on sent que c'est la première version du langage. La richesse fonctionnelle mérite de s'étoffer. Pour une fonctionnalité aussi courante que l'analyse des arguments de la ligne de commande, je suis resté sur ma faim. C'est le package « flag » qui s'occupe de ça. On atteint vite ses limites : impossible de passer plusieurs fois la même option. Impossible de concaténer les options courtes (cmd -t -u ==> cmd -tu). Le parser ne trouve plus rien (et ne prévient pas) si le premier argument ne débute pas par un tiret…

    Le langage est jeune, certes, mais c'est important de proposer une bonne bibliothèque (au moins sur les fonctionnalités basiques) si Go veut se placer d'entrée de jeu comme langage généraliste.

    Je ne suis pas fan de certaines subtilités. Par exemple les tableaux, passés par valeur alors que les slices le sont par référence. En revanche, j'apprécie de pouvoir retourner plusieurs éléments lors d'un return.

    Personnellement j'aime assez Go. Le fait qu'il soit compilé implique - a priori - de bonnes performances d'exécution. Reste à évaluer le poids du runtime sur celles-ci.

    Et vous qui vous initiez aussi, vous en pensez quoi ? (PS: Mon background: C et Python)

    • [^] # Re: Découverte

      Posté par  . Évalué à 4. Dernière modification le 10 avril 2012 à 01:33.

      Et vous qui vous initiez aussi, vous en pensez quoi ?

      ça me plait assez bien.

      j'apprécie de pouvoir retourner plusieurs éléments lors d'un return

      c'est très bien ouais. Le type des fonction déclaré à la fin plutôt que devant comme en C est très bien aussi. C'est beaucoup plus lisible. On sent la marque du langage pascal avec package et var . L'autre feature que j'apprécie c'est deffer.

      Par contre La déclaration des variables est un peu déroutante entre var, label = type et label := action().

      Je trouve l'idée des slices intéressante on doit souvent manipuler, tronquer des tableaux je suis curieux de tester la solution de go.

      Des structures avec des fonctions dédiés plutôt que de l'object avec des méthodes pourquoi pas. Je pense que ça reviens au même c'est peut-être plus facile à saisir conceptuellement que l'objet. En tout cas c'est moins laborieux pour des petites opération que d'avoir à déclarer un objet.

      Malheureusement, je n'ai que trop peu d'expérience avec la programmation concurrentielle pour évaluer la pertinence des solutions proposées par go. Par contre c'est rassurant de voir que ce thème est pris au sérieux et considéré comme majeur.

      C'est vrai que la bibliothèque standard est un peu light mais au moins on a un tout cohérent dès le début.

      conclusion: trop tôt pour me prononcer, mais j'apprécie Go, j'apprécie moins la taille des exécutables qu'il pond (1.5mo pour un Hello World! like). En tous cas je ne veux pas passer à côté d'un langage qui pourrait devenir très important car c'est sous l'impulsion de google, créé par des pointures, opensource et multi-plateforme.

      • [^] # Re: Découverte

        Posté par  (site web personnel) . Évalué à 2.

        Le type des fonction déclaré à la fin plutôt que devant comme en C est très bien aussi.

        Pourquoi pas, par contre devoir en plus mettre le mot clef func devant ça fait assez lourd je trouve

        Exemple :

        func blabla (x int, y int) int {}

        Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

        • [^] # Re: Découverte

          Posté par  . Évalué à 5.

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

      • [^] # Re: Découverte

        Posté par  (site web personnel) . Évalué à 3.

        Des structures avec des fonctions dédiés plutôt que de l'object avec des méthodes pourquoi pas. Je pense que ça reviens au même c'est peut-être plus facile à saisir conceptuellement que l'objet.

        Ça ne revient pas du tout au même, puisque dans le cas des structures le compilateur sait toujours quelle fonction appeler tandis que dans le cas de l'objet les mécanismes d'héritage permettent de redéfinir les comportements (méthodes virtuelles) ce qui empêche le compilateur de toujours savoir comment résoudre les fonctions.

        Conceptuellement c'est beaucoup plus facile à saisir que l'objet et aussi bien moins expressif, donc il n'y a pas de gros miracle. Le paradigme de programmation objet est très complexe et riche en expressivité, il offre de multiples solutions d'ingénierie — et autant de problèmes à résoudre.

    • [^] # Re: Découverte

      Posté par  . Évalué à 2.

      Je viens de coder un petit programme qui recherche dans mes fichiers php la présence de texte à traduire. Donc recherche récursive dans un dossier et un peu d'expression régulière. Et ben ce n'est pas compliqué du tous.
      On dirait presque du langage interprété. J'ai juste à faire attention au type de mes variables. Je dois rajouter quelque chose dans mon tableau -> monTab = append(monTab, item) pas d'objet instancier, pas de mémoire à libérer, ce que j'ai besoin est dans la librairie standard.

      Ca compile, ça marche. C'est un peu trop facile même.

  • # Code lisible?

    Posté par  . Évalué à 4.

    Au premier abord, il y a un truc qui me gêne (très fortement même) : la lisibilité du code.

    Je viens de Java et C, et quand je vois un programme en C++, en Python, en Perl, en bash, j'arrive immédiatement à le comprendre…
    Là, quand je vois 'tick Même si c est un chan, pourquoi ne pas avoir utilisée une jolie fonction "get(c)" et put(tick)", ou n'importe quoi d'équivalent et bien plus explicite pour pusher et poller des messages, que cette obscure syntaxe '

    Bon, après, c'est peut-être parce que j'en ai marre d'apprendre tout le temps des nouveaux langages parce-que-celui-ci-est-mieux-que-tout-ce-qui-se-fait-et-qu-il-resoud-enfin-tous-les-problèmes ! :-)

    • [^] # Re: Code lisible?

      Posté par  . Évalué à 10.

      quand je vois un programme en […] en Perl, […] j'arrive immédiatement à le comprendre…

      Wow, tu a pensé à postuler chez les X mens ou les Avengers ?

    • [^] # Re: Code lisible?

      Posté par  . Évalué à 4.

      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 :)

      • [^] # Re: Code lisible?

        Posté par  (site web personnel) . Évalué à 4.

        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 :)

        Juste pour savoir, tu penses que quelqu'un qui sait lire le perl ne peut pas comprendre quel mot-clé ou opérateur de Go ?
        J'aurais tendance à dire defer, on voit bien qu'il y a beaucoup trop de lettres et pas assez de symbole pour du perl…

        • [^] # Re: Code lisible?

          Posté par  . Évalué à 2.

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

  • # Retour à la pré-histoire

    Posté par  (site web personnel) . Évalué à 0.

    Comparé à d'autres langages, pas forcément récents, comme Python ou Scheme, j'ai quand même l'impression d'un gros retour en arrière… Ne ferait-on pas mieux d'essayer d'améliorer (notamment d'optimiser) ces langages plutôt que d'essayer de créer un nouveau langage système légèrement amélioré ?

    Comme seules innovations je retiendrais :
    * les "goroutines" et les "channels", qui me semblent pouvoir être implémentés dans pas mal d'autres langages sans trop de difficulté
    * les interfaces "duck-typées" c'est à dire que toutes classes implémentant les méthodes d'une interface hérite automatiquement de celle-ci, même si ça n'est pas précisée dans la classe (ou que l'interface a été créée après la classe, ou par quelqu'un d'autre). C'est intéressant, mais finalement ça n'ajoute pas grand chose par rapport à un langage type dynamiquement où l'on a carrément pas besoin d'interface !

    • [^] # Re: Retour à la pré-histoire

      Posté par  (site web personnel) . Évalué à 3.

      oué enfin, scheme par exemple y'a quand même pas grand monde qui l'utilise, et python perso j'aime pas du tout, surtout comparé à Ruby que je trouve beaucoup plus agréable à utiliser.
      Hop, tu vois, finalement il en faut déjà beaucoup des langages pour que ça convienne à tout le monde.

      Ensuite, comme rappelé, il faut pas oublié que l'objectif initial était finalement de renouvler le C mais en restant sur le même segment (la prog système). Ce n'est qu'après que c'est devenu un langage générale, sûrement parce que de nombreuses personnes l'ont pris pour faire autre chose que du système.

      Sur l'histoire d'essayer d'améliorer les existants, c'est loin d'être simple. Déjà si c'était simple les autres langages seraient plus performant, déjà. Ensuite, souvent les gens veulent de la compatibilité, donc si par exemple le but était d'améliorer C il faudrait faire un nouveau standard C, galère.
      Et surtout (c'est d'ailleurs la même question avec javascript et dart), parfois il faut revoir le design complet, il n'est pas toujours possible de modifier suffisamment les langages existant pour en faire ce qu'on veut.

      Mais au final, quel est le problème d'en créer un autre ? Il est probable que, sur certains plans, il viennent remplacer du C ou du C++, et alors ?
      C'est la segmentation le problème ? Le fait d'apprendre de nombreux langages ? Un programmeur doit pouvoir passer d'un langage à un autre sans trop de problème (j'ai pas dit du jour au lendemain, mais quand même). Qui utilise un seul langage ?

      • [^] # Re: Retour à la pré-histoire

        Posté par  . Évalué à 10.

        Le seul inconvénient que je vois avec la multiplication des langages, c'est la diversification des bibliothèques externes, ça devient un peu "si je veux convertir du docx, il faut faire du c++, pour afficher de l'odt, il faut faire du java et pour l'imprimer utiliser Go", c'est parfois frustrant.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Retour à la pré-histoire

          Posté par  (site web personnel) . Évalué à 2.

          C'est pas faux

          Après ce qui est intéressant c'est lorsqu'il y a une lib avec différents bindings, mais c'est vrai que c'est pas toujours le cas.
          Et c'est le plus criant au niveau des GUI puisqu'en général les GUI sont faites pour être programmées dans un langage et perdent de leur intérêt à être utilisées avec un autre.

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

          • [^] # Re: Retour à la pré-histoire

            Posté par  . Évalué à 4.

            Après ce qui est intéressant c'est lorsqu'il y a une lib avec différents bindings

            Il vaut quand même mieux qu'elle soit écrit dans un langage compilé, parce que si tu dois lancé la jvm (c'est moins gênant avec python ou ruby mais quand même) dans ton programme en C, ça fait pas mal de mémoire utilisée pour rien.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Retour à la pré-histoire

              Posté par  (site web personnel) . Évalué à 2.

              Je pensais justement dans l'autre sens, une lib avec un langage compilé (genre C, C++ ou Go quoi) qui a des bindings dans les autres langages. Par ce que intégrer une lib native dans du java je vois bien, l'inverse c'est déjà 'achement plus complexe

          • [^] # Re: Retour à la pré-histoire

            Posté par  . Évalué à 3.

            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é.

        • [^] # Re: Retour à la pré-histoire

          Posté par  (site web personnel) . Évalué à 3.

          Est-ce que LLVM pourrait aider à résoudre ce problème ? Si on a un compilateur/interpréteur LLVM pour chaque langage, est-ce que cela facilite l'interfaçage ? Il me semble (mais c'est de l'ouïe-dire, jamais essayé) que le framework .NET permet facilement d'interface les langages justement parce qu'ils utilisent le même bytecode.

          • [^] # Re: Retour à la pré-histoire

            Posté par  (site web personnel) . Évalué à 3.

            Je dirais que c'est pas la même chose.
            Si tu compiles du C avec LLVM il te reste … du code machine.
            Oui il y a bien un bytecode intermédiaire mais ça fait pas tout.

            .Net c'est différent, ton C#, J#, VB.net, ou autre, est compilé en byte code. Et c'est le bytecode qui est exécuté par la VM .Net. Donc dans ce cas il y a dialogue, mais en fait il y a dialogue car c'est le même langage qui est compilé/exécuté en JIT, c'est le byte code. Et non C# ou autre.
            D'ailleurs tu peux pas, comme ça, interfacer du java et du C#.

            • [^] # Re: Retour à la pré-histoire

              Posté par  . Évalué à 3.

              Il me semble qu'il y avait (a?) un projet pour s'arrêter à l'étape du bytecode llvm et de le compiler avec du JIT à l'exécution. Je suppose que c'est ce ça qu'il voulait parler.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Retour à la pré-histoire

                Posté par  (site web personnel) . Évalué à 2.

                Oué mais ça voudrait dire s'arrêter de la sorte pour tous les composants ou libs du projet.
                C'est un peu comme si on disait que tout était du java finalement, en s'arrêtant au .class

                • [^] # Re: Retour à la pré-histoire

                  Posté par  . Évalué à 3.

                  S'il comparait à .Net, c'était l'idée à mon avis.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Retour à la pré-histoire

                  Posté par  (site web personnel) . Évalué à 2.

                  Je pensais effectivement un peu à ça. Typiquement si je compile mon code C++ en un .class java (imaginons qu'on ait un compilo qui fasse ça), je peux ensuite l'utiliser depuis Java ?

                  C'est clair que ça veut dire recompiler toutes les libs du projet, mais c'est pas forcément un gros problème ça.

                  • [^] # Re: Retour à la pré-histoire

                    Posté par  . Évalué à 3.

                    Pour du C++, c'est plus difficile mais avec JRuby ou Jython, tu peux faire du Ruby ou du Python et utiliser les bibliothèques en bytecode de la JVM.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Retour à la pré-histoire

            Posté par  (Mastodon) . Évalué à 3.

            Je crois que ce n'est pas un problème de binaire, c'est un problème de convention d'appel. Si un langage utilise la convention d'appel C, il sera compatible avec C. Il doit y avoir aussi un truc au niveau des noms de fonctions (qui sont "manglés" en C++ par exemple).

  • # Intéressant

    Posté par  (site web personnel) . Évalué à 4.

    Pour ma part j'étais un peu surpris, voir déçu, des choix en terme de syntaxe (par exemple l'usage de func).
    Un peu comme en coffeescript ou j'ai pas encore réussi à adhérer à

    Par contre, je trouve que le lien sur les web services en go est plutôt parlant et donne envie.
    Pour développer actuellement en grande partie en Java, y compris avec des technos cool (guice, un équivalent à guice-servlet et jersey-guice, de l'osgi, etc), bien que j'arrive à un truc sympa et agréable à utiliser (pour du java) c'est loin de ce que go peut faire.
    En gros, si je voulais faire la même chose que l'exemple mais en java, ce serait beaucoup plus inutilement verbeux.
    Et la solution de renvoyer plusieurs valeurs … miam !

    Enfin voilà, pour ma part c'est réellement un langage qui me semble intéressant, et je trouve que les libs de base sont justement plutôt complètes, surtout si on compare à celle de java qui est plutôt, souvent, minable…

    • [^] # Re: Intéressant

      Posté par  . Évalué à 2.

      je trouve que les libs de base sont justement plutôt complètes, surtout si on compare à celle de java qui est plutôt, souvent, minable…

      Minable? Tu veux faire quoi exactement?

      La lib de base offrait lors de sa sortie un nombre de fonctions largement supérieur aux alternatives multi-plateforme.

      Les libs de java sont nombreuses et variées (parfois trop! C'est justement un reproche qui lui est fait) et je les vois comme un point fort du langage.

      A moins que tu veuilles que Java intègre de base toute les librairies possibles et imaginables, mais je n'en voit pas l’intérêt?

      Alors de quoi parles tu exactement?

      • [^] # Re: Intéressant

        Posté par  (site web personnel) . Évalué à 2.

        Heu oui, la lib de base de java Si on veut faire quelque chose de correct en java, en général il y a deux choix qui s'offrent :

        • utiliser les libs apache (par exemple comons-io)
        • utiliser guava

        Il y a sûrement d'autres alternatives, mais c'est parmi les plus courantes.

        Ce que je reproche à java ? Ben sa lib standard est tellement bas niveau qu'elle n'intéresse personne en général.

        Les libs de java sont nombreuses et variées

        Attention, je parle de la lib standard java, pas des libs qui existent

        Mais pour des exemples : combien de temps a-t-il fallu attendre pour avoir un String.empty (ou isEmpty, sais plus) ?
        Comment on fait, agréablement, du split, du join, etc avec les libs de base ? Ha oui, c'est vrai, la solution du join c'est de faire un stringbuffer et donc de tout faire à la main.

        Pourquoi les libs (autre) fournissent-t-elles toujours les mêmes objets, méthodes ? Simplement car rien de sérieux, avant java7, n'était vraiment fait pour avoir une lib standard correcte.
        Il suffit de prendre http://code.google.com/p/guava-libraries/wiki/StringsExplained et http://code.google.com/p/guava-libraries/wiki/IOExplained par exemple.

        • [^] # Re: Intéressant

          Posté par  . Évalué à 4.

          combien de temps a-t-il fallu attendre pour avoir un String.empty (ou isEmpty, sais plus) ?

          C'est présent depuis java 1.6 http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty%28%29 (au moins, question doc, ils ne s'en sortent pas trop mal par rapport à d'autres).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Intéressant

            Posté par  . Évalué à 0.

            Le problème de String.isEmpty c'est que c'est pas "nullsafe", contrairement à StringUtils.isEmpty. Ça permet d'écrire :

            if (StringUtils.isEmpty(str)) {
   str = "default";
}

            plutôt que :

            if (str == null || str.isEmpty()) {
   str = "default";
}

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

            • [^] # Re: Intéressant

              Posté par  (site web personnel) . Évalué à 5.

              Oué enfin ça c'est une fausse bonne raison.
              Car rien n'aurait empêché de faire un String.isEmpty (donc en static). Mais non…
              D'ailleurs tu viens de montrer pourquoi tout le monde va finalement vers commons de apache, parce que la lib standard de java est chiante.

              • [^] # Re: Intéressant

                Posté par  . Évalué à 0.

                Oué enfin ça c'est une fausse bonne raison.

                Qu'est ce qui est une fausse bonne raison de faire quoi ? J'aime bien utiliser des méthode nullsafe pour ce genre de choses (en pratique je n'utilise jamais isEmpty, mais plutôt isBlank).

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

                • [^] # Re: Intéressant

                  Posté par  (site web personnel) . Évalué à 4.

                  Désolé, le thread était sur le sujet "la lib standard de java say que de la daube" et je suis resté dans le sujet.
                  Et donc ton commentaire va parfaitement dans ce sens car pour tester si ta chaîne est vide tu ajoutes des libs apache commons alors que ce devrait faire partie de l'objet String (même si c'est du static).

                  • [^] # Re: Intéressant

                    Posté par  (site web personnel) . Évalué à 2.

                    Il faut comparer ce qui est comparable. Beaucoup trouve qu'il est plus noble de faire du C ou C++ que du Java alors que leurs bibliothèques n'ont pas 0.1% des fonctionnalités d'un JRE.

                    Il y a même des projets pour rendre Java 8 modulaire, au lieu d'un gros runtime, on aurait un kernel minimal et des modules téléchargés à la demande.

                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                    • [^] # Re: Intéressant

                      Posté par  (site web personnel) . Évalué à 4.

                      Il faut comparer ce qui est comparable

                      Justement, là tu tentes de comparer du C et du C++ à Java. C'est quand même loin d'être sur le même plan.
                      Et d'ailleurs la lib standard de C++… oué, franchement ça fait bien rire, il n'y en a pas vraiment. Ok certains voient la STL (c'est plus ou moins officiel je crois) mais je préfère, de très loin, Qt par exemple.

                    • [^] # Re: Intéressant

                      Posté par  . Évalué à 4.

                      Il faut comparer ce qui est comparable. Beaucoup trouve qu'il est plus noble de faire du C ou C++ que du Java alors que leurs bibliothèques n'ont pas 0.1% des fonctionnalités d'un JRE.

                      Tu as raison et en C++, tu ne peux pas vivre sans tes bibliothèques d'utilitaires « minimal ». Là où ça deviens gênant c'est que si tu utilise Qt tu l'utilise pour tout (parce que sinon tu mange de la conversion std::string Qtring, si tu utilise GTKmm tu va utiliser Glib::ustring etc. Bien sûr aucune n'hérite de std::string.

                      Je trouve vraiment attristant de voir l'état des lieux du C++. Si tu veut avoir une petite bibliothèque de méthode pour traiter des chaînes de caractères, tu dois te fader des conversion dans tout les sens en fonction des autres bibliothèques du projet. Certaines comme Glib::ustring ressemblent à std::string, mais comme tu n'a pas de duck typing c'est inutile (tout juste légèrement plus KISS).

                      Il y a même des projets pour rendre Java 8 modulaire, au lieu d'un gros runtime, on aurait un kernel minimal et des modules téléchargés à la demande.

                      Quand tu dis à la demande c'est au runtime ? Si c'est le cas, faut vraiment que ce soit bien fait parce que Java c'est aussi utiliser dans des environnement hors d'Internet ou avec des réseaux lents, peu fiables et/ou chères. Mais j'espère qu'ils vont se bouger s'ils veulent ce genre de choses, la première version d'essai de Java seras cet été.

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

                      • [^] # Re: Intéressant

                        Posté par  . Évalué à 3.

                        Jigsaw n'est pas un projet récent et tu trouveras toute la documentation qu'il faut notammenent sur la page d'accueil du projet: http://openjdk.java.net/projects/jigsaw/

                        Il reste beaucoup de boulot à faire. Notamment pour détricoter les différentes partie du JDK qui ont énormément d'interdépendances. Le but pour le JRE, c'est d'une part de nettoyer le sac de noeud de la lib standard, et d'autre part que ca soit modularisable au besoin. Selon l'environnement tu peux packager comme tu veux.

                        Et pour la roadmap prévue voir là: http://www.infoq.com/presentations/To-Java-SE-8-and-Beyond

                        • [^] # Re: Intéressant

                          Posté par  . Évalué à 2.

                          [ma vie]
                          Je suis moi même en train de décomposer une base de code modulaire avec plusieurs milliers de classes et du code spaghetti, et bien je compatis avec eux!
                          [/ma vie]

                  • [^] # Re: Intéressant

                    Posté par  . Évalué à 2.

                    Ok je comprends mieux.

                    Je présume que comme pour Objects, ils créeront une classe Strings qui fait le boulot comme il faut.

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

                    • [^] # Re: Intéressant

                      Posté par  (site web personnel) . Évalué à 4.

                      Oui voilà. On voit arriver dans Java 7 ce qui manque depuis longtemps, par exemple Objects.equals :

                      Mais il serait temps que tous les autres helpers arrivent dans le JDK.
                      Bon évidemment, ni besoin ni intéressant de tout rentrer, mais il y a déjà beaucoup de choses à faire.

                      (et tout comme gradle, si tu n'as jamais utilisé Guava je te le conseil. C'est propre, sympa, les fonctionnalités objects, cache ou collections sont bien sympa, surtout si tu n'es pas en jdk 7)

                      • [^] # Re: Intéressant

                        Posté par  . Évalué à 2.

                        (et tout comme gradle, si tu n'as jamais utilisé Guava je te le conseil. C'est propre, sympa, les fonctionnalités objects, cache ou collections sont bien sympa, surtout si tu n'es pas en jdk 7)

                        Je m'en suis servi l'an dernier. C'est vrai que c'est bien. J'ai malheureusement pas encore pu toucher à Java 7 par contre, mais je reporte une partie des nouveautés de Java7 (celles qui ne font pas partie du langage et qui ne sont pas trop chiantes a implémentés) comme la classe Objects par exemple. Je préfère me créer ma classe qui suit précisément l'interface standard (au passage vers Java 7, il suffit de changer l'import pour que ce soit pris en compte). Parce que j'essaie quand c'est possible de privilégier la bibliothèque standard aux bibliothèques externes.

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

                        • [^] # Re: Intéressant

                          Posté par  . Évalué à 2.

                          Bah, un simple string replace dans Eclipse et tu peux impacter toute ta base de code en une opération.

                          Cependant c'est vrai que j'aimerais bien un coccinelle pour Java. J'ai commencé a bosser dessus, mais je dois dire que ça avance pas vite!

              • [^] # Re: Intéressant

                Posté par  . Évalué à 2.

                Je ne connaissais String.isEmpty(), mais c'est vrai que ça pue pas mal quand même!
                Toute méthode que utilisée régulièrement doit être nullsafe.

                OK, j'avoue java pourrait faire beaucoup mieux la dessus de base.

                Allez, voici pour aller dans ton sens:
                http://mestachs.wordpress.com/2012/03/17/dangerous-can-be-dating-in-java-joda-to-the-rescue/

        • [^] # Re: Intéressant

          Posté par  . Évalué à 1.

          Je vais pas te mentir, je me demande comment je faisais pour coder en Java avant Apache Commons :)

          Depuis tout n'est que bonheur est félicitée où je me balade à coup d'interfaces bien pensées, de prédicats et de visiteurs. Bref c'est le bonheur total puisque je ne me dit pas "et m**** je dois encore écrire une pu**** de boucle for".

          Mon code est plus léger (mon cerveau aussi) et je peux me concentrer sur le problème métier au lieu d’écrire ma centième boucle for de la journée.

          En un mot: Miam!!!

          • [^] # Re: Intéressant

            Posté par  . Évalué à 3. Dernière modification le 13 avril 2012 à 09:08.

            J'ai regardé un peu plus en détail Apache Commons (par rapport à Guava de Google) et il me semble qu'elle est un peu poussiéreuse (j'utilise surtout commons-lang d'habitude). Le guide utilisateur de commons io présente des cas qui ne sont plus d'actualités. Le premier exemple :

            InputStream in = new URL( "http://jakarta.apache.org" ).openStream();
try {
   InputStreamReader inR = new InputStreamReader( in );
   BufferedReader buf = new BufferedReader( inR );
   String line;
   while ( ( line = buf.readLine() ) != null ) {
     System.out.println( line );
   }
} finally {
   in.close();
}

            Peut depuis longtemps s'écrire :

            InputStream in = new URL( "http://jakarta.apache.org" ).openStream();
try {
   Scanner sc = new Scanner(in);
   while ( sc.hasNextLine() ) {
     System.out.println( sc.nextLine() );
   }
} finally {
   if (in != null) {
      in.close();
   }
}

            C'est certes toujours plus long que leur solution, mais elle perd de l'intérêt. Ça rend vraiment inutile leur line iterator qui est moins puissant que le Scanner (ce dernier peut gérer les String, les Integer, les Long, etc).

            De plus Apache Commons Collections n'utilise pas les templates. Je présume qu'elle a était écrite pour Java 1.4 ou qu'elle cherche à garder la compatibilité Java 1.4, mais c'est dommage lorsque l'on voit ce que peut apporter l'héritage avec guava.

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

            • [^] # Re: Intéressant

              Posté par  . Évalué à 2.

              Les fonctionnalités se chevauche très largement. Dans l'esprit effectivement, guava si t'es >= Java 5 et commons autrement.

              Reste que si chevauchement il y a, les fonctionnalités de commons ne sont pas entièrement incluses dans guava et tu te retrouves souvent soit à réécrire du code, soit à avoir et guava et commons en dépendance. De toute facon t'as beaucoup de chance que 50% de tes dépendances aient choisi l'un et 50% l'autre…

              La lib standard Java à un vrai problème d'expressivité. Il lui manque souvent des utilitaires haut niveau pour éviter d'aller à la pêche aux dépendances pour des conneries.

            • [^] # Re: Intéressant

              Posté par  . Évalué à 2.

              En effet, commons est compatible JDK1.4 alors que Guava a visé directement la compatibilité avec Java 5, évitant ainsi le code legacy.

              Mais ça commence a changer: commons lang 3 utilise les generics.

              Pour commons collections (celui que j'utilise le plus), je me suis créé une petite classes utilitaire permettant d'utiliser les méthodes de CollectionUtils, mais avec les generics. Il y a des casts sauvages par la, mais c'est pas grave puisque le code l'utilisant ne se cogne pas ce problème mineur.

  • # Indentation du code

    Posté par  (site web personnel) . Évalué à 0.

    reformater le code source d'un programme avec go fmt (c'est une manière particulièrement astucieuse d'éviter les discussions sans fin sur le style à adopter sur un programme : il suffit de lancer go fmt sur son code pour qu'il soit formaté selon les bonnes pratiques)

    J'ai trouvé l'idée super moi aussi… jusqu'à ce que je me rende compte que go fmt ne respect pas la sacro-sainte règle des 80 colonnes ! (d'autant plus étonnant quand on voit les responsables du projet…)
    Du coup le confort en prend un coup dès que les fonctions sont un peu longues sur mon emacs…

    Bug ? Volonté de briser le tabou ? J'ai raté quelque chose ?

    • [^] # Re: Indentation du code

      Posté par  (Mastodon) . Évalué à 8.

      go fmt ne respect pas la sacro-sainte règle des 80 colonnes

      Ça n'a absolument rien de sacré, ça vient d'une limitation matérielle qui n'existe plus depuis longtemps.

      Sur mon écran, 80 colonnes de texte avec des caractères d'une taille agréable pour travailler, ça n'occupe même pas la moitié de la largeur de la zone de texte de mon éditeur. J'aurais vraiment pas envie qu'un outil décide de me couper les lignes à 80 colonnes, ce qui aurait pour principal effet de rendre le code moins lisible (et de gaspiller une bonne partie de mon espace d'affichage)

    • [^] # Re: Indentation du code

      Posté par  . Évalué à 2.

      la sacro-sainte règle des 80 colonnes

      Qu’est-ce que ça a de sacré ? On parle bien d’informatique, là ?
      Je développe sur 160-200 colonnes.

      • [^] # Re: Indentation du code

        Posté par  (site web personnel) . Évalué à 10.

        Je développe sur 160-200 colonnes.

        Ha quand même !

        En typo, en général, on tente d'avoir des lignes contenant 45 à 75 caractères en gros. Disons que c'est autour de ces valeurs que l'oeil s'y retrouve pas mal (afficher un texte sur un écran wide par exemple est particulièrement désagréable). C'est aussi pour cette raison qu'en général les journaux sont sous forme de colonnes.
        Evidemment, si on prend en compte les indentations de code on dépasse rapidement les 80 colonnes, sachant aussi que souvent on lit je pense le code un peu différemment que du texte, notamment grâce à la coloration qui permet de "zapper" quelques termes.
        Tout ça pour dire que 80 me parait bien juste, 200 me parait par contre plutôt énorme.

        Ensuite, l'avantage de lignes pas trop longues est de pouvoir facilement mettre deux codes l'un à côté de l'autre. Et là les 80 colonnes sont pas mal (ou alors c'est parce que j'ai un écran pourri, qui ne fait que 1440 de largeur :-( )

        • [^] # Re: Indentation du code

          Posté par  . Évalué à 1.

          En typo, en général, on tente d'avoir des lignes contenant 45 à 75 caractères en gros. Disons que c'est autour de ces valeurs que l'oeil s'y retrouve pas mal

          Je suis parfaitement d’accord avec ça, mais la programmation, à mes yeux, ce n’est pas du français. L’indentation a vite fait de décaler très à droite. Sans compter que j’aime qu’une commande tienne sur une ligne et que mes noms de variables sont parfois un peu longs.

          Aussi, soyons clair, quand je dis que je code sur 160-200 colonnes, dans les faits, la majeure partie de mon code ne dépasse pas les 120 col., ni même 80 col. la plupart du temps. Mais je n’ai aucun scrupule à aller jusqu’à 160 si besoin. Et, pour les 200 col., ce sont en général des cas particuliers, assez rares, que j’évite de préférence, même si mon écran peut afficher ces 200 col. sans souci (26 pouces: 1920×1200 pixels). Ma référence, c’est plutôt 160 col.

        • [^] # Re: Indentation du code

          Posté par  . Évalué à 2. Dernière modification le 12 avril 2012 à 02:06.

          120 caractères ici. Au moins il est toujours possible de faire une comparaison de texte cote a cote sans avoir besoin d'un dual-screen :)

      • [^] # Re: Indentation du code

        Posté par  . Évalué à 6.

        Le texte à 80 colonnes, ça permet de faire des splits verticaux dans son vim, ça permet d'afficher beaucoup plus d'informations à la fois.

        • [^] # Re: Indentation du code

          Posté par  . Évalué à 3.

          120 colonnes aussi. On n'est pas obligé de se limité aussi court.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Indentation du code

            Posté par  . Évalué à 1.

            Après test sur ma machine du boulot, au dela de 100 caractères je ne peux plus faire de split sans scinder les lignes, donc effectivement 80 c'est trop juste, par contre 120 pour ma part c'est trop.

          • [^] # Re: Indentation du code

            Posté par  . Évalué à 4.

            Ouhais mais si tu as un ecran pas tres grand ca devient rapidement penible les 200 colonnes!

      • [^] # Re: Indentation du code

        Posté par  . Évalué à 1.

        L'important, c'est d'avoir une convention afin que chacun puisse relire le code d'un autre sans que ça déborde de l'éditeur à tout va.
        Historiquement, la valeur de 80 a été adoptée, ça aurait pu être une autre mais peu importe. C'est contre-productif de ne pas la respecter, en tout cas sur des projets avec plus de 2 ou 3 développeurs.

        Remettre en question cette convention, c'est comme commencer à poster en espéranto sur Linuxfr en disant : « qu'est-ce que ça a de sacré le français ? L'espéranto est aussi bien ! ».

        • [^] # Re: Indentation du code

          Posté par  . Évalué à 5.

          D’un autre côté, tous les éditeurs de moins de 15 ans te proposent un wrapping configurable à l’affichage, ce qui rend la convention non seulement désuète mais aussi contre-productive (le faire physiquement empêche d’avoir chacun sa config préférée : 80 pour l’un, 120 pour l’autre, aucun wrapping pour un troisième).

          C’est exactement la même problématique que ceux qui wrappent leurs messages sur linuxfr.

          • [^] # Re: Indentation du code

            Posté par  . Évalué à 7.

            D’un autre côté, tous les éditeurs de moins de 15 ans te proposent un wrapping configurable à l’affichage, ce qui rend la convention non seulement désuète mais aussi contre-productive

            Non, parce que le wrapping produit une mise en forme pénible et inadaptée (au niveau de l'indentation).

            C’est exactement la même problématique que ceux qui wrappent leurs messages sur linuxfr.

            Non, car le langage naturel et le code n'ont pas les mêmes contraintes de mise en forme.

          • [^] # Re: Indentation du code

            Posté par  . Évalué à 6.

            C’est exactement la même problématique que ceux qui wrappent leurs messages sur linuxfr.

            Je ne trouve pas. Parce que du texte peut être coupé après chaque mots, tandis que quand on coupe une ligne de code, on s'arrange pour que ce soit le plus compréhensible possible (par exemple, mettre tout la string en deuxième ligne au lieu de la couper juste à 80 caractères).

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Indentation du code

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            le faire physiquement empêche d’avoir chacun sa config préférée : 80 pour l’un, 120 pour l’autre, aucun wrapping pour un troisième

            Ce qui est juste un cauchemar pour la gestion des versions où tu te retrouves avec un diff de 250 modifs parce que le mec a fait CTRL+Shift+F juste avant de committer une correction d'une ligne.
            Alors après, tu as toujours la possibilité de reformater le code au commit mais bon, rien ne vaut les règles de codage que ce soit pour statuer qu'il faut 80, 110 ou 200 colonnes.

    • [^] # Re: Indentation du code

      Posté par  . Évalué à 10.

      Toi aussi, tu développes sur ton Minitel ?

      • [^] # Re: Indentation du code

        Posté par  . Évalué à 4.

        Pour info, le minitel classique, c'est 40 colonnes :-)

        • [^] # Re: Indentation du code

          Posté par  . Évalué à 10.

          Il a peut-être un dual-screen de Minitels ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Indentation du code

          Posté par  (site web personnel) . Évalué à 4.

          40 colonnes Vidéotex, avec les pseudo graphiques qui se chargeaient ligne par ligne…

          Le Minitel 1B pouvait passer en 80 colonnes VT100.

          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: Indentation du code

        Posté par  (site web personnel) . Évalué à 0.

        Toi aussi, tu développes sur ton Minitel ?

        Pas loin : Emacs !

        Et en effet c'est extrêmement pratique de pouvoir avoir plusieurs colonnes en parallèle (deux, où plus suivant l'écran, fichiers côte à côte, deux endroits dans le fichier… j'aime pouvoir voir une grande partie de mon code d'un seul coup d'oeil !).

        Troll mode : Ça me fait toujours marrer de voir des mecs pleurer parce qu'ils veulent coder sur 150 colonnes pour avoir une meilleur visibilité sur leur IDE où 40% de la place est occupée par des boutons et autres textboxes…

        Je suis un jeune de la vieille école : je code sur Emacs en C, 2 espace par tabulation, 80 colonnes et je compile en C89 ! (voir en K&R quand le compilo est pas top…).
        C'est sûr que mon milieu ne contient pas le mêmes contraintes que dans les langages OO (miam java et ses getter de getter de getter pour aller chercher une valeur bien profonde !) où la ligne se retrouve souvent, au choix, verbeuse (et donc longue) où incompréhensible.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.