[HS] Recherche Développeur pour interview

Salut Í  tous”¯!

Le 22/02/2021 Í  14:20, BERTRAND Joël a écrit :

C'est justement ce que je reproche. On fabrique aujourd'hui, ce qu'on
appelle dans l'électronique des "pousse-cartes". Des gens qui savent Í 
peu près bricoler mais qui ne maÍ®trisent plus grand'chose.

Encore une fois, le but du programme d’informatique au lycée est
d’enseigner la programmation, pas l’électronique. Ensuite, le lycée ne
peut pas former des ingénieurs électroniciens. Cette question n’est pas
pertinente vis-Í -vis du programme du lycée. Se tromper sur les objectifs
est le meilleur moyen de ne jamais les atteindre.

Ben non, lÍ  encore, je ne suis pas d'accord. On simplifie le
développement au détriment des ressources utilisées.

Il faudrait que tu définisses dans quel sens tu utilises le terme
«”¯simplifier”¯», parce que je ne le comprends pas.

La programmation objet, la programmation modulaire, etc., n’ont pas
pour objectif de simplifier la programmation. En revanche, ces approches
permettent de réaliser des choses qui ne sont pas possibles simplement
avec l’approche impérative. Également, cela permet de gérer des projets
bien plus complexes, tant dans le sens de la complexité des concepts
utilisés que de la structure des applications et de la taille des
équipes de développement.

Un bel exemple est le premier proto du linky

Je ne connais pas Linky, je ne peux pas parler.

Cela dit, alors qu’il est question de la programmation au lycée, tu
prends un exemple d’informatique embarquée : c’est très loin de l’objectif.

un passage en assembleur
est nécessaire pour bien savoir de quoi on parle.

En quoi l’assembleur est-il éclairant sur le fonctionnement d’une base
de données relationnelle”¯?

En quoi l’assembleur aide en quoi que ce soit Í  comprendre la
calculabilit锯?

En quoi l’assembleur aide en quoi que ce soit Í  comprendre le
fonctionnement d’un algorithme randomis锯?

En fait, pour avoir enseigné ces matières – qui ne sont pas de
l’électronique, encore une fois ne pas se tromper d’objectif – je
préfère même lorsque les étudiants n’ont pas vu la programmation
impérative, mais uniquement l’approche fonctionnelle, parce qu’en ayant
uniquement en tête l’approche impérative, ils ont plus de mal Í 
comprendre ces notions.

Ton expérience d’électronicien est extrêmement valable. En revanche,
elle ne peut pas être appliquée en dehors de son domaine, c’est se
tromper d’objectif.

Sauf que sans le passage par la case assembleur, il est difficile de
comprendre comment fonctionne réellement le bazar.

Pour ma part, je fais du calcul haute performance. Pour passer des
architectures vectorielles aux architectures superscalaires, pour
comprendre, j’ai essayé d’abord de coder en assembleur. Je n’arrivais Í 
rien. Finalement, j’ai pris de la hauteur et c’est en expérimentant avec
Fortran que j’ai vraiment compris ce qu’il se passait.

Ce n’est qu’une expérience personnelle, mais ça corrobore également mon
expérience d’enseignement. Mais, encore une fois, ce n’est pas une
expérience d’électronicien.

Je m’y connais beaucoup trop mal en électronique, si je fais quelque
chose un électronicien trouvera immédiatement que je fais n’importe quoi
et il aura raison. À l’inverse, il ne faut pas s’imaginer que parce
qu’on s’y connaÍ®t en électronique on s’y connaÍ®t en programmation.

Comment expliques-tu Í 
un étudiant qu'on ne renvoie pas une variable automatique en C si tu ne
lui a pas expliqué avant comment fonctionne la pile ?

Pour ma part, lorsque j’enseigne le C++, que donc j’enseigne avant C,
j’explique le fonctionnement de la pile. De ce que j’en sais, c’est
assez généralisé parmi mes collègues.

Le dernier, c'était un centralien. Tous mes stagiaires sont bac+4/5 en
école d'ingénieur (électronique et/ou informatique).

