Discussion :

[GrandFather]

java c'est lent et gourmand en mémoire... quoi qu'en disent les experts de l'embarqué
la vérification dynamique systématique empêchera toutes améliorations futures

Je tiens quand même à rappeler que le but de ce fil est de cerner les besoins de quelqu'un qui débute dans la programmation et de le conseiller, pas de se plonger dans les arcanes des compilateurs et des machines virtuelles, pas plus que d'entamer un énième troll sur la lenteur de Java.

[gamerome]

Je tiens quand même à rappeler que le but de ce fil est de cerner les besoins de quelqu'un qui débute dans la programmation et de le conseiller, pas de se plonger dans les arcanes des compilateurs et des machines virtuelles, pas plus que d'entamer un énième troll sur la lenteur de Java.

C'est vrai recentrons le sujet!!

S'il veut vraiment des notions de POO encore plus poussées, il peut apprendre le EIFFEL.
Mais au fait, qu'est ce qu'il veut faire exactement? Apprendre la POO pour faire quoi exactement?

[K-Kaï]

Et je pense que avant d'attaquer une approche objet/pas objet langage X ou Y il faut avant tout qu'il trouve un langage qui lui permette de mettre en pratique la base du developpement à savoir l'algorithmique (recursivité,complexité .....).

Je pense que c'est pour cela que certains (dont moi) l'on appris avec le C qui justement autorise bcp de choses (oui meême les pire attrocité j'avoue) mais egalement tout plein de notions interessantes tel les pointeurs entre autres.

[gamerome]

C'est sur que les notions d'algorithmique sont la base de tout. Mais je doute beaucoup qu'il veuille s'y mettre... Ces notions viendront au fur et a mesure de son apprentissage du JAVA

[Luc Hermitte]

:o Faut arreter avec cette idée : java = lent ...
Si c'est tellement lent et gourmand en mémoire, pourquoi java est il si populaire dans le monde professionnel?

Il permet de laisser le cerveau à la maison (en ce qui concerne la gestion de la mémoire), beaucoup de bibliothèques pseudo standard (les sun + les apaches), style quasi unique et non héritage des styles du C, très bon marketing de sun pour ça.

Et puis tout le monde en parle (comme pour d'autres langages). Et pourtant il est loin d'avoir les qualités (en termes de langage) d'autres trucs comme Eiffel p.ex. La visibilité augmente la visibilité.

NB: nous sommes déjà dans un n-ième ressucé du "quel langage pour débuter". On n'est plus à un troll près :-(.

Mes préférés pour apprendre restent Ada et Eiffel, avec un gros coup de coeur pour Prolog (j'adore les ovnis). Mais je ne connais ni OCaml, ni ruby qui, je pense, méritent qu'on s'y intéresse.

Le débutant doit d'abord se concentrer sur l'algorithmique. Après, il aura largement le temps d'approfondir et de voir la gestion de la mémoire, le monde itératif orienté objet (celui de Java, Eiffel, ...), ...

[Jean-Marc.Bourguet]

Il permet de laisser le cerveau à la maison (en ce qui concerne la gestion de la mémoire),

Il ne permet pas... on l'a vendu comme s'il le permettait, c'est différent. Ca a marché, et pourtant tout le monde sait que there is no silver bullet, pour ça comme pour d'autres choses... dont l'apprentissage de la programmation.

beaucoup de bibliothèques pseudo standard (les sun + les apaches),

Est-ce un bien ou un mal? On arrive un peu à cette situation en C++ avec boost. Il y a des avantages à avoir des solutions standards. Il y a aussi des inconvénients, le moindre n'étant pas les problèmes posés par des solutions imparfaites mais standards (mais bon, on connait ça aussi ailleurs).

NB: nous sommes déjà dans un n-ième ressucé du "quel langage pour débuter". On n'est plus à un troll près :-(.

En plus, c'est une des occurences les moins argumentées... Ca tient un peu trop du "j'ai appris ce langage, je n'en connais pas réellement d'autres mais il me convient". Je me souviens dans un discussion de ce genre que quelqu'un avait écrit en substance: si vous n'êtes pas capable de défendre un langage face à un autre, c'est que vous ne connaissez assez bien aucun des deux langages en question pour l'attaquer de ce point de vue.

Mes préférés pour apprendre restent Ada

Mon premier amour en matière de langage (mais pas mon premier langage...). Un peu gros.

et Eiffel,

L'approche un peu trop "tout est objet même si ça ne correspond pas au problème" me dérange dans un contexte de premier langage et d'apprentissage de la programmation. Surtout que la POO correspond assez mal à la problématique qu'on rencontre à ce niveau. Ada, C++, CommonLisp, Oz, peut-être OCaml que je connais pas assez bien ont l'avantage de permettre une approche moins dogmatique.

avec un gros coup de coeur pour Prolog (j'adore les ovnis).

Trop particulier pour servir d'apprentissage. Il faudrait recommencer quasiment tout avec le deuxième langage.

Mais je ne connais ni OCaml, ni ruby qui, je pense, méritent qu'on s'y intéresse.

Mon hésitation principale, c'est "est-ce qu'il faut commencer par du typage dynamique ou du typage statique explicite". Dans le premier cas, je serais fortement tenté par Oz dans le second par Ada. Un typage statique implicite (comme en Haskell, et me semble-t'il en OCaml) est peut-être un bon compromis. Mais Haskell est particulier et je n'arrive pas à accrocher à OCaml (tiens, est-ce que quelqu'un connait un autre langage au typage statique implicite?).

Outre le typage, pas mal de choses séparent quand même Ada et Oz. C'est peut-être un signe qu'il n'y a pas de meilleurs choix absolu, simplement des compromis à faire sur une série d'axes en fonction des objectifs poursuivis et du contexte.

Le débutant doit d'abord se concentrer sur l'algorithmique. Après, il aura largement le temps d'approfondir et de voir la gestion de la mémoire, le monde itératif orienté objet (celui de Java, Eiffel, ...), ...

Raison pour laquelle le C est un mauvais choix: il n'est pas possible de s'affranchir des considérations de bas niveau.

Mais il est nécessaire d'au moins donner un appercu du bas niveau. Un avantage certain pour Ada, C++. Si du moins on est limité à un seul langage. Mais on ne peut pas prétendre être un programmeur compétant en ne maitrisant qu'un langage.

[Luc Hermitte]

Il permet de laisser le cerveau à la maison

Il ne permet pas... on l'a vendu comme s'il le permettait, c'est différent.

Je n'osais le dire. De peur que l'on ne crie au troll.

beaucoup de bibliothèques pseudo standard

Est-ce un bien ou un mal? On arrive un peu à cette situation en C++ avec boost. Il y a des avantages à avoir des solutions standards. Il y a aussi des inconvénients, le moindre n'étant pas les problèmes posés par des solutions imparfaites mais standards (mais bon, on connait ça aussi ailleurs).

C'est une force de vente. Et c'est effectivement la même chose avec boost, bien qu'elle ne soit pas aussi "(re)connu" -- genre le client qui demande ce que seraient les métriques (et autres trucs détectés plus ou moins automatiquement comme l'interdiction de pré-incrémentation, l'obligation de test sécurisant les auto-affectations, ...) suite au passage des outils de qualité sur boost.
Boost me semble à peu près à peine plus connu que ce que sont les bonnes habitudes de développement en C++. Bref, c'est pas terrible. Alors que les bibliothèques Java me paraissent au contraire bien visibles.

Je me souviens dans un discussion de ce genre que quelqu'un avait écrit en substance: si vous n'êtes pas capable de défendre un langage face à un autre, c'est que vous ne connaissez assez bien aucun des deux langages en question pour l'attaquer de ce point de vue.

C'est tellement vrai.

Ada

Mon premier amour en matière de langage (mais pas mon premier langage...). Un peu gros.

Il tient quand même bien la route pour l'apprentissage. Il demande un certain effort il est vrai.
Par contre (après avoi relu la question de l'OP), je ne sais pas si on peut le qualifier de bon langage pour apprendre le POO.

Eiffel

L'approche un peu trop "tout est objet même si ça ne correspond pas au problème" me dérange dans un contexte de premier langage et d'apprentissage de la programmation. Surtout que la POO correspond assez mal à la problématique qu'on rencontre à ce niveau. Ada, C++, CommonLisp, Oz, peut-être OCaml que je connais pas assez bien ont l'avantage de permettre une approche moins dogmatique.

Il est clairement dogmatique. Mais j'ai l'impression que tu soulèves indirectement une autre question : "faut-il commencer par un langage limité OO ?".

prolog

Trop particulier pour servir d'apprentissage. Il faudrait recommencer quasiment tout avec le deuxième langage.

Tout à fait. En plus, il ne correspond absolument pas à la question de l'OP. A avoir touché quand on est un développeur professionnel. (Comme Lisp et d'autres)

Mon hésitation principale, c'est "est-ce qu'il faut commencer par du typage dynamique ou du typage statique explicite". Dans le premier cas, je serais fortement tenté par Oz dans le second par Ada. Un typage statique implicite (comme en Haskell, et me semble-t'il en OCaml) est peut-être un bon compromis. Mais Haskell est particulier et je n'arrive pas à accrocher à OCaml (tiens, est-ce que quelqu'un connait un autre langage au typage statique implicite?).

Pas d'opnion non plus trachée non plus.
(Sinon B (le langage ancêtre du C) peut-être ? J'avais cru comprendre qu'il était à typage statique implicite)

Mais on ne peut pas prétendre être un programmeur compétant en ne maitrisant qu'un langage.

Non pas à recopier 100 fois, mais à mettre en pratique (apprendre des langages divers et variés))


(Mais quelle regression de USENET à phpBB (et assimilés) en matière de citations!)

[Jean-Marc.Bourguet]

Je n'osais le dire. De peur que l'on ne crie au troll.

C'est une force de vente. Et c'est effectivement la même chose avec
boost, bien qu'elle ne soit pas aussi "(re)connu" -- genre le client qui
demande ce que seraient les métriques (et autres trucs détectés plus ou
moins automatiquement comme l'interdiction de pré-incrémentation,
l'obligation de test sécurisant les auto-affectations, ...) suite au
passage des outils de qualité sur boost.

Non. Mais on en est déjà au point où sur les forums ou les
news si on tentait de faire passer le message que
shared_pointer n'est peut-être pas la panacée universelle,
on est presque pris pour un troll.

[Ada] tient quand même bien la route pour
l'apprentissage. Il demande un certain effort il est vrai.
Par contre (après avoi relu la question de l'OP), je ne sais
pas si on peut le qualifier de bon langage pour apprendre le
POO.

Ca me semble être un choix raisonnable; même si l'approche
choisie est un peu non conventionnelle, elle est proche de
celles gens travaillant sur la théorie des types.

[Eiffel] est clairement dogmatique. Mais j'ai
l'impression que tu soulèves indirectement une autre
question : "faut-il commencer par un langage limité
OO?".

A mon humble avis, la réponse est non. Commencer par une
approche dogmatique quand le dogme est proche de l'opinion
dominante n'aide pas à le remettre en question quand il
n'est pas approprié.

(Sinon B (le langage ancêtre du C) peut-être ?
J'avais cru comprendre qu'il était à typage statique
implicite)

C'est un langage "non typé", comme BLISS, BCPL, Forth ou
l'assembleur. C-à-d que les informations sur le type sont
portées par les opérateurs, pas par les opérandes.

On ne peut pas prétendre être un programmeur
compétant en ne maitrisant qu'un langage.

Non pas à
recopier 100 fois, mais à mettre en pratique (apprendre des
langages divers et variés))

J'essaie d'alterner les sources académique (Oz pour reciter
le dernier; au fait je ne peux que conseiller Concepts,
Techniques and Models of Computer Programming de Van Roy et
Haridi. C'est un exposé très bien articulé de choses que je
savais et utilisais mais n'avais jamais vu explicitées --
peut-être que ce n'est pas le cas de gens ayant une
formation théorique plus récente que moi) et les sources
plus "pragmatiques".

(Mais quelle regression de USENET à phpBB (et assimilés) en matière
de citations!)

En matière de citations, la nouvelle version a empirer les
choses avec sa manie de limiter la profondeur... Mais s'il
n'y avait que cela. Passer de Gnus à phpBB est une
régression sur quasiment tous les points (exception: le
formattage, du moins si on ne se sert pas d'un éditeur
extérieur comme moi ici).

[Tuxico]

A mon avis, avant de commencer par la POO faut peut-^etre d'abbord apprendre un langage concret et puis apprendre l'orienté objet...
Je ne conseillerai pas de commencer par le Java car il demande une certaine rigueur et sa syntaxe lui est propre . Je ne suis pas contre mais pas comme premier language, par contre pour la mise en forme de la POO c'est un exellent langage .
Je commencerai par le pascal (pas le delphi!) ou le C . Une fois un de ces langages bien maitrisés, tu connais le principe des fonctions, procédures, types etc et tu peux facilement te lancer dans la POO en rajoutant le java à tes connaissances .
Maintenant c'est mon avis...

[Gnux]

En matière de citations, la nouvelle version a empirer les
choses avec sa manie de limiter la profondeur... Mais s'il
n'y avait que cela. Passer de Gnus à phpBB est une
régression sur quasiment tous les points (exception: le
formattage, du moins si on ne se sert pas d'un éditeur
extérieur comme moi ici).

+1 (et un gros UN). Manque aussi le scoring et la possibilité de pouvoir lire *vraiment* ceci dans un éditeur exterieur comme Vim ou Emacs afin de pouvoir tester le code via un simple copy/paste...En fait ça serait drôlement bien si ce genre de forum embarquait un langage de script permettant de le tuner à son gout comme Elisp pour Gnus ou Lua pour Ion...

Bref, ce que je ne comprends pas c'est la raison pour laquelle tu accordes autant d'importance à la question du typage statique ou dynamique pour un premier langage.
Personnellement, et ce n'est qu'un avis personnel, j'aurais tendance à conseiller un langage relativement proche de l'algorithmie et assez ouvert comme le Pascal, bien que celui ci soit "vieux". Je trouve que malgré sa verbosité il reste clair et surtout surtout, qud j'ai débuté, j'ai trouvé que c'était celui qui me donnait le moins de peine en considération langagière (style: puis je ou non écrire ça?) et par la même celui qui m'a permis de me concentrer sur les algorithmes et leur mise en oeuvre.
Et en fait je pense que c'est très important un langage qui permet, une fois la base apprise de ne pas trop se prendre la tete avec et de se consacrer à la réflexion pour une résolution du problème "intelligente". J'ai vu pas mal de débutants qui pourraient être dits connaissant le <insérer votre langage ici> et qui ne se souciaient que de masquer leur absence de réflexion par cette connaissance du langage qui devenait par là même artificiel...

Enfin j'ai une dernière question: c'est quoi Oz? Jusqu'a ce soir pour moi c'était l'australie ... Tu n'aurais pas un lien vers un tutoriel dans le style "overview" mais assez approfondi tout de même?
<HS> Jean Marc: comment fais tu pour utiliser un éditeur extérieur? Tu copies/pastes depuis l'éditeur? </>

[Jean-Marc.Bourguet]

Bref, ce que je ne comprends pas c'est la raison pour laquelle tu accordes autant d'importance à la question du typage statique ou dynamique pour un premier langage.

C'est le point le plus important sur lequel je n'ai pas d'opinion tranchée. J'aime bien les langages typé dynamiquement. D'après mon expérience ils ont des avantages sur les langages typés statiquement qui contrebalancent leurs inconvénients sur des petits projets mais c'est l'inverse sur les gros (on ne va pas essayer de définir la limite, ce n'est pas l'objet). Si je posais des questions sur les langages au typage statique implicite, c'est qu'ils ont certains -- mais pas tous -- avantages des langages au typage dynamique. Je ne les ai pas pratiqué assez pour savoir comment ils se comportent sur de gros projets.

Dans les contextes d'enseignement, on est toujours sur des petits projets. Est-ce qu'on ne pourrait pas alors profiter de ces avantages? Et prime s'éviter d'avoir à expliquer un système de typage en même temps que les bases de la programmation.

Personnellement, et ce n'est qu'un avis personnel, j'aurais tendance à conseiller un langage relativement proche de l'algorithmie et assez ouvert comme le Pascal, bien que celui ci soit "vieux".

Pour en rester temporairement au problème du typage statique ou dynamique, je ne vois pas en quoi Pascal serait plus proche de l'algorithmie que Scheme par exemple (exemple choisi pour le titre du document le définissant Revised (x) Report on the Algorithmic Language Scheme).

Note que je ne vois absolument aucun avantage de Pascal sur Ada; dans l'autre sens par contre...

Je trouve que malgré sa verbosité il reste clair et surtout surtout, qud j'ai débuté, j'ai trouvé que c'était celui qui me donnait le moins de peine en considération langagière (style: puis je ou non écrire ça?) et par la même celui qui m'a permis de me concentrer sur les algorithmes et leur mise en oeuvre.

Je n'ai pas l'impression que Scheme ou Oz poseraient des problèmes de ce genre; en fait c'est un argument en faveur des langages typés dynamiquement. (C poserait ces problèmes et sans moyen de les éviter; C++ aussi, mais une bonne méthode devrait permettre d'éviter ces considérations assez longtemps pourqu'elles ne gènent plus).

Enfin j'ai une dernière question: c'est quoi Oz? Jusqu'a ce soir pour moi c'était l'australie ... Tu n'aurais pas un lien vers un tutoriel dans le style "overview" mais assez approfondi tout de même?

C'est le langage utilisé dans le bouquin que j'ai cité. [url="http://www.mozart-oz.org/"]Mozart et Oz[/quote]

<HS> Jean Marc: comment fais tu pour utiliser un éditeur extérieur? Tu copies/pastes depuis l'éditeur? </>

J'ai pas encore trouvé plus simple. Je me demande si je ne vais pas finir par essayer une fois le site avec le browser d'emacs.

[Gnux]

Oui mais comme tu l'as dit plus haut dans le thread on ne voit bien les avantages de la POO que sur des projets assez "conséquents" (ie de taille plus importante que les progs utilisés pour débuter). Or Ada, si je ne m'abuse, est un langage fortement OO non?
De plus la doc n'est peu etre pas aussi abondante que pour Pascal qui bénéficie des livres de Delannoy par exemple. Pour ada, il y en a bien un chez Vuibert mais...Bien qu'il ait l'air d'avoir la cote de plus en plus pour l'enseignement, principalement à cause de sa rigueur, il manque encore un peu de docs ou de cours pour en faciliter l'apprentissage

<HS>Lache l'affaire avec w3 j'ai testé sous links et même sous w3 j'ai trouvé ça...enfin tu verras </>

[Luc Hermitte]

Oui mais comme tu l'as dit plus haut dans le thread on ne voit bien les avantages de la POO que sur des projets assez "conséquents" (ie de taille plus importante que les progs utilisés pour débuter). Or Ada, si je ne m'abuse, est un langage fortement OO non?

Absolument pas. Vois plutôt Ada comme un super Pascal. Comparé à Delphi il va par contre manquer le côté IHM faite en deux clics.
Le côté OO n'est qu'un ajout tardif pas réputé des plus réussi selon les versions d'Ada -- de ce que j'ai pu lire, n'ayant jamais manipulé d'"objets" en Ada.

De plus la doc n'est peu etre pas aussi abondante que pour Pascal qui bénéficie des livres de Delannoy par exemple. Pour ada, il y en a bien un chez Vuibert mais...Bien qu'il ait l'air d'avoir la cote de plus en plus pour l'enseignement, principalement à cause de sa rigueur, il manque encore un peu de docs ou de cours pour en faciliter l'apprentissage

Qu'il y ait 150 ouvrages pédagogiques sur un sujet ne rend pas le sujet mieux présenté qu'un autre qui disposerait d'un excellent support de cours. Supports qui peuvent être trouvés sur des sites d'universitaires.

Pédagogiquement parlant, Ada est beaucoup plus intéressant que Pascal, je trouve. Un paramètre ne sera pas copié ou "var", mais [in], [out] ou [inout]. De très jolies abstractions pour les tableaux. Elles permettent de les contraindres (si je me souviens bien du terme exact) pour définir des sous-tableaux très facilement et proprement. Ada est générique, ce qui lui conferre un type plus fort, et permet d'introduire les TAD sans changer de langage ou introduire des hacks.

[TheLeadingEdge]

Pour ada, il y en a bien un chez Vuibert mais...Bien qu'il ait l'air d'avoir la cote de plus en plus pour l'enseignement, principalement à cause de sa rigueur, il manque encore un peu de docs ou de cours pour en faciliter l'apprentissage

J'avais commencé avec ADA, dans les années 90, puis la vague JAVA est passée et à tt emporté ! Mais j'ai gardé ces vieux bouquin en français.

le langage ADA Daniel-jean David editions du PSI

Il date des origines (1982), à voir comme le manuel de référence du langage, pas comme le manuel du programmeur.

Introduction à ADA Pierre le Breux Sibex

Plus didactique,pour débutant en ADA.

[Seb_de_lille]

Ada depuis la version 95 et surtout avec la release 2005 intègre très bien la poo. Le problème est que, comme d'habitude, son approche diffère de c++ ou de java. En plus, il y ajoute sa sécurité légendaire.

Au final, on obtient quelquechose d'efficace, mais pas simple à utiliser quand on vient du monde c++ ou java.

[Jean-Marc.Bourguet]

Oui mais comme tu l'as dit plus haut dans le thread on ne voit bien les avantages de la POO que sur des projets assez "conséquents" (ie de taille plus importante que les progs utilisés pour débuter). Or Ada, si je ne m'abuse, est un langage fortement OO non?

Non. Ada83 n'est pas du tout un langage OO. Ada95 est OO mais contient tout Ada83 comme sous-ensemble.

[Jean-Marc.Bourguet]

Le côté OO n'est qu'un ajout tardif pas réputé des plus réussi selon les versions d'Ada -- de ce que j'ai pu lire, n'ayant jamais manipulé d'"objets" en Ada.

Les reproches que j'ai vu se résument en:
- la syntaxe n'est pas celle à laquelle je suis habitué
- le contrôle d'accès ne fait pas partie des types mais des packages
- ce n'est pas un langage purement OO

Aucune ne me semble bien forte. Et personnellement j'aime bien la séparation entre Type et Type'Class en Ada et la gestion du contrôle d'accès par les packages plutôt que par les types. Surtout dans un contexte pédagogique où cela doit rendre plus clair qu'il s'agit de concepts différents qu'on peut ou non laisser traiter par la même entité.

[outs]

J'aime bien les langages typé dynamiquement. D'après mon expérience ils ont des avantages sur les langages typés statiquement qui contrebalancent leurs inconvénients sur des petits projets mais c'est l'inverse sur les gros

Et prime s'éviter d'avoir à expliquer un système de typage en même temps que les bases de la programmation.

Il y a beaucoup de gens qui pensent comme toi je le sais. Mais perso ce genre de considération me fait bondir. C'est peut être une déformation du au fait qu'actuellement j'étudie les méthodes formelles.

En tout cas je trouve que le typage statique est quelque chose de normal. D'ailleur cela correspond à ce que l'on m'a toujours appris : on additionne pas les pommes et les bananes. Ou alors au lycée en physique quand on faisait les petits calculs sur les dimensions (exemple un truc en km/heure multiplié par un truc en heure ca fait un truc en km). En math aussi quand on apprend a dire dans nos copie que telles variables appartient à tel ensemble, que la fonction çi va de tel ensemble à tel autre, qu'il y a une différence entre un polynome et sa fonction

Alors après quand je vois dans certain langages qu'on peut additionner un string à un entier alors qu'on a aucune certitude que le string contient un entier bien formé ... pas étonnant qu'il reste des bug dans les programmes écrit comme ça.

Bref pour moi la question est réglée c'est typage statique ou inférence statique de type (ce que tu appelle implicite). Tout le reste de devrait plus exister ... c'est quelque peu extrème mais c'est mon point de vue.

PS: désolé pour le hors sujet total. D'un autre coté je pense qu'il n'existe pas de réponse à la question initiale. Ou en tout cas rien de consensuel et accepté.

[Jean-Marc.Bourguet]

Il y a beaucoup de gens qui pensent comme toi je le sais.

J'ai plutôt l'impression de me trouver pris entre deux feux: ceux qui considèrent que seul le typage statique vaut quelque chose et ceux qui considèrent que seul le typage dynamique vaut quelque chose...

Mais perso ce genre de considération me fait bondir. C'est peut être une déformation du au fait qu'actuellement j'étudie les méthodes formelles.

C'est vrai qu'un typage statique aide pas mal dans ce contexte.

En math aussi quand on apprend a dire dans nos copie que telles variables appartient à tel ensemble, que la fonction çi va de tel ensemble à tel autre, qu'il y a une différence entre un polynome et sa fonction.

Les variables en math sont beaucoup plus proche des variables dans les langages déclaratifs (ceux qui n'admettent pas qu'on change la valeur d'une variable). En déduire quoi que ce soit sur les variables de langages à états explicites me semble être un raisonnement par analogie fallacieuse.

D'ailleur cela correspond à ce que l'on m'a toujours appris : on additionne pas les pommes et les bananes. Ou alors au lycée en physique quand on faisait les petits calculs sur les dimensions (exemple un truc en km/heure multiplié par un truc en heure ca fait un truc en km).

Alors après quand je vois dans certain langages qu'on peut additionner un string à un entier alors qu'on a aucune certitude que le string contient un entier bien formé ... pas étonnant qu'il reste des bug dans les programmes écrit comme ça.

Arguments sans rapport aucun avec le typage statique ou dynamique. J'ai vu des langages au typage statique le permettant et des langages au typage dynamique l'interdisant...

c'est quelque peu extrème mais c'est mon point de vue.

Tout ce qui est excessif est insignifiant.

[outs]

Les variables en math sont beaucoup plus proche des variables dans les langages déclaratifs (ceux qui n'admettent pas qu'on change la valeur d'une variable). En déduire quoi que ce soit sur les variables de langages à états explicites me semble être un raisonnement par analogie fallacieuse.

Ben par exemple si on prend la méthode formelle B (c'est son nom ), on a des modèles représentant un système avec des variables pouvant changer de valeur (ce qui correspond à des changement d'état dans le système modélisé). Dans ce cas on peut spécifier qu'un variable x est en entier avec la clause "x appartient à l'ensemble des naturel" (la syntaxe est "x : NATURAL"). Bon les entiers machines ne sont pas des naturels mais ca change pas grand chose à mon discours. Dans ce cas cette clause est une propriétée invariante inductive (enfin c'est ce que l'on souhaite obtenir si le système est correct) c'est à dire que les événements comme les affectations doivent établire la clause sur la nouvelle valeur de x (appellons la x') avec comme hypothèse la clause vrai sur l'ancienne valeur de x (x : NATURAL) et un représentation logique de l'effet de l'effectation (par exemple x'=x+2). Dans ce cas on peut montrer que x : NATURAL est un invariant (toujours vrai). Et ca marche pareil pour le typage des fonction, ensembles, relations.

C'est complétement analogue avec ce que l'on fait en mathématique en passant par la notion d'invariant inductif

Arguments sans rapport aucun avec le typage statique ou dynamique. J'ai vu des langages au typage statique le permettant et des langages au typage dynamique l'interdisant...

(une chose est sur c'est vrai que la méthode pour quoter est pénible ...)

Je veux bien des exemples de langages avec typage statique qui le permet. Ca a ouvert ma curiosité...

Ce que je voulais surtout dire c'est que si le typage des entités est quelque chose de suffisament reconnu pour être appris pendant la scolarité, et être demandé explicitement aux éléves. Alors il me semble logique que les langages demandent à ce que les types puissent être connu de manière indépendant de toutes éxécution.

Tout ce qui est excessif est insignifiant.

Ouais mais bon il faut bien faire des choix dans la vie.

edit PS: en fait je suis surtout pour le typage tout court le problème étant qu'il est rare qu'un langage dynamiquement typé fournisse de bon moyen de gérer le typage. Si un langage typé dynamiquement fournissait un très bon support des types qui me permettrai d'améliorer la suretée de mon programme alors j'accepterai de l'utiliser.

Il faudrait que l'on créé un nouveau post pour cette discussion, faire un follows-up à la main quoi ...