Version imprimable
J'ai fait mes choix, je continu le C avec le livre de Braquelaire: "Méthodologie de la programmation en C".
Et comme langage complémentaire je prends le ruby qui m'a l'air excellent!
Reste à trouver de bons tutos complets en français.
MERCI TOUS POUR VOTRE AIDE PRECIEUSE!!!
le c++ est un tres bon language qui permet en autre de comprendre le fonctionnement interne de Java ou de C#, puis on apprend et on comprend pourquoi le c++ a été designé de cette facon, et le style de programmation evolue nettement dans le temps. Le c c'est bien mais c++ permet d'aller plus loin, plus vite en moins de ligne de code.
ObjectiveC a une syntaxe proche de smalltalk, assez deroutant mais flexible. il n'y a que le mac qui l'utilise donc pas d'avenir finalement.
Reste que maintenant je te conseille aussi de regarder Java et C#, ils sont presents pour beaucoup d'applications et suffisent pour la majorité d'entre eux.
il ne faut plus penser en terme de libraries, mais en terme d'applications.
En clair, ne plus chercher une lib qui fait un traitement, mais regarder quelle appli lancer pour faire le travail. Le composant est revolu, place a l'applicatif. c'est pour ca qu'il est important d'etre multi-language, ouvert et tres curieux.
voila a+
Le C est très certainement le langage que tout programmeur se doit de connaître, et ce pour différentes raisons, entre autres pour les qualités et possibilités d'interfaçage qu'il offre avec la plupart des langages de programmation, mais aussi pour son efficacité, une fois bien maîtrisé.Citation:
Envoyé par 0v3rb1t
Je trouve que c'est un très bon choix que de continuer, voire approfondir le C, et se spécialiser dans un autre langage, plus général et plus haut niveau.
Il ne faut surtout pas tomber dans la pratique que l'on voit trop courament dans certaines écoles d'ingénieurs spécialisées en informatique et mathématiques appliquées, d'où les élèves sortent, leur diplôme en poche, connaissant tout de Java, Tomcat, Log4j, et autres... , mais ne sachant absolument pas utiliser ni même comprendre, les notions les plus élémentaires du C, comme les pointeurs !
Moi, ce genre de situation, ça me fait toujours halluciner !
Citation:
Envoyé par InOCamlWeTrust
+1... c'est fou, on pense presque la même chose, bizarre ;)
mais perso, autant je pense qu'il est important d'approfondir, autant je ne dirais pas la même chose du C++, vu la multitude de langages objets "similaires" qui existent
j'étaye un peu :
loin de moi l'envie de critiquer le langage objet que je maitrise le mieux, je trouve qu'il autorise parfois trop de modification syntaxique qui finisse par rendre le code incompréhensible, tout comme les différents niveaux de polymorphismes présents :roll:
Juste une petite parallele par rapport au sujet en lui-même...
Avant meme d'envisager l'étude d'un langage particulier, j'aurais personnellement tendance à conseiller tres largement l'étude générale de méthodes "d'algorithmie"...
En effet, un ordinateur est tres "carré" dans sa manière de voir les choses, et si on te demande de casser un oeuf et d'en séparer le jaune du blanc, tu devrais pouvoir y arriver avec des explications simples... alors que l'ordinateur, si tu ne lui dit pas clairement comment le faire (en mettant qu'il aie un système lui permettant de tenir l'oeuf ;)) et, surtout, comment réagir aux différentes possiblités qui peuvent apparaitre (ex: le jaune part à gauche, à droite, vers l'avant ou vers l'arriere), toute situation que tu n'auras pas envisagée impliquera le plantage de l'application si elle vient à arriver...
L'idée de l'algorithmie, c'est de réfléchir aussi en profondeur que possible à l'ensemble de la logique qu'il faudra mettre en oeuvre pour obtenir un résultat dont tu seras sur qu'il correspond à ce que tu attends.
Les termes "aussi en profondeur que possible" sont très imprécis, mais, cela signifie que, une fois que tu as définis l'ordre logique dans laquelle les choses doivent arriver, il est bon de penser à tout ce qui peut aller de travers (en partant sur un premier a priori du genre de "l'utilisateur est un imb:aie: distrait, et est tout à fait capable de vouloir mettre une lettre là où je veux un chiffre ou de vouloir introduire une chaine de 20 caractères là où je n'en attend que 10"... ou "et si c'est pas l'utilisateur qui foire, peut etre le système n'est il simplement pas en mesure de faire ce que je demande"
Il existe de nombreuses méthodes, dont tu as peut etre entendu parler, comme le flowchart, très visuel, mais peu adapté à la représentation des boucles (à mon gout), l'UML, particulièrement adapté à la conception orientée objet, le nassichneiderman, qui permet, quand il est correctement mis en oeuvre, d'avoir une traduction immédiate, dans le cadre du développement séquentiel, ou le jakson, qui est particulièrement intéressant quand tu t'attaques à un probleme de "ruptures"
La méthode dite "du pseudo code" ne présente quant à elle, de mon avis, que je n'oblige forcément personne à respecter, qu'un intéret fort limité, hormis que ce soit l'une des seules méthodes qui ne nécessite pas le recours quasi systématique à des images ;)
Toutes ces techniques, avec leurs avantages et leurs inconvéniants, ont ceci en commun, si tu les applique correctement, qu'elles te fournissent de manière détaillée l'ensemble de la logique à mettre en oeuvre avant meme d'en venir à écrire la première ligne de code...
Il s'en suit, hormis dans le cas où tu te rends compte lors de l'écriture du code que tu n'as pas pris un cas en considération, que tu n'as plus à t'inquiéter de la logique, et que l'écriture de ton code devient de la "simple traduction" (cf mon post précédent indiquant le code de boucles en différents langages ;))
L'expérience montre que, meme pour des petites applications simples, on gagne énormément de temps à mettre ces techniques en oeuvre, bien que l'on commence à écrire le code sans doute de nombreuses minutes apres quelqu'un qui ne les mettrait pas en oeuvre... Et que le résultat est généralement "de meilleure qualité".
Le gain de temps vient de plusieurs facteurs, dont celui d'avoir un appercu "global" des séquences logiques au lieu de devoir se poser la question de "qu'est-il maintenant opportun que je fasse" entre chaque ligne de code et, surtout, de gagner du temps en "debuggage" car une grande partie des erreurs seront simplement "syntaxique" (oubli d'une parenthese, d'un point virgule, d'un caractère quelconque, fautes de frappe)...
Bien souvent, la première compilation sans erreur (sans fautes syntaxiques), si la logique a correctement été suivie, sera AUSSI la première compilation efficace de l'application... Libre à toi alors de voir s'il n'est pas intéressant de modifier la logique (peut etre une boucle "jusque" serait-elle préférable à ma boucle "tant que"?")
Evidemment, l'inconvéniant d'étudier d'abord une méthode d'algorithmie, c'est que ca retarde l'écriture de ta première ligne de code... vu que tu commence par apprendre la théorie...
Mais le gain par la suite est considérable ;)
Et en plus, ça permet de prendre de la hauteur :mouarf:Citation:
Envoyé par koala01
Faut pas écrire des posts à 4h du matin, faut dormir ! :aie:
Honnêtement, l'UML, je n'en pense pas que du bien : c'est extrêmement lourd, tout comme tous les langages TOUT objet (j'insiste sur le TOUT : n'allez pas me faire dire quelque chose que je n'ai jamais dit !)... De plus, je ne vois vraiment pas ce que ça vient faire avec l'algorithmie !
Par contre, l'UML peut être un bon moyen si l'on veut voir un peu les dépendances entre classes...
Il ne faut pas se voiler la face : il n'existe aucun modèle donnant la solution toute cuite et il n'en existera jamais, et ce pour plusieurs raisons. Les problèmes sont extrêmement divers ; et l'approche algorithmique, bien qu'il en existe plusieurs modèles, est fortement liée au langage utilisé, voire au type de langage : on ne raisonne pas pareil en C++, en PROLOG et en Haskell, et des algorithmes inconcevables en C seront extrêmement efficaces écrits en Haskel par exemple.
La meilleure façon pour réussir à écrire des algorithmes compliqués dans un langage de programmation, c'est surtout, surtout, surtout, de ne pas foncer tête baissée dans la partie programmation.
Réfléchir 10 heures peut épargner plusieurs semaines de débugage et surtout permet de créer un code clair, concis, lisible et efficace, si on s'y prend bien.
Je dirais aussi qu'il est bon de ne jamais commencer à programmer tant que l'on ne dispose pas de tous les éléments pour implanter l'algorithme : si on commence à programmer et que l'on n'a aucune idée de la structure de données à utiliser pour l'étape suivante, ni même de la façon de procéder, alors il se peut que l'on ait dans un futur proche à repenser entièrement le schmilblik... tout simplement car on se sera rendu compte que l'étape d'après avait aussi beaucoup d'influence sur ce que l'on était en train de programmer il y a deux minutes.
Bien, je l'ai dit dés le départ, les méthodes d'algorithmie ont toutes leurs avantages et leurs inconvéniants...
L'UML, car on parle de lui, sera, pour une partie de ce qu'il contient du moins, particulièrement efficace sur des gros projets, y compris en non orienté objet...
Je penses par exemple aux use cases ou aux diagrames de collaboration
Le flowchart, s'il est peu efficace avec les langage "de troisième génération" (proches du langage parlé), sera redoutable d'efficacité en assembleur
Le nassichneiderman, ce sera plutot le contraire...
Le jackson, s'il sera redoutable d'efficacité dans une gestion de ruptures (ou dans une première étape de préparation de gestion de ruptures) n'est pas pour autant si pratique que cela pour une gestion plus "linéaire" ou utilisant plus des tests que des boucles imbriquées.
Et puis, il y a effectivement le fait qu'il n'y a jamais qu'un seul moyen d'arriver à un résultat, et que certains sont plus efficaces que d'autres...
Un algorithme "merveilleux" d'efficacité dans une situation peut s'avérer catastrophique dans une autre... Mais il continuera malgré tout à réagir exactement de la manière dont on s'y attend...Et, bien que mettant peut etre dix foix plus de temps pour obtenir un résultat, si la logique est bonne et correctement étudiée, le résultat sera malgré tout correct et valable...
A l'usage (du langage), si l'on se rend compte que le fait de suivre une logique plutot qu'une autre permet, effectivement, de diviser le temps de traitement par dix, il sera sans doute opportun d'en prendre note... Mais ce seront des constatation "ampiriques" que chacun doit etre amené à faire à coup d'essai ;)
Zorro==>De fait, j'ai inversé les lettres, je corrige ;)
UML est un langage de modélisation. Il sert à expliquer de façon relativement "standard" (le mot est peut-être mal choisi) la structure d'un logiciel ou d'un composant, ainsi que les interactions entre des composants (classes, modules, ou objets, selon le diagramme utilisé).Citation:
Envoyé par InOCamlWeTrust
Tu peux en penser ce que tu veux, c'est ton choix ;) Mais je ne vois pas en quoi faire un diagramme de classe est plus "lourd" que rédiger une doc de 50 pages pour expliquer la même chose sans faire de schéma...
Quoi qu'il en soit, on s'écarte un peu du sujet, là.
Pas vraiment une bonne recommendation ça...J'espère que Luc Hermitte ne va pas passer par là; sinon il va sortir son fusil à canon scié, on te reverra plus jamais sur ce forum :mouarf:Citation:
Envoyé par Franck.H
objective C est LE langage a connaitre pour le developpement sur MacOsX , avec le framework Cocoa , tu fait les choses TRES facilement :) (c'est bien plus simple que le C++)
Citation:
Envoyé par kedare
en gros, c'est d'un intérêt assez limité... :roll:
Citation:
Envoyé par Gnux
+1... je ne sais pas vraiment ce qu'en pense Luc Hermitte, mais espérer faire du C++ en encapsulant beaucoup de C dans des classes te donnera des "perfs à la Java" :roll:
J'en pense que c'est du ressucé déjà débattu dans tous les sens. Et qu'il est tard.Citation:
Envoyé par gorgonite
Et puis Jean Marc a dit l'essentiel, même si son message sur ce point (apprentissage) me parait être passé complètement inaperçu.
Si je devais rajouter des choses
+ du C: ABI (=> c'est la référence en termes d'interopérabilité), meilleur support sur les platerformes de niches comme les embarqués, langua franca (?) des informaticiens
+ du C++: supporte pratiquement tout le C (au détail de l'absence d'ABI, et des petits points de syntaxe), et en plus: meilleur typage (merci la généricité), plus newbs friendly (faut-il encore que les newbs apprennent le C++ et non pas le C avec classes), un aspect OO non bridé (contrairement à deux autres langages mainstream plus à la mode) (et non parfait), richesse dans les sémantiques que l'on peut conférer à nos types, définitement bien plus que seulement OO (-> généricité + métaprog (qui est un nouveau langage, trop verbeux, en soit)).
Ah! Pour les pertes de perfs, faut arréter de fumer. -> "filetype:pdf n1666", et quantité de posts ici.
L'UML me parait un peu dépassé pour le C++. Il ne me parait pas pouvoir représenter les richesses, et compléxités quand on abuse, de modélisation propres au C++. Bon maintenant j'en ai peut-être une vision superficielle et le boulot de Coplien me laisse entrevoir d'autres choses.
Je pense que ct du au fait que son message très carré n'appelait aucune réponse...D'habitude c'était ta partie ça, c'est pour ça...Citation:
Envoyé par Luc Hermitte
Maintenant je pense aussi qu'il y a clairement un problème dans l'enseignement même du C++ que l'on tend à enseigner (en france tout au moins) à la C...Genre plutot que d'utiliser les facilités de la STL, on utilise des constructions C avec un "enrobage" C++ pour faire bien...:roll:
Au fait luc, t'as trouvé le tps de tester Ruby?
A Centrale Lyon, j'ai été surpris que pour enseigner le C en mise à niveau informatique, ils font en fait du C en utilisant les améliorations du C++, ils utilisent string, et vector au tout début.Citation:
Envoyé par Gnux
Moi j'm'attendais à des vieux cours C + classes de base dont Luc Hermitte parlait.
Après, dans les autres écoles je sais pas...
Le gros problème dans l'enseignement des langages de programmation est que ce sont surtout les mauvais qui les enseignent !
A l'ENSEEIHT, il faut être honnête, l'enseignement des langages de programmation se tient plus ou moins (sauf le cas de Caml, pathétique, enseigné en "tout récursif" via Caml Light... dans ce cas-là, mieux vaut enseigner Haskell !) ; mais il est vrai que certaines pratiques "pédagogiques" pratiquées ailleurs sont extrêmement dangereuses ou à déconseiller fortement.
La vie est comme ça... frappons les profs de programmation et rétablissons une dignité pour nos chers langages !
La révolution est en marche !
Bien alors pourquoi ne pas utiliser directement le C++...Je comprends pas leur raisonnement là.Citation:
Envoyé par HanLee
Pourquoi ne pas partir d'un livre du type Accelerated C++ passer un semestre dessus pour assimiler les bases (les centraliens en règle générale ont l'esprit vif et de solides compétences mathématiques et logiques) pour ensuite introduire le C sous son aspect le plus prosaique (pointeurs, allocations etc...)
J'ai un peu l'impression qu'ils prennent les choses à l'envers...
Haskell...Il est rare de rencontrer un bon programmeur Haskell qui soit allé à l'école, je veux dire la grande celle ou "on apprend l'informatique".Citation:
Envoyé par InOCamlWeTrust
Maintenant s'il y de bons profs, il faut avouer que les meilleurs programmeurs en général bossent dans l'industrie. Les autres prennent ce qu'ils restent...
En IUT Réseaux et Télécommunications, on nous apprend d'abord le C puis le Java, ce qui évite de faire du C en C++. Moi je trouve ça pas mal comme approche, mais bon, c'est vrai qu'on esquive l'obstacle que représente le C++ dans ce cas...