IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre actif
    Profil pro
    Loisir
    Inscrit en
    novembre 2011
    Messages
    155
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Loisir

    Informations forums :
    Inscription : novembre 2011
    Messages : 155
    Points : 280
    Points
    280
    Par défaut
    Je suis d'accord avec le message de Uther.

    De mon côté, je pense remplacera python dans un certain nombre de domaines scientifiques même si cela prendra du temps. Il est entre autre prévu/développé pour les sciences. L'avantage de Julia est qu'il se base sur les caractéristiques de l'informatique moderne, ce qui lui permet d'avoir des performances difficiles à atteindre avec Python qui conserve beaucoup de caractéristiques historiques. Cependant, j'ai l'impression que le public visé diffère un peu de celui de Python. Python semble viser (en science) des spécialistes de leur domaine qui veulent que ça fonctionne facilement quitte à perdre en performance. A l'inverse, Julia semble viser des utilisateurs plus proche de l'informatique, dans le sens près à s'investir pour optimiser les choses, quite à utiliser des techniques plus avancées offertes par le langage.

    Un inconvénient dû à son jeune âge est que c'est un peu la foire côté packages (opinion très personnelle). Je me pose beaucoup de question sur les packages, notamment en raison de mon historique de programmation très orientée vers Python et R qui disposent de modules/bibliothèques très structurants. Typiquement, du côté data science même si le paysage devient plus clair. J'ai posé une question que je pense assez simple sur ScikitLearn.jl et j'ai obtenu des réponses contradictoires (simple wrapper sur les fonctions en Python, accès au code compilé Cython, accès au code C ?). Si dans certains domaines les packages sont assez clairement identifiés, dans d'autres ce n'est pas le cas. Là où en Python, les packages recommandés en ML/DL sont surtout scikit-learn, Tensorflow/Keras et Pytorch, en Julia c'est vraiment plus fouillis. On m'a recommandé près d'une vingtaine de packages en me mettant en garde d'utiliser tel package pour tel type de calcul, tel autre pour d'autres, même si les deux packages couvrent sensiblement les même chose. D'utiliser tel package car il permet de jongler entre d'autres packages selon les caractéristiques des données, ... Et c'est assez similaire pour la visualisation. En tant que novice sur Julia, cette profusion de packages qui font des choses similaires mais qui manquent de quelques fonctions utiles qu'il faut coder ou aller chercher dans d'autres packages rend le langage moins attractif (qu'il ne devrait) par rapport à Python.

  2. #22
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 1 105
    Points : 4 048
    Points
    4 048
    Par défaut
    Plus il y aura de téléchargements, et donc d'utilisateurs, plus il y aura de chances d'avoir des remontées sur ce qui ne va pas, donc d'améliorer l'offre, et aussi d'avoir de nouvelles API autour de Julia.
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  3. #23
    Rédacteur
    Avatar de danielhagnoul
    Homme Profil pro
    Étudiant perpétuel
    Inscrit en
    février 2009
    Messages
    6 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant perpétuel
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2009
    Messages : 6 386
    Points : 23 054
    Points
    23 054
    Billets dans le blog
    120
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Juste comme ça, c'est ce que tu as lu ou entendu quelque part ou tu l'as vraiment expérimenté sur un vrai projet ?
    Vu qu'il y a des similitudes, j'ai trouvé le premier abord de Julia assez facile. Mais on se heurte rapidement aux différences dans le langage et dans le contenu des paquets.

    Le novice qui tombe sur le code ci-dessous devra réfléchir :

    function main()
    
        rayons = [0.75, 1.00, 1.25, 1.50, 1.75, 2.00, 2.15]
        sqrt.(2.0π.*rayons) |> println
    
    end
    
    main()
    
    #=
    [2.1708037636748028, 2.5066282746310002, 2.8024956081989645, 
    3.0699801238394655, 3.315957521978271, 3.5449077018110318, 
    3.6754385330782107]
    =#

    Blog

    Sans l'analyse et la conception, la programmation est l'art d'ajouter des bogues à un fichier texte vide.
    (Louis Srygley : Without requirements or design, programming is the art of adding bugs to an empty text file.)

  4. #24
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    993
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 993
    Points : 1 449
    Points
    1 449
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Juste comme ça, c'est ce que tu as lu ou entendu quelque part ou tu l'as vraiment expérimenté sur un vrai projet ?
    J'ai converti quelques vieux programmes en Pascal. Histoire d'apprivoiser la syntaxe. J'ai appris plusieurs nouveaux langages de cette façon. Cela permet de se concentrer sur l'apprentissage d'une nouvelle syntaxe.

    Si on ne se lance pas dans des trucs comme le multi-tâche, le langage est aussi accessible que le Pascal. Le seul truc un peu déroutant est que c'est supposément un langage objet, mais c'est un type de langage objet assez particulier. Ce serait plus un langage procédural avancé.

    Mon intérêt est qu'il y a un paquet de site qui fonctionne avec Wordpress ou Rails qui pourraient-être converti pour de gros $$. Et qui seraient plus sécures et rapides. Et moins casse-couille que PHP. Julia utilise Unicode en mode native.

    Genie, LE Framework Julia n'est pas prêt pour la production commerciale. Il y a trop librairies manquantes. Mais la vitesse de Génie est déjà impressionnante. Et cela, sans se lancer dans des trucs comme des thread. Mais si vous avez lu mes commentaires, vous savez que le langage supporte déja l'exécution distribué (distributed processing). Ce qui veut dire que théoriquement un site fait avec Génie pourrait être converti de façon à utiliser plusieurs ordinateurs, seulement en changeant des modules.

    Julia est un langage qui n'a pas beaucoup d'erreurs de jeunesse. Comme l'utilisation de l'ASCII pour le PHP. Ou le chiffre 0 qui à la fois est un Booléen, nil et un chiffre. Ou comme les versions incompatibles de Python. Le langage va peut-être ajouter des trucs comme le support pour des macros. Julia a une syntaxe qui est, selon moi, déjà très mature. Et il offre le meilleur des deux mondes. Tu peux fabriquer ton programme sans te soucier des types. Et une fois, qu'il est fonctionnel et que tu as une idée assez claire des tailles à choisir pour les nombres et les tableaux, tu peux l'optimiser en introduisant les types.

    Pour un gars qui a appris à programme sur LISP, Scheme et Pascal, c'est presqu'un retour aux sources.

    Citation Envoyé par danielhagnoul Voir le message
    Vu qu'il y a des similitudes, j'ai trouvé le premier abord de Julia assez facile. Mais on se heurte rapidement aux différences dans le langage et dans le contenu des paquets.

    Le novice qui tombe sur le code ci-dessous devra réfléchir :

    Code Julia : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    function main()
     
        rayons = [0.75, 1.00, 1.25, 1.50, 1.75, 2.00, 2.15]
        sqrt.(2.0π.*rayons) |> println
     
    end
     
    main()
     
    #=
    [2.1708037636748028, 2.5066282746310002, 2.8024956081989645, 
    3.0699801238394655, 3.315957521978271, 3.5449077018110318, 
    3.6754385330782107]
    =#
    Cela demande un effort d'adaptation, mais mon petit doigt me dit que ce code fonctionne déjà en multi-coeur...

    Cet effort additionnel est une aubaine, si on considère les gains acquis. Le même code écrit en Erlang serait sans doute beaucoup plus douloureux à lire ou à écrire.

    Citation Envoyé par Mingolito Voir le message
    Plus il y aura de téléchargements, et donc d'utilisateurs, plus il y aura de chances d'avoir des remontées sur ce qui ne va pas, donc d'améliorer l'offre, et aussi d'avoir de nouvelles API autour de Julia.
    C'est certainement une indication de l'intérêt des programmeurs pour ce langage.
    intel i7
    Mint 20
    Plasma et Cinnamon

  5. #25
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Madmac Voir le message
    J'ai converti quelques vieux programmes en Pascal. Histoire d'apprivoiser la syntaxe.
    Si je posais la question c'est parce qu'avec des petits projets "pour tester la syntaxe", on n'a souvent qu'un aperçu limité du langage.

    Citation Envoyé par Madmac Voir le message
    Le seul truc un peu déroutant est que c'est supposément un langage objet, mais c'est un type de langage objet assez particulier. Ce serait plus un langage procédural avancé.
    Justement, ce n'est pas un langage objet (du moins, pas dans le sens de Java ou Python). C'est plutôt basé sur un système de types polymorphes avec du multiple-dispatch.

    Citation Envoyé par Madmac Voir le message
    Le langage va peut-être ajouter des trucs comme le support pour des macros.
    Julia supporte les macros depuis longtemps : https://docs.julialang.org/en/v1/man...taprogramming/

    Citation Envoyé par Madmac Voir le message
    Et une fois, qu'il est fonctionnel et que tu as une idée assez claire des tailles à choisir pour les nombres et les tableaux, tu peux l'optimiser en introduisant les types.
    Et c'est là que les choses sérieuses commencent. Clairement, l'objectif de julia, c'est d'avoir un langage aussi haut-niveau que python mais aussi rapide que c++. En pratique, on y arrive mais c'est loin d'être aussi simple que d'écrire quelques signatures de types ou d'enlever des variables globales. D'où mon étonnement sur la remarque que "passer vers Julia ne demande pas beaucoup d'effort".

  6. #26
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    993
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 993
    Points : 1 449
    Points
    1 449
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Si je posais la question c'est parce qu'avec des petits projets "pour tester la syntaxe", on n'a souvent qu'un aperçu limité du langage.
    C'est pourtant comme cela que l'on commence à programmer avec un langage qui a de la profondeur. Par exemple, Ruby est un langage qui peut-être programmer de façon procédurale, de façon orienté-objet, de façon fonctionnelle et en mode distribué. Et le noyau standard est énorme. Si je devais complètement maîtriser le langage pour pouvoir l'utiliser, je n'aurais pas encore écrit une ligne de code en Ruby.

    Julia est également un langage avec beaucoup de profondeur, il peut même être utilisé pour faire des programmes qui normalement devraient être écrits en Erlang. Avec Javascript, Ruby et Julia, je peux tout faire ce que veut, sans avoir à apprendre un autre langage. En termes de vitesse, Julia se compare à C++. Et cela sans maîtrise parfaitement le langage. Je n'ai pas à maîtriser le langage pour être sûr du potentiel exceptionnel de ce langage. Il y a très peu de langage de programmation qui contiennent cette description:
    Julia prend en charge trois catégories principales de fonctionnalités pour la programmation simultanée et parallèle:
    Comme mon deuxième Dada, juste derrière l'intelligence artificielle, est l'étude des langages de programmation, j'ai aucun problème à reconnaître un langage de programmation exceptionnel. Ce n'est pas pour me vanter, mais trouver le langage qui pouvait tout faire (et pour faire le noyau d'une IA) à été ma quête du st-Graal pendant au moins trente ans.

    Citation Envoyé par SimonDecoline Voir le message
    Julia supporte les macros depuis longtemps : https://docs.julialang.org/en/v1/man...taprogramming/.
    J'ai sans doute vu le mot méta-programmation qui a fait que je n'ai pas exploré ce chapitre. Merci pour l'info! Mais je ne suis pas sûr que l'on parle de la même chose. Quand je parle de macro, je pense d'un macro langage comme en C. C'est extrêmement pratique quand on écrit du code avec des tableaux et des matrices.

    Citation Envoyé par SimonDecoline Voir le message
    Et c'est là que les choses sérieuses commencent. Clairement, l'objectif de Julia, c'est d'avoir un langage aussi haut-niveau que python mais aussi rapide que c++. En pratique, on y arrive mais c'est loin d'être aussi simple que d'écrire quelques signatures de types ou d'enlever des variables globales. D'où mon étonnement sur la remarque que "passer vers Julia ne demande pas beaucoup d'effort".
    Je me suis probablement mal exprimer. Mais si on considère que Julia est également capable de faire des trucs comparables à du Erlang ou à du Go. Si on compare du code de ces 3 langages, Julia a l'air aussi limpide que du Pascal. . Et pour moi, me passer de valeurs globales, cela ne me demande aucun effort. Car c'est une pratique courante en programmation orienté-objet. Et pour un langage comme C++, je les mets toutes dans une structure (struct) ou un objet. C'est aussi une des caractéristiques d'un bon langage, il nous conditionne à adopter de bonnes pratiques.

    Dès que l'on inclut le multi-tâche et traitement distribué dans le noyau d'un langage, la courbe d'apprentissage sera forcément plus longue qu'un langage comme JavaScript. Par contre, avec un langage comme JavaScript, tu découvres de grosses limites également très rapidement. Et quand cette limite t'apparaître au milieu d'un gros projet, c'est vraiment l'enfer. Alors à choisir entre un niveau de difficulté accrue et la possibilité de me retrouver en enfer, je préfère la difficulté accrue.

    Si un langage est capable de faire le travail de 4 langages, on se doit se calculer chanceux quand cela ne demande pas plus de travail que d'en apprendre 2.
    intel i7
    Mint 20
    Plasma et Cinnamon

  7. #27
    Rédacteur
    Avatar de danielhagnoul
    Homme Profil pro
    Étudiant perpétuel
    Inscrit en
    février 2009
    Messages
    6 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant perpétuel
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2009
    Messages : 6 386
    Points : 23 054
    Points
    23 054
    Billets dans le blog
    120
    Par défaut
    Citation Envoyé par Madmac Voir le message
    Cela demande un effort d'adaptation, mais mon petit doigt me dit que ce code fonctionne déjà en multi-coeur...

    Cet effort additionnel est une aubaine, si on considère les gains acquis. Le même code écrit en Erlang serait sans doute beaucoup plus douloureux à lire ou à écrire.
    Non ! C'est du Julia de base.

    Blog

    Sans l'analyse et la conception, la programmation est l'art d'ajouter des bogues à un fichier texte vide.
    (Louis Srygley : Without requirements or design, programming is the art of adding bugs to an empty text file.)

  8. #28
    Membre éclairé
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 200
    Points : 769
    Points
    769
    Par défaut
    Citation Envoyé par Madmac Voir le message
    Le passage de Python vers Julia ne demande pas beaucoup d'effort.

    Et pour quelqu'un qui débute, Julia un choix très largement supérieur à Python. Et comme plusieurs programmeurs utilisant Python voudrait une version typée, Je ne serais pas étonné que la clientèle traditionnelle passent à Julia.



    Il me semble avoir lu quelque part, qu'Amazon ou Walmart a largement contribué financièrement. Et pour cette raison la version 1.5 est déjà utilisable pour des projets commerciaux. Pour le moment, les librairies ne sont aussi mature que JavaScript. Mais je crois que l'année prochaine, les différences ne seront plus significatives.

    Comparaison de performance Julia Vs Python :https://benchmarksgame-team.pages.de...a-python3.html
    Bon alors déjà, prétendre que Python n'est pas typé, ça me hérisse le poil à chaque fois.

    Quant à l'assertion "Le passage de Python vers Julia ne demande pas beaucoup d'effort", c'est juste totalement faux. Python a une lib standard très fournie. Les paquets Julia hors calcul scientifique ne rivalisent pas encore avec. Julia n'a pas de système de class satisfaisant contrairement à Python. Ça limite quand-même beaucoup le portage de codes Python en Julia.

    Et réciproquement, Python ne supporte pas nativement le calcul matriciel. Ça complique beaucoup le portage de code Julia en Python.

    Plus généralement, Julia n'est intéressant que pour les codes dont le coût à l'exécution est très supérieur au coût de compilation dynamique. Le comportement standard dans Julia sauf package additionnel spécifique, c'est de compiler dynamiquement le code à chaque fois qu'il est exécuté en ligne de commande. Et dans la REPL, la compilation dynamique a lieu à chaque fois qu'un nouveau package est importé, et à la première exécution d'une fonction si elle a été saisie dans le shell.

    Le first plot problem en Julia décrit très bien ce qui est expliqué dans le paragraphe précédent.

  9. #29
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    Python a une lib standard très fournie. Les paquets Julia hors calcul scientifique ne rivalisent pas encore avec.
    Justement non : Python n'a pas de "lib standard très fournie". Il faut passer par Pypi ou Conda, et des environnements virtuels, et ce n'est vraiment pas satisfaisant.
    Au moins Julia a nativement un système de gestion de paquets, même si c'est moins fourni effectivement.

    Citation Envoyé par Jeff_67 Voir le message
    Julia n'a pas de système de class satisfaisant contrairement à Python. Ça limite quand-même beaucoup le portage de codes Python en Julia.
    Pas du tout. Python a un système de classe complètement naze. Il faut même souvent passer par les décorateurs pour pouvoir en faire quelque chose d'intéressant. Le système de type de Julia est bien plus puissant, c'est juste que c'est très différent de la POO "classique" et que ça demande un apprentissage.

    Citation Envoyé par Jeff_67 Voir le message
    Plus généralement, Julia n'est intéressant que pour les codes dont le coût à l'exécution est très supérieur au coût de compilation dynamique.
    ...
    Le first plot problem en Julia décrit très bien ce qui est expliqué dans le paragraphe précédent.
    Oui, le coût de première compilation peut être un problème. Ce sera intéressant de voir si les prochaines versions de Julia améliorent cela.

    Citation Envoyé par Madmac Voir le message
    En termes de vitesse, Julia se compare à C++. Et cela sans maîtrise parfaitement le langage.
    Est-ce-que tu as testé cela par toi-même, si possible sur des projets non-triviaux ? Généralement, en Julia, on a facilement une première implémentation mais il faut souvent pas mal de travail d'optimisation ensuite pour atteindre la vitesse du C++. D'ailleurs, il y a une page de la doc et une section du forum Julia entièrement dédiés à l'optimisation.

    Citation Envoyé par Madmac Voir le message
    Quand je parle de macro, je pense d'un macro langage comme en C. C'est extrêmement pratique quand on écrit du code avec des tableaux et des matrices.
    Les macros C, c'est juste du pre-processing très basique. Les "vraies" macros (comme en LISP ou en Julia) sont beaucoup plus puissantes que cela; elles permettent de vraiment manipuler l'AST.

    Citation Envoyé par Madmac Voir le message
    Par contre, avec un langage comme JavaScript, tu découvres de grosses limites également très rapidement
    Lesquelles ? JavaScript a souvent mauvaise réputation chez les programmeurs mais c'est un langage inspiré de LISP et qui n'est pas particulièrement critiqué dans le domaine des langages de programmation.
    Dernière modification par dourouc05 ; 21/01/2021 à 23h13.

  10. #30
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    993
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 993
    Points : 1 449
    Points
    1 449
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Est-ce-que tu as testé cela par toi-même, si possible sur des projets non-triviaux ? Généralement, en Julia, on a facilement une première implémentation mais il faut souvent pas mal de travail d'optimisation ensuite pour atteindre la vitesse du C++. D'ailleurs, il y a une page de la doc et une section du forum Julia entièrement dédiés à l'optimisation.
    J'ai regarder l'article pour l'optimisation. Et c'est pour le calcul matricielle spécifiquement. Pour l'optimisation de code, c'est cela: https://translate.google.fr/translat...search&pto=aue

    Citation Envoyé par SimonDecoline Voir le message
    Généralement, en Julia, on a facilement une première implémentation mais il faut souvent pas mal de travail d'optimisation ensuite pour atteindre la vitesse du C++.
    Pour le moment. Mais bientôt les CPUs avec 8 coeurs et plus vont devenir la norme. La programmation fonctionnelle est le style de programmation qui permet le plus facilement la conversion de séquence automatiquement en opération avec des threads. Et cela permet des optimisations de compilation qui sont spécifiques à la programmation fonctionnelle. C++ commence seulement à donner la possibilité de faire des Lambdas. Et ce n'est pas spécialement élégant. De l'autre côté, la syntaxe de Julia est déjà pensée pour gérer ce besoin. Et cela a pour conséquence qu'il existe un module pour les cartes Nvidia (CUDA) qui permette l'utilisation de la carte graphique comme co-processeur numérique. Des fonctions comme map et foreach sont déjà préexistants dans le noyau. Éventuellement quelqu'un va développer un transpiler pour convertir le programme en C ou en C++, si le besoin existe. À l'exception des jeux vidéos, je ne vois pas de secteur ou ce soit primordial, car pour le reste du temps, c'est vitesse et précision qui sont les critères qui priment. Avec des temps de réalisation du programme raisonnable. Et par expérience, je peux dire que pour les trucs complexes. Si on désire des résultats rapides. Il vaut mieux faire un prototype en Ruby, plutôt que de se lancer directement dans la conception en C++.


    Citation Envoyé par SimonDecoline Voir le message
    Les macros C, c'est juste du pre-processing très basique. Les "vraies" macros (comme en LISP ou en Julia) sont beaucoup plus puissantes que cela; elles permettent de vraiment manipuler l'AST.
    Je n'utilise pas énormément les macros, mais pour un truc comme un interpréteur prolog avec des indirections de plusieurs niveaux. Un truc comme:

    piles_de_retour(4, pile_de_variables[3], pile_de_functor[2]) est plus parlant pr[4][3][2]. Et ce qui est particulier avec les tableaux, est dans le cas d'une une expression comme b[3] = b[3] , le premier b[3] est une procédure et second est une fonction. Et si on désire remplacer le tout par des fonctions on doit faire un truc comme set_b(v,p) et get_b(p). Et on doit convertir l'expression de départ en set_b(3 get_b(3)), ce qui est moins clair à comprendre. Et c'est un cas simple, avec une matrice à trois dimensions cela donne des expressions beaucoup plus bordélique. Non seulement c'est plus facile à comprendre, mais si tu décides de remplacer les tableaux par des vecteurs, la conversion est relativement aisée avec des macros.

    J'utilise rarement les macros comme fonction, mais plutôt comme un outil de substitution d'expressions.

    Citation Envoyé par SimonDecoline Voir le message
    Lesquelles ? JavaScript a souvent mauvaise réputation chez les programmeurs mais c'est un langage inspiré de LISP et qui n'est pas particulièrement critiqué dans le domaine des langages de programmation.
    J'ai pas spécialement de problème avec le langage. Mais c'est un outil qui a été développé pour le web. Et si on sort de ce domaine, il devient pénible. Tout est dans le nom. C'est un outil de script, pas un langage complet. Théoriquement, il est possible de faire une maison avec un marteau et un égoïne, mais est-ce sensé ?

    Citation Envoyé par Jeff_67 Voir le message

    Plus généralement, Julia n'est intéressant que pour les codes dont le coût à l'exécution est très supérieur au coût de compilation dynamique. Le comportement standard dans Julia sauf package additionnel spécifique, c'est de compiler dynamiquement le code à chaque fois qu'il est exécuté en ligne de commande. Et dans la REPL, la compilation dynamique a lieu à chaque fois qu'un nouveau package est importé, et à la première exécution d'une fonction si elle a été saisie dans le shell.
    Considérant que la compilation ce fait en parallèle, je considère pas que c'est vraiment un problème significatif, à moins de vouloir faire un script. Alors là, un langage interprété est plus approprié. Mais pour une véritable application, c'est plutôt pendant le développement que cela représente un handicap. Et je sais que Python est typé, j'aurais du dire strictement typé.

    Citation Envoyé par danielhagnoul Voir le message
    Non ! C'est du Julia de base.
    C'est parce que le code est énoncé comme de la programmation fonctionnelle, que j’émets cette hypothèse. Mais le temps de d'exécution la fonction sqrt est peut-être trop court pour justifier un calcul en parallèle.
    intel i7
    Mint 20
    Plasma et Cinnamon

  11. #31
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 303
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 303
    Points : 8 212
    Points
    8 212
    Billets dans le blog
    43
    Par défaut
    Je n'ai jamais eu l'occasion de me pencher sur ce langage, cette frénésie sans fin à lancer une nouvelle hype pouvant être épuisante à la longue, mais je n'ai jamais été un fervent partisan de Python, au mieux tièdement.
    Pour la pédagogie et l'enseignement de la programmation, pourquoi pas, mais j'ai toujours eu du mal à comprendre pourquoi il était si prisé dans le milieu scientifique et notamment dans le calcul numérique dans la mesure où il s'agit d'un langage interprété et donc forcément moins performant qu'un langage compilé.
    On m'objectera qu'il y avait de nombreuses bibliothèques Python qui reposaient sur du code en C, moyennant un interfaçage (glue code).
    Mais dans ce cas, n'importe quel autre langage interprété aurait pu faire l'affaire.

    Ce qui semble surtout intéressant avec Julia, à mes yeux, c'est son interopérabilité avec le C (et dans une très moindre mesure avec le Fortran, parce que bon...).
    La possibilité d'appeler du C directement sans cérémonial est très séduisante et permet d'avoir quasiment le meilleur des deux mondes : la flexibilité d'un langage interprété, et la rapidité de fonctions compilées.

    Content donc Julia grignote du terrain sur Python.

    Idéalement, si Julia pouvait aussi appeler nativement du code Rust, je pense que ce serait le meilleur combo du moment.
    Tutoriels et FAQ TypeScript

  12. #32
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par yahiko Voir le message
    Je n'ai jamais eu l'occasion de me pencher sur ce langage, cette frénésie sans fin à lancer une nouvelle hype pouvant être épuisante à la longue,
    ...
    Idéalement, si Julia pouvait aussi appeler nativement du code Rust, je pense que ce serait le meilleur combo du moment.
    On ne fait pas des nouveaux langages pour le plaisir mais pour répondre à des cas d'utilisation parfois très différents.
    Dans certains cas, Python + un peu de C convient très bien. Dans d'autres cas, il faut faire du code à la fois performant et haut-niveau, et Julia est bien plus adapté. Quant à Rust, c'est du typage statique avec gestion mémoire manuelle, donc des cas d'utilisation encore différents.

    Citation Envoyé par Madmac Voir le message
    J'ai regarder l'article pour l'optimisation. Et c'est pour le calcul matricielle spécifiquement.
    Je ne sais pas de quel article tu parles mais ce ne doit pas être la page de la doc : https://docs.julialang.org/en/v1/man...formance-tips/
    Quant au calcul matriciel, c'est très optimisé de base dans Julia donc c'est sûrement le genre de code qui demande le moins d'effort d'optimisation à l'utilisateur.

    Citation Envoyé par Madmac Voir le message
    Pour le moment. Mais bientôt les CPUs avec 8 coeurs et plus vont devenir la norme
    Ca n'a pas vraiment de rapport. Généralement il faut déjà optimiser un minimum au lieu de balancer un code inefficace sur plein de CPU. De plus, à ma connaissance, Julia gère le distribué et non le multi-core, donc ce n'est pas juste ajouter une ligne de directive comme avec OpenMP.

    Citation Envoyé par Madmac Voir le message
    La programmation fonctionnelle est le style de programmation qui permet le plus facilement la conversion de séquence automatiquement en opération avec des threads. Et cela permet des optimisations de compilation qui sont spécifiques à la programmation fonctionnelle.
    Ca c'est la théorie. Mais en pratique, il faut que les fonctions ne fassent pas d'effet de bord et très peu de langages vérifient cela et font vraiment ce genre d'optimisation.

    Citation Envoyé par Madmac Voir le message
    C++ commence seulement à donner la possibilité de faire des Lambdas. Et ce n'est pas spécialement élégant.
    En C++, les lambdas existent depuis 2011. Et avant cela, on avait les objets-fonctions; c'était horrible mais ça existait depuis les années 90.

    Citation Envoyé par Madmac Voir le message
    Et cela a pour conséquence qu'il existe un module pour les cartes Nvidia (CUDA) qui permette l'utilisation de la carte graphique comme co-processeur numérique.
    CUDA est utilisable par plein de langages : C, C++, Fortran, Python...

    Citation Envoyé par Madmac Voir le message
    J'ai pas spécialement de problème avec le langage. Mais c'est un outil qui a été développé pour le web. Et si on sort de ce domaine, il devient pénible. Tout est dans le nom. C'est un outil de script, pas un langage complet. Théoriquement, il est possible de faire une maison avec un marteau et un égoïne, mais est-ce sensé ?
    Désolé mais je vois aucun argument là-dedans indiquant les "grosses limites" de JavaScript.
    Dernière modification par dourouc05 ; 22/01/2021 à 21h39.

  13. #33
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    711
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 711
    Points : 1 774
    Points
    1 774
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    On ne fait pas des nouveaux langages pour le plaisir mais pour répondre à des cas d'utilisation parfois très différents.
    Dans certains cas, Python + un peu de C convient très bien. Dans d'autres cas, il faut faire du code à la fois performant et haut-niveau, et Julia est bien plus adapté. Quant à Rust, c'est du typage statique avec gestion mémoire manuelle, donc des cas d'utilisation encore différents.
    La plupart ne créent peut-être pas de nouveaux langages pour le plaisir, mais il faut au moins essayer d'en créer avec un ensemble d'intérêts évidents, à la hauteur de ce qu'implique un nouveau langage complet.

    Le problème est qu'il y a tellement de nouveaux langages qui se créent, tous avec leur(s) intérêt(s) et leurs inconvénients, qu'on peu parfois douter que chaque nouveau langage récent apporte suffisamment d'avantages pour pouvoir justement être du niveau d'un nouveau langage à part entière.

  14. #34
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    993
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 993
    Points : 1 449
    Points
    1 449
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message


    Je ne sais pas de quel article tu parles mais ce ne doit pas être la page de la doc : https://docs.julialang.org/en/v1/man...formance-tips/
    Quant au calcul matriciel, c'est très optimisé de base dans Julia donc c'est sûrement le genre de code qui demande le moins d'effort d'optimisation à l'utilisateur.
    Oublie mon commentaire, en recherchant Julia et optimisation, j'ai abouti sur un truc qui parlait de calcul avec contrainte.



    Citation Envoyé par SimonDecoline Voir le message
    Ca n'a pas vraiment de rapport. Généralement il faut déjà optimiser un minimum au lieu de balancer un code inefficace sur plein de CPU. De plus, à ma connaissance, Julia gère le distribué et non le multi-core, donc ce n'est pas juste ajouter une ligne de directive comme avec OpenMP.
    C'est une capacité implicite des expressions fonctionnels. Chaque fois qu'un langage utilise un truc du genre, avec un tableau ou une liste:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    mon_tableau.each do |x|
     Fait_une_opération_élément_x
    end
    Cela peut être substitué mécaniquement par un pool de thread. Pour peu que Fait_une_opération_élément_x demande plus que quelque cycle CPU, la substitution en vaut la peine. Donc si l'optimisation n'est pas faite avec les versions actuelles, cela va finir par se produire.

    Autre conséquence de ce type de code est que les compilateurs peuvent également faire un autre type d'optimisation:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Conserver Fait_une_opération_élément_x
    dans la cache du CPU. Il y a un tas de trucs qui ont été développés avec l'APL qui sont adaptables à Julia.

    Citation Envoyé par SimonDecoline Voir le message
    En C++, les lambdas existent depuis 2011. Et avant cela, on avait les objets-fonctions; c'était horrible mais ça existait depuis les années 90.
    Je sais, mais comme tu le mentionnes c'était un truc pour maso. Il y a eu de nouveaux développements de ce côté, avec les dernières évolutions qui ont introduit des éléments de programmation fonctionnelle, mais cela reste tortueux.


    Citation Envoyé par SimonDecoline Voir le message
    CUDA est utilisable par plein de langages : C, C++, Fortran, Python...
    Mais aucun d'eux n'offre la vitesse d'un langage compilé sans devoir gérer la mémoire. Fortran n'existe plus dans mon esprit. Quelqu'un va finir par faire un convertisseur vers un autre langage et il va tomber dans l'oubli.


    Citation Envoyé par SimonDecoline Voir le message
    Désolé mais je vois aucun argument là-dedans indiquant les "grosses limites" de JavaScript.
    La vitesse, l'absence de GUI, une libraire presqu'uniquement orienté sur le web. En théorie, il est possible de faire des applications comme Atom, mais en pratique avec des documents le moindrement gros, on devine que le truc a été écrit avec un langage interprété. Quand on sort du web, cela demande beaucoup d'efforts.

    Citation Envoyé par yahiko Voir le message
    Je n'ai jamais eu l'occasion de me pencher sur ce langage, cette frénésie sans fin à lancer une nouvelle hype pouvant être épuisante à la longue, mais je n'ai jamais été un fervent partisan de Python, au mieux tièdement.
    Mais à moins, que je me trompe, c'est le seul langage compilé qui ne nous force pas à déclarer les types pendant le développement et qui nous dispense de la gestion de mémoire. C'est à mes yeux, une révolution.
    intel i7
    Mint 20
    Plasma et Cinnamon

  15. #35
    Rédacteur
    Avatar de danielhagnoul
    Homme Profil pro
    Étudiant perpétuel
    Inscrit en
    février 2009
    Messages
    6 386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : Belgique

    Informations professionnelles :
    Activité : Étudiant perpétuel
    Secteur : Enseignement

    Informations forums :
    Inscription : février 2009
    Messages : 6 386
    Points : 23 054
    Points
    23 054
    Billets dans le blog
    120
    Par défaut


    Contrairement à ce que je pensais dans mes messages précédents, une variable est toujours globale même dans un module.

    Voir mon billet de blog : Julia. Comment éviter les variables globales ?

    Blog

    Sans l'analyse et la conception, la programmation est l'art d'ajouter des bogues à un fichier texte vide.
    (Louis Srygley : Without requirements or design, programming is the art of adding bugs to an empty text file.)

Discussions similaires

  1. Quel langage de programmation pour le Web est-il plus sécurisé ?
    Par Hinault Romaric dans le forum Général Conception Web
    Réponses: 17
    Dernier message: 30/12/2019, 07h39
  2. Réponses: 13
    Dernier message: 19/05/2014, 14h16
  3. Quel langage de programmation pour le Web est-il plus sécurisé ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 14
    Dernier message: 25/04/2014, 11h38
  4. Windows Azure : plus simple, plus flexible, plus ouvert
    Par Gordon Fowler dans le forum Microsoft Azure
    Réponses: 2
    Dernier message: 08/06/2012, 21h44
  5. Quel est le langage de programmation le plus pertinent pour du traitement audio ?
    Par LeTouriste dans le forum Langages de programmation
    Réponses: 3
    Dernier message: 02/11/2006, 11h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo