Ouais, tu me sors la justification classique que sortent tous les employeurs dans ce genre de travail (voir la vidéo du SNJV par exemple). Cette justification fait croire que la passion peut remplacer le salaire à la fin du mois. Maintenant, si on remet notre cerveau en marche, qu'est-ce qui justifie, à compétences égale, de ne pas avoir le même salaire sous prétexte que dans un cas, ce sont des passionnés, et dans l'autre, ce ne sont de simples salariés ? Absolument rien.
Pourquoi faudrait-il nécessairement être moins bien payé pour les métiers pour lesquels on est passionné (marche avec logiciel libre mais aussi jeux vidéo) ?
Je viens de retomber sur quelques liens que j'avais prévu de mettre dans cet épisode, je les mets donc ici pour mémoire.
Gamepad : un draft du W3C pour gérer les manettes de jeu dans le navigateur. La partie intéressante est la normalisation de la manette (et notamment de la numérotation des boutons).
Game Input Simplified : une tentative de simplifier la gestion des inputs, et qui ressemble assez dans l'idée à ce qui se trouve dans jnuit, mais avec du Javascript.
Quand SFML gérera le tactile, ça ne sera pas trop dur je pense d'ajouter ce périphérique. Mais bon, après, mon objectif, ça reste le desktop, pas le mobile. Un RPG sur mobile, j'en ai un (Andor's Trail) et c'est une calamité à jouer.
Ensuite, je pense que le tactile, c'est un peu pareil que pour la WiiMote, il faut des jeux et des gameplays adaptés si tu veux vraiment en profiter.
Je vais devoir bien réfléchir au prochain moyen d'apparaître dans l'épisode 13…
Je pense que ça va être plus difficile ;)
Le but est de pouvoir gérer de multiples interactions
Oui, on en avait discuté, mais du coup, c'est quand même assez flou pour moi la manière dont on pourrait programmer ce genre de chose en l'état avec jnuit. Après, pour beaucoup de jeux, un truc plus simple suffit. Et j'aime bien le KISS.
Si vraiment vous avez de l'argent à dépenser, je vous conseillerais plutôt d'embaucher un graphiste. Vous êtes sur un clone de jeu (à peu près), donc vous allez souffrir de la comparaison avec l'original. Et la comparaison n'est pour l'instant pas en votre faveur. Donc quitte à dépenser, autant investir dans de jolis graphismes (et le mieux serait que ces graphismes apportent un style différent de l'original).
Les utilisateurs de noyaux alternatifs ou d'architecture alternatives, ils ont l'air de ne pas trop compter selon toi. Or, pour ces utilisateurs (notamment ceux qui ont des architectures alternatives), il n'y a souvent pas beaucoup d'autres choix que Debian. Ce ne sont pas des délires technophiles, c'est répondre aux besoins d'une certaine catégorie de gens qui n'ont pas d'autres choix ailleurs.
Non mais attends, cet argument, c'est pour faire pleurer dans les chaumières (et ça a l'air de marcher). Le post du blog reconnaît lui-même qu'à la version précédente, la gestion de l'accessibilité était "à peine acceptable". Et maintenant, ils en font une condition sine qua none. Donc, laisser tomber les malvoyants (comme à la version précédente) et avoir GNOME, c'est bon, et tout faire pour les malvoyants et avoir GNOME, c'est bon aussi. Dans les deux cas, c'est juste avoir GNOME et trouver des arguments rétro-compatibles.
Est-ce que Xfce offre, facilement, les même possibilités ? Et non, il ne suffit pas de dire que Xfce tourne sur les différentes architectures supportées par Debian, et que c'est amplement suffisant, point.
Un admin, il saura faire, quoi qu'il arrive, donc la question que tu poses est un faux problème. Et du point de vue de Debian, le fait que ça tourne partout simplifiera la vie de tout un tas de gens.
Et ça sera sans doute la même chose pour les écrans HiDPI
Sans support HiDPI, on a un écran noir ? Non, ça marche quand même, pas de quoi fouetter un chat. Alors qu'un GNOME sur kFreeBSD…
Entre l'accessibilité (qui n'est pas nulle chez KDE hein) et le fait de marcher sur tous les noyaux Debian, je crois que le choix est vite fait : je laisse tomber l'accessibilité.
Je trouve que les arguments donnés dans le post sont de mauvaise foi. La plupart s'applique également à KDE (sauf peut-être la taille de l'équipe) mais jamais il n'en est fait mention, on est face à un faux choix : GNOME ou XFCE. Alors qu'il existe d'autre DE, KDE en tête.
Dans la mauvaise foi, on trouve aussi ce passage sur les power users qui savent installer KDE ou XFCE et que le truc par défaut, ça doit être pour les gens qui ne savent pas faire (genre je prends les gens pour des cons). Ok. Mais alors pourquoi parler des admins dans les arguments ? Ils sauront aussi installer GNOME s'il n'est pas par défaut non ? (D'ailleurs, dans mon bout d'université, c'est KDE qui est installé avec Debian)
Mais mon moment préféré, c'est quand il dit que ça devrait être discuté (ça ok, c'est vrai) comme a été discuté le système d'init. C'est vrai qu'à deux mois de la date de gel, on peut se permettre 6 mois de discussions de couleur de garage à vélo sur le DE par défaut.
Ha oui, et en parlant de système d'init, arguer du fait que c'est bien intégré à systemd et que celui-ci est le système d'init par défaut, c'est un peu léger. Il est le système d'init par défaut sur les Linux, donc pas sur les version kFreeBSD par exemple. On fait comment là ?
C'est pour ça que XFCE, c'est un choix que je trouve raisonnable : ça offre un DE utilisable et léger qui fonctionne sur l'ensemble des variantes architecturale de Debian, point.
Une approche triviale ou simpliste, ça sera trivialement ou simplement cassable. Prend Vigénère par exemple (qui est trivial et simpliste), ça va résister à ta petite sœur, mais ça ne résistera pas à un étudiant en informatique, et encore moins à une agence gouvernementale américaine.
Ce genre de propos ne fait que maintenir la sécurité informatique dans une bulle d'expertise inaccessible au commun des mortels.
La cryptographie (qui est le sous-ensemble de la sécurité informatique qui nous intéresse ici) est bien un domaine d'experts. Elle n'est pas inaccessible au commun des mortels, comme le disait quelqu'un plus haut, comprendre ce qui ne marche pas (comme le cas présenté) requiert assez peu de connaissance. Après, concevoir des algorithmes de sécurité, ça demande d'avoir étudié des maths et de l'informatique pendant un certain nombre d'années. Ça ne s'improvise pas.
L'idée principale qui sous-tend le logiciel libre, c'est tout de même le partage, pas des remarques toutes faites comme "quand on sait pas, on fait pas" qui n'ont rien de constructive.
Il y a des tonnes de bouquins sur la sécurité, ça n'a rien à voir avec logiciel libre ou pas logiciel libre. Quand on prétend s'attaquer à un domaine, on se renseigne un minimum sur le domaine en question. Mais la sécurité en informatique échappe étrangement à cette règle.
Le problème, ce n'est pas que le projet ne soit pas libre, mais que visiblement, l'auteur du projet n'a aucune foutue idée de ce qu'il fait et que, au mieux, on va appeler ça du bricolage, mais certainement pas de la cryptographie. Et il suffit d'avoir suivi un cours de sécurité à l'université pour le comprendre.
Donc, je suis désolé de le dire, mais il n'aura certainement aucune contribution, ou en tout cas aucune contribution sérieuse, parce que son projet n'est pas très sérieux à la base donc ne donne absolument pas envie de contribuer. Il aura sans doute des contributions de gens qui se laissent facilement impressionner par des termes techniques sans consistance.
La morale de ce projet (et de tant d'autres), c'est qu'il vaut mieux laisser la cryptographie à des gens qui savent s'en servir et dont c'est le métier. Ou alors, il faut apprendre.
C'est pourquoi d'ailleurs ils ne sont jamais utilisés
Historiquement, il a été utilisé pour le téléphone rouge. Et dans quelques autres cas très spécifique.
utiliser 10 fois un masque jetable ne le fragilise pas tant que ça, au delà tu peux imaginer des attaques statistique
La sécurité prouvée du masque jetable repose sur le fait qu'on jette la clef, parce que jeter la clef ne fait apparaître aucune redondance dans le message chiffré. Si tu réutilises la clef, tu as perdu, ça revient à faire du chiffrement XOR.
C'est fatiguant à force cette loi américaine qu'on s'impose de nous même jusque sur notre territoire.
Ce n'est que le début. Une fois qu'on aura le grand marché transatlantique, on nous dira qu'il faut aligner les législations… sur la législation américaine. On le voit avec un autre journal plus loin : un opérateur américain qui opère à l'étranger est sous le coup de la loi américaine, mais un opérateur étranger qui opère aux US est aussi sous le coup de la loi américaine. Et bientôt, un opérateur étranger qui opère à l'étranger sera aussi sous le coup de la loi américaine (en fait, ça existe déjà, voir Megaupload par exemple).
La règle qui dit qu'on déclare une variable au plus près de sa première utilisation et dans la portée minimum est maintenant une des règles fondamentales de la programmation dans n'importe quel langage, ça évite tout un tas d'erreur. Donc se traîner des limitations techniques qui empêchent de bien programmer, oui ça me paraît important.
Je préfère leur montrer le type booléen et leur expliquer les expressions booléennes avec un vrai type booléen, et leur dire ensuite qu'en C, on représente un booléen avec un entier. Le type booléen existe dans quasiment tous les langages (et même en C d'ailleurs depuis C99 même si l'usage fait que personne ne l'utilise) donc autant leur montrer.
Tout dépend de ce que tu mets dans la pédagogie. Là, on a devant nous des étudiants, pas des enfants, donc ils savent déjà apprendre, notre mission est de leur apprendre à apprendre. Certes il faut un peu de pédagogie mais il faut surtout de la méthode et de l'efficacité.
Si tu introduis ça au début, pur des personnes qui ne continueront probablement pas à faire de la programmation, tu les dégoutes.
J'ai devant moi des étudiants scientifiques (qui vont aller après dans des filières diverses : physique, chimie, maths, sciences de l'ingénieur) et quand il néglige les cours d'informatique en L1, je les mets en garde : ils en auront besoin plus tard, quoi qu'il fasse. Et quand je regarde les programmes des différents filières, il y a de la programmation à un moment donné parce que la plupart des sciences utilisent maintenant fortement l'informatique (au même titre que les maths). Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.
Maintenant, j'ai peut-âtre été trop restrictif dans les types de base, et je t'accorde que différencier décimal/entier serait prebablement pertinent. Comme tu parlais de C/C++, j'avais à lesprit la totalité des types C/CPP (int, short , long, float, double, etc ….) qui sont difficiles à appréhender quand tu commences à programmer.
Il ne faut pas leur apprendre les types de C/C++, il faut leur apprendre les types ! Donc, entiers (de diverses tailles, mais int suffit dans 90% des cas), flottants (double dans 90% des cas), char pour manipuler des caractères ASCII, booléen pour calculer des expressions booléennes. Déjà avec ça, on a du boulot. Parce que choisir le bon type parmi ces 4 familles, c'est parfois compliqué. Surtout char en fait, il est très bien parce qu'il permet d'expliquer qu'on peut représenter un truc abstrait (un caractère) par un entier, suivant une norme qu'on se définit. Et qu'on peut faire pareil après, par exemple pour dire que 1 veut dire oui et 2 veut dire non. C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.
Un truc rigolo à faire est de faire une capture d'écran et de la mettre en plein écran… Généralement, ça peut prendre plusieurs minutes avant que l'utilisateur s'aperçoive qu'il y a quelque chose qui ne va pas.
L'idéal ce serait d'en voir plusieurs, et laisser les élèves choisir celui ou ceux qu'ils préfèrent.
La concurrence libre et non-faussée entre les langages de programmation, et la main invisible choisira le meilleur langage… Sauf qu'en réalité, ça ne se passe pas comme ça. Parce que le temps d'apprentissage d'un langage (et pas juste les trucs de base) est trop important par rapport au temps dédié à cet apprentissage. Et le choix, il revient aux enseignants, qui construisent un parcours pédagogique complet pour montrer tous les aspects de l'informatique.
Si le(s) prof(s) en connaissent plusieurs, pourquoi ne pas leur faire des séances découvertes de chaque avant de les laisser en choisir un individuellement pour les travaux pratiques?
Ha ben oui, c'est vrai qu'on a tellement de temps à consacrer à ce genre de lubie. Sans compter que corriger des TP écrits dans des langages différents doit être un plaisir sans bornes.
[^] # Re: Pour l'honneur !
Posté par rewind (Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 7.
Ouais, tu me sors la justification classique que sortent tous les employeurs dans ce genre de travail (voir la vidéo du SNJV par exemple). Cette justification fait croire que la passion peut remplacer le salaire à la fin du mois. Maintenant, si on remet notre cerveau en marche, qu'est-ce qui justifie, à compétences égale, de ne pas avoir le même salaire sous prétexte que dans un cas, ce sont des passionnés, et dans l'autre, ce ne sont de simples salariés ? Absolument rien.
[^] # Re: Pour l'honneur !
Posté par rewind (Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 2.
Pourquoi faudrait-il nécessairement être moins bien payé pour les métiers pour lesquels on est passionné (marche avec logiciel libre mais aussi jeux vidéo) ?
[^] # Re: les 3 en un ?
Posté par rewind (Mastodon) . En réponse au journal Replopbot: un threeway en chameau, ça vous botte?. Évalué à 9.
Le problème, ce ne sont pas les clients, mais les serveurs (et les services) ;)
# Quelques oublis
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E12 : interfaces physiques et graphiques. Évalué à 4.
Je viens de retomber sur quelques liens que j'avais prévu de mettre dans cet épisode, je les mets donc ici pour mémoire.
jnuit, mais avec du Javascript.[^] # Re: Et le tactile
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E12 : interfaces physiques et graphiques. Évalué à 3.
Quand SFML gérera le tactile, ça ne sera pas trop dur je pense d'ajouter ce périphérique. Mais bon, après, mon objectif, ça reste le desktop, pas le mobile. Un RPG sur mobile, j'en ai un (Andor's Trail) et c'est une calamité à jouer.
Ensuite, je pense que le tactile, c'est un peu pareil que pour la WiiMote, il faut des jeux et des gameplays adaptés si tu veux vraiment en profiter.
[^] # Re: control & detect
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E12 : interfaces physiques et graphiques. Évalué à 2.
Je pense que ça va être plus difficile ;)
Oui, on en avait discuté, mais du coup, c'est quand même assez flou pour moi la manière dont on pourrait programmer ce genre de chose en l'état avec jnuit. Après, pour beaucoup de jeux, un truc plus simple suffit. Et j'aime bien le KISS.
[^] # Re: Merci !
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E12 : interfaces physiques et graphiques. Évalué à 4.
De rien, le plaisir est pour moi. Et puis je me délecte à mettre des liens sur des pages Wikipédia aussi importantes que «Vraie vie» ;)
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 2.
https://www.debian.org/ports/
Alternatif, ça comprend tout ce que les autres distributions font pas ou peu :
Même sans mettre arm, ça fait déjà un paquet. Et à ma connaissance, il n'y a que Gentoo qui fait à peu près aussi éclectique.
# Graphismes
Posté par rewind (Mastodon) . En réponse à la dépêche CatchChallenger 0.5. Évalué à 8.
Si vraiment vous avez de l'argent à dépenser, je vous conseillerais plutôt d'embaucher un graphiste. Vous êtes sur un clone de jeu (à peu près), donc vous allez souffrir de la comparaison avec l'original. Et la comparaison n'est pour l'instant pas en votre faveur. Donc quitte à dépenser, autant investir dans de jolis graphismes (et le mieux serait que ces graphismes apportent un style différent de l'original).
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 3.
Les utilisateurs de noyaux alternatifs ou d'architecture alternatives, ils ont l'air de ne pas trop compter selon toi. Or, pour ces utilisateurs (notamment ceux qui ont des architectures alternatives), il n'y a souvent pas beaucoup d'autres choix que Debian. Ce ne sont pas des délires technophiles, c'est répondre aux besoins d'une certaine catégorie de gens qui n'ont pas d'autres choix ailleurs.
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 9.
Non mais attends, cet argument, c'est pour faire pleurer dans les chaumières (et ça a l'air de marcher). Le post du blog reconnaît lui-même qu'à la version précédente, la gestion de l'accessibilité était "à peine acceptable". Et maintenant, ils en font une condition sine qua none. Donc, laisser tomber les malvoyants (comme à la version précédente) et avoir GNOME, c'est bon, et tout faire pour les malvoyants et avoir GNOME, c'est bon aussi. Dans les deux cas, c'est juste avoir GNOME et trouver des arguments rétro-compatibles.
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 2.
Un admin, il saura faire, quoi qu'il arrive, donc la question que tu poses est un faux problème. Et du point de vue de Debian, le fait que ça tourne partout simplifiera la vie de tout un tas de gens.
Sans support HiDPI, on a un écran noir ? Non, ça marche quand même, pas de quoi fouetter un chat. Alors qu'un GNOME sur kFreeBSD…
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à -1.
Entre l'accessibilité (qui n'est pas nulle chez KDE hein) et le fait de marcher sur tous les noyaux Debian, je crois que le choix est vite fait : je laisse tomber l'accessibilité.
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par rewind (Mastodon) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 10.
Je trouve que les arguments donnés dans le post sont de mauvaise foi. La plupart s'applique également à KDE (sauf peut-être la taille de l'équipe) mais jamais il n'en est fait mention, on est face à un faux choix : GNOME ou XFCE. Alors qu'il existe d'autre DE, KDE en tête.
Dans la mauvaise foi, on trouve aussi ce passage sur les power users qui savent installer KDE ou XFCE et que le truc par défaut, ça doit être pour les gens qui ne savent pas faire (genre je prends les gens pour des cons). Ok. Mais alors pourquoi parler des admins dans les arguments ? Ils sauront aussi installer GNOME s'il n'est pas par défaut non ? (D'ailleurs, dans mon bout d'université, c'est KDE qui est installé avec Debian)
Mais mon moment préféré, c'est quand il dit que ça devrait être discuté (ça ok, c'est vrai) comme a été discuté le système d'init. C'est vrai qu'à deux mois de la date de gel, on peut se permettre 6 mois de discussions de couleur de garage à vélo sur le DE par défaut.
Ha oui, et en parlant de système d'init, arguer du fait que c'est bien intégré à systemd et que celui-ci est le système d'init par défaut, c'est un peu léger. Il est le système d'init par défaut sur les Linux, donc pas sur les version kFreeBSD par exemple. On fait comment là ?
C'est pour ça que XFCE, c'est un choix que je trouve raisonnable : ça offre un DE utilisable et léger qui fonctionne sur l'ensemble des variantes architecturale de Debian, point.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 3.
Une approche triviale ou simpliste, ça sera trivialement ou simplement cassable. Prend Vigénère par exemple (qui est trivial et simpliste), ça va résister à ta petite sœur, mais ça ne résistera pas à un étudiant en informatique, et encore moins à une agence gouvernementale américaine.
[^] # Re: Pas convaincu
Posté par rewind (Mastodon) . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 2.
Depuis quand la factorisation est-elle dans NP ?
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 7.
La cryptographie (qui est le sous-ensemble de la sécurité informatique qui nous intéresse ici) est bien un domaine d'experts. Elle n'est pas inaccessible au commun des mortels, comme le disait quelqu'un plus haut, comprendre ce qui ne marche pas (comme le cas présenté) requiert assez peu de connaissance. Après, concevoir des algorithmes de sécurité, ça demande d'avoir étudié des maths et de l'informatique pendant un certain nombre d'années. Ça ne s'improvise pas.
Il y a des tonnes de bouquins sur la sécurité, ça n'a rien à voir avec logiciel libre ou pas logiciel libre. Quand on prétend s'attaquer à un domaine, on se renseigne un minimum sur le domaine en question. Mais la sécurité en informatique échappe étrangement à cette règle.
[^] # Re: Le projet est libre, vous pouvez participer
Posté par rewind (Mastodon) . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 10.
Le problème, ce n'est pas que le projet ne soit pas libre, mais que visiblement, l'auteur du projet n'a aucune foutue idée de ce qu'il fait et que, au mieux, on va appeler ça du bricolage, mais certainement pas de la cryptographie. Et il suffit d'avoir suivi un cours de sécurité à l'université pour le comprendre.
Donc, je suis désolé de le dire, mais il n'aura certainement aucune contribution, ou en tout cas aucune contribution sérieuse, parce que son projet n'est pas très sérieux à la base donc ne donne absolument pas envie de contribuer. Il aura sans doute des contributions de gens qui se laissent facilement impressionner par des termes techniques sans consistance.
La morale de ce projet (et de tant d'autres), c'est qu'il vaut mieux laisser la cryptographie à des gens qui savent s'en servir et dont c'est le métier. Ou alors, il faut apprendre.
[^] # Re: Pas convaincu
Posté par rewind (Mastodon) . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 2.
Je répond aussi au message grand-parent.
Historiquement, il a été utilisé pour le téléphone rouge. Et dans quelques autres cas très spécifique.
La sécurité prouvée du masque jetable repose sur le fait qu'on jette la clef, parce que jeter la clef ne fait apparaître aucune redondance dans le message chiffré. Si tu réutilises la clef, tu as perdu, ça revient à faire du chiffrement XOR.
[^] # Re: report des bugs
Posté par rewind (Mastodon) . En réponse au journal FFmpeg de retour dans Debian. Évalué à 6.
Ce n'est que le début. Une fois qu'on aura le grand marché transatlantique, on nous dira qu'il faut aligner les législations… sur la législation américaine. On le voit avec un autre journal plus loin : un opérateur américain qui opère à l'étranger est sous le coup de la loi américaine, mais un opérateur étranger qui opère aux US est aussi sous le coup de la loi américaine. Et bientôt, un opérateur étranger qui opère à l'étranger sera aussi sous le coup de la loi américaine (en fait, ça existe déjà, voir Megaupload par exemple).
[^] # Re: Pascal...
Posté par rewind (Mastodon) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 1.
La règle qui dit qu'on déclare une variable au plus près de sa première utilisation et dans la portée minimum est maintenant une des règles fondamentales de la programmation dans n'importe quel langage, ça évite tout un tas d'erreur. Donc se traîner des limitations techniques qui empêchent de bien programmer, oui ça me paraît important.
[^] # Re: Pascal...
Posté par rewind (Mastodon) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
Je préfère leur montrer le type booléen et leur expliquer les expressions booléennes avec un vrai type booléen, et leur dire ensuite qu'en C, on représente un booléen avec un entier. Le type booléen existe dans quasiment tous les langages (et même en C d'ailleurs depuis C99 même si l'usage fait que personne ne l'utilise) donc autant leur montrer.
[^] # Re: Pascal...
Posté par rewind (Mastodon) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.
Tout dépend de ce que tu mets dans la pédagogie. Là, on a devant nous des étudiants, pas des enfants, donc ils savent déjà apprendre, notre mission est de leur apprendre à apprendre. Certes il faut un peu de pédagogie mais il faut surtout de la méthode et de l'efficacité.
J'ai devant moi des étudiants scientifiques (qui vont aller après dans des filières diverses : physique, chimie, maths, sciences de l'ingénieur) et quand il néglige les cours d'informatique en L1, je les mets en garde : ils en auront besoin plus tard, quoi qu'il fasse. Et quand je regarde les programmes des différents filières, il y a de la programmation à un moment donné parce que la plupart des sciences utilisent maintenant fortement l'informatique (au même titre que les maths). Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.
Il ne faut pas leur apprendre les types de C/C++, il faut leur apprendre les types ! Donc, entiers (de diverses tailles, mais int suffit dans 90% des cas), flottants (double dans 90% des cas), char pour manipuler des caractères ASCII, booléen pour calculer des expressions booléennes. Déjà avec ça, on a du boulot. Parce que choisir le bon type parmi ces 4 familles, c'est parfois compliqué. Surtout char en fait, il est très bien parce qu'il permet d'expliquer qu'on peut représenter un truc abstrait (un caractère) par un entier, suivant une norme qu'on se définit. Et qu'on peut faire pareil après, par exemple pour dire que 1 veut dire oui et 2 veut dire non. C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.
# capture d'écran et plein écran
Posté par rewind (Mastodon) . En réponse au sondage Quand je vois une session ouverte.... Évalué à 7.
Un truc rigolo à faire est de faire une capture d'écran et de la mettre en plein écran… Généralement, ça peut prendre plusieurs minutes avant que l'utilisateur s'aperçoive qu'il y a quelque chose qui ne va pas.
[^] # Re: Pas de "bonne" réponse
Posté par rewind (Mastodon) . En réponse au journal Python comme premier langage de programmation ?. Évalué à 6.
La concurrence libre et non-faussée entre les langages de programmation, et la main invisible choisira le meilleur langage… Sauf qu'en réalité, ça ne se passe pas comme ça. Parce que le temps d'apprentissage d'un langage (et pas juste les trucs de base) est trop important par rapport au temps dédié à cet apprentissage. Et le choix, il revient aux enseignants, qui construisent un parcours pédagogique complet pour montrer tous les aspects de l'informatique.
Ha ben oui, c'est vrai qu'on a tellement de temps à consacrer à ce genre de lubie. Sans compter que corriger des TP écrits dans des langages différents doit être un plaisir sans bornes.