Pouvoir réutiliser des fonctions déjà écrites

Je partage tout à fait votre constat.

Aujourd'hui, CoddyRun ne permet effectivement pas encore d'importer directement des fonctions ou procédures définies dans un autre fichier au moment de l'exécution.

D'un point de vue pédagogique comme pratique, c'est une fonctionnalité très intéressante.
Elle permet de développer et tester une bibliothèque de fonctions utilitaires une seule fois, de la stocker dans un fichier dédié, puis de la réutiliser dans différents projets sans avoir à recopier le code.

Le programme principal reste ainsi plus lisible, plus concis et plus facile à maintenir.

À noter qu'il existe déjà une solution intermédiaire : vous pouvez enregistrer vos fonctions et procédures dans votre bibliothèque personnelle puis les importer dans un programme.

Sélectionnez la fonction ou la procédure dans l'éditeur de code, puis effectuez un clic droit et choisissez « Ajouter à la bibliothèque ».

Il vous suffit ensuite de cliquer sur le lien correspondant dans la rubrique « Bibliothèque » pour insérer automatiquement votre fonction ou procédure dans l'éditeur, à l'emplacement actuel du curseur.

Votre idée est bonne, et j'y avais déjà pensé. Le problème est que, si demain vous partagez un programme utilisant une fonction présente uniquement dans votre bibliothèque personnelle, cette fonction ne sera pas disponible chez la personne qui reçoit le code via son raccourci ou son import.

C'est d'ailleurs pour cette raison que le système actuel insère directement le code de la fonction ou de la procédure dans le projet. Ainsi, le programme reste autonome et peut être partagé sans dépendre de la bibliothèque d'un autre utilisateur.

L'objectif de CoddyRun est aussi de permettre à chacun d'ouvrir et d'exécuter un programme sans avoir à rechercher ou installer des bibliothèques externes. C'est un point important, notamment dans un contexte d'apprentissage.

On pourrait effectivement imaginer une bibliothèque en ligne commune, dans laquelle chacun pourrait publier et partager ses fonctions ou procédures. Cependant, cela irait à l'encontre de la philosophie de CoddyRun.

L'un des objectifs du langage est de pouvoir fonctionner entièrement sans dépendance à Internet.

Je tiens beaucoup à cet aspect :

un programme doit pouvoir être créé, exécuté, partagé et appris dans n'importe quel contexte, même sans connexion.

C'est aussi pour cette raison que je privilégie actuellement l'insertion directe du code des fonctions et procédures dans le projet. Le programme reste autonome, facilement partageable et ne dépend ni d'un serveur, ni d'une bibliothèque distante, ni d'une version particulière d'un dépôt en ligne.

Aujourd'hui, je n'ai pas vraiment d'autre alternative. Pour garantir qu'un programme puisse être partagé et exécuté par tout le monde sans dépendance externe, l'utilisateur doit créer ses propres fonctions et procédures puis les intégrer directement dans son code principal.

Ce n'est peut-être pas la solution la plus élégante, mais elle a l'avantage d'assurer qu'un programme reste totalement autonome. Ainsi, lorsqu'il est partagé, il contient déjà tout ce dont il a besoin pour fonctionner, sans nécessiter de bibliothèque.

Bonjour à tous,

L’idée aurait effectivement pu être intéressante. Cependant, comme le dit CoddyRun, les programmes doivent rester autonomes afin de pouvoir être partagés et utilisés par tout le monde.

D’un point de vue pédagogique, je pense finalement que l’appel de fonctions ou de procédures invisibles peut ajouter de la complexité. Pour comprendre la structure complète d’un programme, il faudrait rechercher dans la bibliothèque toutes les fonctions utilisées, ce qui demanderait davantage de manipulations.

Le fait de conserver les fonctions et les procédures directement dans le programme ajoute certes quelques lignes, mais tout reste visible au premier coup d’œil. Pour comprendre le fonctionnement du code, je trouve cette solution plus claire. Cela reste bien entendu mon point de vue.

Pouvoir enregistrer ses propres fonctions et procédures dans la bibliothèque est déjà une très bonne chose. Il suffit ensuite de les importer dans le code en un seul clic. Personnellement, ma bibliothèque contient environ 200 fonctions et procédures, notamment des fonctionnalités qui ne sont pas disponibles nativement dans CoddyRun, comme :

