Ouin bon. J'avais les deux yeux dans le même trou! Merci du rappel
Ouin bon. J'avais les deux yeux dans le même trou! Merci du rappel
En ce qui me concerne , je suis arrivé à la conclusion que pour travailler sur une application complexe on ne peux pas se contenter d'utiliser un seul langage surtout en I.A.
Ce qui m'apparaît certain, c'est que les divers langages ne sont efficients que dans des domaines relativement restreints.
Les langages informatiques me semblent surtout orientés 'métiers' .
Pour reprendre par exemple l'approche de "Data science at the command line" de Jeroen Janssens , on s’aperçoit que ce domaine fait appel à un nombre relativement important de différents langages .
A chaque phase d'un problème d'intelligence artificielle d'un minimum d'envergure
il faut repasser par une analyse UML pour arriver à comprendre ce qu'on nous demande.
Ensuite découvrir les systèmes des data envisageables pour nourrir l'application envisagée,
puis décortiquer ces mêmes data plus ou moins structurées , ou pas, et dans diverses langues (mondialisation oblige) , et ... et re-ULM car autre paradigme
Encore les traduire, (avec toutes les réserves que cela suppose) pour créer des repères compatibles et
Enfin créer la data-base à partir de laquelle on va pouvoir commencer à envisager de construire nos hypothèses ...u
travaux : logique, statistiques , graphiques , d'aide à la structuration de la pensée ... j'en passe et des meilleurs.
Prendre les décisions rationnelles ... programme d'aide à la décision sans doute ?
a) Il est très clair qu'aucun langage ne peut résoudre toutes les étapes de notre processus.
b) il est tout aussi clair que nos hiérarchies sous la pression de nos financiers , n'acceptera jamais que n'existe pas de solution simple
du style [ ordinateur + programme + data = solution ] , donc quand un vendeur de langage lui promet que ' Mais bien sûr ' , vous allez vous retrouvez dans une impasse.
Depuis 15 ans je travaille en linux , Debian pour ne pas le nommer et sa philosophie est de fabriquer les outils dont on a besoin ( s'ils n'existent pas encore ) en assemblant divers programmes qui via des ' tuyaux ' résolvent les différentes étapes de votre problème.
L' OS est gratuit bien entendu , et vous trouverez de l'aide sur internet si vous comprenez que celui qui vous aide le fait gratuitement (en général)
Sur mon PC 57000 paquets sont disponibles , dont 13000 sont installés (toujours gratuitement) Les paquets sont des programmes , documentés et fiables , et qui peuvent souvent s'enchaîner. Et toujours si vous passant par des fichiers relais pour les data.
Le problème devient : quelle série de paquets vais-je utiliser ;
la méthode de résolution est : un premier pas, et puis ... les suivants
Il se fait, que chaque difficulté vaincue , reste une valeur mobilisable ultérieurement.
Qui va sano ,va lento !
L'informatique est une science de l'automatisation d'une partie de la pensée : celle qui est automatisable.
Ce n'est une course que pour des perdants
Cordialement , Paradoxalix
PS La pensée humaine s'exprime dans plus de mille langue , aucune n'est à l'abri des conneries , toutes peuvent exprimer des choses sublimes
les langages informatiques ...
Sans vouloir rentrer dans une gueguerre stérile entre les différents langages ... je pense que l'étude n'a pas compris l'intérêt même de Lua : son intégrabilité avec d'autres langages telle que les C/C++.
En effet, la majorité des programmes demandant de gros traitements lourds ne sont pas en Lua pure, mais en Lua qui fait appel à des fonctions en C/C++.
Hyper simple à mettre en place, facile à maintenir et diablement efficace (y compris énergiquement parlant).
Évidemment, les langages compilé sont plus rapides/efficaces. Mais ça ne prend pas en compte la compilation qui permet d'avoir ce résultat.
Autant dans un produit livré à grande échelle (OS, etc...) c'est avantageux (à tous points de vue : je n'imaginepas un kernel en python 🫢, mais pour des programmes "individuels" le temps d'apprentissage des langages compilés, les multiples compilations avant d'arriver au résultat final/fonctionnel rendent ce verdict plus circonstanciel.
Bonjour destroyedlolo,
Ce qui est vrai pour Lua l'est également pour la plupart des langage interprétés qui sont intéressants essentiellement pour servir de glue pratique entre des bibliothèques compilées (souvent en C ou C++).
Cela illustre que la comparaison de langages n'a pas de sens. On compare le meilleur environnement disponible avec un langage codé par les meilleurs programmeurs.
Doter un langage interprété d'un compilateur changera tout le tableau sans avoir à toucher au langage lui-même.
Par ailleurs, un langage confidentiel aura plus de mal à trouver des développeurs pouvant en tirer la quintessence. Ceci explique certainement quelques inversions surprenantes entre c, v, i dans le tableau. Le taux de propositions de codes par langage serait intéressant à connaître.
Salut
Partager