Réforme de la classe de terminale : spécialité Informatique

[M@yeulC]

Eh bien, le python est, si je ne m'abuse, un script destiné à être interprété au sein d'une application, et non pas un langage de programmation à part entière, qui a besoin d'être compilé avant d'être exécuté à part.

En cela, il se rapproche du TI-BASIC.

[noelnadal]

Oui. Mais le TI-Basic est considéré comme un langage (officiel en plus). Le Python aussi donc ?

[Lionel Debroux]

Python est un langage à part entière, qui a son propre interpréteur standalone, et un moyen de précompiler (vers du bytecode) le code Python.
Python est rarement intégré comme interpréteur au sein d'une autre application. Il y a plus léger et plus efficace, comme... Lua

[mdr1]

Je remarque que beaucoup de gens trouvent plus pédagogique d'apprendre un langage mieux cadré, avec plus de contraintes.
Eh bien je pense exactement l'inverse, je m'explique à travers une comparaison : si à un enfant on ne cesse d'être derrière lui à lui dire "travaille, joue, mange, dors etc.", eh bien il ne sera pas capable d'être autonome et de le faire par lui-même, de juger par lui-même, de décider. Ainsi, il faut lui laisser de la liberté pour qu'il apprenne par lui-même tout en le guidant.
Pour en revenir avec l'objet primaire, si l'on donne l'habitude à l'élève d'un langage avec trop de contraintes, trop cadré, il sera perdu lorsqu'il tentera d'apprendre un langage comme C/C++ ou Java et lorsqu'il pratiquera de l'algorithmique schématique. À l'inverse, si on le met face à un langage où on peut donner un présentation plus libre au programme, si on lui donne des bons tuyaux, il prendra de bonnes habitudes.

[noelnadal]

En fait d'après le programme la principale notion enseignée c'est les fonctions. Les fonctions c'est aprtout pareil sauf les instructions qui sont parfois plus intuitives dans les langages de haut niveau.

[Levak]

Pour en revenir avec l'objet primaire, si l'on donne l'habitude à l'élève d'un langage avec trop de contraintes, trop cadré, il sera perdu lorsqu'il tentera d'apprendre un langage comme C/C++ ou Java et lorsqu'il pratiquera de l'algorithmique schématique. À l'inverse, si on le met face à un langage où on peut donner un présentation plus libre au programme, si on lui donne des bons tuyaux, il prendra de bonnes habitudes.

Ce que tu oublies, c'est que les "contraintes" sont essentielles à connaître avant de s'embarquer dans les langages de plus haut niveau, non pas pour culture, mais tout simplement parce que ces mêmes langages reposent sur des routines de plus bas niveau. Les oublier ou ne pas les connaître te feras, et ça je l'ai vu pas mal de fois, écrire du code qui, en Java/C#/Python est intelligent, raisonnable etc ... mais qui plus bas est une pure grossièreté.

Un exemple tout bête : mettre des résultats dans des variables pour les réutiliser plus tard.
En bas niveau, notamment lorsque tu utilises des string, tu te rends compte de ce type de problème et tu vas tout faire pour minimiser les calculs/traitement en sauvegardant dans des variables intermédiaires.
En haut niveau, tu vas oublier cet aspect là et tu vas très certainement calculer 50 fois la même chose sans t'en apercevoir (ex: calcul de la longueur d'une chaine de caractères). Donc en plus du coup des machines virtuelles, interprétation ou autres, tu encaisses des calculs inutiles que tu pourrais éviter si, par toi même tu imagines ce qui se passe au niveau de la machine. On ne te demande pas de savoir refaire un processeur, juste de prendre en considération qu'il n'est pas magique =)

Je sais que pédagogiquement, c'est plus facile l'objet, mais il faut, je pense, passer par la case départ avant de pratiquer ces choses. Je pense cela parce qu'autour de moi, un nombre insaisissable de personnes qui n'avaient jamais programmé avant ont 1) mis du temps, trop de temps à comprendre tous les concepts de l'objet 2) buté et produit des codes abominables non optimisé et impossible à maintenir. Ils viennent te voir et te demandent pourquoi ça marche pas, tu as envie de tout effacer et de recommencer à leur place.

