Discussion :

[moldavi]

Bonjour.

Je conseillerais évidemment l'assembleur pour le côté machine, le langage C pour sa rigueur, et le C++ pour l'approche objet.

Le problème principal que je vois avec les développeurs que je côtoie, ce n'est pas la maîtrise du langage, mais l'habilité à architecturer du code.


Ecrire 20 lignes de code dans n'importe quel langage, tout le monde sait faire, suffit de faire un tour sur stackoverflow (et encore, faut bien choisir...).

Ecrire 1 Million de ligne de code bien organisée, architecturée, maintenable, et là il n'y a plus grand monde.

Mais pour y arriver, il faut des expériences sur des langages avec rigueur, et sur des langages objets.

[Uther]

Pour le coup le C est certainement le dernier des langages que je conseillerais pour apprendre la rigueur, avec JavaScript. Pour ça, il y a des langages bien plus adaptés comme Rust ou Ada.

Et pour apprendre l'objet, le C++ ne serait certainement mon premier choix non plus, sauf peut-être pour des personnes qui maitrisent déjà très bien le C. Le C++ c'est une base de C sur lequel on a empilé, plus ou moins bien, pas mal de nouveaux concepts, dont l'objet. Ça en fait un langage très complet, mais aussi très complexe, et pas facile à bien utiliser. Des langages comme Java ou C# sont pensés de base pour l'objet et bien plus facilement approchables.

[Mat.M]

Ce que je trouve dommage en c, c'est qu'ils n'aient pas normalisé les types modernes, comme les tables de hash, divers containers, listes etc., qui du coup se retrouvent
implémentées de nombreuses fois de manière différente, ou enrichi les lib standard.

je comprends pas ce message: les conteneurs ça existe en C++ non ?
Après c'est certain qu'avec fichier avec extension .c on peut pas utiliser les conteneurs du C++.

[Uther]

En effet, il parlait clairement du C pas du C++.

[Jacti]

Je conseillerais évidemment l'assembleur pour le côté machine, le langage C pour sa rigueur, et le C++ pour l'approche objet.

L'assembleur est à bannir sauf dans des cas bien particuliers. Dans ma carrière de 40a d'ingénieur informaticien j'ai écrit environ 200 lignes d'assembleur et pourtant je faisais des programmes proches de la machine : compilateurs, systèmes d'armes, satellites de télécom, etc.
S'il y a bien un langage qui n'est pas rigoureux c'est le langage C. Je connais la norme ANSI presque par cœur car j'ai eu la chance de superviser le développement d'un compilateur C depuis la feuille blanche. C'est un langage faiblement typé ce qui n'est plus recommandé aujourd'hui. On peut faire à peu près n'importe quoi avec les pointeurs, etc.
Je ne recommande pas C++ pour apprendre la programmation objet car c'est un langage bien trop compliqué pour un débutant en objet. De plus, ce n'est pas un "vrai" langage objet. Je le qualifierais plutôt de langage de pointeurs... Pour apprendre la programmation objet, je recommande Java.

[moldavi]

Bonjour.

L'assembleur est à bannir sauf dans des cas bien particuliers. Dans ma carrière de 40a d'ingénieur informaticien j'ai écrit environ 200 lignes d'assembleur et pourtant je faisais des programmes proches de la machine : compilateurs, systèmes d'armes, satellites de télécom, etc.
S'il y a bien un langage qui n'est pas rigoureux c'est le langage C. Je connais la norme ANSI presque par cœur car j'ai eu la chance de superviser le développement d'un compilateur C depuis la feuille blanche. C'est un langage faiblement typé ce qui n'est plus recommandé aujourd'hui. On peut faire à peu près n'importe quoi avec les pointeurs, etc.
Je ne recommande pas C++ pour apprendre la programmation objet car c'est un langage bien trop compliqué pour un débutant en objet. De plus, ce n'est pas un "vrai" langage objet. Je le qualifierais plutôt de langage de pointeurs... Pour apprendre la programmation objet, je recommande Java.

