freem a écrit 4909 commentaires

Seule la découverte simple est au programme.

Ça, ça à dû changer alors, parce que je me rappellerais toujours avoir été interrogé sur le module "clavier" --qui se constituait principalement de code-- du projet lors du bac (pour mon plus grand plaisir d'ailleurs, j'avoue que le programme était si simple que je n'avais eu ni besoin de réviser, ni même de consulter quelque document que ce soit, j'ai regardé les examinateurs dans les yeux tout le long de ma présentation :D).
Pour être précis, je ne sais pas si c'était obligatoire, mais on avait étudié la programmation de PIC (par contre, il ne me semble pas qu'on avait manipulé) et du coup, j'ai un peu de mal avec la notion d'utiliser des langages qui ne sont pas capables d'accès bas niveau dans ces classes (d'électronique, hein, pour les autres STI c'est sûr que l'intérêt est restreint) tels que python, par exemple.

En tout cas merci pour ces infos des changements qui ont eu lieu… intéressant de savoir que l'arduino est arrivé dans certains lycées.

SysML

Tiens, je n'avais jamais entendu parler de ça. Vais aller combler ce manque fissa…

La preuve: tant que tu ne lui mets pas de claque, il ne sait pas qu'il à fait une connerie, jusqu'a ce que tu lui en mettes une :p

J'ai envie de dire que tous ceux étant passés par une STI quelconque devraient être d'accord avec toi: que ce soit en électricité ou en mécanique, le typage des résultats à été la cause de pas mal de points perdus, ou gagnés (parce qu'en fonction des types et des ordres de grandeurs, ou pouvait repérer certaines erreurs dans les algo raisonnements utilisés…).

En tout cas, perso, je ne peux qu'être d'accord avec toi: pour passer d'un type à un autre, passer par une fonction spécifique est une excellente chose. Il m'arrive même de penser que C++ est trop laxiste par moments (il permets toujours les cast implicites, notamment de short vers char, même s'il est possible de demander au compilo d'avertir puis de transformer ce warn en erreur)… alors qu'il l'est nettement moins que le C.
Que ça oblige à la rigueur n'est pas un problème, mais un avantage, parce que les ordinateurs ne sont, jusqu'à preuve du contraire, pas des être dotés de raison/sens artistique, donc quand on leur "parle" il est évident qu'il faut être rigoureux.

Je t'avoue que j'ai toujours eu une tendance à aimer la portabilité, et souvent se baser sur un standard aide pas mal. Ça explique que je préfère utiliser dash pour les scripts (enfin, /bin/sh, mais sous debian il linke vers dash ;) ce qui est pas plus mal me concernant ).

Ceci dit, pour des one-shot, bash me gêne pas.

Commencer par PHP, avec du HTML?
Euh… quitte à enseigner le dev/l'aglo, autant utiliser des langages qui sont conçus, dès le départ, pour être enseignés. PHP n'en fait pas partie, il s'agit d'un langage qui me donne personnellement l'impression d'être brouillon.
Basic, peut-être (suis pas sûr), pascal, très certainement, et idem pour python.

Pour continuer sur PHP, tu dis:

plutôt du PHP avec un peu de HTML par exemple, il est aisé pour les élèves de faire des algorithmes simples en mettant en place un petit serveur.

Monter un serveur (par élève histoire qu'il y en ait pas un qui foute la merde…), enseigner PHP et HTML côte à côte?
Que ce soit pour enseigner du dev généraliste ou de l'algo, je sais une chose: je ne me tournerais pas vers un langage purement web, tel que PHP: il y à bien trop de choses à apprendre autour pour arriver à comprendre ce que l'on fait. Par exemple, pourquoi le HTML ne réagit pas de la même manière sur toutes les machines (fonction du browser et même de sa version!)? Il n'y à rien de plus frustrant que les bugs qui sont fonction de l'environnement, surtout pour un élève je pense.

Pour le .xinitrc je l'utilise après avoir tester les dispositions des écrans à la main, il serait idiot de refaire la commande à chaque démarrage du x11.

Oui, ça me semblait évident :)

Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…

Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère, et il y à même des gens qui ont créé astyle, qui permets de pull un projet avec mon codestyle, et de le push avec le codestyle d'origine.