Bon, je n’ai jamais enseigné l’électronique, je ne peux pas me
prononcer Í  ce sujet.

Après, j’ai par exemple enseigné la programmation Í  l’École des ponts,
je confirme que ce n’est pas un cours d’électronique, ce n’est pas son
objectif. Si on prend en stage d’électronique un étudiant qui n’a pas
suivi d’enseignement d’électronique, en effet, il va y avoir un problème.

Mais, encore une fois, il ne faut pas confondre électronique et
programmation informatique.

Ben tiens.. L'arduino... Je reproche Í  l'Arduino exactement ce que je
reproche au développement informatique moderne.

En l’espèce, on parle bien de l’enseignement de l’électronique au
lycée, pas en école d’ingénieur. Encore une fois, on ne peut pas
poursuivre le même objectif avec des lycéens qu’avec des élèves
ingénieurs. Il est essentiel de ne pas se tromper d’objectif. En sortant
du lycée, on ne peut pas attendre qu’un lycéen soit capable de concevoir
un compteur Linky.

Je te laisse répondre que l'évolution de l'informatique va forcément
dans le bon sens

Je n’ai jamais dit ça, merci de ne pas déformer mon propos. Tout ce que
j’ai dit, c’est que l’informatique a évolué et qu’il faut prendre cette
évolution en compte.

À bientÍ´t.

--
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

--=-vU0vxXN+aPBNoFTFdbd9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lundi 22 f̓©vrier 2021 ̓  13:49 +0100, Yoann LE BARS a ̓©crit͂ :

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Apprendre lÍ¢€™assembleur est une bonne chose pour un ̓©lectronicien. En
revanche, il est fortement ̓  d̓©conseiller d̓©sormais pour un
informaticien qui ne fait pas de syst̓¨me : les processeurs sont
d̓©sormais et depuis longtemps superscalaires et multicÅ“urs et, avec de
telles architectures, un programme en assembleur sera inefficace tant en
termes de performances que dÍ¢€™usage des ressources

C'est oublier que beaucoup de syst̓¨mes de build utilis̓©s pour faire ces
logiciels complexes g̓©n̓¨rent de l'assembleur ̓  un moment ...
L'assembleur n'est donc pas inefficace c'est juste que faire la m̓ªme chose
prend trop de temps et ne serait pas ̓  la port̓©e de beaucoup de monde.

Ga̓«tan

--=-vU0vxXN+aPBNoFTFdbd9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEd7zcTjS9jiJYzB4MTEjQapSg6ZkFAmAzwzYACgkQTEjQapSg
6Zl30Qf8CqlCIIrIajAOEqUCjX6vhjsMAPICVihvpMbbLWj2dURxEzt7hcq8IS9K
LmsK2Q8gkzxxCptt09+Mo74lZ8/hyyreOxcmm9eodGDulumz09xL1lgxckzVRsKi
e4mv89tgTWxsKg8p46eBTIemyetNCWiSh8WXJ0WLccK8xFY2/BHtGneVY5uMwr4x
W9DPsZD8VrR0b0WRfZ1hUirR3TpMSWMKkY8Ya10wJQ63Ui3RclaMfuWOq+cs0/Qk
uVRy+GL++tMYPgEtM1nzcuYSJ9sDlOqLkKC+l03FtpEoopOKzj7/+IrKQoFX8bR/
zO47hjsgom+T+IQqCY+6gEE80g1wSw=v7
-----END PGP SIGNATURE-----

--=-vU0vxXN+aPBNoFTFdbd9--

Salut Í  tous”¯!

Le 22/02/2021 Í  15:44, Gaëtan PERRIER a écrit :

C'est oublier que beaucoup de systèmes de build utilisés pour faire ces
logiciels complexes génèrent de l'assembleur Í  un moment ...
L'assembleur n'est donc pas inefficace c'est juste que faire la même chose
prend trop de temps et ne serait pas Í  la portée de beaucoup de monde.

D’expérience, je pense que cette assertion est fausse, dans le sens que
les choses sont plus complexes.

