• # Impression de déjà vu

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

    En gros l’intérêt de ce langage serait d’être multi-paradigmes (fonctionnel et impératif), rapide, facile à programmer, et d’encourager le partage du code. À part pour la vitesse, ça fait tout de même furieusement pensé à Python. Non ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Impression de déjà vu

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

      Sauf que Python n'a pas été conçu pour le parallélisme et que le Python actuel mélange les objets Python et les objets Numpy et que tout cela est un beau hack qui a quand même ses limites ;-)

    • [^] # Re: Impression de déjà vu

      Posté par  . Évalué à 1.

      • [^] # Re: Impression de déjà vu

        Posté par  . Évalué à 4. Dernière modification le 01 novembre 2020 à 17:29.

        Salut,

        La comparaison est peu pertinente à mon avis, du moins quand on travaille avec de la donnée.

        Lire un CSV, c'est du one-shot -à condition que le fichier soit bon évidemment- mais ensuite, faudrait comparer la vitesse d'un chargement d'un rda en R et l'équivalent si ça existe en python ou julia (aucune idée si ça existe…).

        Et perso, quand je traite de la donnée, le temps de chargement est négligeable par rapport au reste.

        Matricule 23415

      • [^] # Re: Impression de déjà vu

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

        Ils ont comparé avec la lecture via pandas ?

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

    • [^] # Re: Impression de déjà vu

      Posté par  . Évalué à 1.

      Je ne connaissais pas ce langague, alors après avoir lu l'article en question, je suis allée voir un peu de quoi il en retournait, et j'ai eu la même conclusion que toi :
      ça ressemble fortement à du python avec une syntaxe proche du C

      Du coup, c'est peut-être moi qui n'ai rien compris, mais qu'apporte-t-il vraiment de plus ?

      • [^] # Re: Impression de déjà vu

        Posté par  . Évalué à 6.

        Du coup, c'est peut-être moi qui n'ai rien compris, mais qu'apporte-t-il vraiment de plus ?

        Vitesse et parallélisation automatique. Essentiels pour le calcul scientifique.

    • [^] # Re: Impression de déjà vu

      Posté par  . Évalué à 4.

      Je l'avais essayé il y a quelques années (programmation scientifique, donc je suis dans le public visé). Plus rapide que Python, certes, mais à l'usage, j'avais pas trop vu l'intérêt par rapport à du C++ basique ou du Fortran.

      Si vous ne voulez pas vraiment programmer, je pense que Python reste meilleur (plus simple, bon écosystème, suffit presque tout le temps d'un point de vue perf), et que si vous êtes à l'aise avec la programmation (pour un scientifique, j'entends), n'importe quel langage orienté perf fera l'affaire.

      De plus, vu le niveau moyen des scientifiques qui programment, de nombreux problèmes de perf viennent des algorithmes plus que du langage.

      • [^] # Re: Impression de déjà vu

        Posté par  . Évalué à 4.

        C++ basique ou du Fortran.

        Avoir accès à un paradigme fonctionnel ? Avoir la parallélisation géré au sein du langage ? Avoir un gestionnaire de paquet ?

        Si vous ne voulez pas vraiment programmer[…]

        C'est à dire ?

        [python] suffit presque tout le temps d'un point de vue perf

        Les nombreux projets qui cherchent à augmenter les performances de python me semblent ne pas aller dans ton sens.

        De plus, vu le niveau moyen des scientifiques qui programment, de nombreux problèmes de perf viennent des algorithmes plus que du langage.

        C'est une bonne raison pour ne pas les laisser avec un langage leur permettant un accès direct à la mémoire.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Impression de déjà vu

          Posté par  . Évalué à 1.

          Avoir accès à un paradigme fonctionnel ?

          Dans le milieu scientifique que je fréquentais, ce n'était carrément pas une demande. La plupart ne savaient pas ce que c'était.

          Avoir la parallélisation géré au sein du langage ?

          Concrètement, par rapport à openmp ? Ce n'est pas « le langage », mais ça marche partout.

          Avoir un gestionnaire de paquet ?

          Gros +1, là.

          C'est à dire ?

          La plupart des scientifiques qui codaient que je connaissais, ils le faisaient parce qu'il n'avait pas le choix. Il avait appris un outil (parfois Matlab, Fortran 77, mais de plus en plus souvent Python), et l'utilisaient à l'arrache pour faire leur traitement de donnée. C'était bel et bien des scientifiques, pas des codeurs.

          Et quand ils voulaient faire des trucs compliqués, quand les perfs devenaient nécessaires, quand ça marchait pas, ils venaient demander de l'aide aux 3 du labo qui s'en sortaient mieux. C'était un outil, mais leur pas leur principal (et effectivement, vaut mieux ne pas les laisser avec un langage leur permettant un accès direct à la mémoire).

          Je pense que l'on a pas vu le même cas d'usage de la programmation en sciences.

          • [^] # Re: Impression de déjà vu

            Posté par  . Évalué à 4.

            Dans le milieu scientifique que je fréquentais, ce n'était carrément pas une demande. La plupart ne savaient pas ce que c'était.

            C'est normal, on demande rarement quelque chose dont on ne sais pas qu'il existe, mais le paradigme fonctionnel est généralement plus confortable quand on vient des mathématiques car il exprime plus les mathématiques plus idiomatiquement. La fonction factoriel en haskell peut s'écrire comme ça :

            factorial 0 = 1
            factorial n = n * factorial (n - 1)

            On fait difficilement plus limpide pour qui fait des mathématiques.

            Concrètement, par rapport à openmp ?

            openmp c'est limité comme forme de parallélisme.

            Ce n'est pas « le langage », mais ça marche partout.

            openmp5 dont la spec a 2 ans continue d'être implémenté dans gcc et est surtout implémenté pour C et C++ plus que pour fortran.

            Et quand ils voulaient faire des trucs compliqués, quand les perfs devenaient nécessaires, quand ça marchait pas, ils venaient demander de l'aide aux 3 du labo qui s'en sortaient mieux.

            C'est pratique de pouvoir aider sans dire « non mais attends on va tout réécrire dans un langage que tu ne saura pas lire ».

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Impression de déjà vu

            Posté par  . Évalué à 4.

            Concrètement, par rapport à openmp ?

            Parallélisation automatique. En gros c'est le compilateur JIT qui se débrouille de paralléliser ce qui peut l'être, pas l'utilisateur.

        • [^] # Re: Impression de déjà vu

          Posté par  . Évalué à 2.

          Les nombreux projets couvrent une majorité des besoins: numpy, numba, cython, tensorflow, etc…

    • [^] # Re: Impression de déjà vu

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 02 novembre 2020 à 22:51.

      À part pour la vitesse, ça fait tout de même furieusement pensé à Python. Non ?

      Ben en fait ça fait penser non seulement à Python mais à plein de langages de programmations: OCaml, Lisp, Clojure, Ruby, JavaScript, Scala, Go, …

Suivre le flux des commentaires

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