La différence entre toi et moi, c'est que toi tu es bouffi de certitude sans démonstration, alors que moi je ne fais que des préconisations. Dans mon message je ne donne que des conseils ouverts à la discussion. Toi tu donnes des certitudes sans t'expliquer, comme si tu avais la science infuse (nous savons tous que tu n'es pas un gourou de l'informatique). Et au vu de ton message, j'ai compris que tu étais un gland bouffi de certitude qui n'explique rien. Dans tous les cas, tes certitudes sans démonstration ne m'ont pas convaincu.

Si tu es intelligent, tu remarqueras que mon message commence par "Je conseillerais". La différence entre toi et moi, c'est que moi je conseille, et toi tu affirmes, sans démontrer... tu es un gland.

Peut-être qu'avec tes 40 ans d'expérience, tu vas me surprendre. J'attends le développement de tes certitudes pour m'incliner...

PS : j'ai rigolé pour les 200 lignes d'assembleur écrites en 40 ans d'expérience.

PS2 : j'ai répondu, mais je pense que tu es un troll. Si tu n'es pas un troll, c'est que tu es vraiment un gland.

[Fagus]

je comprends pas ce message: les conteneurs ça existe en C++ non ?
Après c'est certain qu'avec fichier avec extension .c on peut pas utiliser les conteneurs du C++.

Oui, peut être que les mainteneurs du langage considèrent que ce n'est pas la peine d'ajouter de standardiser des évolutions significatives qui existent déjà en c++ . Après tout, même si ça se mélange ±, les compilateurs normaux sont les mêmes...

[Uther]

PS2 : j'ai répondu, mais je pense que tu es un troll. Si tu n'es pas un troll, c'est que tu es vraiment un gland.

Va prendre ton Xanax, respire un coup, ça va bien se passer. Ce que dit Jacti n'était pas une agression, et en tout cas ne méritait pas ce genre de réponse. Ce qu'il dit correspond à quelque chose de bien reconnu qui ne me semblait pas nécessiter forcément des énormes justifications, mais si tu en veux pas de problème.

L'assembleur est certes utile à connaitre, ne serai ce qu'en surface, pour avoir une bonne compréhension du fonctionnement bas niveau quand on atteint un niveau assez avancé. Mais pour une première approche il est clairement trop orienté machine. L'abstraction fournie par les langages de plus haut niveau simplifie la découverte de l’algorithmie.
De nos jours, quasiment plus personne ne programme une application substantielle en assembleur de A à Z. L'assembleur reste un outil utile à connaitre pour ce qui est des usages avancés comme la rétro-ingénierie, la micro-optimisation, l'analyse du comportement d'un compilateur, ... mais de fait, de nos jours, ce n'est absolument pas un langage conseillé pour une introduction à la programmation.

PS : j'ai rigolé pour les 200 lignes d'assembleur écrites en 40 ans d'expérience.

Ça n'a pourtant rien de drôle. Dans ma carrière, j'ai eu régulièrement a lire de l'assembleur pour comprendre comment optimisait le compilateur, et j'ai occasionnellement utilisé quelques lignes de "inline assembly" pour des micro-optimisation, mais je n'en ai clairement jamais développé un programme complet en assembleur depuis que j'ai fini mes études. La majorité des informaticiens feront carrière sans problème sans jamais avoir à y toucher. L'assembleur est certes utile a connaitre, mais clairement pas indispensable pour la grande majorité des développeurs surtout ceux qui ne s'orientent pas vers le bas niveau.

[Jacti]

Peut-être qu'avec tes 40 ans d'expérience, tu vas me surprendre. J'attends le développement de tes certitudes pour m'incliner...

PS : j'ai rigolé pour les 200 lignes d'assembleur écrites en 40 ans d'expérience.

PS2 : j'ai répondu, mais je pense que tu es un troll. Si tu n'es pas un troll, c'est que tu es vraiment un gland.