Alors, oui, un compilateur transforme un code en langage machine, mais
ce n’est pas la même chose que de développer en assembleur. Il n’y a pas
une simple table d’équivalence entre le code et l’exécutable généré.

En particulier, sur les architectures superscalaires, il y a quantité
d’optimisations que peuvent réaliser les compilateurs qui ne sont pas Í 
la portée d’un programmeur humain – pas Í  la portée de peu de monde, Í 
la portée de personne.

Quelques exemples, tirés du calcul Í  hautes performances (mon domaine),
o͹ les temps de calculs sont un problème essentiel.

Dans les boucles, il est préférable de s’interroger sur l’utilisation
du pipeline. Même si de base les processeurs ont des mécanismes de
prévision des boucles, en réorganisant une boucle on peut gagner
quelques cycles. Il n’y a pas vraiment de règle générale, c’est plutÍ´t
une approche stochastique qui permet de déterminer au mieux comment les
réorganiser.

Toujours au sujet des boucles, il est bienvenu de les dérouler. La
profondeur optimale de déroulement n’est de même pas une question de
règle générale, encore une fois ça s’approche stochastiquement.

Organiser les données dans le bus permet également pas mal de gain. Ça,
outre qu’il faut passer du temps pour le faire Í  la main, ça a tendance
Í  rendre les programmes moins lisibles.

Il y a encore plein de méthodes Í  appliquer, qui pour atteindre
l’optimum, Í  la main, nécessite énormément de temps, d’essais, mais
aussi rendent les codes peu compréhensible, donc difficile Í  maintenir
et augmente grandement le nombre d’erreurs.

Par ailleurs, faire ça Í  la main se fait au détriment de la
structuration du code, donc limite la complexité des tÍ¢ches que pourra
réaliser le code – typiquement, du calcul parallèle auto-adaptatif.

À bientÍ´t.

--
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

Salut Í  tous”¯!

Le 22/02/2021 Í  15:54, Gaëtan PERRIER a écrit :

Ne pas perdre de vue qu'un langage évolué est juste un outil qui va simplifier
plus ou moins certaines choses mais aussi en rendre plus complexes d'autres et
que tout va de toute façon se terminer en une série d'opcodes digérés par les
CPU et assimilés.

Je n’ai jamais dit le contraire.

Et il ne faut pas restreindre certains langages Í  un type de programmation.
Rien n'empêche de faire de l'objet en C par ex.

Encore une fois, je n’ai pas dit le contraire.

Cela dit, encore une fois les nombreuses tentatives montrent qu’il n’y
a pas de langage parfait pour tout. Par exemple, on peut s’amuser Í 
faire des fonctions de l’ordre supérieur en C, mais ce sera très
illisible et peu efficace parce que le compilateur n’est pas adapté Í  ça.

À bientÍ´t.

--
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

--=-KoxI5NTL9rH4+aWjHaGf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lundi 22 f̓©vrier 2021 ̓  15:58 +0100, Yoann LE BARS a ̓©crit͂ :

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Salut ̓  tousÍ¢€¯!

Le 22/02/2021 ̓  15:44, Ga̓«tan PERRIER a ̓©crit͂ :
> C'est oublier que beaucoup de syst̓¨mes de build utilis̓©s pour faire ces
> logiciels complexes g̓©n̓¨rent de l'assembleur ̓  un moment ...
> L'assembleur n'est donc pas inefficace c'est juste que faire la m̓ªme chose
> prend trop de temps et ne serait pas ̓  la port̓©e de beaucoup de monde.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ DÍ¢€™exp̓©rience, je pense que cette assertion est fausse, dans le sens
que
les choses sont plus complexes.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Alors, oui, un compilateur transforme un code en langage machine,
mais
ce nÍ¢€™est pas la m̓ªme chose que de d̓©velopper en assembleur. Il nÍ¢€™y a pas
une simple table dÍ¢€™Íƒ©quivalence entre le code et lÍ¢€™ex̓©cutable g̓©n̓©r̓©.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ En particulier, sur les architectures superscalaires, il y a quantit̓©
dÍ¢€™optimisations que peuvent r̓©aliser les compilateurs qui ne sont pas ̓ 
la port̓©e dÍ¢€™un programmeur humain Í¢€“ pas ̓  la port̓©e de peu de monde, ̓ 
la port̓©e de personne.