est_entier()

Je trouve également intéressant que le nombre de fonctions natives reste raisonnablement limité. Cela encourage les utilisateurs à créer leurs propres fonctions et à comprendre leur fonctionnement. Sinon, il deviendrait trop facile d’appeler des fonctions toutes faites sans savoir comment elles fonctionnent réellement.

Cela dit, pourquoi ne pas proposer cette petite fonctionnalité en option pour les utilisateurs qui préféreraient appeler directement des morceaux de code enregistrés dans leur bibliothèque ?

Bonjour à tous,

Eliora a écrit :

Cela dit, pourquoi ne pas proposer cette petite fonctionnalité en option pour les utilisateurs qui préféreraient appeler directement des morceaux de code enregistrés dans leur bibliothèque ?

Oui, cela pourrait être possible grâce à une nouvelle section intitulée "Mes fonctions et procédures", accessible depuis "Mes programmes".

La rubrique "Ma bibliothèque" conserverait son fonctionnement actuel et servirait toujours à insérer des morceaux de code directement dans l’éditeur.

Je pourrais développer un nouveau module permettant de créer, modifier et gérer des fonctions et des procédures depuis cette nouvelle section.

Du côté du langage, je pourrais réutiliser le mot-clé "appelle".

Par exemple, si IntToHex est le titre d’une fonction enregistrée dans "Mes fonctions et procédures", son utilisation pourrait s’écrire ainsi :

affiche appelle(IntToHex(1000))

La fonction serait alors exécutée, sans que son code soit directement visible dans le programme principal.

À titre d’information, cette nouvelle section aurait un fonctionnement différent de "Ma bibliothèque".

La bibliothèque actuelle permet de stocker plusieurs types de blocs de code afin de les insérer dans l’éditeur.
La nouvelle section "Mes fonctions et procédures", quant à elle, serait exclusivement réservée aux fonctions et aux procédures. Chacune devrait être créée et enregistrée séparément.

Dans l’éditeur, il suffirait ensuite de cliquer sur le nom d’une fonction ou d’une procédure appelée pour afficher directement son code.
Cela permettrait de conserver un programme principal plus court, tout en gardant un accès simple au contenu utilisé.

Il resterait toutefois à réfléchir à la gestion du partage, afin que les programmes puissent continuer à fonctionner de manière autonome chez tous les utilisateurs.

Si cette nouvelle fonctionnalité vous convient et vous paraît utile, je pourrais l’intégrer à la prochaine mise à jour de CoddyRun. Qu’en pensez-vous ?

Merci pour le retour.

La solution proposée me paraît bien voire très bien.

Je n'avais pas vu la section 'Ma Bibliothèque' et du coup le clic droit pour intégrer dans son programme actuel une fonction déjà réalisée est appréciable. J'ai encore des choses à découvrir sur cet environnement :-)

Cependant je reste convaincu que dans le cadre d'un apprentissage la validation de fonctions au fur à mesure des besoins est un plus. Cela devrait permettre à l'apprenant de comprendre la nécessité de réaliser des tests pour couvrir toutes les configurations possibles ce que beaucoup de débutants ne font pas (moi le premier à mes débuts et j'avoue même encore aujourd'hui).
Pour illustrer mon propos : sur la simple fonction est_entier donnée en exemple, normalement n doit être un nombre pour fonctionner correctement, et effectivement pour n vaut 'Ok' on sort une erreur mais pas si n vaut '11' puisque 'est_nombre('11')' sort vrai. C'est le langage qui veut cela, mais tous les langages ne sont pas aussi permissifs. Pour cette simple fonction cela ne prête pas à conséquence mais pour d'autres plus complexes ... Bref il me semble nécessaire de le savoir.

Je ne partage pas l'avis sur la lisibilité d'un code complet. Les codes peuvent très vite être longs (surtout si on y intègre un minimum de commentaires) et le débogage peut devenir assez fastidieux, même si avec CoddyRun je dois reconnaître que les outils de l'environnement facilitent bien les choses. Donc pouvoir évacuer toutes les parties traitées et testées me paraît nécessaire.

Je ne suis pas tout à fait d'accord non plus sur la crainte d'une

