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 ?
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 ;-)
Posté par _kaos_ .
É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.
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 ?
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.
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.
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 :
factorial0=1factorialn=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 ».
# Impression de déjà vu
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (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 Sytoka Modon (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 Maderios . Évalué à 1.
Effectivement:
Le langage de programmation Julia serait capable de lire les fichiers CSV dix à vingt fois plus vite que Python et R
Poster une information ne signifie pas nécessairement adhésion
[^] # Re: Impression de déjà vu
Posté par _kaos_ . É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 lolop (site web personnel) . Évalué à 2.
Ils ont comparé avec la lecture via pandas ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Impression de déjà vu
Posté par moi1392 . É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 Jean-Baptiste Faure . Évalué à 6.
Vitesse et parallélisation automatique. Essentiels pour le calcul scientifique.
[^] # Re: Impression de déjà vu
Posté par Gabbro . É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 barmic 🦦 . Évalué à 4.
Avoir accès à un paradigme fonctionnel ? Avoir la parallélisation géré au sein du langage ? Avoir un gestionnaire de paquet ?
C'est à dire ?
Les nombreux projets qui cherchent à augmenter les performances de python me semblent ne pas aller dans ton sens.
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 Gabbro . Évalué à 1.
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.
Concrètement, par rapport à openmp ? Ce n'est pas « le langage », mais ça marche partout.
Gros +1, là.
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 barmic 🦦 . Évalué à 4.
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 :
On fait difficilement plus limpide pour qui fait des mathématiques.
openmp c'est limité comme forme de parallélisme.
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.
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 Jean-Baptiste Faure . Évalué à 4.
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 nlgranger . Évalué à 2.
Les nombreux projets couvrent une majorité des besoins: numpy, numba, cython, tensorflow, etc…
[^] # Re: Impression de déjà vu
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 02 novembre 2020 à 22:51.
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.