Il y a aussi des cas o̓¹ le compilo ne fait pas une optim qui vu d'un humain est
pourtant ̓©vidente ... Mais ok c'est assez rare.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Quelques exemples, tir̓©s du calcul ̓  hautes performances (mon
domaine),
o̓¹ les temps de calculs sont un probl̓¨me essentiel.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Dans les boucles, il est pr̓©f̓©rable de sÍ¢€™interroger sur lÍ¢€™utilisation
du pipeline. M̓ªme si de base les processeurs ont des m̓©canismes de
pr̓©vision des boucles, en r̓©organisant une boucle on peut gagner
quelques cycles. Il nÍ¢€™y a pas vraiment de r̓¨gle g̓©n̓©rale, cÍ¢€™est plut̓´t
une approche stochastique qui permet de d̓©terminer au mieux comment les
r̓©organiser.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Toujours au sujet des boucles, il est bienvenu de les d̓©rouler. La
profondeur optimale de d̓©roulement nÍ¢€™est de m̓ªme pas une question de
r̓¨gle g̓©n̓©rale, encore une fois ̓§a sÍ¢€™approche stochastiquement.

Le d̓©roulement d'une boucle n'est pas toujours opportun. L'architecture
hardware derri̓¨re compte ̓©norm̓©ment pour savoir si il y aura gain. Il faut
surtout commencer par construire la boucle correctement. Avec beaucoup d'archi
il faut d̓©compter pour comparer ̓  z̓©ro, ̓§a r̓©duit fortement l'overhead du
bouclage, surtout sur les petites boucles. Faut se m̓©fier aussi avec le cache.
Si la mise ̓  plat provoque un chargement du cache bien souvent t'es perdant.

Mais maintenant de plus en plus de compilo savent d̓©rouler une boucle par eux
m̓ªme quand tu demandes une optim en vitesse. ̓‡a ̓©vite de faire un code qui
deviendra non portable si tu fais le d̓©roulement dans le code lui-m̓ªme.

͂ ͂ ͂ ͂ ͂ ͂ ͂ ͂ Organiser les donn̓©es dans le bus permet ̓©galement pas mal de gain.
̓‡a,
outre quÍ¢€™il faut passer du temps pour le faire ̓  la main, ̓§a a tendance
̓  rendre les programmes moins lisibles.

Non pas obligatoirement. Tu as des choses que tu peux faire par "calcul" plut̓´t
que par du if ... then ... comme ̓§a tu n'as de vidange du pipeline dans un des
2 cas. Etc.

Mais pour ̓§a faut avoir un minimum conscience de comment fonctionne ce qui est
en dessous ...


Ga̓«tan

--=-KoxI5NTL9rH4+aWjHaGf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEd7zcTjS9jiJYzB4MTEjQapSg6ZkFAmAz0vsACgkQTEjQapSg
6Zl6rAgAssXCuXhLtzz84IqhXHpsu3x7Bwv/XTKhCEJXz2xc4xkHveKVPK+Klbzo
Rbn6L1N17sHy1PuAlgpvVYIWPN6y7DAs9hN8K/Noe72WP+cLudyXpWDwHA3+8och
WwLxNntHB6tw18hQ33SejJmlGDwS4Fg9I7GoXmTQePw5Si513eV4+IRwTW8mTmds
f+dCNwQdaSTVrnH3MTpTppmeIffEzkEmNB/AxAoIfuYA9eU2siSFm+IGqvjgzwI4
DjW6SPXKvGSS3nnbdiMxctqFpze70KeWcs69tsPdeGuja/CPU6yXXcWl8qx5oQK/
lzRgrzKPqX7UV50KsnxpeAE+WJWvrA==MNQ1
-----END PGP SIGNATURE-----

--=-KoxI5NTL9rH4+aWjHaGf--

