Le lundi 22 février 2021 à 14:20 +0100, BERTRAND Joël a écrit : > > > > > En plus, python est comme le php, > > > un truc polymorphe, procédural, objet... Qui permet donc de prendre > > > toutes les mauvaises habitudes rapidement. > > > > Heu… Cela fait plusieurs décennies qu’on a montré l’intérêt de > > toutes > > ces techniques de programmations pour réaliser des programmes complexes. > > Ben non, là encore, je ne suis pas d'accord. On simplifie le > développement au détriment des ressources utilisées. Ce qu'on faisait il > y a quarante ans avec un processeur 8 bits et 8 Ko de ROM demande > aujourd'hui pour les mêmes fonctionnalités un processeur 32 bits avec un > OS complet. Un bel exemple est le premier proto du linky sur lequel j'ai > eu l'occasion de bosser et qui embarquait un OS complet avec une JVM et > 4 Go de mémoire (pour rappel, c'est un truc qui fait du comptage et qui > traite onze contacts sur un réseau en treillis, vraiment de quoi avoir > besoin de 4Go de mémoire !). Complètement d'accord avec toi ! Androïd en est un exemple criant ! > > > Les gains apportés par ces techniques ont été maintes fois prouvés et il > > est important d’apprendre à bien les utiliser. Notamment, ces méthodes > > ont montré leur très grande efficacité à gérer des projets complexes > > avec des équipes importantes et des codes à la durée de vie très longue. > > Les programmes en assembleurs n’ont pas toutes ces importantes qualités. > > Entre le programme en assembleur (dont effectivement on s'accordera à > dire qu'il n'est pas portable) et la programmation objet, il y a tout un > tas de concepts comme la programmation procédurale. Je ne prétends pas > qu'il faut programmer en assembleur, mais qu'un passage en assembleur > est nécessaire pour bien savoir de quoi on parle. 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. 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. > > > Il faut se méfier, parce que le point de vue d’un électronicien est > > très valable, mais ce n’est pas un point de vue adapté à la programmation. > > > > > Je considère aussi que le passage initial par l'assembleur n'est > > > pas > > > idiot histoire de bien comprendre par la suite les subtilités des > > > adressages par exemple. > > > > 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. > > Sauf que sans le passage par la case assembleur, il est difficile de > comprendre comment fonctionne réellement le bazar. Donc on se retrouve > avec des gars qui font à peu près n'importe quoi. 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 ? Tout ce qu'il aura > retenu, c'est qu'il ne faut pas le faire sans jamais avoir réfléchi au truc. 100% d'accord. Gaëtan
Attachment:
signature.asc
Description: This is a digitally signed message part