Tu me reproches de ne donner que des certitudes (déjà, là, la phrase n’est pas en bon français. On ne « donne pas des certitudes » mais on les assène) mais tu auras remarqué que je dis pourquoi le langage C est exempt de rigueur : faible typage et manipulation de pointeur laxiste, entre autres.
Pour C++ c’est pareil : trop compliqué pour un débutant en objet. Ce n’est pas un vrai langage objet car il ne contraint pas à « faire de l’objet » . On peut écrire en C++ comme en C, sans faire de l’objet contrairement à Java où toute fonction doit être dans une classe.
Quant à l’assembleur, je ne vois pas pourquoi mes 200 lignes d’assembleur te font rigoler car c’était juste pour montrer qu’apprendre l’assembleur aujourd’hui n’est pas du tout indispensable. Ce qui est essentiel, par contre, et qui ne se fait plus dans les cursus informatique c’est un vrai cours d’architecture machine et système : la notion de ring, la segmentation, le tas (heap), les machines RISK, l’overlay, les GPU, les sémaphores, etc.
Enfin je n’aime pas beaucoup (c’est un euphémisme) ta façon de me parler en me traitant « de gland » ce qui montre que tu es un malotru et ce qui n’encourage pas à une discussion ouverte comme tu sembles le préconiser. Sache, de plus, qu’en 40 ans d’expérience j’ai effectivement acquis un certain nombre de certitudes car, outre le développement, j’ai aussi participé à l’élaboration de nombres de cursus informatique via des comités de programmes dans des grandes écoles, des organismes de formation et que j’ai enseigné nombre de langages de programmation comme C, C++, Java, Lisp, Prolog, ADA, Pascal ainsi que la conception objet dès les années 80.
Merci de revoir ton style d’écriture car « bouffi de certitudes » n’est pas des plus convivial pour amorcer une discussion.
Il semble plutôt que tu ne supporte pas la contradiction et j’ai voulu effectivement te montrer que les langages que tu as chois ne sont pas les meilleurs pour apprendre la programmation.
D’ailleurs pour apprendre la programmation, il est préférable de commencer par «écrire des algorithmes en pseudocode et de les appliquer ensuite à tel ou tel langage. D’ailleurs, en parallèle de la pure programmation, il est essentiel d’apprendre à mesurer la complexité algorithmique et de ne pas vouloir écrire du code optimisé dès le premier jet.
Enfin, dans le développement, ce n’est pas la partie programmation la plus important mais la partie conception globale et détaillée et là, on ne trouve pas grand monde de compétent… hélas.

[TJ1985]

Bonjour.



La différence entre toi et moi, c'est que toi tu es bouffi de certitude sans démonstration, alors que moi je ne fais que des préconisations. Dans mon message je ne donne que des conseils ouverts à la discussion. Toi tu donnes des certitudes sans t'expliquer, comme si tu avais la science infuse (nous savons tous que tu n'es pas un gourou de l'informatique). Et au vu de ton message, j'ai compris que tu étais un gland bouffi de certitude qui n'explique rien. Dans tous les cas, tes certitudes sans démonstration ne m'ont pas convaincu.

Si tu es intelligent, tu remarqueras que mon message commence par "Je conseillerais". La différence entre toi et moi, c'est que moi je conseille, et toi tu affirmes, sans démontrer... tu es un gland.

Peut-être qu'avec tes 40 ans d'expérience, tu vas me surprendre. J'attends le développement de tes certitudes pour m'incliner...

PS : j'ai rigolé pour les 200 lignes d'assembleur écrites en 40 ans d'expérience.

PS2 : j'ai répondu, mais je pense que tu es un troll. Si tu n'es pas un troll, c'est que tu es vraiment un gland.

Si vous voulez apprendre la programmation, fuyez ce type de personnage, ils ne vous apprendront jamais rien d'exploitable. Ou plus probablement, ils vous dégoûteront par crainte de la concurrence si vous êtes doué.

[moldavi]

Bonjour.

Si vous voulez apprendre la programmation, fuyez ce type de personnage, ils ne vous apprendront jamais rien d'exploitable. Ou plus probablement, ils vous dégoûteront par crainte de la concurrence si vous êtes doué.

C'est de bonne guerre.