Salut Í  tous”¯!

Le 22/02/2021 Í  16:51, Gaëtan PERRIER a écrit :

Il y a aussi des cas o͹ le compilo ne fait pas une optim qui vu d'un humain est
pourtant évidente ... Mais ok c'est assez rare.

Oui, de plus en plus rare. Tellement rare que de toute façon un
compilateur bien utilisé produit désormais de toute façon un code bien
plus efficace qu’un code réalisé immédiatement en assembleur.

Le déroulement d'une boucle n'est pas toujours opportun. L'architecture
hardware derrière compte énormément pour savoir si il y aura gain.

Oui, c’est ce que je disais : ça dépend totalement du contexte. Je n’ai
donné que quelques exemples pour lesquels je n’ai pas donné de détail,
mais il y en a plein d’autres. À chaque fois, alors, oui, ça dépend du
contexte, du matériel, de ci, de ça. C’est exactement ce que je dis : Í 
chaque fois, il n’y a rien de systématique, ça s’approche stochastiquement.

Donc, c’est bien ce que je dis : les optimisations, ce ne sont que des
cas particuliers, dans tous les sens. Tellement que, sur un projet
complexe, les optimisations Í  la main sont vouées Í  l’échec.

Donc, nous sommes bien d’accord : ça dépend complètement du contexte.

Mais maintenant de plus en plus de compilo savent dérouler une boucle par eux
même quand tu demandes une optim en vitesse. Ça évite de faire un code qui
deviendra non portable si tu fais le déroulement dans le code lui-même.

Oui, c’est très exactement ce que je disais…

Non pas obligatoirement. Tu as des choses que tu peux faire par "calcul" plutÍ´t
que par du if ... then ... comme ça tu n'as de vidange du pipeline dans un des
2 cas. Etc.

Oui, c’est ce que je dis : ça dépend du contexte, ça n’est jamais
systématique.

Mais pour ça faut avoir un minimum conscience de comment fonctionne ce qui est
en dessous ...

Dans la plupart des cas, savoir intimement comment fonctionne un
processeur n’apporte aucune information pour savoir comment améliorer
son code. Par exemple, ça ne sert Í  rien dans un système Í  réseau de
neurones, dans des codes de simulations numériques, dans la gestion de
base de données, etc. Comme dit, comme tu l’as confirmé, dans ces cas-lÍ 
l’optimisation machine n’est pas accessible Í  un être humain.

Dans la majorité des cas, ce qu’il faut, c’est bien réfléchir Í  ses
algorithmes et Í  ses structures de données, réaliser un code propre,
lisible et documenté, par ailleurs ne surtout pas faire d’optimisation Í 
la main. DéjÍ , parce que dans ce cas, le compilateur ne pourra plus
appliquer ses algorithmes d’optimisations, alors que le compilateur est
bien plus efficace qu’un être humain Í  cette tÍ¢che. Ensuite, parce que
ces optimisations augmentent statistiquement le nombre de bogues. Enfin,
parce qu’un code a une durée de vie très supérieure Í  la durée des
machines qui les exécutent et les optimisations ne seront plus les mêmes
et l’équipe qui maintiendra le code ne sera plus la même que celle qui a
initié le projet.

En revanche, il faut apprendre Í  utiliser son compilateur, l’architecte
du programme doit prendre le temps de bien le configurer. Ce qui n’est
pas une question d’électronicien.

Donc, dans la majorité des cas, il est faux de dire que pour réaliser
un bon code il faut savoir comment fonctionne le processeur. Au
contraire, Í  vouloir trop coller Í  un processeur particulier, on se
lance dans des optimisations vaines et qui vont dégrader le code.

Bien entendu, ça ne veut pas dire qu’il ne faut pas connaÍ®tre le
fonctionnement d’un ordinateur dans les grandes lignes, simplement que
la connaissance intime n’est en rien un plus dans ces applications.

En revanche, il est vrai qu’il y a des domaines bien déterminés o͹ il
faut connaÍ®tre intimement l’architecture, par exemple : la programmation
système, la réalisation de compilateurs, l’embarqué. En revanche, dans
ces cas-lÍ , la connaissance de l’algorithmique est essentielle également.