[mdr1]

Ce que tu oublies, c'est que les "contraintes" sont essentielles à connaître avant de s'embarquer dans les langages de plus haut niveau, non pas pour culture, mais tout simplement parce que ces mêmes langages reposent sur des routines de plus bas niveau. Les oublier ou ne pas les connaître te feras, et ça je l'ai vu pas mal de fois, écrire du code qui, en Java/C#/Python est intelligent, raisonnable etc ... mais qui plus bas est une pure grossièreté.

Un exemple tout bête : mettre des résultats dans des variables pour les réutiliser plus tard.
En bas niveau, notamment lorsque tu utilises des string, tu te rends compte de ce type de problème et tu vas tout faire pour minimiser les calculs/traitement en sauvegardant dans des variables intermédiaires.
En haut niveau, tu vas oublier cet aspect là et tu vas très certainement calculer 50 fois la même chose sans t'en apercevoir (ex: calcul de la longueur d'une chaine de caractères). Donc en plus du coup des machines virtuelles, interprétation ou autres, tu encaisses des calculs inutiles que tu pourrais éviter si, par toi même tu imagines ce qui se passe au niveau de la machine. On ne te demande pas de savoir refaire un processeur, juste de prendre en considération qu'il n'est pas magique =)

Ton exemple du calcul de la longueur d'une chaine de caractère est erroné, en tout cas pour le Java, car quand on va demander de recevoir cette valeur, elle sera inscrite à un champ de l'instance, il n'y aura nullement besoin de quelque calcul que ce soit.
Ensuite, ce dont tu parles est l'optimisation, mais pas le pédagogique que je défendais dans ma thèse. Bien évidemment que ça permet de faire plus d'optimisations de programmer en assembleur, mais l'assembleur est très éloigné de l'algorithmique humaine.

Je sais que pédagogiquement, c'est plus facile l'objet,

Attention, l'objet n'est pas plus facile pour l'apprentissage, mais pour le développement.
Donc pédagogiquement il n'est pas plus simple, mais plus logique.

mais il faut, je pense, passer par la case départ avant de pratiquer ces choses. Je pense cela parce qu'autour de moi, un nombre insaisissable de personnes qui n'avaient jamais programmé avant ont 1) mis du temps, trop de temps à comprendre tous les concepts de l'objet 2) buté et produit des codes abominables non optimisé et impossible à maintenir. Ils viennent te voir et te demandent pourquoi ça marche pas, tu as envie de tout effacer et de recommencer à leur place.

Ça, ce sera valable tous langages confondus, même en assembleur. Et il sera plus facile de corriger la trajectoire dans des langages plus haut niveau de part l'utilisation de concepts plus faut niveau, contrairement à l'asm où de très nombreuses techniques changeant selon les cas etc. sont présentes.

Personnellement, j'adore programmer en assembleur, mais ce n'est pas du tout un langage ressemblant à "l'algorithmique".

[Levak]

Ton exemple du calcul de la longueur d'une chaine de caractère est erroné, en tout cas pour le Java, car quand on va demander de recevoir cette valeur, elle sera inscrite à un champ de l'instance, il n'y aura nullement besoin de quelque calcul que ce soit.

Moui, j'y ai pensé juste après avoir posté mon message
Mais ça reste un dé-référencement suivit d'un accès mémoire contre un simple accès mémoire si tu la sauvegardé =)

Ensuite, ce dont tu parles est l'optimisation, mais pas le pédagogique que je défendais dans ma thèse. Bien évidemment que ça permet de faire plus d'optimisations de programmer en assembleur, mais l'assembleur est très éloigné de l'algorithmique humaine.

Je ne descendrais pas jusqu'au niveau de l'assembleur, mais bien à celui du C. Le C est bas niveau par rapport au C#, Java et python. Ca suffit pour voir pas mal de problèmes et avoir conscience que le plancher n'est pas mouillé, chose que beaucoup de nouveaux programmeurs de haut niveau oublient.