Par exemple, est-il possible de faire un truc comme ça:

int foo(
  char bar
)
{
  this.is.a.very
  (
   long, line,
   which,
   only,
   serves,
   as, a, dumb,
   example
  );
}

Même si le code que j'ai utilisé en exemple est complètement crétin, il n'empêche que ça serve, parfois.
De même, en openGL 1 (oui, je sais c'est obsolète, mais la question n'est pas là), il existe des fonction glbegin() et glend() qui permettent de définir entre les blocs une suite d'instructions graphiques.
Quand je m'en suis servi, j'ai indenté le code entre ces deux fonctions, parce que c'était un peu comme une structure de contrôle au final.
Avec python, ce serait impossible…
Ensuite, j'ai pensé à utiliser un bloc d'instruction, c'est plus simple et lisible. Mais avec python, est-ce faisable? Parfois, cette dernière technique me sert aussi quand je refacto du code atteint de gigantisme fonctionnel (fonction qui me force à scroller 5minutes pour en voir la fin…) histoire de pré-découper le code en future fonctions, le jour ou quelqu'un d'autre aura le temps :=) (oui, je devrais le faire moi-même, sauf que, c'est pas parfois pas si simple que ça…).
Encore une fois, quid de ces cas particuliers en python?

En fonction des réponses, il se pourrait que l'une de mes barrières pour commencer python saute… Parce que oui, l'indentation et le style de code, c'est important, voire sacré pour moi, et j'aime pas spécialement qu'on me les impose (quand je bosse sur un projet, j'essaie de suivre ce qui est utilisé, cependant, mais la situation est différente, l'histoire à toujours raison!)

PS: je n'ai pas réussi à formater correctement de la même façon que toi du texte normal… tu as fais comment? Ni foo ni
```
foo
```

ne marchaient :/

c'est pas à cause d'une restriction arbitraire lié au codage

La preuve, on peut surcharger les opérateurs dans certains langages, et la conséquence directe est qu'il est possible de faire que 3 + "foo" fasse "3foo". Certains le font d'ailleurs, et ça donne des choses très drôles. (c'est assez court, mais pour les flemmards: à partir d'1:35 ça commence à parler de ce genre de joyeusetés. Surtout au sujet de JS pour le coup…)

NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!

Quand on écoute ce que raconte un informaticien à un public de débutant, on se demande comment il apprendrait à conduire à quelqu'un :

Perso, j'ai une solution pour éviter ça: j'évite autant que faire se peut de parler d'informatique. Et quand on me pose explicitement une question, que je ne peux pas esquiver, je m'arrange pour donner le moins d'info possible.
C'est pas que je veux pas, mais le souci c'est qu'on s'aperçoit que de toute façon ça va souler l'autre, qui n'en à rien à foutre.
Au final, quand ils demandent "pourquoi", il demandent une réponse type "ohla, c'est compliqué mais t'inquiètes, je gère", qui leur permets de se dédouaner de devoir cogiter et mettre les mains dans l'informagique…
Bien entendu, on va me rétorquer que, tout le monde est pas obligé, blabla connaître l'ordi, blabla… sauf que quand c'est le mécano, il va pas se priver de t'emmerder avec ses histoires de delco, par exemple. Même qu'en général ça m'intéresse et je repose des questions, et pourtant j'ai pas l'intention de devenir mécano… (juste un exemple hein)

Je dirais surtout au final, que les informaticiens sont encore un peu vus comme des sorciers, et qu'il est tellement plus simple de se dédouaner de ses conneries en disant "ouai, mais tu comprends, ça marche jamais comme il faut, j'ai rien installé et maintenant c'est super lent! En plus sur les sites ils me disent que mon windows est pas en sécurité et qu'il faut cliquer sur la bannière. D'ailleurs l'autre jour ma banque m'a envoyé un mail, mais c'était bizarre, y'avais pleins de fautes. Enfin, je leur ai envoyé mon code de CB comme ils demandaient, c'était urgent…".
Bon, j'exagère: le passage "mais c'était bizarre, y'avais pleins de faute" est fictif et irréaliste.