Tu fais de l'open source ? Je voudrais voir ta façon de coder, histoire de me faire une idée de tes compétences.

On ne sait jamais, tu vas peut-être m'éblouir avec ton code.

Va prendre ton Xanax, respire un coup, ça va bien se passer. Ce que dit Jacti n'était pas une agression, et en tout cas ne méritait pas ce genre de réponse.

Si tu veux comprendre ma réaction, c'est que sur ce site, depuis 2003, j'en ai eu pas mal de confrontation avec des développeurs bouffis de certitude sans démonstration. Nous tous, développeurs, sommes d'ailleurs confrontés à ces certitudes. Je pense y avoir échappé, mais j'ai certainement eu une période équivalente. A un moment, des développeurs pensent avoir la science infuse. Ce n'est parce qu'un jour tu as fait un truc génial en développement, que tu es le dieu du développement.

Ce qu'il dit correspond à quelque chose de bien reconnu qui ne me semblait pas nécessiter forcément des énormes justifications, mais si tu en veux pas de problème.

C'est tellement bien reconnu , que depuis 2003 que je suis sur ce site, je ne sais même pas de quoi tu parles. Peut-être une démonstration ?

L'assembleur est certes utile à connaitre, ne serai ce qu'en surface, pour avoir une bonne compréhension du fonctionnement bas niveau quand on atteint un niveau assez avancé. Mais pour une première approche il est clairement trop orienté machine. L'abstraction fournie par les langages de plus haut niveau simplifie la découverte de l’algorithmie.
De nos jours, quasiment plus personne ne programme une application substantielle en assembleur de A à Z. L'assembleur reste un outil utile à connaitre pour ce qui est des usages avancés comme la rétro-ingénierie, la micro-optimisation, l'analyse du comportement d'un compilateur, ... mais de fait, de nos jours, ce n'est absolument pas un langage conseillé pour une introduction à la programmation.

La compréhension du fonctionnement de la machine est indispensable. Qui va développer les moteurs, qui nécessite des connaissances bas niveau, si tout le monde n'apprends que du haut niveau ?

Ça n'a pourtant rien de drôle. Dans ma carrière, j'ai eu régulièrement a lire de l'assembleur pour comprendre comment optimisait le compilateur, et j'ai occasionnellement utilisé quelques lignes de "inline assembly" pour des micro-optimisation, mais je n'en ai clairement jamais développé un programme complet en assembleur depuis que j'ai fini mes études. La majorité des informaticiens feront carrière sans problème sans jamais avoir à y toucher. L'assembleur est certes utile a connaitre, mais clairement pas indispensable pour la grande majorité des développeurs surtout ceux qui ne s'orientent pas vers le bas niveau.

A un moment, il faut former des développeurs compétents, cela veut dire du bas niveau, pour que des développeurs qui n'y comprennent rien, et qui ne font pas du bas niveau, comme tu le suggères, puissent écrire des programmes potables.

Donc en gros, pour que des nuls en programmation puissent écrire des programmes en Java, il faut quand même des mecs qui comprennent l'assembleur pour écrire le moteur de Java.

Tu me reproches de ne donner que des certitudes (déjà, là, la phrase n’est pas en bon français. On ne « donne pas des certitudes » mais on les assène)

Oui, c'est vrai. Ce n'est pas du bon français.

Mais du coup, je me suis posé la question. Est-ce que que j'ai affaire à un génie du langage qui maîtrise le français et les langages de programmation, au même niveau ?

mais tu auras remarqué que je dis pourquoi le langage C est exempt de rigueur : faible typage et manipulation de pointeur laxiste, entre autres.

Je suis désolé, mais quand un gland me dit que le langage C est à faible typage, je sais que je parle à un troll.

En gros, tu maîtrise bien la langue française, mais tu n'y connais rien du tout en langage C. C'est ma conclusion sur ton intervention.

[Uther]

C'est tellement bien reconnu , que depuis 2003 que je suis sur ce site, je ne sais même pas de quoi tu parles. Peut-être une démonstration ?

