Epreuve d'info. de l'X (opt.info)

[gardener]

Non, C et pascal sont plus impératifs. Bon évidemment on peut faire du fonctionnel avec pascal et de l'impératif avec CamL, mais c'est pas fait pour.
Je ne sais pas quelle version de CamL est utilisée en prépa, mais l'important n'est pas de connaitre les langages et toutes leurs fonctionnalités sur le bout des doigts, loin de là. L'important est de manipuler des trucs de base (en pascal c'était affectations, fonctions, procedures, listes, boucles, pointeurs, et c'est tout.)

[Dodor]

Le (O)Caml, c'est pas non plus monstrueux à apprendre (tout seul). (du moins la partie suffisante pour la prépa) (donc pas la POO, j'ai fait exclusivement de l'Objective Caml pendant un an et demi en n'utilisant que les modules List, Array + plus rarement String et Char + encore moins, mais très utile pour les TP ENS, même si pas pour celui que j'ai eu, Stack et Queue)
Les sujets de l'X (récents) sont faisables dès la fin de la sup. C'est ce qui fait que beaucoup ont moins que ce qu'ils prévoyaient : ce n'est quasiment que du code, et parfois/souvent, il est nécessaire de faire des fonctions auxiliaires à expliciter précisément, clairement et de manière suffisamment concise. C'est ce que beaucoup oublient. (bon, y a aussi ceux qui ont déjà du mal à coder ce qui est demandé, mais ceux-là sont moins surpris)

