Apprentissage des langages
Mala
Membre, Modérateur
dans 1182100592:Je suis étudiant en IUT info, et je viens de finir ma première année, et j'ai trouvé le module de C vraiment trop court et très peu approfondi à mon goût, contrairement au Java (bon ok, je peux pas sacquer les Garbage Collector) qu'on a eu à toutes les sauces. Ce qui m'intéresse ici avec l'Objective-C c'est notamment la gestion de la mémoire, et beaucoup de choses très intéressantes que je commence à voir.
Bienvenue dans ce monde de douceur fait de pointeurs et de gestion mémoire bien loin de la bulle de tes profs... Non pas que je n'aime pas le Java (Bon ok, je ne peux pas sacquer le Garbage Collector
) mais c'est l'usage abusif qui en est fait niveau scolaire qui m'effare. Sous réserve d'apprendre un véritable langage objet, on fait l'impasse sur beaucoup trop de notions de base pourtant utiles à la formation de développeurs solides.En tous les cas, bienvenue!
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est vrai que trouve ça dommage de ne pas approfondir plus des langages où la gestion de la mémoire est manuelle, parce que bon, ok le Java se développe, mais le Java c'est bien que pour certaines applis, après aller faire un CS4 en Java, va falloir une vie pour appliquer une pauvre petit filtre.
Par contre d'après ce que j'ai cru comprendre, la nouvelle version 2.0 de l'Objective-C qui sortira avec Leopard aura un pseudo "garbage collector" il me semble.
Tout a fait. A croire qu'ils veulent faire de l'oeil aux programmeurs Java parce qu'il n'y a plus que ça aujourd'hui.
Je développe essentiellement en java dans le cadre d'application web 3 tiers, comme la plupart des développeurs java.
Donc je ne pense pas que l'on puisse comparer le Framework Cocoa et le langage objective-c à Java même si il est possible de réaliser des applications java basé sur un design pattern MVC.
Il est quand même très rare de voir une application mac écrite entièrement en Java ou même en Cocoa associé à du code java.
Pour ce qui est de la gestion de la mémoire je ne pense pas que ce soit la faute du garbage collector de Java qui soit fautif. Car avant même de commencer à apprendre le Java on apprend généralement le c, puis le c++.
Microsoft et le langage C# est le langage le plus enseigné dans les IUT et BTS (C'est le marché qui veut ça), à l'instar de Visual Basics il y quelques années et est malheureusement responsable de cette mauvaise habitude.
Pour le C#, je ne peux pas l'affirmer mais il ne me semble pas qu'il soit au programme de mon DUT, par contre un ami en Master l'a étudié seulement à ce moment là .
Edith: J'ai vu le bouquin "Cocoa par la pratique" dans la section débutant qui était conseillé.
Sachant que j'ai réussi à imprimer "Cocoa Fundamentals Guide" et "The Objective-C Language", est-il nécessaire de me le procurer, que pourrait-il apporter de plus que ces pdf ? Même question pour un bouquin sur le même site http://www.eyrolles.com/Informatique/Livre/9780596003012/livre-learning-cocoa-with-objective-c.php
ou encore celui ci [url=http://là ]http://www.eyrolles.com/Informatique/Livre/9780672325861/livre-programming-in-objective-c.php[/url]
ne cherche pas plus loin
Ayant fait un IUT Info industrielle, j'ai commencé par de l'assembleur, du C et enfin du langage objet avec le C++. Et là on déroule la pelote de laine dans le bon sens. L'assembleur permet ainsi de bien comprendre les pointeurs ainsi que l'adressage mémoire et une fois qu'on a compris le C en tant que language procédural (qui est déjà un sacré plus par rapport à l'assembleur), on est en mesure d'apprécier le confort qu'apporte une approche objet.
Ce n'est donc bien évidement pas a Java en lui même que je m'en prends mais à l'usage qui en est fait pour former les futurs diplômés. 80% de ces derniers ne jureront que par ce langage pour la simple et bonne raison qu'il ne connaà®tront quasiment rien d'autre.
Et ça c'est très dommage mais, comme tu le dis, il y a quelques années c'était le VB...
En fait, le Java offre de très bonnes performances en calcul pur aujourd'hui. La JVM a beaucoup évolué depuis ses débuts mais malheureusement Java traà®ne toujours cette réputation. C'est surtout sur la gestion mémoire que des langages comme le C++ conservent leur avance.
Pour ma part j'ai fait un IUT Informatique et un BTS Informatique dans les deux j'ai heureusement eu la chance d'avoir des professeurs ayant une certaines logique et surtout une passion pour l'informatique.
Mais je sais et je l'ai vu de mes propres yeux certains professeurs issu d'entreprise privé qui ne jure que par la plateforme .net. Cela est du essentiellement à la demande du marché actuel. Dans ma région (Languedoc-Roussillon) énormément d'entreprise propose des progiciels autour de la suite bureautique office et ne cherche que des développeurs orienté .net et cela et bien dommage.
Mais le mal est réparé et la discussion est maintenant dans un forum approprié, donc vous n'avez plus aucune excuse pour vous lacher.
Donc pour rester dans le sujet (puisque maintenant on y est bien), oui c'est assez hallucinant ces dérives au niveau formation. Mais le pire c'est que je suis persuadé qu'ils font ça en toute bonne foie sans voir le mal. Le risque a terme est de faire des développeurs trop spécialisés (dans le mauvais sens du terme). Mais que ce passera-t-il lorsque .Net sera passé de mode (comme d'autres avant lui)?
Mais je reste confiant. Tant qu'il y aura des Mulots à regarder un peu plus loin que le bout de leur code...
Ah, je fais du hors sujet.
Bon pour revenir au sujet, ça ne me choque en fait pas trop (mais bon, comme je suis pas informaticien, mon avis est peut-être biaisé)
- les études servent à apprendre à apprendre, pas à accumuler des connaissances qui sont de toutes façons oubliées dès que l'examen est passé
- on ne sait "rien" en sortant de l'école, bien souvent les beaux principes enseignés sont radicalement transformés par la réalité du marché et on doit de toute façon se (re)former sur le tas
- il faut bien étudier "quelque chose", et si le marché est demandeur pour du .net pourquoi pas, mais tant que cela n'exclut pas de voir à côté d'autres frameworks pour que l'étudiant ait eu l'occasion de jouer avec d'autres approches (même si perso, je trouverais plus intelligent de faire du QT ou GTK)
- le terme "informaticien" est très vague non? Il y a une grosse différence d'approche entre un développeur de "bibiliothèques" et "pour end-user", dans un cas, les performances sont souvent critiques et savoir de quoi on parle est mieux, mais dans l'autre la connaissance du bas niveau me semble pas nécessaire. Exemple: je suis sûr qu'on peut faire des applis très réactives en utilisant CocoaRuby tous les appels "non critiques". Il me semble que la majorité des postes va au deuxième type? Et il y a surement des filières plus spécialisées pour les "bibliothèqueux" non?
Sinon pour ce qui est de la gestion automatique de la mémoire dans le cadre de développement d'applis "finales", ça me dérange si les performances sont moins bonnes, mais si on arrive à un niveau comparable de performance, voire meilleur, pourquoi s'en priver?
Oubliées certes, mais très vite retrouvées si elles ont été intelligemment absorbées.
Pas d'accord. Il faut avoir quelques modèles de bases en tête qui servent de références, et le C est parfait pour cela. Cela permet d'avoir une logique de fonctionnement, et non un épais catalogue désordonné.
Si le marché est orienté .net, je n'ai rien contre mais comme le dis mala il ne faut pas qu'il est une génération de développeur focalisé sur des technologies et qui ne cherche pas à en découvrir d'autres.
Aujourd'hui, le propre de l'informaticien est de savoir s'adapter à tout les cas de figure et ceci quelque soit la technologie utilisé et pour finir il doit ce former en permanence.
Je n'ai pas été assez clair: je ne dis pas qu'il reste rien après un examen (sinon faire des études ne sert à rien), mais ce qu'il en reste généralement ne sont pas des trucs aussi superficiels que des noms de fonctions, mais les principes de base et surtout (normalement) comment se servir utilement d'une doc pour retrouver l'info "oubliée" (c'est ça que j'entends par "apprendre à apprendre"). Donc en résumé, ce qui reste est une démarche et des principes de base, qu'on peut généralement appliquer à d'autres domaines.
- C'est du pur objet
- Y'a un Garbage Collector
Donc finalement si on apprend que ce langage, on n'a pas forcément conscience complètement de la logique objet dans le sens les principes qu'elle apporte en plus par rapport à un langage comme le C. Si on apprend le C puis le Java, on prend pleinement conscience que "wow c'est super puissant l'objet", et on voit pourquoi l'utiliser et quand c'est mieux de s'en passer (par exemple en algorithmie pure), alors que sinon on ne connait rien d'autre et on a été formatté à ça donc on ne cherche pas forcément à aller ailleurs.
Et pour le GC c'est pareil, si on a fait que du Java avec son GC, on n'acquiert pas la logique des mécanismes de gestion de mémoire ou d'optimisation, ou les règles de "c'est moi qui alloue donc c'est moi qui delete", etc.
Donc quand on en vient à aller sur d'autres langages, on est perdu, on trouve que c'est chiant de gérer la mémoire soi-même ou que tout ne soit pas objet, et on trouve tout les autres langages nuls en ne jurant que par Java. C'est un peu caricatural mais pourtant je connais des cas
Dans ce cas ce genre de personnes tu leur parles de QT, de C, de C++ ou d'Objective-C, ils iront pas plus loin que de te dire "ouais mais ça on a déjà dans Java, de toute façon Java c'est trop de la balle y'a que ça de vrai". Tu vas me dire, les gens comme ça ils sont butés ça n'a rien à voir, mais moi je pense que si au contraire : le fait qu'ils aient été "formattés" au Java pendant leur études joue énormément.
C'est un peu comme ceux qui n'ont été formatté dans leurs études qu'à Windows et Visual, ils n'ont eu d'expérience qu'avec ça et ne jurent que par ça, sans avoir gouté aux autres possibilités.
Donc de toute façon le mieux est à mon avis de faire un peu son touche-à -tout (côté langages, frameworks, etc) pour pouvoir avoir une vision d'ensemble, pouvoir comparer, savoir ce qui est le mieux à utiliser dans tel ou tel cas, et savoir reprendre des concepts intéressants de chacun. Et pour ça fait bien avoir un éventail minimum au départ du côté des études, sinon beaucoup ne vont pas chercher plus loin. Ou commencent par le Java, et font ensuite du C mais ça les dégoutte par rapport à ce qu'ils ont gouté du Java, donc s'arrêtent là ...
Autre exemple, pour rester dans le cas de Mulot qui parlait de traitement d'images à un moment. Combien de programmeurs formés à Java sont conscients que leur algos prennent 2x plus de mémoire qu'un programme C sur de simples allocations de matrices? Et cela parce que Java n'implémente pas la notion de variables non signées. Et le jour où il doivent développer quelque chose en C/C++ et bien il vont conserver leurs automatismes d'allouer des matrices d'un octet supérieur.
Maintenant, imaginons que l'on traite un lot d'images à la chaà®ne. En Obj-C, on va s'empresser d'ajouter un pool pour libérer les objets autorelease (notamment les représentations bitmap qui montent très vite) dans la boucle de traitement. Quel sera le réflexe d'un programmeur qui a été bercé dans les garbage collectors? Et bien pour l'avoir constaté là encore avec un stagiaire: aucune. Il n'a même pas pris la peine d'ouvrir le moniteur d'activité pour jeter un oeil.
Là où un programmeur a une vision fine de sa gestion mémoire, les garbage collectors laissent la machine mouliner un moment. J'espère me tromper avec celui d'Obj-C et qu'il sera très efficace mais pour le moment je n'ai jamais été convaincu à l'usage avec d'autres langages. Je répète ce que j'ai dit plus haut mais, jusqu'à preuve du contraire dans quelques mois, je reste persuadé que dans le cas d'Obj-C c'est avant tout une opération marketing pour "séduire" les développeurs Java.
Edit: mon message fait un peu redondance avec Ali. Il a posté plus vite que moi!
Tout a fait. Et dans ce cas, il n'y a guère que les passionnés qui comprennent l'intérêt d'aller voir plus loin. D'un autre côté, ça filtre... ::)
"les jeunes actuellement, c'est la catastrophe, ils considèrent que leur travail est bien fait lorsqu'il n'y a pas d'erreur à la compilation".
Les arguments que vous donnez vont dans ce sens et sont plutôt révélateurs d'un état d'esprit qu'il y a chez beaucoup de gens: du moment que le travail est fait, c'est bon, peu importe qu'il soit bien fait ou non.
Et quand tu parles "d'automatisme d'allouer des matrices d'un octet supérieur", ce que j'aurais envie de te répondre est: un gars qui a déjà des automatismes à la sortie de l'école ça c'est grave (que ce soit en Java ou C), alors qu'il me semble que s'il y a bien une chose qu'une école devrait apprendre, c'est l'esprit critique. Et un type compétent pour moi, c'est avant tout quelqu'un qui a l'esprit critique et qui est curieux, le chemin qu'il a pris pour apprendre est un plus évidemment, mais trop se focaliser dessus peut parfois être une erreur.
Pour prendre mon cas personnel, j'ai commencé avec le Basic (ce qui est le pire, d'après ce que j'ai pu comprendre), puis je suis passé à l'objective-c, et ce n'est pas pour autant que j'autorelease à tout bout de champ ou que je mélange complètement les 3 couches du MVC ou que je redessine ma vue complètement dans chaque drawRect:...
Parenthèse: je trouve que l'autorelease pool est une des pires idées de Foundation. Pour ceux qui trouvent que c'est en contradiction avec mon affirmation précédente sur les GC, voici l'explication: l'autorelease pool pour moi est un travail à moitié fait: ou on fait du full manuel, ou on fait de l'automatique complet et on le fait au bon moment (c'est à dire au moment des allocations). L'autorelease pool, ce n'est rien d'autre que "reporter" un problème.
En ce qui concerne l'ordre dans lequel on doit aborder les langages, il ne faut pas se focaliser sur Java, C ou C++.
Ce qui est important (à mes yeux), c'est plus la "philosophie" du langage.
J'ai du mal à concevoir un cursus informatique où on ne commencerai pas par l'apprentissage de l'analyse (que ce soit de l'algorythmique de base ou tout autre méthode plus évoluée).
Ensuite, vient le temps de la découverte des langages procéduraux. C'est la base de la programmation : même l'objet est procédural. Ici des langages comme C, Pascal, ou VB peuvent faire office.
Enfin, temps moderne oblige, il faut finir par les langages POO.
Du reste, on peut apprendre le procédural avec Java (une simple classe avec son main() peut faire illusion, sans entrer dans l'approche objet immédiatement).
.
Le problème c'est que tu voudrais généraliser ton cas. Hors tu es le prototype même du programmeur motivé par la passion. Et cela fait une énorme différence dans la faculté d'apprentissage. Mais si, tout comme moi il y a quelques années, tu penses que les programmeurs sont tous des gens passionnés et bein non c'est loin d'être le cas. A titre d'exemple, ma promo il y a une dizaine d'années comprenait 50% de Bac S Bio qui venaient là parce que ça leur semblait intéressant et qu'il y avait du débouché. Mon binôme n'avait même jamais utilisé un clavier de PC...
Beaucoup de gens font de l'informatique pour manger et tu peux toujours leur venter les mérites de tel ou tel chose et bien ils s'assoiront gentiment dessus s'ils n'y ont pas été correctement sensibilisé au départ.
Après effectivement le langage en soit n'est pas le plus important mais chaque langage apporte des approches complémentaires (capacité d'introspection pour le java ou l'Obj-C, héritage multiple pour le C++, etc). Enseigné dans un ordre logique (afin d'éviter les frustrations qu'évoquait Ali) cela fait toute la différence une fois sur le terrain.
C'est vrai qu'on a zappé un peu ce point. C'est effectivement la première étape et généralement elle se prolonge en parallèle de l'apprentissage des langages.
Non non, je ne voulais pas généraliser mon cas, mon but était plutôt de te donner un contre exemple qu'un programmeur "mono-culture" (puisque je me considère comme tel) n'allait pas forcément toujours transposer son ancien "savoir" lorsqu'il passait à autre chose. Mais c'est vrai, comme tu le soulignes c'est mal choisi.
Dans mon cursus j'ai eu quelques cours de stats et rien que dans ces cours j'ai utilisé 3 logiciels différents (Minitab, SAP et R - et en utilisant fichiers de script plutôt que l'interface graphique) et je ne parle pas d'autres logiciels que j'ai du utiliser pour d'autres cours. Donc en faisant cette bête transposition, je n'aurais jamais pensé qu'une filière consacrée à ce domaine soit formattée à ce point: faire surtout du Java/.net ne choque pas, mais de là à ne faire que ça.
Je suis entièrement d'accord avec Bru sur ces différents points.
Il est clair que commencer à travailler sur un langage, quel qu'il soit sans savoir comment procéder de manière abstraite pour résoudre un problème (abstraite au sens indépendant du langage) est indispensable si l'on veut faire autre chose que afficher "Hello World !" en cliquant sur un bouton ou bien faire "sonner" son ordinateur avec un équivalent de NSBeep(). Bien sûr, c'est beaucoup moins drôle de faire de l'algo que de la programmation tout de suite, mais ca permet de se concenter sur l'efficacité (le fond) plutôt que sur le code lui-même, écrit dans un langage donné (la forme).
En ce qui concerne l'apprentissage des langage, je pense qu'une des choses acquises aujourd'hui est que la connaissance (du moins superficielle, c'est-à -dire la syntaxe et la philosophie) C est essentielle quand on veut programmer si ce n'est par le fait que tous les langages dont vous parlez depuis le début de cette discussion sont tous issus du C. De même, il est très important de savoir que sont les langages orientés objets et d'en saisir la différence avec les non-OO. Pour cela, je suis convaincu que le Java est un langage excellent. En effet, on peut commencer à faire sentir la puissance de langage procéduraux comme le C avec les fonction en particulier tout en ne se souciant pas de suite des problèmes de gestion mémoire qui sont, somme toute, assez compliqués et qui donc, à mon avis, ne peuvent pas être saisis dans toute leur complexité sans avoir a priori programmé un minimun des choses comme des tableaux ou des matrices ...
De même, je trouve un peu bête de faire apprendre des langages de POO sans jamais avoir toucher à la PNOO (sinon, aucune connaisance de ce que sont les fonctions ou les types ...). C'est pour cette raison que Java est excellent. En effet Java a un aspect non orienté objet ( et qui permet de faire des programmes de calcul de racine carrée par exemple ...) et un aspect OO qui permet, entre autre, de gérer l'UI ou les réseaux. On peut traiter ces aspects séparément et Java est donc, a mon avis, un excellent langage d'apprentissage à part pour la gestion mémoire (le GC ne le permet pas).
Bien sûr, on peut apprendre avec le C, mais il pose un concept qui, a mon avis, n'est pas essentiel dans une première approche mais qui est extraordinairement puissant et un poil complexe, les pointeurs. Malheureusement, comme le C ne permet pas des choses comme la création de tableau de taille non définie à la compil' sans pointeurs, ca devient très galère de faire apprendre les rudiments de l'algo des matrices avec les C à des gens qui n'ont pas fait bcp de prog, je ne le considère pas idéal pour commencer.
euh ben si on peut faire (depuis la norme C99)
scanf("%d",&N);
int tab[N];
Il n'y a rien de complexe dans les pointeurs : il s'agit tout simplement de savoir où sont en machine les données que l'on manipule, et éventuellement de le mémoriser.
Les adresses s'introduisent naturellement dès qu'on parle de tableau et de chaà®ne de caractères et cela ne pose pas de problème. D'ailleurs à un premier niveau d'apprentissage, il y a peu de différences entre une adresse et un indice ...
Bien sur, on attend pour les doubles pointeurs, les pointeurs de fonctions ...
NON , et NON
Le modèle informatique des tableaux et matrices a une logique spécifique par rapport au modèle associé en mathématique. Il faut donc en informatique, introduire très rapidement le modèle adressé (qui est très simple) afin de ne pas brouiller les cartes.
Ce modèle d'ailleurs explique ensuite naturellement la notion de structure .
Pour bien comprendre un livre, on commence par le début.
Avant d'apprendre les tables de multiplications, on apprend à compter.
Avant d'apprendre à lire, on apprend l'alphabet.
Etc.
Bon, sur ce coup, je savais absolument pas, étant donné que toutes les fois où j'ai fait un truc dans ce genre ca me gueulais dessus ...
Non, c'est sûr que les pointeurs, ce n'est pas non plus la mer à boire, mais il se trouve que c'est quand même moins évident a manipuler que les indices : par exemple faire un transfert de valeur par pointeurs dans une fonction c'est pas évident pour quelqu'un qui débute Ca ne peut pas être expliqué par un simple : tu as une fonction
[tt]void f(int val, int *ptr){
*ptr = val;
} [/tt] avec laquelle tu passes la valeur de val dans la variable pointée par ptr. Traiter les pointeurs qu'a moitié (que sur leur aspect d'indices en expliquant juste qu'un pointeur c'est une sorte d'accesseur d'un tableau) fait perdre beaucoup d'intérêt à la notion de pointeurs, même si cet apprentissage n'est pas insurmontable.
Ok, je sais parfaitement que sur les tableau et les matrices, maths et info ne sont pas vraiment équivalent, mais ce dont je parlais est le problème de la gestion de la mémoire qui apparaà®t quand on souhaite travailler avec des tableaux à taille variable ou des chaà®nes de caractères (en tous cas, en ce qui concerne le C) étant donné que toute allocation d'un bloc d'octets en mémoire peut-être ramenée (du moins toujours pour le C) à la création d'un tableau d'octets. En ce sens, je trouve qu'il est important de connaà®tre les tableaux et leur pendant, les pointeurs.
La, par contre, je suis pas sûr de te suivre.
Parfaitement d'accord. En fait, le petit ennui avec moi quand je parle de tout cela, c'est que je ne suis ni prof, ni étudiant en info (ni vraiment étudiant tout cours) et que ce que je sais, je l'ai appris tout seul en lisant des bouquins et des articles sur le web - comme pas mal de gens ici, j'imagine
Gestion mémoire à la mano, Autorelease pool, Garbage Collector. Votre sentiment?
Il faut pourtant absorber intelligemment scanf("%d",&N) et scanf("%s",s); qui est de la même nature que le problème du passage par valeurs (ici la valeur de l'adresse) que tu indiques.
Là je ne suis pas d'accord avec un "vous comprendrez quand vous serez plus grand" qui est souvent donné à ce stade. Je préfère dire ce qui se passe "physiquement"
C'est indispensable de parler vite d'adresse pour comprendre la grande majorité des fonctions sur les chaà®nes
Comprendre l'allocation d'une zone mémoire par référence à un tableau me semble mettre les choses à l'envers. Je m'explique : ce qui "existe physiquement" c'est la mémoire, donc la visualisation de la mémoire précède conceptuellement la notion de tableau. (même si je suis mathématicien de formation)
Là encore une structure (et par la suite les objets) n'est qu'un simple bloc mémoire dont la structure est donnée par la définition de celle-ci.
Ultra-simple à voir en interprétation mémoire.
Les gens compliqués parleront de tableau à tailles variables, mais là cela devient du délire par rapport à la simplicité de la visualisation en adresse.
Toujours une mauvaise idée le "vous comprendrez quand vous serez plus grand" en ce qui concerne les sciences quand il est possible d'expliquer.
Ha, je suis pas le seul à avoir ce pb de rapprochement constant entre maths et info ...
Non, j'entendais juste par là que les blocs mémoire en info peuvent être rapprocher à des listes en maths et donc, une fois que l'on connais juste ce qu'est un tableau en info, a un tableau. Il s'agit juste d'un rapprochement sur un fonctionnement et une représentation et non sur la nature même de l'objet lui-même
On est globalement d'accord, mais étant donné que je suis un peu jeune pour avoir eu (ou fait ...) aucun cours sur le sujet, je n'ai aucune experience des détails ...
Oui je l'avais compris comme cela, et nos points de vue ne sont pas éloignés.
J'ai du avori beaucoup de chance, car dans ma formation Scientifique puis d'ingénieur Génie Civil, qui n'a donc à priori rien à voir avec l'informatique, j'ai eu droit, dans l'ordre :
- à un cours d'algorithmique, et donc l'avantage énorme de l'abstraction du langage pour orienter sa réflexion sur la résolution du problème et non sur les subtilités de tel ou tel autre langage.
- à un cours de C, ou la prof faisait des gesticulations inconsidérées et des schémas et contre schémas pour que tout le monde puisse bien comprendre la logique des pointeurs et le fonctionnement de la mémoire...