Maintenant, dans la pratique, j'ai déjà expliqué le fonctionnement d'un diagramme de classe qui décrivait un soft qui utilisais une mécanique de plug-in à quelqu'un, qui était un minimum curieuse et dotée de raison.
Cette personne (adulte, certes) semblait avoir compris… en même temps, la POO + l'UML, ça aide considérablement à expliquer ce qu'un programme fait et comment il le fait. Bien plus que l'algorithmique.

je dirai que tu as une mauvaise connaissance du shell

Ton assertion sur ma mauvaise connaissance du shell est vraie, mais je dirais que tu mélanges shell et bash également car:

#!/bin/sh
for (( i=0 ; i < 5 ; i++ ))
do
  echo $i
done

donne:

./test.sh: 2: ./test.sh: Syntax error: Bad for loop variable


note bien tu peux aussi utiliser la bonne vieille méthode : for i in $( seq 1 4 )

Effectivement, j'ai tendance à oublier l'existence de seq (CQFD avec mon mauvais shell;)). Je ne prétends pas être un expert en shell, je ne dirais même pas être de niveau avancé. Je suis sûr que les quelques scripts que je me bricole feraient fuir plus d'un admin chevronné.

par contre je ne mixe pas du awk et du shell

J'ai cité ce problème car je l'ai eu il y à peu sur un usage ponctuel, mais je fais pas mal de scripts pour manipuler du SQL aussi, et là ça devient assez pénible.
En fait, dès lors que l'on mélange du shell avec un autre langage, ça deviens pénible, j'ai l'impression. (Mais je t'avoue que mélanger les langages est un truc que je préfère habituellement éviter comme la peste)

une simplicité enfantine le jour où j'ai découvert $() à la place de ``;

C'est vrai que c'est une sacrée bouffée d'air pur.

et encore, l'utilisation de read a b c d plop règle bon nombre de problème.

Tu peux détailler un peu? Les connaissances sur le shell sont toujours bonnes à prendre.

coproc est aussi bien pratique dans certains cas :)

Je ne connais pas… Je viens de regarder la doc de bash à son sujet, mais j'ai un peu de mal à voir l'intérêt? (en même temsp, vendredi, gueule de bois qui viens enfin de s'estomper, tout ça… pas au meilleur de ma forme pour découvrir des histoires de pipe redirigés et comprendre l'intérêt xD)

Et? Je ne vois pas où tu veux en venir: si tu utilises, disons, Qt d'une part, et, par exemple, libpq (lib qui permets d'interroger postgresql) il va bien falloir qu'à un moment tu la fasses, cette conversion…
Du coup, si tu utilises au maximum les fonctionnalités fournies par le standard, c'est bien plus simple de combiner l'usage de différentes libs.

Si ce qui t'ennuies, c'est ce genre de choses: QString -> std::string -> QString -> std::string -> QString -> std::string -> QString pour une donnée unique, c'est que peut-être que les relations entre les classes de ton programmes sont mal faites? Peut-être qu'avec une meilleure architecture ce serait évitable?
Pas toujours, c'est vrai, mais j'ai parlé d'éviter, et de cas généraux. Si je dois, pour une raison ou une autre, manipuler en permanence un type non-standard dans un code, alors tant pis. Mais ça arrive assez rarement, et quand ça m'arrive je constate qu'en général, il est intéressant de l'encapsuler. Du coup, j'utilise toujours du non-standard, c'est vrai, mais seule l'encapsulation est dépendante de la lib externe.
Conséquence, s'il faut porter le projet, ou changer de techno sous-jacente, il y à moins de code à revoir.

J'avoue ne pas vraiment comprendre pour quelle raison tu souhaites ne pas utiliser les QString dans des classes d'IHM de Qt…