Maintenant, le point de départ était le programme d’enseignement de la
programmation au lycée. Clairement, Í  ce niveau, la question est de les
préparer Í  aborder le plus large panel de situations qui peuvent se
présenter en informatique. Du coup, clairement, le plus important est
que les élèves aient une première approche de l’algorithmique. Dans ce
cadre, l’assembleur, qui oblige de se concentrer sur le matériel et avec
lequel il est beaucoup plus difficile de mettre en évidence les
algorithmes, est contre-productif, en plus de rebuter la majorité des
élèves. Python, au contraire, qui permet une première approche de
l’algorithmique et justement oblige Í  réaliser un code indenté donc mis
en forme, remplit vraiment très bien cet objectif.

À bientÍ´t.

--
Yoann LE BARS
https://le-bars.net/yoann/
Diaspora* : ylebars@framasphere.org

Le 22/02/2021 Í  17:35, X a écrit :

[...]

Dans vos élucubrations vous pensez Í  la jeune fille qui attend son
interview ?

--
Daniel

This is a multipart message in MIME format.

------=_NextPart_000_09B8_01D70953.DAC1D2B0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,



Merci Daniel dÍ¢€™avoir remis les pendules ̓  lÍ¢€™heure.

Je ne suis pas de toute premi̓¨re jeunesse (70 ans bient̓´t), mais j'ai le profil a priori:

* Mes formations initiales (li̓©es ̓  mon ̓¢geÍ¢€¦) Fortran, Cobol, Algol, Pascal, assembleurs divers et vari̓©s
* Formation puis utilisation de C et C++ d̓¨s sa cr̓©ation pour des projets dÍ¢€™informatique industrielle (̓  lÍ¢€™Íƒ©poque) et de gestion (aujourdÍ¢€™hui).
* Mes utilisations r̓©centes de C et C++ : un projet dÍ¢€™authentification (et non pas identification) via le r̓©seau veineux (mains, mais aussi pieds pour les nouveaux n̓©s) et, en cours, des d̓©veloppements pour lÍ¢€™automatisation de fermes aquaponiques.
* Vous avez parl̓© de Python, je lÍ¢€™ai utilis̓© mais ne suis pas expert.



Donc je r̓©pondrai volontiers aux questions de Morgane si elle le souhaite. Comme je ne suis pas toujours devant mon ̓©cran, jÍ¢€™ai mis mon num̓©ro de t̓©l̓©phone.



Bien cordialement,



Mathieu ROSSI

T̓©l. 06 80 95 66 82



-----Message d'origine-----
De : NoSpam <no-spam@tootai.net>
Envoy̓© : lundi 22 f̓©vrier 2021 19:23
̓€ : debian-user-french@lists.debian.org
Objet : Re: [HS x 2] Recherche D̓©veloppeur pour interview





Le 22/02/2021 ̓  17:35, X a ̓©crit :

[...]

Dans vos ̓©lucubrations vous pensez ̓  la jeune fille qui attend son interview ?



--

Daniel