Et puis, clairement, la syntaxe du Caml (en général) est beaucoup plus facile à utiliser qu'en C/Pascal. Pas besoin de préciser le type de chaque variable/argument (même si néanmoins possible, quand tu veux que ta fonction ait le type exact demandé par l'énoncé). Le fait qu'il n'y ait pas besoin de compiler (contrairement au C) simplifie également la vie (même si ça devant ta copie, tu t'en fous). Tu as aussi besoin de beaucoup moins de parenthèses.

[FSaad]

Le (O)Caml, c'est pas non plus monstrueux à apprendre (tout seul). (du moins la partie suffisante pour la prépa) (donc pas la POO, j'ai fait exclusivement de l'Objective Caml pendant un an et demi en n'utilisant que les modules List, Array + plus rarement String et Char + encore moins, mais très utile pour les TP ENS, même si pas pour celui que j'ai eu, Stack et Queue)
Les sujets de l'X (récents) sont faisables dès la fin de la sup. C'est ce qui fait que beaucoup ont moins que ce qu'ils prévoyaient : ce n'est quasiment que du code, et parfois/souvent, il est nécessaire de faire des fonctions auxiliaires à expliciter précisément, clairement et de manière suffisamment concise. C'est ce que beaucoup oublient. (bon, y a aussi ceux qui ont déjà du mal à coder ce qui est demandé, mais ceux-là sont moins surpris)

Et puis, clairement, la syntaxe du Caml (en général) est beaucoup plus facile à utiliser qu'en C/Pascal. Pas besoin de préciser le type de chaque variable/argument (même si néanmoins possible, quand tu veux que ta fonction ait le type exact demandé par l'énoncé). Le fait qu'il n'y ait pas besoin de compiler (contrairement au C) simplifie également la vie (même si ça devant ta copie, tu t'en fous). Tu as aussi besoin de beaucoup moins de parenthèses.

Quoi?
O.O
et personne ne sait encore ce qui va nous être enseignez l'année prochaine en sup ?

[Dodor]

En sup, mon prof nous a fait (à peu près dans cet ordre, et aux oublis/énoncés près, avec à chaque fois implémentation dans le langage) :
- bases d'OCaml et introduction à la récursivité
- listes, tris (insertion et fusion)
- impératif : tableau, chaînes de caractères...
- logique
- piles et files (un ou deux cours)

En spé :
- encore de la logique (révisions/compléments ?)
- relations binaires, graphes et arbres
- langages et automates

Et à côté de ça, y a les TD/TP/colles (nom différent selon la personne qui en parle...) où on peut voir d'autre chose dans l'esprit de la prépa.

[VictorVVV]

Le (O)Caml, c'est pas non plus monstrueux à apprendre (tout seul). (du moins la partie suffisante pour la prépa) (donc pas la POO, j'ai fait exclusivement de l'Objective Caml pendant un an et demi en n'utilisant que les modules List, Array + plus rarement String et Char + encore moins, mais très utile pour les TP ENS, même si pas pour celui que j'ai eu, Stack et Queue)
Les sujets de l'X (récents) sont faisables dès la fin de la sup. C'est ce qui fait que beaucoup ont moins que ce qu'ils prévoyaient : ce n'est quasiment que du code, et parfois/souvent, il est nécessaire de faire des fonctions auxiliaires à expliciter précisément, clairement et de manière suffisamment concise. C'est ce que beaucoup oublient. (bon, y a aussi ceux qui ont déjà du mal à coder ce qui est demandé, mais ceux-là sont moins surpris)

Et puis, clairement, la syntaxe du Caml (en général) est beaucoup plus facile à utiliser qu'en C/Pascal. Pas besoin de préciser le type de chaque variable/argument (même si néanmoins possible, quand tu veux que ta fonction ait le type exact demandé par l'énoncé). Le fait qu'il n'y ait pas besoin de compiler (contrairement au C) simplifie également la vie (même si ça devant ta copie, tu t'en fous). Tu as aussi besoin de beaucoup moins de parenthèses.

Quoi?
O.O
et personne ne sait encore ce qui va nous être enseignez l'année prochaine en sup ?

La plupart des variables sont en fait des constantes, donc pré-initialisées, donc on connait leur type.
Pour les vraies variables, elles doivent être initialisées dès le départ donc là aussi on connait leur type.

[beauby]

Tu as aussi besoin de beaucoup moins de parenthèses.

Ca doit être une blague ^^.

[TLN]

Tu as aussi besoin de beaucoup moins de parenthèses.

C'est à la fois vrai et faut. Quand on applique des fonctions, la curryfication fait qu'on se passe généralement allègrement de parenthèse quand on passe les arguments de la fonction. Le fait de nommer aussi les arguments avec des "let a = expr1 in f a" permet de se passer de parenthèse (pas la peine d'écrire "f (expr1)" donc).
Par contre dès qu'il faut écrire un truc dans un if, ou avec des "match with" imbriqués, là ça devient plus technique. Idem pour évaluer des expressions booléennes : de ce point de vue je trouve que la précédence des opérateurs du C est beaucoup mieux faite.

La plupart des variables sont en fait des constantes, donc pré-initialisées, donc on connait leur type.
Pour les vraies variables, elles doivent être initialisées dès le départ donc là aussi on connait leur type.

Ce n'est pas aussi simple que ça. Quand tu écris « let f a b = a + b;; » le compilateur ou l'interpréteur sait déjà que f est de type « int → int → int », même si tu n'utilises pas encore f sur des entiers, tout simplement parce que + est un opérateur infixe qui a le type « int → int → int ».
Mais ce n'est pas toujours aussi immédiat. Prenons un exemple un peu plus intéressant :

Code : Tout sélectionner

let f =
   let a = ref [] in
   function x -> x :: !a

Ca nous donne une fonction de type « '_a -> '_a list », dont le type n'est connu que partiellement ('_a peut être n'importe quoi). Cependant ce n'est pas une fonction polymorphe pour autant, et tu vas pouvoir fixer ce « '_a » par une utilisation ultérieure de f :

Code : Tout sélectionner

f 3;;
f;;

Alors oui on ne modifie pas le contenu de la référence "a", mais n'empêche qu'on ne peut utiliser f que sur un type seulement (changer « let a = ref [] » par « let a = [] » pour obtenir une fonction polymorphe).


Mais bon tout ça, si tu ne le sais pas déjà, tu auras l'occasion d'en entendre parler l'an prochain

[Dodor]

Tu as aussi besoin de beaucoup moins de parenthèses.

C'est à la fois vrai et faux. Quand on applique des fonctions, la curryfication fait qu'on se passe généralement allègrement de parenthèse quand on passe les arguments de la fonction. Le fait de nommer aussi les arguments avec des "let a = expr1 in f a" permet de se passer de parenthèse (pas la peine d'écrire "f (expr1)" donc).

Je suppose que, ici, expr1 n'est pas le nom d'un argument, mais quelque chose du genre "fun1 arg1 arg2".

Pour les "match with" imbriqués, *généralement*, il *suffit* de mettre les motifs *dans le bon ordre*. (mais ce problème est relativement peu fréquent)
Pour les if imbriqués, il faut jongler... (avec les parenthèses et/ou les begin/end quand c'est un peu long) Mais ça doit pas forcément être plus simple en C. (des accolades ? je ne me souviens plus...)

M'enfin, en général, si on est suffisamment propre avec son code, les problèmes de syntaxe (il est vrai, généralement des parenthèses, parfois des ";" manquants...) sont repérables par un œil avisé. C'est pas non plus en J qu'on demande de coder ! (quoi que, ça pourrait être un bon exercice... )

[thom's]

J'ai une question un peu dans le sujet : quand on prend option info, du coup on a aucune chance de tomber sur du Maple aux épreuves de l'X ou des Mines ? J'ai l'impression en regardant les énoncés que finalement, le tronc commun d'informatique (Maple) ne sert par la suite qu'aux SI-stes, et qu'un info n'en entendra plus parler (ça m'arrangerait d'ailleurs, parce que Maple c'est moche, si c'est pour l'utiliser à la manière d'une grosse calculatrice merci je sais faire, mais ça m'intéresse pas )

[nael]

Il n'y a en effet qu'aux oraux de centrale qu'un info peut se retrouver devant un truc de calcul formel.

Tu peux aussi prendre maple au TP d'algo de l'ENS il me semble mais bon ...