Écoute, tu es le premiers que je vois proposer de manière sérieuse l'assembleur comme langage d'apprentissage. Je comprend bien l'idée séduisante d'approcher l'informatique avec une approche bottom-up : commencer au plus bas niveau pour aller vers le plus abstrait. Mais a peu près tous les professeurs te diront que ça n'est absolument pas conseillé, tout comme on ne va pas conseiller d'apprendre l'arithmétique a l'école primaire en commençant par les Axiomes de Peano, qui permettent pourtant de prouver que 1+1=2.
L'abstraction apportée par les langages de plus haut niveau est bien plus naturelle et évite qu'un débutant soit submergé d’emblée par les détails du fonctionnement à bas niveau.

La compréhension du fonctionnement de la machine est indispensable. Qui va développer les moteurs, qui nécessite des connaissances bas niveau, si tout le monde n'apprends que du haut niveau ?

La compréhension précise du bas niveau est utile pour certains types de programmes, quand on a atteint un certain niveau, mais le sujet à la base, c'est l'introduction à la programmation pour des débutants complets. Mieux vaut attaquer les problématiques de très bas niveau une fois que l'on maitrise les bases de l’algorithmie.

A un moment, il faut former des développeurs compétents, cela veut dire du bas niveau, pour que des développeurs qui n'y comprennent rien, et qui ne font pas du bas niveau, comme tu le suggères, puissent écrire des programmes potables.

Compétant, ça veut dire apte a répondre au besoin, et bien souvent, le bas niveau n'est pas ce dont on a besoin, surtout quand on débute. On peut faire un serveur d'application web en assembleur, mais dans la pratique, on ne le fera pas parce que ça n'est pas le bon outil : ça prendra un temps fou et il va falloir réinventer la roue 50 fois au passage.
Quand on apprend la programmation, ce qui est utile, c'est de voir rapidement et simplement les résultats de ce que l'on fait et de ne pas être retenu par des problématiques annexes.

Donc en gros, pour que des nuls en programmation puissent écrire des programmes en Java, il faut quand même des mecs qui comprennent l'assembleur pour écrire le moteur de Java.

Ça va les chevilles ? Tous les programmeurs Java ne sont pas des nuls loin de là, ils font face à des problèmes différents des vôtres, pour des résultats différents, c'est tout.
Oui les développeurs haut niveau ont forcément besoin à un moment de s'appuyer sur des outils réalisés à bas niveau. Mais ça ne veut pas dire que le bas niveau est une science supérieure, tout comme le plombier ou le boulanger ne te sont pas supérieur, même si tu as besoin d'eux pour manger du pain ou prendre une douche.

Je suis désolé, mais quand un gland me dit que le langage C est à faible typage, je sais que je parle à un troll.

C'est difficile de donner raison à l'un ou l'autre sur ce sujet étant donné qu'il y a un consensus indéniable sur le fait que la notion de typage fort/faible ne fait pas du tout consensus, contrairement à la notion de typages statique/dynamique.

Il n' y a pas de discussion sur le fait que C est statiquement typé : c'est à dire que les variables ont un type fixé définitivement à la compilation et que ce type ne changera pas au cours de l’exécution, contrairement à ce qui peut se passer en Python ou JavaScript.

Maintenant, comparé a d'autre langages, le C reste très laxiste sur les types notamment au niveau des conversion implicites, potentiellement dangereuses, notamment au niveau des pointeurs. Cela fait que je comprend tout a fait pourquoi on peut être tenté de le classer comme ayant un typage faible, comparé à l'Ada ou au Rust qui évitent toute conversion implicite, voire au Java ou C++ ou le modèle objet et les génériques permettent de réduire les recours aux pointeurs hasardeux.

[moldavi]

Bonjour.

Pour l'instant, je ne vais répondre qu'à l'affirmation que le langage C est à typage fort. On verra plus tard le reste.

C'est difficile de donner raison à l'un ou l'autre sur ce sujet étant donné qu'il y a un consensus indéniable sur le fait que la notion de typage fort/faible ne fait pas du tout consensus, contrairement à la notion de typages statique/dynamique.