------=_NextPart_000_09B8_01D70953.DAC1D2B0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Texte brut Car";
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
span.TextebrutCar
{mso-style-name:"Texte brut Car";
mso-style-priority:99;
mso-style-link:"Texte brut";
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1643735723;
mso-list-type:hybrid;
mso-list-template-ids:68481730 67895297 67895299 67895301 67895297 67895299 67895301 67895297 67895299 67895301;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:ͯ‚·;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:ͯ‚§;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:ͯ‚·;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:ͯ‚§;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:ͯ‚·;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:ͯ‚§;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoPlainText>Bonjour,<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Merci Daniel dÍ¢€™avoir remis les pendules ̓  lÍ¢€™heure.<o:p></o:p></p><p class=MsoPlainText>Je ne suis pas de toute premi̓¨re jeunesse (70 ans bient̓´t), mais j'ai le profil a priori:<o:p></o:p></p><ul style='margin-top:0cm' type=disc><li class=MsoPlainText style='mso-list:l0 level1 lfo1'>Mes formations initiales (li̓©es ̓  mon ̓¢geÍ¢€¦) Fortran, Cobol, Algol, Pascal, assembleurs divers et vari̓©s<o:p></o:p></li><li class=MsoPlainText style='mso-list:l0 level1 lfo1'>Formation puis utilisation de C et C++ d̓¨s sa cr̓©ation pour des projets dÍ¢€™informatique industrielle (̓  lÍ¢€™Íƒ©poque) et de gestion (aujourdÍ¢€™hui).<o:p></o:p></li><li class=MsoPlainText style='mso-list:l0 level1 lfo1'>Mes utilisations r̓©centes de C et C++&nbsp;: un projet dÍ¢€™authentification (et non pas identification) via le r̓©seau veineux (mains, mais aussi pieds pour les nouveaux n̓©s) et, en cours, des d̓©veloppements pour lÍ¢€™automatisation de fermes aquaponiques.<o:p></o:p></li><li class=MsoPlainText style='mso-list:l0 level1 lfo1'>Vous avez parl̓© de Python, je lÍ¢€™ai utilis̓© mais ne suis pas expert.<o:p></o:p></li></ul><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Donc je r̓©pondrai volontiers aux questions de Morgane si elle le souhaite. Comme je ne suis pas toujours devant mon ̓©cran, jÍ¢€™ai mis mon num̓©ro de t̓©l̓©phone.<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Bien cordialement,<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Mathieu ROSSI<o:p></o:p></p><p class=MsoPlainText>T̓©l. 06 80 95 66 82<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText><span style='mso-fareast-language:FR'>-----Message d'origine-----<br>De&nbsp;: NoSpam &lt;no-spam@tootai.net&gt; <br>Envoy̓©&nbsp;: lundi 22 f̓©vrier 2021 19:23<br>̓€&nbsp;: debian-user-french@lists.debian.org<br>Objet&nbsp;: Re: [HS x 2] Recherche D̓©veloppeur pour interview</span></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Le 22/02/2021 ̓  17:35, X a ̓©crit&nbsp;:<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText> &gt; [...]<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Dans vos ̓©lucubrations vous pensez ̓  la jeune fille qui attend son interview ?<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>--<o:p></o:p></p><p class=MsoPlainText>Daniel<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_000_09B8_01D70953.DAC1D2B0--

Salut la liste !

Donc je répondrai volontiers aux questions de Morgane si elle le souhaite. Comme je ne suis pas toujours devant mon écran, j’ai mis mon numéro de téléphone.

De mon cÍ´té aussi, j'ai relayé l'appel auprès d'un copain développeur en C, C++ et autres langages,
qui a répondu positivement ce matin. Morgane aura donc la possibilité de mener 2 entretiens pour le
prix d'un… et d'apprécier l'écho que renvoie Debian User French !

Bonne soirée,

Ph. Gras

On 2/22/21 5:35 PM, Yoann LE BARS wrote:

Salut Í  tous”¯!

Le 22/02/2021 Í  16:51, Gaëtan PERRIER a écrit :

Il y a aussi des cas o͹ le compilo ne fait pas une optim qui vu d'un humain est
pourtant évidente ... Mais ok c'est assez rare.

Oui, de plus en plus rare. Tellement rare que de toute façon un
compilateur bien utilisé produit désormais de toute façon un code bien
plus efficace qu’un code réalisé immédiatement en assembleur.

Quand un développe avec un langage efficace (C ou C++), il n'y a aucune
raison a priori d'utiliser l'assembleur.

Ce n'est que a posteriori si on constate un besoin d’accélérer une
portion de code que l'on pourra utiliser un passage en asm...

Ceci était vrai il y a 40 ans, et l'est peut-être un peu encore avec des
raspberry pi, mais cela ne m'est plus arrivé ce siècle-ci...

En 1973, on s'interrogeait pour savoir s'il fallait acheter un
ordinateur professionnel (HP2100) avec 16k de mémoire ou 24k...