Je sais que pédagogiquement, c'est plus facile l'objet,

Attention, l'objet n'est pas plus facile pour l'apprentissage, mais pour le développement.
Donc pédagogiquement il n'est pas plus simple, mais plus logique.

Ok, j'avais mal lu/compris ta réponse tout à l'heure, on est donc maintenant sur la même longueur d'onde =)

Ça, ce sera valable tous langages confondus, même en assembleur. Et il sera plus facile de corriger la trajectoire dans des langages plus haut niveau de part l'utilisation de concepts plus faut niveau, contrairement à l'asm où de très nombreuses techniques changeant selon les cas etc. sont présentes.

Ce n'est pas valable dans tous langages confondus car si tu programmes de la merde, en bas niveau ça se voit/sent/ressent. En haut niveau, si tu programmes de la merde, le compilo te dit rien, adapte (il n'optimise donc pas les calculs) et tu te retrouves avec un exécutable qui marche, mais prend des plombes à tourner dans des boucles parc que ça utilise des fonctions time-critical.

Personnellement, j'adore programmer en assembleur, mais ce n'est pas du tout un langage ressemblant à "l'algorithmique".

On a, je pense, pas la même vision de l'algorithmique. Etant donné que je n'ai vu ça que dans mon école d'info où la structure algorithmique est elle même basée sur les pointeurs (listes chainées contre listes statiques). Tu as de l'algorithmique au lycée ? (Ou alors tu n'as vu ni l'un ni l'autre ?)

[mdr1]

Ensuite, ce dont tu parles est l'optimisation, mais pas le pédagogique que je défendais dans ma thèse. Bien évidemment que ça permet de faire plus d'optimisations de programmer en assembleur, mais l'assembleur est très éloigné de l'algorithmique humaine.

Je ne descendrais pas jusqu'au niveau de l'assembleur, mais bien à celui du C. Le C est bas niveau par rapport au C#, Java et python. Ca suffit pour voir pas mal de problèmes et avoir conscience que le plancher n'est pas mouillé, chose que beaucoup de nouveaux programmeurs de haut niveau oublient.[/quote]
Ok mais il n'y a rien de logique en algorithmique avec les pointeurs.

Ça, ce sera valable tous langages confondus, même en assembleur. Et il sera plus facile de corriger la trajectoire dans des langages plus haut niveau de part l'utilisation de concepts plus faut niveau, contrairement à l'asm où de très nombreuses techniques changeant selon les cas etc. sont présentes.

Ce n'est pas valable dans tous langages confondus car si tu programmes de la merde, en bas niveau ça se voit/sent/ressent. En haut niveau, si tu programmes de la merde, le compilo te dit rien, adapte (il n'optimise donc pas les calculs) et tu te retrouves avec un exécutable qui marche, mais prend des plombes à tourner dans des boucles parc que ça utilise des fonctions time-critical.

Tu veux parler de la "merde" implicite ?
En haut niveau, le compilateur pourra faire des optimisations, et beaucoup plus qu'en bas niveau car il a une vue d'ensemble.
Et en assembleur, même pas du tout. What you program is what the file compiled is.

Personnellement, j'adore programmer en assembleur, mais ce n'est pas du tout un langage ressemblant à "l'algorithmique".

On a, je pense, pas la même vision de l'algorithmique. Etant donné que je n'ai vu ça que dans mon école d'info où la structure algorithmique est elle même basée sur les pointeurs (listes chainées contre listes statiques). Tu as de l'algorithmique au lycée ? (Ou alors tu n'as vu ni l'un ni l'autre ?)

C'est tout pourri ce que j'ai au lycée, et puis ce qu'on fait au lycée y a pas fonctions, graphismes et tout.
Ma vision de l'algorithmique, c'est celle qui est purement logique et sans rapport avec le matériel, et que l'on peut représenter avec des organigrammes.

[Wellen]

Ma vision de l'algorithmique, c'est celle qui est purement logique et sans rapport avec le matériel, et que l'on peut représenter avec des organigrammes.

La même, pour moi c'est le programme "en français".