Discussion :

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

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

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

[abriotde]

Le passage de Python vers Julia ne demande pas beaucoup d'effort.

C'est assez vrai mais bon, il faut relativiser. Il y a quand même pas mal de spécificitées Python (pythonerie) et elles n'existent pas en Julia et vice versa. Mais néanmoins, je dirais que pour un développeur débutant, Python et Julia sont sensiblement aussi accessible l'un que l'autre et passer de Python à Julia est assez aisé dans la mesure ou l'ont reste dans le même type de langage : sans compilation, procédural de la ligné de C, avec un système de gestion de librairies avancé... Par contre en interne Julia est fortement typé (même si c'est beaucoup caché) contrairement a Python, c'est peut-être la plus grosse marche.

C'est un peu comme comparer PHP à Perl. En comparaison, Rust, introduit de la programmation fonctionnelle par rapport a C, il est plus proche d'un mixte entre divers inspirations très diverses (mais Rust se destine a des informaticien pointus comme C qui ont un bagage pour évoluer).