C'est plus de l'ordre du réflexe en fait, j'ai une tendance à préférer utiliser ce qui est standard en priorité, l'avantage étant que plus tu utilises le matériel standard, moins le temps d'embrayage d'un nouveau sur le projet est long s'il ne connaît que le langage.
Accessoirement, même si, à l'heure actuelle, Qt est très modulaire (je ne l'ai pas utilisé depuis la v3, mais j'ai un croisé les dépêches qui en parlent), ça n'a pas toujours été le cas, je me trompe?

tu crée une couche entre le core de appli et la ou les biblio que tu utilise

Pas vraiment, c'est juste qu'en général, l'usage d'une lib n'est utile que dans une couche donnée de l'application, par exemple l'IHM.
Le cœur de l'application et les autres couches n'ont pas à utiliser voire même juste connaître les outils utilisés par les autres couches. Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM (et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur…), alors que la tentation est quand même vachement forte (ceci étant dit, je considère C++/Qt comme étant quasiment un langage différent de C++).

Je m'amuse pas à faire une lib d'interfaçage à chaque projet pour chaque lib, sinon on en finit pas :)

Jamais je n'ai remis en question la pertinence de mettre le code non portable le plus loin possible du code portable :)

C'est d'ailleurs une chose que j'essaie de faire au maximum, et ce, même avec les lib: ne pas inclure une lib partout, limiter son usage à un set de classes qui ne vont faire quasiment que s'en servir. Et ce pour chaque lib, comme ça le jour ou, pour une raison ou un autre, il faut changer la lib, ben pas besoin de refaire la totalité du programme. (d'ailleurs, c'est pour ça que je ne ressens pas le besoin d'utiliser des frameworks, voire que je considère ces outils comme quasi-néfastes, mais c'est un sujet pour un vendredi… oups :) )

C'est vrai qu'on ne peut pas qualifier le shell de psychorigide. En fait, c'est même le contraire, pour faire du shell il vaut mieux ne pas avoir peur du flou artistique.
Les différences entre les '', les "" deviennent très vite très fun dès que l'on doit utiliser un langage tiers, ce qui est plus que commune avec shell, par exemple lorsque l'on utilise awk.

Je vais pas trop taper sur le shell, cet outil si pratique, mais, il me semblait que l'on parlait dans ce sujet de langages faciles à apprendre. Hors, le shell est bien plus complexe que le C, pour moi. Ok, dans le C, on à la gestion de la mémoire, mais au moins la syntaxe est claire et s'acquiert rapidement. Ça commence à faire quelques temps que j'utilise shell au taf, et même si je ne peux nier qu'il à ses avantages, je pense que si le man était en papier, mon livre de man s'ouvrirait tout seul à, par exemple, la page "test". Ou peut-être à la page "boucles for pour compter" (qui n'existe certes pas).

À choisir entre la "psychorigidité" du C et les trips sous LSD du shell, je n'hésite pas une seule seconde.

Ah, j'oubliais. En C, ton programme il compile ou il compile pas, c'est binaire. En shell, un coup il s'exécute, un coup il s'exécute pas… en fonction des chemins dans le code.
Du coup, je te rejoins: le ';' c'est pour les psychorigides. Mais l'algorithmique est une science, pas un truc qu'on fait après vidé une infusion de champignons…

J'imagine que ça dépend de la formation en question, je doute fortement que le C ait été remplacé en STI électronique…

