Des experts C++ qui se qualifie 4.5 / 5 en C++ et qui sont perdus dés avec 3 minutes quand tu leur parle de VTable.
Ça fait presque vingt ans que je programme quasi-exclusivement en C++, et ça ne me viendrait absolument pas à l'idée de me qualifier d'expert C++. D'une part, parce que je ne me considère pas comme tel, et, d'autre part, parce que je ne vois pas l'intérêt pour moi d'être un expert en C++, pour l'usage que j'en ai.
Le C++ est un outil que j'utilise de la manière qui me convient le mieux, qui n'est pas, j'en conviens, la plus répandue. Je me tiens au courant des fonctionnalités ajoutées au fur et à mesure des nouvelles versions et j'en adopte une de temps en temps (la dernière, ce sont les variadic templates, dont j'use et abuse), parce qu'elle me facilite mon travail de développeur. Ce qui fait que je dois n'en utiliser, au final, qu'une faible partie. Mais à quoi cela me servirait-il d'en connaître plus si je n'en ai pas l'usage ? À impressionner d'éventuels recruteurs ? Si mon compte Github ne leur suffit pas pour savoir si mes compétences en matière de programmation répondent ou non à leurs besoins, c'est leurs propres compétences qui laissent à désirer…
Pour reprendre une analogie fort populaire dans notre milieu : je possède ma voiture depuis plus de dix ans, et je bataille plusieurs minutes deux fois par an pour mettre mon auto-radio (intégré) à l'heure (c'était d'actualité il y a peu), alors que la procédure prend moins de 10 secondes si on la connaît. Du coup, malgré les dix ans et quelques que je l'ai en ma possession, difficile de me qualifier d'expert du modèle que je possède. Et ça ne me pose aucun problème, vu ce que je connais d'elle me suffit pour m'amener d'un point A à un point B dans des conditions que j'estime satisfaisantes.
Sous KDE, du moins avec Kubuntu, il y a Muon Package Manager. C'est assez proche de Synaptic, et je l'utilise systématiquement à la place de Discover. Le seul cas où j'utilise encore Discover, c'est pour les mises à jour, quand il s'ouvre lorsque l'on clique sur la notification.
Au début, je fermais la notification, et je faisais les mises à jour avec Muon. Mais Discover fait exactement les mêmes mises à jour, y compris les paquets qui n'apparaissent pas dans Discover et que j'ai donc installé via Muon, y compris également les paquets installés à partir d'un PPA, avec Muon.
J'ai eu, à l'occasion d'un projet, à programmer en différents langages (Java, Node.js, Perl, PHP, Python et Ruby), dont aucun ne m'était familier, la même bibliothèque faisant appel à des fonctionnalités assez poussées (réseau bas niveau, multi-tâche, gestion d'accès concurrents…), et c'est avec Python que je me suis le plus… amusé. En outre, pour l'implémentation de certains algorithmes, j'ai souvent écrit du code au feeling, trop paresseux que j'étais pour consulter la documentation, et c'est en encore avec Python que le code a le plus souvent fonctionné du premier coup, ou seulement après quelques modifications mineures. Ceci dit, les différences entre les versions 2 et 3, surtout concernant les fonctions réseau bas niveau, sont assez irritantes, mais il est assez facile d'écrire une surcouche qui permette de faire du réseau sans avoir à se préoccuper de la version utilisée de Python (version 2, version 3, surcouche).
Il y a quand même une singularité, que je qualifierais de maladresse, qui a du mal à passer. Par exemple, {1,2} est un set contenant deux nombres (notez les {} comme délimiteurs) et (3,4) un tuple contenant deux nombres (notez les () comme délimiteurs). Jusqu'à là, tout va bien. Par contre, bien que {5} est bien un set contenant un nombre, (6) n'est pas un tuple contenant un nombre, mais le nombre lui-même. Pour avoir un tuple contenant un seul nombre, il faut écrire (7,). Vu l'usage qui est généralement fait des parenthèses, ça peut se comprendre, mais ça reste assez déroutant. À noter que 8,9 (sans les parenthèses) est aussi un tuple contenant deux nombres.
Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.
Concernant l'apprentissage de la programmation, c'est Python qui semble être le plus utilisé. C'est encore lui qui est le langage de prédilection lorsque qu'il s'agit de manipuler les ports GPIO d'un Raspberry Pi. C'est donc vers ce langage que je me suis tourné pour un projet d'outil pédagogique (journal dédié) destiné à être utilisé dans le cadre de cours de programmation. Le fait de facilement avoir accès aux mécanismes internes de Python facilite l'écriture d'exercices pour ce genre de cours (ou du moins l'idée que je me fais d'exercices de ce genre). Alors, ce projet n'existe qu'en Python (pour le moment), donc je ne peux le comparer avec d'autres langages de ce point de vue, mais je ne vois pas trop comment faire mieux que Python. J'ai vraiment facilement et relativement élégamment pu résoudre les problématiques liés à ce genre de projets (vais peut-être faire un journal, voire une dépêche, sur le sujet un de ces jours…). Par contre, je me garderais bien de me prononcer sur la pertinence de l'utilisation de Python pour l'apprentissage de la programmation, n'ayant pas assez de recul.
Ne prenez pas ce commentaire pour plus qu'il n'est : un ressenti, donc totalement subjectif. Sachant, en outre, que, malgré toutes les qualités de Python, et des autres langages que j'ai pu essayer, le C++ reste mon langage de prédilection…
Le premier lien est l'équivalent d'un man gpio, et le second permet de voir à quoi ressemble la sortie de la commande readall. Ainsi, on peut installer l'utilitaire en connaissance de cause, et non pas juste pour se faire une idée, sans être sûr de vouloir le conserver.
Cet utilitaire n'est pas toujours installé d'office, même avec les distributions dédiées. Il n'était pas installé sur mon ODROID, par exemple.
Il y a aussi l'utilitaire gpio, installé d'office (il me semble) sur une Raspbian, avec notamment la commande readall, qui permet d'avoir une vue d'ensemble de la configuration et de l'état de chaque port GPIO. On peut voir cette commande en action sur cette vidéo (c'est du Peertube).
Dans ce cas précis , strchr(…) serait préférable, mais les deux seraient de toute manière plutôt l'équivalent de string.find(…). C'est var in other_var, en tant que construction du langage, qui n'a pas d'équivalent en C…
Comme indiqué dans le journal, le but ce n'est pas d'apprendre Python, mais la programmation en général. Donc, après avoir trouvé la solution pythonesque, un nouvel énoncé leur sera soumis dont la solution ressemble à celle proposée dans le fichier ci-dessus, histoire de les entraîner à écrire des boucles for.
À noter que les futurs professeurs d'informatique dans les lycées seront titulaires d'un CAPES d'informatique (qui va être crée en 2020), et non plus titulaires d'un CAPES de mathématique, ou de je ne sais quoi, option informatique…
Comme quoi, il y du progrès ; il semblerait qu'il y aurait même une agrégation d'informatique en projet.
Pour ce que j'en sais, les cours de programmation s'inscrivent effectivement dans une discipline plus large, mais seront obligatoires, ainsi que l'utilisation de Python, donc exit Scratch et consorts. En outre, la place accordée à la programmation sera assez importante, mais c'est peut-être un choix des enseignants, sachant qu'ils n'ont pas de directives précises à ce sujet. Maintenant, cela diffère peut-être en fonction des lycées…
Pour revenir sur le fond de l'article, et donc la question de l'interface utilisateur dans l'enseignement de la programmation avec Python, l'éducation nationale a déjà fait un choix fort à ce niveau, avec une vision proche de la programmation fonctionnelle.
L'idée est de passer par un éditeur de texte intégrant une console python (repl.it est un bon exemple) ou par des jupyter notebooks, et de passer systématiquement par l'usage de fonction. Pour schématiser l'élève écrit ses fonctions côtés éditeurs, et il les appelle côté console.
Là aussi, de ce qu'on m'en a dit, chaque élève se verra doté d'un ordinateur portable qui lui sera propre, avec un environnement de développement Python, donc les services comme Repl.it ne seront pas utilisés, même s'il n'y a rien qui s'y oppose. Pour le reste, comme les consignes qu'ils ont reçus sont assez vagues, c'est eux qui décident…
Le but est de séparer au maximum et dès le départ la partie logique, de la partie interface.
La partie interface n'est d'ailleurs pas du tout abordée en maths, elle le sera uniquement en NSI. Mais comme NSI propose du web, les élèves devraient pouvoir créer (en étant pas mal guidé), leur propre interface lors des projets.
De plus, un des but de cet enseignement est de bien séparer HTML et Javascript, front-end et back-end. Introduire Python avec une interface web risque d'amener des confusion à ce niveau.
Pour ce qui est de l'interface web, ce sera totalement transparent. Au lieu d'utiliser print(…), ils utiliseront une autre commande qui, au lieu d'afficher un contenu dans une console texte, l'affichera dans l'interface web de l'exercice à l'endroit prévu pour cela. De la même manière, au lieu d'utiliser des input(…) pour récupérer des données utilisateurs, ils les récupèreront via les paramètres d'un callback. Ils n'auront pas affaire à HTML, JavaScript, DOM, CSS…. Dans un second temps, il sera tout à fait possible de proposer des exercices pour aborder ces technologies.
Du coup, je me demande si vraiment, c'est un problème d'esthétique que d'intéresser les jeunes au code.
Ben quand même, une console texte, ce n'est pas très folichon. Avec une interface web, à l'aide de quelques règles CSS, on peut arriver à faire quelque chose de visuellement fun. Bon, les exercices présentés dans ce journal ne sont pas un bon exemple de ce point de vue, vu mon niveau en CSS… D'ailleurs, s'il y a des volontaires maitrisant CSS pour enjoliver les exercices…
De plus, le fait d'utiliser des technos web, c'est pour leur montrer que, non, leur smartphone, ce n'est pas seulement pour avoir accès Facebook, Instagram, Twitter ou que sais-je encore. On peut aussi l'utiliser pour avoir accès à des applications que l'on a soi-même crées.
Marrant, quand j'étais au lycée il y a fort fort longtemps, on avait appris le BASIC sur TO7/70. Ça m'avait royalement gonflé de dessiner des carrés de couleur à l'écran, alors du Python, il va vraiment falloir être pédagogue.
Je ne sais pas si ça va faire une grande différence, mais le but n'est pas d'apprendre Python, mais d'apprendre la programmation. Donc, on va, à priori, laisser toutes le subtilités de Python de coté. En outre, grâce à l'interface web, on va pouvoir faire des exercices bien plus amusants que le traçage de carrés.
Pour ce qui est de la programmation objet, comme on peut en avoir un aperçu là et là, ça peut être tout à fait abordé dans le cadre d'exercices dédiés.
Vu la définition et les cas d'usage que tu cites, un proxy ne serait-il pas implémentable avec une classe abstraite en C++ ?
Je pose cette question pas tant pour faire avancer le débat que pour voir s'il n'y a pas quelque chose qui m'échappe…
Ça ne répond pas à ton cahier des charges, mais j'ai également opté pour Marp, et j'utilise PDF Presenter pour afficher en plein écran le PDF généré par Marp.
Cela fait plus de vingt ans que je développe, autant professionnellement que pour mes projets personnels, quasi exclusivement en C++. Je n'utilise qu'une partie des possibilités offertes par ce langage, et rares sont les nouveautés que j'adopte. La dernière en date sont les variadic templates, apparus avec C++11. Je ne peux donc prétendre être un expert C++, et ça n'a d'ailleurs jamais été mon ambition.
Je peux d'autant moins prétendre être un expert C++ que les seules bibliothèques C++ que j'utilise sont… les miennes.
À mes débuts, il n'y avait pas autant de langages qu'aujourd'hui, et la plupart n'étaient pas très répandus. En outre, comme je connaissais déjà le langage C, c'est tout naturellement que je me suis tourné vers le C++. Ayant, dés le début, fait le choix d'écrire des programmes portables, entre les différences de comportement d'une même bibliothèque d'une plateforme à l'autre, et les bugs de certaines bibliothèques, je me suis retrouvé à écrire mes propres bibliothèques C++, codées en interne en C.
Cela est grandement facilité par le fait qu'avec C++, j'ai directement accès aux bibliothèques C standards, ainsi que systèmes, voire à l'assembleur. J'utilise donc exactement le même environnement de développement pour, d'une part, développer mes bibliothèques C++ (en C ou en assembleur), et, d'autre part, pour développer les logiciels qui s'appuient sur ces bibliothèques. Avec la plupart des autres langages, pour avoir des performances optimales, j'aurais dû quand même développer les bibliothèques en C ou en C++, et donc avoir deux environnements de développement radicalement différents. Pour le jeune aspirant développeur que j'étais à l'époque, cela aurait été probablement rédhibitoire.
Rétrospectivement, bien que ce choix ai été dicté par les circonstances, coder dans un langage sans en utiliser les bibliothèques standards paraît tout à fait insensé, encore plus de nos jours. Pourtant, c'est un choix que je ne regrette absolument pas. L'avantage est que j'ai des bibliothèques avec une API sur mesure, vu que je peux la modifier comme bon me semble, et dont les performances ne sont limitées que par les caractéristiques de la machine sur laquelle sont exécutés mes logiciels. L'inconvénient, c'est que, aujourd'hui, je suis le seul à vouloir/pouvoir modifier mes logiciels, essentiellement parce que mes bibliothèques ne sont pas documentées.
Ces derniers mois, j'ai eu l'occasion de réaliser des développements pour Java, Node.js, PHP, Python, Ruby et je suis actuellement en train d'en réaliser pour Perl. Bien que j'ai trouvé certains de ces langages intéressants par certains aspects, je préfère, et de loin, coder en C++. Mais cela est probablement dû à ma manière inhabituelle de coder en C++, c'est-à-dire en utilisant exclusivement des bibliothèques maisons.
Cette manière de coder est hautement critiquable et ne saurait être encouragée. N'empêche que c'est la mienne et qu'elle me convient parfaitement. Et il se trouve que C++ est l'un des rares langages (le seul à ma connaissance, avec le C) qui facilite autant cette manière de coder, autant par l'ouverture de son environnement de développement (accès direct au C et à l'assembleur), que par les performances qu'il permet d'obtenir (qui n'ont rien à envier à celles des bibliothèques fournies en standard).
Voilà donc un autre point de vue d'un développeur C++ ayant eu un début de parcours fort similaire au tien.
Concernant certains des points évoqués dans ton journal.
Je ne trouve pas que développer en C++ est lent, mais c'est probablement parce que j'ai une flopée de bibliothèques pour mettre facilement et rapidement en œuvre toutes les fonctionnalités dont j'ai pu avoir besoin au cours de mes différents développements. Certes, développer ces bibliothèques m'a pris du temps, mais cela s'est fait au fil de l'eau, en généralisant au maximum et en déportant chaque nouvelle fonctionnalité dans une bibliothèque dés que j'ai eu besoin de cette fonctionnalité pour un logiciel.
Pour ce qui est de la compilation, vu que je n'ai jamais de dépendances du fait que je n'utilise pas de bibliothèques tiers, je n'ai besoin que d'un Makefile pour la compilation. Ce Makefile est généré à partir d'un fichier projet avec un format maison qui se contente, en gros, d'indiquer la nature du projet (exécutable, bibliothèque dynamique…), et de lister les bibliothèques utilisées. Ce fichier projet sert d'ailleurs aussi au paquetage automatique des sources de l'application dans le but de la distribuer.
Le seul gros manque, c'est une méthode standard de paquetage, ainsi qu'éventuellement un dépôt officiel. Ce n'est pas tellement gênant pour des développement à façon, car je fournis au client généralement un .zip avec les binaires. Mais pour tout mes développements open source, à part pour Windows, je ne sais pas comment faire pour mettre à disposition mes logiciels sans les faire compiler par l'utilisateur, ce qui implique qu'il ai un compilateur C++, en plus de make.
Certes, et, personnellement, je ne m'en prive pas, mais Python est fortement mis en avant.
Le Pi de Raspberry Pi, c'est pour Python (https://www.techspot.com/article/531-eben-upton-interview/), bien que ça soit de moins en moins mis en avant. En outre, les bibliothèques logicielles pour piloter les ports GPIO sont, à la base, en C ou C++, mais ce sont les bindings en Python qui sont le plus utilisés. Et ça vaut aussi pour les bibliothèques dédiées au pilotage de certains robots (Poppy Ergo Jr et consorts).
Les exemples de programmes des tutoriels sur le pilotage de kits ou de robots avec un RPI sont systématiquement en Python, accompagnés parfois de leur version en C ou C++. Il existe des exemples de programmes en Java, mais c'est vraiment exceptionnel.
Merci pour votre réponse, je comprends mieux la démarche du framework Atlas.
Merci de m'avoir donner l'occasion d'éclaircir mes propos !
Quand je parlais de "code serveur" je voulais dire "back-end".
En fait, back-end et front-end sont gérés par le même code source. Plus besoin de front-end en tant que tel.
En tout cas, je trouve l'approche SPA bien plus attractive que les CGI en effet et c'est comme ça que j'anime mes cours de javascript.
Quand je présente le toolkitAtlas, la plupart des gens pensent de prime abord que c'est pour faire des CGI. Il faut vraiment que j'insiste, parfois lourdement, pour leur faire comprendre que c'est pour faire des SPA… En outre, la gestion des SPA est plus proche de la gestion des applications bureau, et repose moins sur HTML.
Je suis d'accord avec vous, c'est un langage difficile d'accès pour les débutants et beaucoup sont perdu avec les différentes syntaxes, les callbacks etc.
Passé cette difficulté, j'ai l'impression d'arriver à faire des choses sympa (un paint, des petits jeux vidéo, un forum websockets etc.) en peu de lignes et cela quasi sans librairie tiers (en js vanilla donc).
S'il y a besoin d'un serveur, je fournis quelque chose de minimaliste afin de leur permettre de se concentrer sur l'interaction utilisateur.
Mon but, avec le toolkitAtlas, c'est de pouvoir ajouter une GUI à un programme aussi simplement que possible, justement pour que le développeur puisse se concentrer sur le cœur du programme.
Je ne saurais dire si JavaScript est adapté pour l'apprentissage. En outre, avec la version Node.js du toolkitAtlas, l'approche est différente de celle du JavaScriptfront-end, mais il reste cependant le système des callbacks.
Je me concentre actuellement sur Python parce que c'est le langage qui est le plus souvent cité lorsque l'on parle d'initiation à la programmation, et, d'autre part, c'est également le langage le plus utilisé lorsqu'il s'agit de piloter des montages électroniques ou des robots connectés à un Raspberry Pi. Et piloter des robots, comme indiqué dans la dépêche, avec un smartphone, ça fait son petit effet auprès des adolescents :-)…
C'est dans cette optique que je questionnais l'intérêt d'Atlas, mais vous avez très bien défendu ce projet et il m'apparaît pertinent dans le cadre d'un apprentissage de la programmation.
Je suis en train de monter un atelier d'initiation à la programmation basé sur le toolkitAtlas, et j'espère le mettre à l'épreuve prochainement. J'espère que les faits vous donneront raison :-)…
Je le vois, ce qui perturbe les apprenants c'est la masse de petites choses différentes à retenir, comprendre etc. et plus l'environnement est hétérogène (c'est le cas pour le web) et plus c'est difficile d'accès.
C'est pour cela que le toolkitAtlas se veut une alternative à tous ces frameworks habituellement utilisés, car l'apprentissage de ces derniers est bien trop ardu pour des débutants. Le toolkitAtlas est, certes, bien moins puissant, mais c'est largement suffisant pour débuter. Libre à eux d'utiliser un framework lorsqu'ils auront acquis les connaissances nécessaires pour le maîtriser.
C'est pour cela aussi que quand je démarre sur Php, je leur fais faire des programme en ligne de commande avant de voir la génération du Html et l’interaction avec une base données SQL. Ce que beaucoup de tuto sur internet font en même temps. Résultat : les apprenants ne font pas la différence entre client et serveur et ont un mal fou à comprendre que le programme Php ne fait que générer du html (ou du json dans le cadre d'API web).
La version PHP du toolkitAtlas est justement prévue pour fonctionner en mode CLI. Pour un langage qui a popularisé les CGI, faire des SPA, en mode CLI qui plus est, ça en perturbe plus d'un :-)…
Bref, l'apprentissage de la programmation reste aujourd'hui quelque chose d'assez rude je trouve et j'en vois beaucoup qui décrochent. Sans doute que l’écart entre leur rapport quotidien avec l'informatique (les smartphones, des applis codées par des milliers de dev pendant plusieurs mois) et ce qu'ils arrivent péniblement à faire en cours. Si le toolkit Atlas peut faire la différence alors c'est top !
Au début, je pensais que le fait de pouvoir facilement accéder aux applications, réalisées avec le toolkitAtlas, avec un smartphone était assez anecdotique. L'idée originale, derrière cela, c'est que les adolescents puissent facilement montrer leurs réalisations à leur entourage ; à leur âge, ils ont besoin de reconnaissance, d'encouragements. Maintenant, je pense de plus en plus que c'est un point essentiel, car cela démystifie le smartphone. Je pense que la plupart perçoive leur smartphone comme un portail vers cette chose mystérieuse qu'est le cloud, dont seules les grosses boîtes, comme les GAFAMs, ont la maitrise. Avec le toolkitAtlas, ils ont un aperçu de ce que c'est, techniquement, le cloud, et j'espère que cela donnera à certains l'envie d'approfondir le sujet, et de se l'approprier.
PS : Je me rappelle avoir codé en quelques heures maxi un jeu vidéo inspiré d'Angribirds en js avec mon fils qui faisait les dessins. Grace aux pages Github et autres services de mise en ligne, on avait quelque chose qu'on pouvait montrer facilement (pas testé sur smartphone mais ça devrait peut tourner) : http://dedesite.github.io/angry_birds_filo/
C'est sympathique. J'aime bien la cinématique, ça fait vraiment penser au jeu original :-) !
Ca m'est marrant, quand on exécute le main, on vois une petite fenêtre dans le navigateur comme si on exécutait le programme python localement.
Bon travail!
Merci, mais je n'ai aucun mérite. C'est parce que le programme tourne dans Repl.it, une application web qui permet de disposer, sans rien avoir à installer, d'un environnement de développement pour pas mal de langages, juste en utilisant un navigateur web. Les logs proviennent de cette appli.
Mais ça fait quoi exactement?
Comme indiqué dans le commentaire plus haut, noyé dans les logs, il y a une URL (elle change à chaque fois) qui, lorsqu'on l'ouvre, propose une interface permettant de faire varier la valeur des différents paramètres de la fonction gaussienne et de voir leur influence sur le graphique.
Avec le programme d'origine, on est obligé de modifier ces valeurs directement dans le programme, ce qui n'est pas très pratique. On peut également modifier le programme pour passer les valeurs de ces paramètres via des arguments de la ligne de commande, ou encore en permettant leur saisie à coup de input(). Seule cette dernière option est présentée dans le guide faisant l'objet de ce journal mais, hormis sa présentation et un exemple de mise en œuvre, elle n'est pas exploitée par ailleurs.
Une autre solution serait de doter le programme d'une GUI. Malgré les indéniables avantages d'une telle interface, une telle option n'est même pas évoquée dans ce guide. Probablement, mais ce n'est qu'une supposition, parce que l'effort nécessité par la mise en œuvre et l'apprentissage d'un des nombreux frameworks existants est disproportionné par rapport aux bénéfices qu'on en retirerait dans le cadre de leur utilisation dans des programmes tels que ceux présentés dans ce guide.
Ces frameworks sont complexes parce qu'ils proposent des fonctionnalités évoluées. Le toolkitAtlas est destiné à être utilisé dans les cas on l'on n'a besoin que de fonctionnalités basiques. Et c'est aussi pour cela que l'utilisation du toolkitAtlas ne nécessite que des connaissances basiques, faciles à acquérir, en technologies web.
J'ai dernièrement fait l'acquisition d'un kit électronique d'apprentissage destiné à être utilisé avec un Raspberry Pi. Il y avait un tutoriel fournit avec ce kit proposant, à titre d'exemple, un programme Python destiné à piloter une LED RGB. Ce programme faisait afficher des couleurs aléatoires par la LED. Là aussi, aucune interactivité. Alors, à l'instar de ce que j'ai fait ici, j'ai modifié le programme pour lui ajouter une GUI, à l'aide du toolkitAtlas, programme que l'on peut voir à l'œuvre ici.
Beaucoup de tutoriels gagneraient en attractivité en proposant des exercices et des exemples de programmes avec un minimum d'interactivité, à l'heure où tout le monde est habitué à manipuler des interfaces graphiques avec leurs smartphones. Et l'un des buts du toolkitAtlas est justement de pouvoir facilement modifier un programme pour le rendre interactif par l'ajout d'une GUI.
Comme indiqué dans ce journal, je cherche des exemples de programmes Python auxquels je pourrais rajouter une GUI, et je me suis permis de modifier le programme gauss-2d.py pour en faire ça. Il faut ouvrir l'URL indiquée dans la console (il peut être nécessaire de scroller vers le haut pour la trouver) dans une nouvelle fenêtre, et mettre les deux fenêtres côte à côte.
Python ne m'est pas très familier, et encore moins matplotlib, donc c'est très largement améliorable, tout comme l'interface.
[^] # Re: Sans Ironie.
Posté par Claude SIMON (site web personnel) . En réponse au journal S'acheter son logement avec le salaire d'un expert C++ (ou autre techno). Évalué à 3.
Ça fait presque vingt ans que je programme quasi-exclusivement en C++, et ça ne me viendrait absolument pas à l'idée de me qualifier d'expert C++. D'une part, parce que je ne me considère pas comme tel, et, d'autre part, parce que je ne vois pas l'intérêt pour moi d'être un expert en C++, pour l'usage que j'en ai.
Le C++ est un outil que j'utilise de la manière qui me convient le mieux, qui n'est pas, j'en conviens, la plus répandue. Je me tiens au courant des fonctionnalités ajoutées au fur et à mesure des nouvelles versions et j'en adopte une de temps en temps (la dernière, ce sont les variadic templates, dont j'use et abuse), parce qu'elle me facilite mon travail de développeur. Ce qui fait que je dois n'en utiliser, au final, qu'une faible partie. Mais à quoi cela me servirait-il d'en connaître plus si je n'en ai pas l'usage ? À impressionner d'éventuels recruteurs ? Si mon compte Github ne leur suffit pas pour savoir si mes compétences en matière de programmation répondent ou non à leurs besoins, c'est leurs propres compétences qui laissent à désirer…
Pour reprendre une analogie fort populaire dans notre milieu : je possède ma voiture depuis plus de dix ans, et je bataille plusieurs minutes deux fois par an pour mettre mon auto-radio (intégré) à l'heure (c'était d'actualité il y a peu), alors que la procédure prend moins de 10 secondes si on la connaît. Du coup, malgré les dix ans et quelques que je l'ai en ma possession, difficile de me qualifier d'expert du modèle que je possède. Et ça ne me pose aucun problème, vu ce que je connais d'elle me suffit pour m'amener d'un point A à un point B dans des conditions que j'estime satisfaisantes.
Commentaire que j'ai écris il y quelques années sur comment ne pas être considéré comme un spécialiste C++ malgré une pratique quasi-quotidienne de plus de 12 ans : https://linuxfr.org/users/fredx/journaux/ce-qu-on-demande-a-un-developpeur-aujourd-hui#comment-1471811.
Zelbinium, la programmation ludique
[^] # Re: The Wayland Itches project
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche GNOME 3.34. Évalué à 2. Dernière modification le 25 octobre 2019 à 18:17.
Sous KDE, du moins avec Kubuntu, il y a Muon Package Manager. C'est assez proche de Synaptic, et je l'utilise systématiquement à la place de Discover. Le seul cas où j'utilise encore Discover, c'est pour les mises à jour, quand il s'ouvre lorsque l'on clique sur la notification.
Au début, je fermais la notification, et je faisais les mises à jour avec Muon. Mais Discover fait exactement les mêmes mises à jour, y compris les paquets qui n'apparaissent pas dans Discover et que j'ai donc installé via Muon, y compris également les paquets installés à partir d'un PPA, avec Muon.
Zelbinium, la programmation ludique
[^] # Re: Personne pour le moment
Posté par Claude SIMON (site web personnel) . En réponse au message Diner des philosophes et jeu des bâtonnets. Évalué à 1.
Petite erreur à la fin du premier paragraphe :
Zelbinium, la programmation ludique
[^] # Re: Sur l'utilisabilité et le jeu
Posté par Claude SIMON (site web personnel) . En réponse au journal Balance virtuelle, application éducative javascript. Évalué à 1.
Le bouton Ranger les masses est cliquable une fois la balance à l'équilibre.
Zelbinium, la programmation ludique
# Utilisation de Python par un profane
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 10.
J'ai eu, à l'occasion d'un projet, à programmer en différents langages (Java, Node.js, Perl, PHP, Python et Ruby), dont aucun ne m'était familier, la même bibliothèque faisant appel à des fonctionnalités assez poussées (réseau bas niveau, multi-tâche, gestion d'accès concurrents…), et c'est avec Python que je me suis le plus… amusé. En outre, pour l'implémentation de certains algorithmes, j'ai souvent écrit du code au feeling, trop paresseux que j'étais pour consulter la documentation, et c'est en encore avec Python que le code a le plus souvent fonctionné du premier coup, ou seulement après quelques modifications mineures. Ceci dit, les différences entre les versions 2 et 3, surtout concernant les fonctions réseau bas niveau, sont assez irritantes, mais il est assez facile d'écrire une surcouche qui permette de faire du réseau sans avoir à se préoccuper de la version utilisée de Python (version 2, version 3, surcouche).
Il y a quand même une singularité, que je qualifierais de maladresse, qui a du mal à passer. Par exemple,
{1,2}est un set contenant deux nombres (notez les{}comme délimiteurs) et(3,4)un tuple contenant deux nombres (notez les()comme délimiteurs). Jusqu'à là, tout va bien. Par contre, bien que{5}est bien un set contenant un nombre,(6)n'est pas un tuple contenant un nombre, mais le nombre lui-même. Pour avoir un tuple contenant un seul nombre, il faut écrire(7,). Vu l'usage qui est généralement fait des parenthèses, ça peut se comprendre, mais ça reste assez déroutant. À noter que8,9(sans les parenthèses) est aussi un tuple contenant deux nombres.Bon, je passe sur l'absence de switch/case, et d'enum ; on s'y fait assez rapidement.
Concernant l'apprentissage de la programmation, c'est Python qui semble être le plus utilisé. C'est encore lui qui est le langage de prédilection lorsque qu'il s'agit de manipuler les ports GPIO d'un Raspberry Pi. C'est donc vers ce langage que je me suis tourné pour un projet d'outil pédagogique (journal dédié) destiné à être utilisé dans le cadre de cours de programmation. Le fait de facilement avoir accès aux mécanismes internes de Python facilite l'écriture d'exercices pour ce genre de cours (ou du moins l'idée que je me fais d'exercices de ce genre). Alors, ce projet n'existe qu'en Python (pour le moment), donc je ne peux le comparer avec d'autres langages de ce point de vue, mais je ne vois pas trop comment faire mieux que Python. J'ai vraiment facilement et relativement élégamment pu résoudre les problématiques liés à ce genre de projets (vais peut-être faire un journal, voire une dépêche, sur le sujet un de ces jours…). Par contre, je me garderais bien de me prononcer sur la pertinence de l'utilisation de Python pour l'apprentissage de la programmation, n'ayant pas assez de recul.
Ne prenez pas ce commentaire pour plus qu'il n'est : un ressenti, donc totalement subjectif. Sachant, en outre, que, malgré toutes les qualités de Python, et des autres langages que j'ai pu essayer, le C++ reste mon langage de prédilection…
Zelbinium, la programmation ludique
[^] # Re: Seulement WebKit sur IOS
Posté par Claude SIMON (site web personnel) . En réponse au journal Une exploitation massive de failles dans iOS depuis plus de 2 ans. Évalué à 8. Dernière modification le 31 août 2019 à 23:24.
Si, mais, pour les raisons précédemment citées, il s'appuie sur WebKit au lieu de Gecko…
Zelbinium, la programmation ludique
[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Ordinateur à carte unique : Raspberry Pi 4 et consort. Évalué à 3.
Le premier lien est l'équivalent d'un
man gpio, et le second permet de voir à quoi ressemble la sortie de la commandereadall. Ainsi, on peut installer l'utilitaire en connaissance de cause, et non pas juste pour se faire une idée, sans être sûr de vouloir le conserver.Cet utilitaire n'est pas toujours installé d'office, même avec les distributions dédiées. Il n'était pas installé sur mon ODROID, par exemple.
Zelbinium, la programmation ludique
[^] # Re: C sur Raspberry
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Ordinateur à carte unique : Raspberry Pi 4 et consort. Évalué à 3. Dernière modification le 23 août 2019 à 08:45.
Il y a aussi l'utilitaire
gpio, installé d'office (il me semble) sur une Raspbian, avec notamment la commandereadall, qui permet d'avoir une vue d'ensemble de la configuration et de l'état de chaque port GPIO. On peut voir cette commande en action sur cette vidéo (c'est du Peertube).Zelbinium, la programmation ludique
[^] # Re: Code
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
Dans ce cas précis ,
strchr(…)serait préférable, mais les deux seraient de toute manière plutôt l'équivalent destring.find(…). C'estvar in other_var, en tant que construction du langage, qui n'a pas d'équivalent en C…Zelbinium, la programmation ludique
[^] # Re: Code
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
C'est bien pour ça qu'il y a ceci…
Comme indiqué dans le journal, le but ce n'est pas d'apprendre Python, mais la programmation en général. Donc, après avoir trouvé la solution pythonesque, un nouvel énoncé leur sera soumis dont la solution ressemble à celle proposée dans le fichier ci-dessus, histoire de les entraîner à écrire des boucles
for.Zelbinium, la programmation ludique
[^] # Re: un pendant python à Ruby Shoes!
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 3.
Peut-être PySimpleGUI ?
Zelbinium, la programmation ludique
[^] # Re: Précisions sur l'informatique dans le secondaire.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 1.
À noter que les futurs professeurs d'informatique dans les lycées seront titulaires d'un CAPES d'informatique (qui va être crée en 2020), et non plus titulaires d'un CAPES de mathématique, ou de je ne sais quoi, option informatique…
Comme quoi, il y du progrès ; il semblerait qu'il y aurait même une agrégation d'informatique en projet.
Zelbinium, la programmation ludique
[^] # Re: Précisions sur l'informatique dans le secondaire.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 1.
Merci pour toutes ces informations.
Pour ce que j'en sais, les cours de programmation s'inscrivent effectivement dans une discipline plus large, mais seront obligatoires, ainsi que l'utilisation de Python, donc exit Scratch et consorts. En outre, la place accordée à la programmation sera assez importante, mais c'est peut-être un choix des enseignants, sachant qu'ils n'ont pas de directives précises à ce sujet. Maintenant, cela diffère peut-être en fonction des lycées…
Là aussi, de ce qu'on m'en a dit, chaque élève se verra doté d'un ordinateur portable qui lui sera propre, avec un environnement de développement Python, donc les services comme Repl.it ne seront pas utilisés, même s'il n'y a rien qui s'y oppose. Pour le reste, comme les consignes qu'ils ont reçus sont assez vagues, c'est eux qui décident…
Pour ce qui est de l'interface web, ce sera totalement transparent. Au lieu d'utiliser
print(…), ils utiliseront une autre commande qui, au lieu d'afficher un contenu dans une console texte, l'affichera dans l'interface web de l'exercice à l'endroit prévu pour cela. De la même manière, au lieu d'utiliser desinput(…)pour récupérer des données utilisateurs, ils les récupèreront via les paramètres d'un callback. Ils n'auront pas affaire à HTML, JavaScript, DOM, CSS…. Dans un second temps, il sera tout à fait possible de proposer des exercices pour aborder ces technologies.Zelbinium, la programmation ludique
[^] # Re: Programmation objet ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
Ben quand même, une console texte, ce n'est pas très folichon. Avec une interface web, à l'aide de quelques règles CSS, on peut arriver à faire quelque chose de visuellement fun. Bon, les exercices présentés dans ce journal ne sont pas un bon exemple de ce point de vue, vu mon niveau en CSS… D'ailleurs, s'il y a des volontaires maitrisant CSS pour enjoliver les exercices…
De plus, le fait d'utiliser des technos web, c'est pour leur montrer que, non, leur smartphone, ce n'est pas seulement pour avoir accès Facebook, Instagram, Twitter ou que sais-je encore. On peut aussi l'utiliser pour avoir accès à des applications que l'on a soi-même crées.
Zelbinium, la programmation ludique
[^] # Re: Programmation objet ?
Posté par Claude SIMON (site web personnel) . En réponse au journal Apprentissage de la programmation : comment moderniser les exercices. Évalué à 2.
Je ne sais pas si ça va faire une grande différence, mais le but n'est pas d'apprendre Python, mais d'apprendre la programmation. Donc, on va, à priori, laisser toutes le subtilités de Python de coté. En outre, grâce à l'interface web, on va pouvoir faire des exercices bien plus amusants que le traçage de carrés.
Pour ce qui est de la programmation objet, comme on peut en avoir un aperçu là et là, ça peut être tout à fait abordé dans le cadre d'exercices dédiés.
Zelbinium, la programmation ludique
[^] # Re: 'Marp' + 'PDF Presenter'
Posté par Claude SIMON (site web personnel) . En réponse au message recherche une solution pour faire des slides en markdown sous Fedora 30 . Évalué à 1.
Je n'en sais rien ; je n'ai pas trouvé l'entrée de menu qui permet d'afficher cette information. Mais je crois que c'est la 0.0.13…
Apparemment, Marp est abandonné au profit d'un nouvelle suite logicielle appelée Marp Next, mais je n'ai pas encore regardé en détail…
Zelbinium, la programmation ludique
[^] # Re: Performance
Posté par Claude SIMON (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 1.
Vu la définition et les cas d'usage que tu cites, un proxy ne serait-il pas implémentable avec une classe abstraite en C++ ?
Je pose cette question pas tant pour faire avancer le débat que pour voir s'il n'y a pas quelque chose qui m'échappe…
Zelbinium, la programmation ludique
# 'Marp' + 'PDF Presenter'
Posté par Claude SIMON (site web personnel) . En réponse au message recherche une solution pour faire des slides en markdown sous Fedora 30 . Évalué à 2. Dernière modification le 06 juin 2019 à 19:54.
Ça ne répond pas à ton cahier des charges, mais j'ai également opté pour Marp, et j'utilise PDF Presenter pour afficher en plein écran le PDF généré par Marp.
J'ai écris un journal sur le sujet : https://linuxfr.org/users/epeios/journaux/markdown-presentation-processor-ou-de-l-interet-des-fichiers-texte. Certains y évoquent des alternatives dans les commentaires. Peut-être que tu y trouveras ton bonheur…
Zelbinium, la programmation ludique
# Moi, pas du tout expert C++, je ne compte pas abandonner C++
Posté par Claude SIMON (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 4.
Cela fait plus de vingt ans que je développe, autant professionnellement que pour mes projets personnels, quasi exclusivement en C++. Je n'utilise qu'une partie des possibilités offertes par ce langage, et rares sont les nouveautés que j'adopte. La dernière en date sont les variadic templates, apparus avec C++11. Je ne peux donc prétendre être un expert C++, et ça n'a d'ailleurs jamais été mon ambition.
Je peux d'autant moins prétendre être un expert C++ que les seules bibliothèques C++ que j'utilise sont… les miennes.
À mes débuts, il n'y avait pas autant de langages qu'aujourd'hui, et la plupart n'étaient pas très répandus. En outre, comme je connaissais déjà le langage C, c'est tout naturellement que je me suis tourné vers le C++. Ayant, dés le début, fait le choix d'écrire des programmes portables, entre les différences de comportement d'une même bibliothèque d'une plateforme à l'autre, et les bugs de certaines bibliothèques, je me suis retrouvé à écrire mes propres bibliothèques C++, codées en interne en C.
Cela est grandement facilité par le fait qu'avec C++, j'ai directement accès aux bibliothèques C standards, ainsi que systèmes, voire à l'assembleur. J'utilise donc exactement le même environnement de développement pour, d'une part, développer mes bibliothèques C++ (en C ou en assembleur), et, d'autre part, pour développer les logiciels qui s'appuient sur ces bibliothèques. Avec la plupart des autres langages, pour avoir des performances optimales, j'aurais dû quand même développer les bibliothèques en C ou en C++, et donc avoir deux environnements de développement radicalement différents. Pour le jeune aspirant développeur que j'étais à l'époque, cela aurait été probablement rédhibitoire.
Rétrospectivement, bien que ce choix ai été dicté par les circonstances, coder dans un langage sans en utiliser les bibliothèques standards paraît tout à fait insensé, encore plus de nos jours. Pourtant, c'est un choix que je ne regrette absolument pas. L'avantage est que j'ai des bibliothèques avec une API sur mesure, vu que je peux la modifier comme bon me semble, et dont les performances ne sont limitées que par les caractéristiques de la machine sur laquelle sont exécutés mes logiciels. L'inconvénient, c'est que, aujourd'hui, je suis le seul à vouloir/pouvoir modifier mes logiciels, essentiellement parce que mes bibliothèques ne sont pas documentées.
Ces derniers mois, j'ai eu l'occasion de réaliser des développements pour Java, Node.js, PHP, Python, Ruby et je suis actuellement en train d'en réaliser pour Perl. Bien que j'ai trouvé certains de ces langages intéressants par certains aspects, je préfère, et de loin, coder en C++. Mais cela est probablement dû à ma manière inhabituelle de coder en C++, c'est-à-dire en utilisant exclusivement des bibliothèques maisons.
Cette manière de coder est hautement critiquable et ne saurait être encouragée. N'empêche que c'est la mienne et qu'elle me convient parfaitement. Et il se trouve que C++ est l'un des rares langages (le seul à ma connaissance, avec le C) qui facilite autant cette manière de coder, autant par l'ouverture de son environnement de développement (accès direct au C et à l'assembleur), que par les performances qu'il permet d'obtenir (qui n'ont rien à envier à celles des bibliothèques fournies en standard).
Voilà donc un autre point de vue d'un développeur C++ ayant eu un début de parcours fort similaire au tien.
Concernant certains des points évoqués dans ton journal.
Je ne trouve pas que développer en C++ est lent, mais c'est probablement parce que j'ai une flopée de bibliothèques pour mettre facilement et rapidement en œuvre toutes les fonctionnalités dont j'ai pu avoir besoin au cours de mes différents développements. Certes, développer ces bibliothèques m'a pris du temps, mais cela s'est fait au fil de l'eau, en généralisant au maximum et en déportant chaque nouvelle fonctionnalité dans une bibliothèque dés que j'ai eu besoin de cette fonctionnalité pour un logiciel.
Pour ce qui est de la compilation, vu que je n'ai jamais de dépendances du fait que je n'utilise pas de bibliothèques tiers, je n'ai besoin que d'un Makefile pour la compilation. Ce Makefile est généré à partir d'un fichier projet avec un format maison qui se contente, en gros, d'indiquer la nature du projet (exécutable, bibliothèque dynamique…), et de lister les bibliothèques utilisées. Ce fichier projet sert d'ailleurs aussi au paquetage automatique des sources de l'application dans le but de la distribuer.
Le seul gros manque, c'est une méthode standard de paquetage, ainsi qu'éventuellement un dépôt officiel. Ce n'est pas tellement gênant pour des développement à façon, car je fournis au client généralement un .zip avec les binaires. Mais pour tout mes développements open source, à part pour Windows, je ne sais pas comment faire pour mettre à disposition mes logiciels sans les faire compiler par l'utilisateur, ce qui implique qu'il ai un compilateur C++, en plus de make.
Zelbinium, la programmation ludique
[^] # Re: C'est pas mal, mais
Posté par Claude SIMON (site web personnel) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.
Et où as-tu vu que j'ai quoi que ce soit contre Python ?
D'ailleurs, je suis tellement contre Python que j'ai même publié un paquet Python : https://pypi.org/project/atlastk/ :-) !
Zelbinium, la programmation ludique
[^] # Re: C'est pas mal, mais
Posté par Claude SIMON (site web personnel) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1.
Certes, et, personnellement, je ne m'en prive pas, mais Python est fortement mis en avant.
Le Pi de Raspberry Pi, c'est pour Python (https://www.techspot.com/article/531-eben-upton-interview/), bien que ça soit de moins en moins mis en avant. En outre, les bibliothèques logicielles pour piloter les ports GPIO sont, à la base, en C ou C++, mais ce sont les bindings en Python qui sont le plus utilisés. Et ça vaut aussi pour les bibliothèques dédiées au pilotage de certains robots (Poppy Ergo Jr et consorts).
Les exemples de programmes des tutoriels sur le pilotage de kits ou de robots avec un RPI sont systématiquement en Python, accompagnés parfois de leur version en C ou C++. Il existe des exemples de programmes en Java, mais c'est vraiment exceptionnel.
Zelbinium, la programmation ludique
[^] # Re: Encore un nouveau standard?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Zoom sur trois projets émergents portés par Mozilla : Fluent, Bugbug et BinaryAST. Évalué à 1.
PGCD ?
Zelbinium, la programmation ludique
[^] # Re: Est-ce vraiment plus accessible ?
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les jeunes et la programmation (Atlas toolkit v0.7). Évalué à 1.
Merci de m'avoir donner l'occasion d'éclaircir mes propos !
En fait, back-end et front-end sont gérés par le même code source. Plus besoin de front-end en tant que tel.
Quand je présente le toolkit Atlas, la plupart des gens pensent de prime abord que c'est pour faire des CGI. Il faut vraiment que j'insiste, parfois lourdement, pour leur faire comprendre que c'est pour faire des SPA… En outre, la gestion des SPA est plus proche de la gestion des applications bureau, et repose moins sur HTML.
Mon but, avec le toolkit Atlas, c'est de pouvoir ajouter une GUI à un programme aussi simplement que possible, justement pour que le développeur puisse se concentrer sur le cœur du programme.
Je ne saurais dire si JavaScript est adapté pour l'apprentissage. En outre, avec la version Node.js du toolkit Atlas, l'approche est différente de celle du JavaScript front-end, mais il reste cependant le système des callbacks.
Je me concentre actuellement sur Python parce que c'est le langage qui est le plus souvent cité lorsque l'on parle d'initiation à la programmation, et, d'autre part, c'est également le langage le plus utilisé lorsqu'il s'agit de piloter des montages électroniques ou des robots connectés à un Raspberry Pi. Et piloter des robots, comme indiqué dans la dépêche, avec un smartphone, ça fait son petit effet auprès des adolescents :-)…
Je suis en train de monter un atelier d'initiation à la programmation basé sur le toolkit Atlas, et j'espère le mettre à l'épreuve prochainement. J'espère que les faits vous donneront raison :-)…
C'est pour cela que le toolkit Atlas se veut une alternative à tous ces frameworks habituellement utilisés, car l'apprentissage de ces derniers est bien trop ardu pour des débutants. Le toolkit Atlas est, certes, bien moins puissant, mais c'est largement suffisant pour débuter. Libre à eux d'utiliser un framework lorsqu'ils auront acquis les connaissances nécessaires pour le maîtriser.
La version PHP du toolkit Atlas est justement prévue pour fonctionner en mode CLI. Pour un langage qui a popularisé les CGI, faire des SPA, en mode CLI qui plus est, ça en perturbe plus d'un :-)…
Au début, je pensais que le fait de pouvoir facilement accéder aux applications, réalisées avec le toolkit Atlas, avec un smartphone était assez anecdotique. L'idée originale, derrière cela, c'est que les adolescents puissent facilement montrer leurs réalisations à leur entourage ; à leur âge, ils ont besoin de reconnaissance, d'encouragements. Maintenant, je pense de plus en plus que c'est un point essentiel, car cela démystifie le smartphone. Je pense que la plupart perçoive leur smartphone comme un portail vers cette chose mystérieuse qu'est le cloud, dont seules les grosses boîtes, comme les GAFAMs, ont la maitrise. Avec le toolkit Atlas, ils ont un aperçu de ce que c'est, techniquement, le cloud, et j'espère que cela donnera à certains l'envie d'approfondir le sujet, et de se l'approprier.
C'est sympathique. J'aime bien la cinématique, ça fait vraiment penser au jeu original :-) !
Zelbinium, la programmation ludique
[^] # Re: Ah ben ça tombe bien !
Posté par Claude SIMON (site web personnel) . En réponse au journal Document de cours : "Python for science". Évalué à 1.
Merci, mais je n'ai aucun mérite. C'est parce que le programme tourne dans Repl.it, une application web qui permet de disposer, sans rien avoir à installer, d'un environnement de développement pour pas mal de langages, juste en utilisant un navigateur web. Les logs proviennent de cette appli.
Comme indiqué dans le commentaire plus haut, noyé dans les logs, il y a une URL (elle change à chaque fois) qui, lorsqu'on l'ouvre, propose une interface permettant de faire varier la valeur des différents paramètres de la fonction gaussienne et de voir leur influence sur le graphique.
Avec le programme d'origine, on est obligé de modifier ces valeurs directement dans le programme, ce qui n'est pas très pratique. On peut également modifier le programme pour passer les valeurs de ces paramètres via des arguments de la ligne de commande, ou encore en permettant leur saisie à coup de
input(). Seule cette dernière option est présentée dans le guide faisant l'objet de ce journal mais, hormis sa présentation et un exemple de mise en œuvre, elle n'est pas exploitée par ailleurs.Une autre solution serait de doter le programme d'une GUI. Malgré les indéniables avantages d'une telle interface, une telle option n'est même pas évoquée dans ce guide. Probablement, mais ce n'est qu'une supposition, parce que l'effort nécessité par la mise en œuvre et l'apprentissage d'un des nombreux frameworks existants est disproportionné par rapport aux bénéfices qu'on en retirerait dans le cadre de leur utilisation dans des programmes tels que ceux présentés dans ce guide.
Ces frameworks sont complexes parce qu'ils proposent des fonctionnalités évoluées. Le toolkit Atlas est destiné à être utilisé dans les cas on l'on n'a besoin que de fonctionnalités basiques. Et c'est aussi pour cela que l'utilisation du toolkit Atlas ne nécessite que des connaissances basiques, faciles à acquérir, en technologies web.
J'ai dernièrement fait l'acquisition d'un kit électronique d'apprentissage destiné à être utilisé avec un Raspberry Pi. Il y avait un tutoriel fournit avec ce kit proposant, à titre d'exemple, un programme Python destiné à piloter une LED RGB. Ce programme faisait afficher des couleurs aléatoires par la LED. Là aussi, aucune interactivité. Alors, à l'instar de ce que j'ai fait ici, j'ai modifié le programme pour lui ajouter une GUI, à l'aide du toolkit Atlas, programme que l'on peut voir à l'œuvre ici.
Beaucoup de tutoriels gagneraient en attractivité en proposant des exercices et des exemples de programmes avec un minimum d'interactivité, à l'heure où tout le monde est habitué à manipuler des interfaces graphiques avec leurs smartphones. Et l'un des buts du toolkit Atlas est justement de pouvoir facilement modifier un programme pour le rendre interactif par l'ajout d'une GUI.
Zelbinium, la programmation ludique
# Ah ben ça tombe bien !
Posté par Claude SIMON (site web personnel) . En réponse au journal Document de cours : "Python for science". Évalué à 2.
Comme indiqué dans ce journal, je cherche des exemples de programmes Python auxquels je pourrais rajouter une GUI, et je me suis permis de modifier le programme
gauss-2d.pypour en faire ça. Il faut ouvrir l'URL indiquée dans la console (il peut être nécessaire de scroller vers le haut pour la trouver) dans une nouvelle fenêtre, et mettre les deux fenêtres côte à côte.Python ne m'est pas très familier, et encore moins matplotlib, donc c'est très largement améliorable, tout comme l'interface.
Zelbinium, la programmation ludique