J'aime bien tes histoires de consensus, mais je ne sais toujours pas de quoi tu parles. Peut-être as-tu des liens qui confirment ce consensus ?

Il n' y a pas de discussion sur le fait que C est statiquement typé : c'est à dire que les variables ont un type fixé définitivement à la compilation et que ce type ne changera pas au cours de l’exécution, contrairement à ce qui peut se passer en Python ou JavaScript.

Oui, c'est ce que l'on appelle du typage fort... Visiblement tu découvres l'eau chaude, mais on sent que tu vas tenter une entourloupette ci-dessous.

Maintenant, comparé a d'autre langages, le C reste très laxiste sur les types notamment au niveau des conversion implicites, potentiellement dangereuses, notamment au niveau des pointeurs. Cela fait que je comprend tout a fait pourquoi on peut être tenté de le classer comme ayant un typage faible, comparé à l'Ada ou au Rust qui évitent toute conversion implicite, voire au Java ou C++ ou le modèle objet et les génériques permettent de réduire les recours aux pointeurs hasardeux.

C'est là aussi que j'ai compris que tu étais un gland. Les problèmes de conversion ne font pas du C un typage faible. Au contraire, pour le langage C, à typage fort, c'est évident que les conversions sont compliquées. En gros, ta démonstration ne fait que confirmer que le langage C est à typage fort.

Si tu penses qu'un langage qui permet de faire 1 + "1" (entier + string), et qui est maîtrisé par tous les développeurs, je n'y crois pas une seconde. Tout le monde sait qu l'on ne mélange pas des choux et des carottes.

Un typage fort oblige le développeur à prendre ses responsabilités. Un typage faible, c'est croire que tout va bien, vu que les choux et les carottes ne plantent pas...

[Uther]

Bonjour.
J'aime bien tes histoires de consensus, mais je ne sais toujours pas de quoi tu parles. Peut-être as-tu des liens qui confirment ce consensus ?

Par exemple : https://en.wikipedia.org/wiki/Strong_and_weak_typing

In computer programming, one of the many ways that programming languages are colloquially classified is whether the language's type system makes it strongly typed or weakly typed (loosely typed). However, there is no precise technical definition of what the terms mean and different authors disagree about the implied meaning of the terms and the relative rankings of the "strength" of the type systems of mainstream programming languages.

Oui, c'est ce que l'on appelle du typage fort... Visiblement tu découvres l'eau chaude, mais on sent que tu vas tenter une entourloupette ci-dessous.

Je ne découvres pas l'eau chaude, je te rassures je connais le sujet depuis une bonne vingtaine d'années. J'essaie juste de t'expliquer, sans te traiter de gland au passage, qu'il y a un terme qui est clairement défini pour ça et qui ne souffre pas de débat : c'est le typage statique. Visiblement pour toi c'est aussi la définition de typage fort, mais cette définition ne fait pas l'unanimité, et pour le coup c'est toi qui à l'air de le découvrir.

Si tu penses qu'un langage qui permet de faire 1 + "1" (entier + string), et qui est maîtrisé par tous les développeurs, je n'y crois pas une seconde. Tout le monde sait qu l'on ne mélange pas des choux et des carottes.

En tout cas la syntaxe de cette phrase n'est pas très maitrisée, le français n'est pas un langage fourni avec un compilateur strict .
Si tu veux dire que accepter les conversion du type 1 + "1" est une mauvaise idée, tu prêches un convaincu.

Un typage fort oblige le développeur à prendre ses responsabilités. Un typage faible, c'est croire que tout va bien, vu que les choux et les carottes ne plantent pas...

Je suis tout a fait d'accord, et c'est pour ça que le positionnement du C n'est pas évident. Le typage statique lui offre certaine garanties par rapport à des langages comme JavaScript. Mais le C reste quand même beaucoup plus léger en termes de garanties offertes par le typage que des langages comme Ada ou Rust.

[foetus]

c'est le typage statique. Visiblement pour toi c'est aussi la définition de typage fort, mais ça c'est très discuté, et c'est toi qui as l'air de découvrir ça.

