• # BEURK !!!!

    Posté par  . Évalué à 0. Dernière modification le 25 janvier 2016 à 22:25.

    Il y a tellement de langages plus intéressants …. En plus, les derniers rebondissements entre Oracle et Google à propos des APIs m'ont rendu méfiant : Java sapu cépalibre.

    • [^] # Re: BEURK !!!!

      Posté par  . Évalué à 1.

      exemple de langages plus intéressants et leur utilisations.

      • [^] # Re: BEURK !!!!

        Posté par  . Évalué à -3. Dernière modification le 26 janvier 2016 à 00:23.

        javascript et ses nombreux framework, dont les moteurs foisonnent et permettent de faire de plus en plus de choses sur quasi tout les périphériques. C'est LA techno du moment :)
        On peut même exporter sur android : https://www.pubnub.com/blog/2014-10-22-how-to-convert-your-javascript-app-into-an-android-app-with-phonegap/

        Côté complexité, je trouve que Java et javascript similaire (quoi que les framework dispo pour javascript rendent bien plus facile le codage, après je ne connais pas les framework java (j'ai juste eu 3 mois de cours dessus :P )

        Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: BEURK !!!!

          Posté par  . Évalué à 6.

          Mouai, j'ai toujours trouvé la POO ainsi que l'aspect asynchrone (les callbacks en cascade) du Javascript relativement déroutantes pour un débutant.
          C'est peut-être la techno du moment, je ne pense pas que ce soit le meilleur choix pour celui qui souhaite apprendre à faire les chose sérieusement.

          • [^] # Re: BEURK !!!!

            Posté par  . Évalué à 0.

            D'accord avec toi, ces enchainements en cascade sont très bien pour générer des plantages en cascade …
            En tout cas ce n'est pas avec Java qu'on apprendra à faire les choses sérieusement …

            • [^] # Re: BEURK !!!!

              Posté par  . Évalué à 3.

              Java != javascript
              On peut faire des choses sérieuses avec n'importe quel langage non exotique. Autant qu'on peut faire des conneries avec n'importe quel langage.

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: BEURK !!!!

          Posté par  . Évalué à 4.

          Euh, c'est moi ou tu compares un langage purement interprété à un langage compilé (enfin, compilé… mais je vais éviter les trolls, pas l'endroit)?

          Je doute qu'il y ait besoin de performances à son niveau tout comme je doute qu'il veuille faire des applets, donc je parlerai pas de l'argument des perfs.
          J'imagine aussi qu'il parle uniquement d'un site "statique", pour son début: pas de pages qui se rafraîchissent au minimum, juste des formulaires en dur et des pages en réponse.
          Pour ce type d'usages Java à un certain nombre d'avantages tout de même (et je suis un dev C++, imagines combien il me coûte d'écrire ça!).

          Je citerai:

          • typage fort, qui évite (aux débutants notamment, mais je ne suis plus débutant depuis longtemps et j'apprécie énormément le typage fort, pour ça que j'évite le C même) pas mal de prises de tête à l'exécution.
          • langage à la syntaxe simple, qui permets au compilateur de vérifier que le programmeur n'à rien omis. Typiquement, toutes les exceptions doivent être traitées systématiquement (moi je trouve ça lourd, mais au moins c'est un UB comme en C++), donc le dev doit faire du code propre. Enfin, il peut faire de la merde (catch( exception e){} doit être faisable j'imagine), mais le compilo l'aura avertit…

          Perso, je préfèrerai avoir à maintenir des sites web codés en Java qu'en PHP, ou il est nécessaire d'avoir des opérateurs qui vérifient explicitement l'égalité des valeurs et du type, ou en JS qui est pénible à lire (je n'ai probablement pas eu la chance de lire du JS propre ceci dit). Dans ces deux cas également, tu peux te retrouver avec des erreurs à l'exécution, qui auraient été détectées directement par Java.

          Sinon, pour rester dans les langage interprétés, python semble pas mal en vogue, pour ce qui est de la simplicité d'apprentissage.

          • [^] # Re: BEURK !!!!

            Posté par  . Évalué à 1.

            Pour ce type d'usages Java à un certain nombre d'avantages tout de même (et je suis un dev C++, imagines combien il me coûte d'écrire ça!).

            C'est une blague ?

            angage à la syntaxe simple, qui permets au compilateur de vérifier que le programmeur n'à rien omis. Typiquement, toutes les exceptions doivent être traitées systématiquement (moi je trouve ça lourd, mais au moins c'est un UB comme en C++), donc le dev doit faire du code propre.

            Ouais, dans le traitement de leurs exceptions, les devs java devraient apprendre à renvoyer des messages simple : parce que le probleme de emttre des exceptions partout, c'est qu'on se retrouve avec des logs qui sont remplies d'exception java qui ne veulent rien dire sauf pour qui connait le langage.

            • [^] # Re: BEURK !!!!

              Posté par  . Évalué à 2.

              C'est une blague ?

              Je veux bien troller sur les problèmes que je reproche à Java comparé à C++, mais ça n'apporterais rien ici.
              Et sinon, oui, je sais que C++ à des défauts aussi (p.e., beaucoup trop d'UB à mon goût) et qu'il n'y à rien dans le standard pour réseau ou le web, et très probablement pas de framework web décent.

              Ouais, dans le traitement de leurs exceptions, les devs java devraient apprendre à renvoyer des messages simple

              Ce n'est pas la faute du langage si l'utilisateur se contente de ré-envoyer l'exception, si? On peut faire de la merde dans tous les langages. Et plus particulièrement ceux qui ont un typage faible et/ou absent.
              Perso, mon opinion, c'est que balancer à l'utilisateur la stack d'appels quand y'a une exception, c'est un bug volontaire: le dev à été trop flemmard pour faire son taf.

              • [^] # Re: BEURK !!!!

                Posté par  . Évalué à 2.

                Ce n'est pas la faute du langage si l'utilisateur se contente de ré-envoyer l'exception, si? On peut faire de la merde dans tous les langages. Et plus particulièrement ceux qui ont un typage faible et/ou absent.
                Perso, mon opinion, c'est que balancer à l'utilisateur la stack d'appels quand y'a une exception, c'est un bug volontaire: le dev à été trop flemmard pour faire son taf.

                Je ne visais pas spécialement le langage, mais je me pose quand même une question : pourquoi est-ce davantage en Java que l'on voit ce genre de choses ? Un tas d'exceptions qui apparaissent dans les logs, mais ça n'empêche pas l'appli de tourner …

                • [^] # Re: BEURK !!!!

                  Posté par  . Évalué à 3.

                  Je ne visais pas spécialement le langage, mais je me pose quand même une question : pourquoi est-ce davantage en Java que l'on voit ce genre de choses ?

                  Je ne peux que partager ma théorie:

                  Java est un langage très prisé dans les écoles, mais on ne force pas les étudiants à traiter les erreurs correctement.
                  Comme Java impose d'avoir un try/catch dans chaque fonction dont une des fonctions fille peut lancer, on se retrouve avec des try/catch en cascade qui ne font que des rethrow.

                  J'imagine, n'étant pas un dev Java (ça m'est arrivé d'en faire, maintenance pour taf, mais j'ai toujours essayé d'esquivé) que quand on relance, ça ajoute automatiquement des infos?
                  Ou alors, c'est juste le comportement des outils standards, et comme les codes Java que j'ai vus ont toujours été faits par des gorets (du genre que tu peux diminuer de 15% la taille d'un fichier en 1ère lecture sur des fichiers de 4KLoc… véridique.) les exceptions sont juste balancées dans des messagesbox ou balancées sur stdout à l'arrache. Résultat: débuggable, mais galère.

                  Perso les exceptions, je commence à me dire qu'en fait, si je peux m'en passer, je le ferais quitte à faire des efforts ou à devoir fournir une interface un peu différente de l'habitude.
                  Je n'ai jamais été fan d'essayer de remettre le programme d'équerre en cas d'erreur (parfois il n'y a pas le choix, ok) je préfère un plantage propre (avec une sauvegarde des données si utile, et c'est bien là que les exceptions, utilisées correctement sont intéressantes).
                  Récemment, j'ai appris qu'en C++ une exception non récupérée est un UB. Je pensais que c'était un crash en standard, car c'est le comportement par défaut de VS, GCC et clang, mais non.
                  Du coup, ça veut dire que tous les codes que j'ai écrits jusqu'à ce que je m'aperçoive de ça, sont bugués, parce que j'utilisais les exceptions pour renvoyer des infos de débogage si elles ne sont pas attrapées, histoire qu'au moindre crash le dev ou l'admin sache exactement ce qui à causé l'exception (rade de RAM, IO foireuse, etc… ) sauf que vu que c'est un UB, si ça se trouve le programme ne balance pas les infos correctement, ou pire, oublie de nettoyer certains trucs.
                  J'ai aussi récemment appris que les appels à exit, par exemple, cassent les exceptions. Du coup, vu que j'aime beaucoup balancer mes codes réutilisables dans des bibliothèques, mon style de codage en à pris en coup: j'essaye d'éviter au maximum les exceptions quitte à risquer un segfault. Au moins un segfault, ça crash, c'est garantit.

                  Bref, les exceptions c'est l'un des aspects de l'OO sur lesquels je me pose aujourd'hui de vraies questions.
                  Et pour ce qui est de l'ADA… ça fait 4 ans que je me dis qu'il faudrait que je m'y mette… il y à Rust, aussi, qui m'intéresse beaucoup. Parce que moi, je veux que le compilo soit le plus chiant possible, histoire qu'au moins quand ça exécute, il y ait de grandes chances que ça marche. C++ est un peu léger de ce côté.

                  • [^] # Re: BEURK !!!!

                    Posté par  . Évalué à 2.

                    Je n'ai jamais été fan d'essayer de remettre le programme d'équerre en cas d'erreur

                    moi non plus … ça ne sert à rien. En général on a encore plus de problèmes après

                    parfois il n'y a pas le choix, ok

                    Je veux bien le croire, mais dans quel cas ? Si c'est pour de la disponibilité, il vaut mieux avoir l'approche Erlang : un moniteur qui relance le prog qui s'est vautré.

                    (avec une sauvegarde des données si utile, et c'est bien là que les exceptions, utilisées correctement sont intéressantes).

                    On est d'accord. Mais pour en revenir aux logs Java, je pense que les devs devraient avoir 2 flux de logs, ou générer des niveaux de verbosité : des logs à destination de l'admin ne contenant pas forcément toutes les traces du plantage, mais avec un message clair, et des logs (ou un niveau plus verbeux dans la log) à destination des devs pour le debug.

                    j'ai appris qu'en C++ une exception non récupérée est un UB.

                    Tu veux dire quoi par UB ?

                    J'ai aussi récemment appris que les appels à exit, par exemple, cassent les exceptions.

                    Ca je l'avais lu il y a longtemps dans un forum il me semble. Je l'avais oublié depuis (mais je ne fais plus de C++ depuis longtemps).

                    moi, je veux que le compilo soit le plus chiant possible, histoire qu'au moins quand ça exécute, il y ait de grandes chances que ça marche.

                    Là dessus je suis un peu partagé, et je pense qu'il faut voir au cas par cas : dans certains cas, pour certains types de développement, c'est inutile d'avoir un compilo qui rale au moindre truc qui ne serait pas assez déclaré. Il faut juste se poser les bonnes questions,: qu'est-ce qui se passe si ça plante? Quelles sont les conséquencess ? Et à partir de là on choisit.

                    • [^] # Re: BEURK !!!!

                      Posté par  . Évalué à 2.

                      Je veux bien le croire, mais dans quel cas ? Si c'est pour de la disponibilité, il vaut mieux avoir l'approche Erlang : un moniteur qui relance le prog qui s'est vautré.

                      J'avoue ne jamais avoir rencontré le cas, j'aurai du dire: "peut-être que". Je suis aussi le genre à préférer m'asseoir plutôt que de causer des dégâts en essayant de marcher avec une casse tordue.

                      Mais pour en revenir aux logs Java, je pense que les devs devraient avoir 2 flux de logs, ou générer des niveaux de verbosité : des logs à destination de l'admin ne contenant pas forcément toutes les traces du plantage, mais avec un message clair, et des logs (ou un niveau plus verbeux dans la log) à destination des devs pour le debug.

                      +1

                      Tu veux dire quoi par UB ?

                      Undefined Behavior. Autrement dit, ça peut marcher d'une façon sur une cible et différemment sur une autre cible, tout en respectant le standard. C'est un truc qui commence à m'agacer sévèrement en C++: trop d'UB.

                      Là dessus je suis un peu partagé, et je pense qu'il faut voir au cas par cas : dans certains cas, pour certains types de développement, c'est inutile d'avoir un compilo qui rale au moindre truc qui ne serait pas assez déclaré.

                      Peut-être que dans certains cas, c'est excessifs, c'est vrai. Mais malheureusement, les langages dits interprétés ont tendance à ne râler qu'à l'exécution.
                      Dans le cas des langages compilés, je suis probablement trop centré sur C++ pour en discuter intelligemment. En tout cas, ce qui est certain, c'est que j'ai essayé d'utiliser un peu le nouvel usage du mot-clé auto, qui permets de définir automatiquement le type d'une variable. Quelques semaines plus tard, il m'est arrivé de ne pas me rappeler ce que je manipulais au 1er regard.
                      Du coup, je vois 2 avantages à l'obligation de spécifier le type et le nom des variables: le fait que le compilo peut vérifier, et le fait que le relecteur n'ait pas besoin de réfléchir 5 minutes au premier bloc de code qui utilise des structures imbriquées.
                      auto reste utile à mes yeux, mais c'est à mon avis une fonctionnalité qui à un fort impact sur la maintenance dès lors qu'on utilise des structures non triviales (un [multi][map|set]::iterator par exemple), chose que je n'ai jamais vue dite.
                      D'un autre côté, je n'ai que rarement vu des codes sans warning être involontairement durs à maintenir. Sauf quand ils ne sont pas activés, bien sûr, mais là je considère que c'est volontaire.

                    • [^] # Re: BEURK !!!!

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

                      On est d'accord. Mais pour en revenir aux logs Java, je pense que les devs devraient avoir 2 flux de logs, ou générer des niveaux de verbosité

                      Les dévs java utilisent une librairie pour les logs, souvent log4j et évidemment il y a plusieurs niveaux de logs, info, debug, warning, error…
                      Les sysadmins devraient juste se préoccuper de error et transmettre, de la même façon les logs de debug ne s'affichent pas en prod mais uniquement dans les environnements de développements ou de bench.

                      • [^] # Re: BEURK !!!!

                        Posté par  . Évalué à 2.

                        Alors les devs java ne se préoccupent pas de leur exceptions en les laissant traiter par l'appelant, ni des erreurs en laissant les sysadmins (qui n'ont à la base rien à faired de log4j qui est bien pourri), donc ils font quoi ?

                        Pour un admin, configurer un niveau de log devrait se faire simplement. Mais quand on voit ça, on se dit que c'est une blague :

                            <?xml version="1.0" encoding="UTF-8"?>
    <Configuration status="WARN">
      <!-- Define custom levels before using them for filtering below. -->
      <CustomLevels>
        <CustomLevel name="DIAG" intLevel="350" />
        <CustomLevel name="NOTICE" intLevel="450" />
        <CustomLevel name="VERBOSE" intLevel="550" />
      </CustomLevels>

      <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
          <PatternLayout pattern="%d %-7level %logger{36} - %msg%n"/>
        </Console>
        <File name="MyFile" fileName="logs/app.log">
          <PatternLayout pattern="%d %-7level %logger{36} - %msg%n"/>
        </File>
      </Appenders>
      <Loggers>
        <Root level="trace">
          <!-- Only events at DIAG level or more specific are sent to the console. -->
          <AppenderRef ref="Console" level="diag" />
          <AppenderRef ref="MyFile" level="trace" />
        </Root>
      </Loggers>
    </Configuration>

                        • [^] # Re: BEURK !!!!

                          Posté par  . Évalué à 2.

                          les sysadmins […] ils font quoi ?

                          Ils font virer les dev incompétents. Plus sérieusement, j'aimerai bien que les logiciels soient moins codés avec les pieds.
                          Et ce n'est pas la faute des langages, si le dev fait tout ce qu'il peut pour mal l'utiliser.

                  • [^] # Re: BEURK !!!!

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

                    J'imagine, n'étant pas un dev Java (ça m'est arrivé d'en faire, maintenance pour taf, mais j'ai toujours essayé d'esquivé) que quand on relance, ça ajoute automatiquement des infos?

                    Non, juste re-balancer une exception ne la fait pas grossir, ça change rien.
                    Par défaut, certains IDE écrivent "catch(Exception e) e.printStacktrace()" ça écrit la pile jusqu'au plantage mais c'est une très mauvaise pratique. Soit on gère l'exception, soit on la balance plus haut sans y toucher.
                    Donc si il y a une stack trace, elle est sortie par la JVM, autant dire qu'il s'est vraiment passé quelque chose de grave, mais il est hors de question d'arrêter la JVM pour ça vu que ça revient à éteindre le serveur.
                    Si c'est pas le cas, c'est effectivement la faute du développeur.

                    Les exceptions sont utilisées pour des comportements non voulus mais prévisibles.

                    Par exemple, si ça plante quelque part au niveau d'une mise-à-jour de stocks, la fonction va dire "oups ça a planté" à la fonction appelante, cette dernière va dire "ah tu fais chier, j'en sais rien moi" elle renvoie l'erreur à la fonction appelante qui elle va dire "ah, vous êtes relou, moi j'avais déjà fait le paiement, bon bein je vais rembourser et je préviens le patron au cas où" (avec des logs et un message plus ou moins clair).
                    Du coup, si le dév est mauvais, il va coder "oups ça a planté, je sais pas ce que je fais du coup j'affiche tous les logs possible, le sysadmin va se débrouiller pour revert le paiement à la main et moi je fais comme si j'avais rien vu"

                    Bein ça continue de marcher, mais y a des trous, plus ou moins grave…

                    • [^] # Re: BEURK !!!!

                      Posté par  . Évalué à 2.

                      Par défaut, certains IDE écrivent "catch(Exception e) e.printStacktrace()" ça écrit la pile jusqu'au plantage mais c'est une très mauvaise pratique.

                      Ah les générateurs de code… voilà pourquoi je me méfie de ces trucs. En tout cas merci de l'éclaircissement.

              • [^] # Re: BEURK !!!!

                Posté par  . Évalué à 3.

                Je veux bien troller sur les problèmes que je reproche à Java comparé à C++, mais ça n'apporterais rien ici.

                Je parlais surtout de faire du web avec java. Sinon, tant qu'à voir du typage fort, autant utiliser Ada. Mai s bon, il est tard et je suis trop crevé pour troller.

          • [^] # Re: BEURK !!!!

            Posté par  . Évalué à 1. Dernière modification le 26 janvier 2016 à 22:03.

            Euh, c'est moi ou tu compares un langage purement interprété à un langage compilé (enfin, compilé… mais je vais éviter les trolls, pas l'endroit)?

            Semi interprété si tu préfère, mais l’exécution est tout de même déléguée à un moteur, tout comme pour Python, Javascript, PHP et j'en passe.

            Quant à Javascript: je te rejoins sur l'illisibilité du code, sans framework tout du moins.
            L'avantage de javascript sur Java est qu'il est plus facile de disposer d'un moteur (nodejs, navigateur) sur un périphérique et qu'il ne nécessite pas un IDE (un éditeur de texte et un navigateur suffisent).

            Et plus particulièrement ceux qui ont un typage faible et/ou absent.

            Je ne vois pas le rapport (j'ai appris au cours PHP et Java en même temps).

            Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

            • [^] # Re: BEURK !!!!

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

              Pour le langage compilé, je pense qu'il parle du fait qu'un plus grand nombre d'erreurs sont visibles à la compilation et pas au runtime, c'est plus agréable.
              Heureusement qu'on ne parle pas de performance, car NodeJS s'en sort très bien

              Le typage faible, ça fait que on se retrouve avec des "1"+1 et on sait pas si c'est 11 ou 2.
              Par exemple appeler une fonction sur un objet, si la fonction n'existe pas, on le sait tout de suite en java. Alors que en javascript/php il faut faire l'appel au runtime avant de se rendre compte que c'est pas possible car l'objet n'est pas du type qui a la fonction à ce moment là…

              • [^] # Re: BEURK !!!!

                Posté par  . Évalué à 3.

                Le typage faible, ça fait que on se retrouve avec des "1"+1 et on sait pas si c'est 11 ou 2.
                Par exemple appeler une fonction sur un objet, si la fonction n'existe pas, on le sait tout de suite en java. Alors que en javascript/php il faut faire l'appel au runtime avant de se rendre compte que c'est pas possible car l'objet n'est pas du type qui a la fonction à ce moment là…

                A ce propos il ne faut pas confondre typage faible et typage dynamique. J'ai failli faire l'erreur en vous lisant.

            • [^] # Re: BEURK !!!!

              Posté par  . Évalué à 3.

              il ne nécessite pas un IDE

              Pour java un éditeur de texte et un compilateur suffisent, pas besoin d'IDE.

          • [^] # Re: BEURK !!!!

            Posté par  . Évalué à 2.

            mais au moins c'est un UB comme en C++

            Oups! Ce n'est pas, pardon.

      • [^] # Re: BEURK !!!!

        Posté par  . Évalué à 2. Dernière modification le 26 janvier 2016 à 09:42.

        Erlang, avec eJabberd ou RabbitMQ, riak …

      • [^] # Re: BEURK !!!!

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

        Et même si on veut absolument se traîner cette baleine asthmatique de JVM, il y a Scala, Groovy, Clojure, Kotlin, Ceylon…

        • [^] # Re: BEURK !!!!

          Posté par  . Évalué à 3.

          Ah, ça y est, je cmprends !! Je croyais que lorsque je lançais un programme java sur ma machine, et que je l'entendais souffler, c'est parce que le processeur avait chaud, mais en fait j'ai tout faux, c'est la JVM qui respire !!!

          Merci de m'avoir éclairé sur ce point.

          • [^] # Re: BEURK !!!!

            Posté par  . Évalué à 1.

            Pour info, des programmes tournaient en Java sans problème sur les premiers téléphones portables faisant autre chose que téléphoner.
            Du coup, je suis obligé de te demander quel programme écrit en Java fait ainsi souffler ta machine, pendant qu'un programme équivalent en terme de fonctionnalités mais lui écrit en JS fait fonctionner sans problème?

            • [^] # Re: BEURK !!!!

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

              La lourdeur en vrai c'est pas tant la JVM, d'ailleurs android c'est toujours du Java et ça marche bien.
              Mais c'est tout ce qu'on met derrière, genre pour du JEE, un glassfish ou un tomcat ça bouffe déjà pas mal de RAM.
              Et puis souvent ce sont des logiciels qui ont 10 ans et des dizaines de stagiaires ont mis les doigts dedans, en utilisant des dizaines de bibliothèques elles aussi parfois pas optimisées, ça aurait été pareil avec un autre langage aussi répandu de nos jours je pense.

              Mais bon, peut-être que toutes les abstractions liées au langage font que c'est facile de faire les choses mais compliqué de les faire bien.

              • [^] # Re: BEURK !!!!

                Posté par  . Évalué à 2.

                La lourdeur en vrai c'est pas tant la JVM, d'ailleurs android c'est toujours du Java et ça marche bien.

                Je suis bien d'accord.

                Mais bon, peut-être que toutes les abstractions liées au langage font que c'est facile de faire les choses mais compliqué de les faire bien.

                Hum. Je ne sais pas. Si on prend la lib standard de Java, y-a-t-il tant d'abstractions que ça?
                Je ne connais pas le détail exact pour Java, mais je sais qu'en C++ il y à des moments ou la lib standard n'est pas adaptée (notamment quand on fait gaffe à la mémoire) et où il ne faut pas hésiter à utiliser des alternatives.
                Proposer une option avec des abstractions trop lourdes/nombreuses ne me semble pas forcément une mauvaise chose, tant que ça reste une option. N'y a-t-il pas moyen en Java de faire les choses simplement?

            • [^] # Re: BEURK !!!!

              Posté par  . Évalué à 3.

              Du coup, je suis obligé de te demander quel programme écrit en Java fait ainsi souffler ta machine,

              Eclipse ?

              • [^] # Re: BEURK !!!!

                Posté par  . Évalué à 2. Dernière modification le 31 janvier 2016 à 02:10.

                y'a un des IDEs JS aussi puissants qu'éclipse et moins buggués/lourds/fuyants?

  • # ty

    Posté par  . Évalué à -3.

    C'est vrai que les tuto sont bien tapé. Je ne connaissais pas ce site, merci du partage ;)

    Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: ty

      Posté par  . Évalué à 2.

      Pour les personnes qui seraient intéressées malgré cette tentative éhontée de publicité masquée, le site est une version française de tutorialspoint (qui lui même à tendance à plagier la doc officielle des projets). La version anglaise est plus complète et ne souffre pas d'erreur de traduction.

    • [^] # Re: ty

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

      J'ai pas tout lu mais en gros j'ai ouvert deux pages, la première ça parle de ant… ahem
      et la deuxième ça parle de pentium 200MHz et de Linux 7.1… Du coup je doute de la qualité

  • # Loi des forums

    Posté par  . Évalué à 4.

    Plus la note d'un journal est négative, plus la probabilité qu'il ait été créé par quelqu'un qui vient juste de se créer un compte linuxfr est élevée.

    Cette probabilité est encore plus forte si le journal contient un lien.

    • [^] # Re: Loi des forums

      Posté par  . Évalué à 0. Dernière modification le 26 janvier 2016 à 17:51.

      je suis d'accord avec vous que webtotoriels est similaire à tutorialspoint mais ce dernier n'a pas de tutoriels en français sans oublier aussi que l'idée de traduire en français est positive car moi personnellement je trouve de difficultés en anglais ne soyez pas dur dans vos opinions qu'il y a une publicité. dans mon côté j'ai trouvé le lien au hasard et je veux le partager avec vous parce que la logique de forum est le partage de connaissance tout simplement.

      • [^] # Re: Loi des forums

        Posté par  . Évalué à 3.

        Je me suis pas embêté à chercher si tu veut juste te faire de la pub, mais si tu es nouveau ici, et que tu comptes rester, il te faut savoir 2 choses:

        • les habitués ne voient pour la plupart les notes des commentaires que comme des curiosités (quoique sur les demandes de forum et journaux ça permets d'estimer un peu la qualité, tout de même)
        • certains sont très véhéments, parfois en fonction de leur humeur. C'est d'ailleurs un truc que j'aime ici: le politiquement correct n'est pas d'actualité, sans pour autant que les sujets soient des suites d'insultes. Et au vu de la quantité de population de ce site, c'est fréquent que quelqu'un le soit, véhément (ou ait envie de chercher la petite bête) :)

        Pour le reste:

        l'idée de traduire en français est positive car moi personnellement je trouve de difficultés en anglais

        Dans ce cas, il sera difficile de devenir un programmeur.
        Soyons clairs: programmer nécessite de comprendre l'anglais, surtout quand on parle de choses qui évoluent souvent, typiquement le web. Les docs techniques sont obligatoires, quand on veut vraiment faire les choses, et elles sont en anglais. Les codes sont en anglais le plus souvent, et cela inclue les commentaires. Je ne parlerai pas des ressources genre stackoverflow (qui est sûrement devenu quasi-incontournable à toute personne s'intéressant à la prog, pour le coup).

        Et puis, franchement, l'anglais technique n'est pas si difficile que ça. Mais bon, oui, une bonne traduction de tutoriels est toujours une bonne chose.
        À ce sujet, je pense que tu auras plus de retours positifs sur des sites tels développez.com, ils recensent énormément de tutoriels de tous types, tous langages, et il y a un effort pour traduire des tutoriels vers le français.

Suivre le flux des commentaires

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