facilité d’appeler des fonctions toutes faites sans savoir comment elles fonctionnent réellement.

Est-ce qu'on connaît le codage de toutes les fonctions comme le logarithme ou un sinus, non, pourtant cela ne nous empêche pas de les utiliser. Pour l'anecdote, je me suis penché une fois sur la factorielle. On a tous appris à l'école qu'elle n'est définie que sur des entiers positifs pourtant il existe une fonction factorielle définie sur les réels (et complexes) la fonction s'appelle Gamma(z). J'ai voulu savoir comment elle était codée et bien au vu de l'algorithme je ne perds pas grand chose à ne pas le connaître.
Bref chacun est libre de savoir ce qu'il cherche avec un environnement comme CoddyRun. Je pense à croire que c'est la curiosité et l'envie d'apprendre qui est le moteur de cet intérêt.

Après, comme dit Eliora, ce n'est que mon avis. Je ne suis pas informaticien, la programmation n'est qu'un de mes hobby parmi tant d'autres et de plus je suis plus intéressé par l'algorithmique que par le codage. Le juste équilibre entre simplicité d'un codage et la possibilité de créer des projets complexes accessibles/compréhensibles et donc partageables sera certainement difficile à trouver. À chacun de formuler ses attentes et à CoddyRun de voir si on reste dans la philosophie initiale de ce beau projet qui est, il me semble, de faciliter l'apprentissage de la programmation avant de basculer sur un langage plus utilisé dans le monde professionnel.

Bonjour Freecrazy,

Merci pour ce retour détaillé et bien argumenté. C'est exactement ce genre d'échange qui fait avancer CoddyRun.

Content que la Bibliothèque et l'insertion par clic droit vous plaisent. Il reste effectivement quelques recoins à explorer 🙂

Sur la validation des fonctions au fil de l'eau, votre exemple est très parlant. Que est_nombre('11') renvoie vrai alors que 'Ok' provoque une erreur, c'est la souplesse du langage.
Mais c'est justement le genre de subtilité qu'un débutant ne soupçonne pas et qu'un test bien pensé fait apparaître. Prendre l'habitude de se demander "et si on me passe autre chose que ce que j'attends ?" est sans doute l'un des réflexes les plus utiles à acquérir.

Sur la lisibilité, je vous rejoins. Passé une certaine taille, pouvoir mettre de côté les parties déjà traitées et testées pour se concentrer sur ce qui reste à écrire, c'est un vrai gain. C'est d'ailleurs ce que permet la nouvelle fonctionnalité (CoddyRun v4.2) d'appel d'une fonction ou d'une procédure enregistrée dans Mes programmes (Mes fonctions et procédures) : la fonction est appelée depuis votre programme sans que son code y apparaisse. Le programme principal reste donc court et lisible.

Quant à l'argument du sinus et du logarithme, il est imparable : on s'appuie tous les jours sur des fonctions dont on ignore l'implémentation, et c'est même tout l'intérêt de l'abstraction. (Belle anecdote sur Gamma au passage. Ses implémentations reposent en général sur des approximations de type Lanczos ou Stirling, et on peut effectivement vivre très bien sans les connaître !)

En revanche, je ne prévois pas d'ajouter un système de tests intégré.

pour plusieurs raisons :

• CoddyRun doit rester simple. Chaque outil ajouté est une notion de plus à comprendre pour un débutant, et l'interface s'alourdit vite.
• On peut déjà travailler comme vous le décrivez : on écrit et on teste la fonction dans un programme à part, avec tous les cas qu'on veut (y compris '11' et 'Ok'), puis on l'enregistre dans Mes fonctions et procédures et on l'appelle depuis le programme principal.
• Écrire ses propres tests est un exercice formateur en soi. Un outil qui le ferait à la place de l'apprenant lui retirerait une partie de la réflexion.
• Les frameworks de tests font partie de ce qu'on découvre ensuite dans les langages professionnels. CoddyRun a vocation à préparer ce passage, pas à tout reproduire.

C'est ce fameux juste équilibre dont vous parlez : rester accessible tout en permettant des projets plus ambitieux. Vos remarques restent précieuses et je les garde en tête.

Merci encore Freecrazy, et n'hésitez pas à continuer à partager vos idées ici !