en lisant la page wikipedia typage fort en français, il y a 1 beau tableau

+-----------+----------------------------+-----------------------------+
| Typage    |            Fort            |            Faible           |
+-----------+----------------------------+-----------------------------+
| Statique  | Ada, Java, Pascal, ou même | Langage C : short add (int  |
|           | Visual Basic avec l'Option | x, int y) { return x+y; }   |
|           | Explicit                   | C++ : Personne p; p < 13;   |
+-----------+----------------------------+-----------------------------+
| Dynamique | Ruby, Python               | JavaScript : "2" + 4 → "24" |
+-----------+----------------------------+-----------------------------+

En gros statique veut dire "langage compilé" et dynamique "langage interprété" dont souvent il n'y a pas vraiment de types.

Je dis cela , mais en C il n'y a pas vraiment de type : tout est entier (même les énumérations), et les structures tu ne peux que les passer en paramètre (pas d'opérateurs initialisation, affectation/ copie, déplacement, addition, ...)

[Uther]

en lisant la page wikipedia typage fort en français, il y a 1 beau tableau

Si je n'ai pas cité l'article en français, c'est que même si il indique lui aussi que la notion de typage fort n'a pas une définition consensuelle, il va juste après, via ce tableau, en donner une qui est tout aussi discutable que les autres. L'article anglais à une meilleure approche en montrant divers critères assez bien définis qui peuvent permettre de classer le typage d'un langage, sans se permettre de présumer de ceux qui méritent le qualificatif de typage fort ou non.

En gros statique veut dire "langage compilé" et dynamique "langage interprété" dont souvent il n'y a pas vraiment de types.

Même si la plupart des langages à typage statique sont "compilés", la notion de typage statique n'est pas forcément liée à la façon d’exécuter le langage. Ça signifie juste que les types sont définis de manière définitive : ni le type d'une variable ni la structure d'un type ne peuvent être modifiés pendant l’exécution du programme.
Rien n’empêche un interpréteur de gérer les types de manière statique (c'était notamment le cas des interpréteurs Java d'avant l'arrivée du JIT), tout comme il existe des compilateurs pour des langages qui ont un typage dynamique.

[foetus]

Même si la plupart des langages à typage statique sont "compilés", la notion de typage statique n'est pas forcément liée à la façon d’exécuter le langage. Ça signifie juste que les types sont définis de manière définitive : ni le type d'une variable ni la structure d'un type ne peuvent être modifiés pendant l’exécution du programme.

Je ne voulais pas de te répondre parce que je ne suis pas d'accord avec toi : on peut donner des définitions, mais comme chaque langage soit va piocher ailleurs soit fait son propre système soit veut améliorer les défauts de certains autres, alors les frontières sont [assez] "floues".
Mais le tableau me parait assez pertinent pour donner 1 image des "types" et ton lien explique les points de comparaison.

Mais dire qu'avec le typage statique, "les types ne sont pas modifiables à l'exécution" ce n'est pas vrai, et tu vas te t'empresser de me reprendre "c'est pour cela qu'il n'y a pas de définitions possibles".
À l'exécuton, l'intérieur du type n'est pas modifiable (quoique, avec 1 pointeur c'est possible) mais les types sont modifiables.

Le C est quand même basé sur la notion de pointeur, voire même void*/ reinterpret_cast en C++ : recevoir en paramètre 1 "chunk" l'interpréter et faire ce qu'il faut faire.
En C++ on a la notion de "down casting"/ "up casting"/ dynamic_cast : pareil, basé sur les pointeurs, cela permet de manipuler l'héritage à l'exécution. C'est + restrictif parce que les types sont limités à ceux de l'héritage.
Le patron Usine/ "Factory" est basé là-dessus.

En Objective-C (mais pas que lui), il y a le "duck typing" ("If it walks like a duck and it quacks like a duck, then it must be a duck") : alors cela doit être 1 fonctionnalité peu utilisée, mais tu peux faire "passer" les types qui respectent les conditions à l'exécution (c'est restrictif)
La réflexion en Java c'est la même chose.

