Discussion :

[Supernul]

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.

[Mingolito]

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.

[danielhagnoul]

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]
=#

[Madmac]

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.

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.

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.

[Invité]

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.

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.

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/

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

[Madmac]

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.

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.

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.

[danielhagnoul]

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.

[Invité]

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.

[Invité]

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.

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.

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.

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.

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.

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.

[Madmac]

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

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

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.

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

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

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.

[yahiko]

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.

[Invité]

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.

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.

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.

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.

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.

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

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.

[blbird]

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.

[Madmac]

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.

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.

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.

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.

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.

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.

[danielhagnoul]

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 ?