D'ailleurs, je pense ne pas être le seul à avoir tapé mes premières lignes sur une calculatrice, et c'était pas en mode "graphique".
Le programme que tu décrit me rappelle très clairement mes premiers…hum… programmes… pourtant j'étais "déjà" en seconde… (même si le contenu des programmes n'était pas dans le même genre d'humour que ce que tu décris, l'algo devait être assez proche :) )
Ensuite j'ai codé sur PC avec qbasic, encore une fois le mode texte était mon préféré (en fait, j'utilisais beaucoup de semi-graphique), et si j'avais eu à passer par du gtk, qt, ou je ne sais quoi, je ne pense pas que j'aurai persévéré. Avant de vouloir des choses belles, on veut d'abord un truc facile à faire et manipuler, et pour ça, y'a pas mieux que les bons vieux terminaux (un coup de locate, un coup de color, et un coup de print, et voila, c'est joli :) ).

Mais dans ce cas, que faire des noms de variables ?

google trad' est ton ami… non je déconnne :)

Et accessoirement, il n'y à pas besoin de connaître le C pour être "informaticien" ou même développeur. Ce n'est rien d'autre qu'un langage comme un autre, ce n'est ni le seul langage ancien, ni le seul langage bas niveau, ni le seul langage compilé, ni le seul langage portable, ni le seul langage que l'on peut utiliser "gratuitement".

Et c'est encore moins le seul langage qui cumule ces qualificatifs.

Moui enfin, d'un autre côté, ça reviens à foutre dans une lib (statique) le code non portable, donc on déplace le problème du fait que le kernel comporte du code qui n'est pas faisable en C standard.

je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.

Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
D'ailleurs, si j'ai bonne mémoire, le python à justement été créé pour enseigner, car justement le fait d'imposer un coding style permets de faire sauter à l'œil les bugs… ou pas (en fait si, mais c'est plus compliqué que juste prendre en compte les espaces blancs dans le code source…).

Windev quoi…

Essayes de les démarrer de la console, tu verras peut-être des messages qui t'indiqueront le problème.
Une autre solution pour choper de l'info, c'est d'utiliser xev (à lancer à partir de la console) et de vérifier en cliquant sur la fenêtre de ton choix et en faisant le raccourcis clavier qui va bien, que tout est ok. Attention, xev est verbeux, très verbeux.

Utiliser des extensions dans du code kernel ça ne me choque pas, dans du code applicatif c’est déjà plus discutable.

L'arrivée de clang à permis d'en nettoyer une partie… et d'implémenter dans clang une partie des extensions gnu. Malgré tout ça, il y à encore pas mal de paquets qui ne compilent pas, au moins sous Debian, avec clang (5.7% aux dernières news).

Et sinon, je me demande quelle est la proportion moyenne des kernels *BSD qui n'est pas écrite en C standard? Quelqu'un aurait une info la dessus? (après tout, il s'agit des seuls kernels libres capables d'être utilisés au quotidien sur un bureau que je connaisse, en plus de linux, et donc les seuls dont les stats soient d'une certaine pertinence?)

Depuis quelques temps, j'ai réussi à choper des écrans pour peupler ma 2nde carte graphique (du bas de gamme, que j'avais soupçonné à tord d'être HS, et que je conservais donc, au cas ou).
Elles sont équipées de chipset NVidia (donc si on veut se retreindre au LL, faut se coltiner nouveau et son absence d'accélération matérielle pour la 3D).

Il m'est pour le moment impossible de faire reconnaître par i3 les écrans placés sur la 2nde carte graphique, et ce, même avec le pilote propriétaire (à noter qu'il s'agit d'une seconde instance de Xorg je pense) mais ils s'allument bien.

J'ai fait quelques expérimentations contre ma volonté avec Ubutun, et je me suis aperçu que ça fonctionne, en fonction du DE utilisé: gnome ou unity sont les seuls qui prennent en charge aisément une seconde carte graphique. Pourquoi, je n'en ai aucune fichue idée, honnêtement.
Autre point "amusant", sous Debian stable, xrandr ne repère même pas la 2nde carte, tandis que sous Ubuntu (la dernière mouture en date, me semble), selon le DE, il voit (gnome/unity), ou pas(xfce,kde,lxde), les écrans.

PS: squeeze est la old-stable (certes encore maintenue car promue au rang de LTS), pour rappel. Sauf raison précise, tu devrais peut-être songer à upgrader, quitte à faire une machine virtuelle (XEN par exemple) avec squeeze. Enfin bon, tu fais comme tu le sens.
PPS: quand je parle des DE d'Ubuntu, j'ai installé les différentes variantes séparément, il est très probable qu'il y ait une différence de paquets installés au delà du DE, mais vu le bordel que c'est dans cette distro, je n'ose creuser… près de 2000 paquets installés par défaut, ça me fait mal au cœur, surtout que les flags d'installation automatique ne sont pas placés correctement, voire pas du tout!