[Uther]

Mais dire qu'avec le typage statique, "les types ne sont pas modifiables à l'exécution" ce n'est pas vrai, et tu vas te t'empresser de me reprendre "c'est pour cela qu'il n'y a pas de définitions possibles".
À l'exécuton, l'intérieur du type n'est pas modifiable (quoique, avec 1 pointeur c'est possible) mais les types sont modifiables.

Je pense que tu mélanges la notion de structure de l'objet et de contenu de l'objet, car non, dans les langage à typage statique comme le C, le Java ou le Rust, la structure d'un type ne change pas pendant l’exécution, même si il peut être interprété de différente façon par les pointeurs qui y font référence.

Par exemple en C, si tu déclares :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
struct {
    int x;
    int y;
} point;

Ta variable "point" contiendra toujours uniquement 2 champs de type int et tu ne peux changer ça.

Alors qu'en JavaScript tu peux faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
var point = {
    x: 0;
    y: 0;
}
point.z = 0
point = "P"

La variable "point" va d'abord recevoir un troisième champ "z", qui n'existait pas à sa création.
Puis la variable "point" va passer du type Object au type string.

C'est ça, et seulement ça qui constitue la définition du typage statique/dynamique : si le type et la structure d'une variable peut évoluer durant l’exécution du programme.

Le C est quand même basé sur la notion de pointeur, voire même void*/ reinterpret_cast en C++ : recevoir en paramètre 1 "chunk" l'interpréter et faire ce qu'il faut faire.

C'est vrai qu'au final tu peux finir avec des pointeurs dont le type ne correspond pas aux données qu'ils pointent. Cette largesse du C au niveau des pointeurs et des conversions automatiques fait que je comprend tout à fait que l'on ne souhaite pas le considérer comme un langage a typage fort.
Mais c'est une problématique distincte de la notion de typage statique/dynamique. Tout ça ne modifie pas, en soi le type des variables durant l’exécution. Même les pointeurs ne changent pas de type, ils sont juste convertis.

En C++ on a la notion de "down casting"/ "up casting"/ dynamic_cast : pareil, basé sur les pointeurs, cela permet de manipuler l'héritage à l'exécution. C'est + restrictif parce que les types sont limités à ceux de l'héritage.
Le patron Usine/ "Factory" est basé là-dessus.

En effet c'est plus propre que la gestion de pointeur basique du C, mais là encore ça n'est qu'une histoire de conversion de pointeurs, ça n'a rien à voir avec la notion de typage statique.

La réflexion en Java c'est la même chose.

La réflexion en java permet de modifier le contenu d'une variable, mais pas son type ou sa structure. Tu ne peux pas utiliser la réflexion pour ajouter, retirer ou modifier la signature des champs ou des méthodes d'un objet.

[Jacti]

Je suis désolé, mais quand un gland me dit que le langage C est à faible typage, je sais que je parle à un troll.

En gros, tu maîtrise bien la langue française, mais tu n'y connais rien du tout en langage C. C'est ma conclusion sur ton intervention.

Je maintiens que le langage C est à faible typage car il autorise les conversions implicites. En langage C on peut affecter un flottant à un entier sans "caster" ou l'inverse. On peut additionner un char et un entier. Le résultat est la somme du code ASCII du char avec l'entier. Si ce n'est pas du faible typage alors c'est quoi ?

De plus, ça devient agaçant que tu me traites de gland. Et quand tu dis que je n'y connaît rien en langage C, je te rappelle que j'ai participé au développement d'un compilateur de langage C et, qui plus est, pour la partie sémantique.

[moldavi]

Bonjour.

C'est sympa vos liens wikipedia. Ils ne racontent que de la merde, mais c'est normal, n'importe quel gland peut participer à l'écriture.

Je m'attendais à des liens vers des sommités de l'informatique.

Je ne vois toujours pas de consensus, juste des glands qui écrivent ce qu'ils veulent sur wikipedia, sans aucune référence. C'est un peu léger pour être crédible.