 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : quel premier langage pour debuter en prog? | |
| HelloWorld | rhâ ... je voulais pas répondre mais comme ca y est au moins 2 fois :
"A mon humble avis, pour commencer a programmer, c'est meme pas la peine de commencer par un langage de prog. Faut commencer par la base; l'algorithme." "moi, je te propose des cours d'algo en premier... " franchement : vous vous voyez passer votre premier mois d'apprentissage uniquement en écrivant sur papier "si ceci, alors cela ..." y'a rien de plus motivant pour un débutant que de pouvoir afficher "HelloWolrd" dans une fenetre MSDOS :lol: :lol: :lol: :lol: apres (et ca prend pas trop longtemps ...) il attaque les algos ... "Sans aucune hésitation, le Pascal est le meilleur langage pour bien débuter car simple est performant" c'est "le meilleur" qui me derange : le meilleur pour toi. moi je prefere le C :na: le Pascal est un tres bon langage pour débuter ... "Les vrais programmeurs, eux, te diront qu'ils préfèrent le C++." ben ouai, parce que y'a les vrais programmeurs et les faux programmeurs : le faux programmeur il est la, il tappe du code sur des kilometres ... alors que le vrai programmeur, lui, il tappe du code sur des kilometres , mais c'est un vrai programmeur ;) "(sous unix, c'est gratos) " deja que c'est dur de commencer seul à programmer, alors si en + il doit se mette à UNIX ... personnelement, mon évolution dans les langages de programmation a bcp ete influencee par les compilos que j'ai eu. Et si je ne me suis jamais mis au JAVA, c'est parseke que j'ai pas eu de compilo. idem Pascal ou j'ai eu que Delphi, assez tardivement ... alors que j'ai eu un compilo C++ des mes debuts ... (j'avais pas internet) |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| HelloWorld | rhâ ... je voulais pas répondre mais comme ca y est au moins 2 fois :
"A mon humble avis, pour commencer a programmer, c'est meme pas la peine de commencer par un langage de prog. Faut commencer par la base; l'algorithme." "moi, je te propose des cours d'algo en premier... " franchement : vous vous voyez passer votre premier mois d'apprentissage uniquement en écrivant sur papier "si ceci, alors cela ..." y'a rien de plus motivant pour un débutant que de pouvoir afficher "HelloWolrd" dans une fenetre MSDOS :lol: :lol: :lol: :lol: apres (et ca prend pas trop longtemps ...) il attaque les algos ... "Sans aucune hésitation, le Pascal est le meilleur langage pour bien débuter car simple est performant" c'est "le meilleur" qui me derange : le meilleur pour toi. moi je prefere le C :na: le Pascal est un tres bon langage pour débuter ... "Les vrais programmeurs, eux, te diront qu'ils préfèrent le C++." ben ouai, parce que y'a les vrais programmeurs et les faux programmeurs : le faux programmeur il est la, il tappe du code sur des kilometres ... alors que le vrai programmeur, lui, il tappe du code sur des kilometres , mais c'est un vrai programmeur ;) "(sous unix, c'est gratos) " deja que c'est dur de commencer seul à programmer, alors si en + il doit se mette à UNIX ... personnelement, mon évolution dans les langages de programmation a bcp ete influencee par les compilos que j'ai eu. Et si je ne me suis jamais mis au JAVA, c'est parseke que j'ai pas eu de compilo. idem Pascal ou j'ai eu que Delphi, assez tardivement ... alors que j'ai eu un compilo C++ des mes debuts ... (j'avais pas internet) |
| Moustaaki | moi, je te propose des cours d'algo en premier...
parceque c'est bien bô de connaitre les balises d'un langage mais encore faut il savoir s'en servir ! donc fait des prog en algo puis en pseudo langage et là, t'auras de bonne base. après du C (sous unix, c'est gratos) puis aprend les principe de la prog objet puis C++ ou java qui sont tout les 2 des langages objets. Le java est bp plus intuitif et bp mieux documenté et t'as des outils comme JBuilder gratuit qui sont très très bien. commence par la base ! (fait pas du ADA, personne n'en fait :p ) l'ideal, c'est le COBOL !!!!! là, t'aura pas le probleme de gaspillage de ressource puisque certain en ont si peur (cf juste au dessus !) ou alors fait une application complète en asm ! [edit]--Message édité par Moustaaki--[/edit] |
| LogonSystem | Petalouchi :
C'est une belle philosophie de penser qu'on devrait apprendre l'informatique en ne faisant que de la théorie algorithmique, mais le problème c'est que la plupart des gens ont besoin d'avoir un rapport à la machine plus concret. J'ai moi aussi fait un IUT (Aix) et les cours d'algo s'appuyait très nettement sur le pascal. BiFace...: J'arrête les citations, car ca fait des interventions un peu longues. Concernant le groupe ayant appris le C et qui a du mal a "transcrire" ses algos, le problème n'est donc pas algorithmique (ce que tu laissais supposer par rapport au langage) mais simplement dans le mode d'apprentissage du C.. La difficulté à écrire provient aussi de la nécessité à comprendre mieux ce que la machine fait. Cela te semble moins intéressant, mais je t'ai trouvé fort peu loquace sur les informaticiens "formés" en langage de "haut niveau" et qui gaspillent des ressources dont ils n'ont pas la notion. Tu t'en fous peut-être de savoir qu'un informaticien n'a pas idée de la manière dont il "charge" une machine, mais c'est bien pour ça que les systèmes d'apprentissage de l'info génèrent tant de programmeurs qui font des programmes qui consomment inutilement des ressources. Toute la notion entre manipuler des adresses rapidement plutôt que le contenu de ce qui est adressé par les pointeurs, c'est la différence entre le C et le Pascal. Non pas que l'un des langages ne sache pas faire ce que fait l'autre, mais cette notion doit être comprise en C pour progresser. Ton pamphlet sur les "mesures fiables et précises" en matière d'optimisation me fait sourire. Des programmes C utilisé comme du Pascal, j'en ai vu pas mal, et ça montre que beaucoup ne perçoivent pas l'intérêt de manipuler un pointeur plutôt que les données associées. Puisque tu parles de pointeurs et d'allocations, tu as l'air d'oublier un détail (et c'est moi qui trouve ça grave), c'est que le C manipule essentiellement des pointeurs et que si il existe une manière simplifiée d'allouer via la déclaration (char toto[10]) il n'en reste pas moins que toto est toujours un pointeur (une adresse) sur 10 caractères en mémoire, alors qu'en pascal on parlera des 10 caractères en même temps en manipulant la variable... De fait, les instructions NEW/RELEASE sont très peu employées en pascal, qui fait tout le travail de déclaration en sous main. Le pascal ne gère pas habituellement des pointeurs et est donc moins souple pour manipuler ses données. Que cela te défrise, je n'y peux rien. Je ne rentre pas dans une guerre de paroisse entre C et Pascal car c'est stupide, d'autant que j'ai utilisé les deux. Pour recentrer encore une fois le débat, un programmeur Pascal a moins conscience de ce que la machine fait. (Et que tu t'en foutes est profondément navrant, surtout si tu as formé des gens) Enfin, ton discours sur le Turbo Pascal est aberrant. Bien sûr que le Turbo Pascal a été porté sur d'autres plateformes que INTEL! Déjà, sous CP/M, il existait. Donc au moins sur des machines à base de Z80A. Je ne confonds rien. Le concept d'instruction d'adresse de variable n'existait pas sur le pascal de base. Il faut bidouiller pour l'obtenir dans ce dernier cas. En outre, la façon dont ce concept a été implémenté n'a pas été, comme tu le prétend faussement, un pointeur "abstrait" du type void. Ces instructions ramenaient bel et bien un segment et un offset sur intel, tel que défini par le 8088. Et en Z80A, ben y'avait un hic, vu qu'une adresse, c'est 16 bits seulement. Pour le C, tu fais erreur aussi. La représentation du pointeur en terme d'adresse est transparente, ce qui fait sa portabilité. Bref, un programme en Turbo Pascal manipulant des adresses est handicapé car le concept d'adresse n'est pas inné dans ce langage, contrairement au C. C.Q.F.D :p |
| petoulachi | Je vois que la mode est au post de 10km de long. tellement long, que j'ai eu la flemme de les lire. Donc je fais dans le court.
A mon humble avis, pour commencer a programmer, c'est meme pas la peine de commencer par un langage de prog. Faut commencer par la base; l'algorithme. Comme ça tu apprends les structures de base (liste, tableau et autres traitement sur les chaines de caracteres.) une fois que ça c bon, tu peux commencer aussi a comprendre comment ça marche a l'interieur de la machine. Parce que c bien bo de dire que t'as fais des applications en VB, si des qu'il ya un bug tu n'es pas apte a le comprendre et à le cerner, he bin t'es pas sorti. Donc, ensuite je te conseille d'apprendre les pointeurs et la gestion de la memoire (l'asm est super pour ça... sinon au pire du C). et une fois que tu maitrise un peu tout ça, il ne te reste plus qu'a faire de l'objet; meme chjose, commence a en faire avec de l'algo. ET une fois que tou ça est fait, tu seras capable d'apprendre n'importe quel langage tres rapidement (il ne te restera plus qu'a connaitre la syntaxe (et encore c toujours les meme choses qui reviennent) et les fonctions specifiques. D'ailleurs, si je peux te donner un conseil, c'est de finir sur du Java; le Java c'est le futur ! voila c mon opinion, car j'ai appris la prog comme ça, mais pas tout seul ; je sort d'un IUT info |
| Meuh | bon bifaceMcLeOD et LogonSystem, on vous laisse finir cette joute verbale. On vous laisse les clés et n'oubliez pas d'eteindre en sortant... :D
PS : Pas mal le concours de "celuiQuiMetLePlusDeCitationDansUneSeuleReponseMemeSiC'estPasTresConstructif"... |
| AMDFan | Sans aucune hésitation, le Pascal est le meilleur langage pour bien débuter car simple est performant.
Ensuite, faire de l'asm peut être interessant pour ta culture générale car on peut contrôler tout le PC avec ça. Enfin, le C++ que je trouve indispensable (mais surtout pas le C, beaucoup trop archaïque avec ses char*, sa gestion des fichiers et ses printf en core que ce dernier ne soit pas trop génant). Les blaireaux qui ne savent pas programmer proprement te diront qu'ils préfèrent le Java parce que c'est très simple, à un point tel que tu prends des sales habitudes (gestion mémoire faite par GC). Les vrais programmeurs, eux, te diront qu'ils préfèrent le C++. Toutefois, le JAVA est très en vogue en ce moment. Pour trouver du boulot, tu seras obligé de t'y mettre. M'enfin, si tu sais programmer en C++, alors passer au JAVA sera une rigolade. Quant à ADA, je ne sais pas à quoi ça ressemble, mais on dit que c'est un langage encore moins permissif que le Pascal ce qui est un bien pour les applications très importantes. Il est d'ailleurs évoqué par le B. |
| HelloWorld | le site résume un peu le débat : avec haskell, on va plus vite pour écrire (avec moins de bugs) mais c'est moins performant que le C
ils donnent l'exemple du quicksort qui tient en 4 ou 5 lignes au lieu d'une bonne vingtaine en C : "It isn't all roses, of course. The C quicksort uses an extremely ingenious technique, invented by Hoare, whereby it sorts the array in place; that is, without using any extra storage. As a result, it runs quickly, and in a small amount of memory. In contrast, the Haskell program allocates quite a lot of extra memory behind the scenes, and runs rather slower than the C program. In effect, the C quicksort does some very ingenious storage management, trading this algorithmic complexity for a reduction in run-time storage management costs. In applications where performance is required at any cost, or when the goal is detailed tuning of a low-level algorithm, an imperative language like C would probably be a better choice than Haskell, exactly because it provides more intimate control over the exact way in which the computation is carried out." LogonSystem <-> BifaceMcLeod : je crois que aucun de vous n'a raison et aucun n'a tord ! c'est juste le contexte de travail qui peut vous départager = ce que l'on attend de vous : du travail vite fait et qui marche ou alors quelque chose de performant ... |
| youdontcare | je lis un peu des diatribes au dessus ... :D
je rejoins totalement l'avis de BifaceMcLeOD sur la longueur des programmes "plus ils sont courts, mieux c'est". d'ailleurs quelqu'un connait il le haskell ? (haskell.org) c'est un "functional language" très haut niveau, qui parait il a déjà donné d'excellents résultats (des chefs de projets chez nokia rapportaient un temps de développement plus rapide avec moins de bugs etc ... la panacée). j'ai pas encore eu le temps de creuser, qq1 sur le forum peut être ? |
| youdontcare |
je lis qq réponses et je constate que personne n'a parlé de php.
|
| BifaceMcLeOD | Bon, on va peut-être s'arrêter là, à aucun moment on ne parle de la même chose. Et quand l'un de nous écrit quelque chose, l'autre lit tout autre chose... :sarcastic: Je noterai cependant tes phrases suivantes :
|
| LogonSystem | "Je ne justifie pas les effets de bords, je justifie la complexité d'utilisation des effets de bords. Et on constate globalement plus d'erreurs dans les programmes C dans l'industrie que dans les programmes Java. Comment l'expliquer ?"
Faudra m'expliquer ce qu'est l'utilisation d'un effet de bord à partir du moment où ce sont les conséquences imprévues d'un algorithme. Pour te répondre sur le second point, c'est très simple. La majeure partie des programmes dans le monde sont encore écrits en C et en Cobol. Java, dans l'industrie, tu te projettes un peu trop loin dans l'avenir! "C'est pourtant exactement ce que j'ai fait au cours de ma formation personnelle... Et ça ne m'a pas semblé si compliqué. Dès que l'on accepte de ne pas voir le lien tout de suite avec ce qu'on a appris avant. " C'est de la mauvaise foi. :fou: Et on risque effectivement de ne pas être d'accord avec ce type d'argumentation. Apprendre l'assembleur après le basic est plus dur que l'inverse. Tout comme apprendre la programmation structurée après la programmation non structurée est plus dur que l'inverse. Dire le contraire est mensonger, tout simplement! "Tu es gentil, j'en ai formé des dizaines, des débutants..." On ne dirait pas! Car tu ne tiendrais pas des propos de ce type. Ou alors c'est la formation qui laissait à désirer! :??: "Et à la fin de l'année, quand je comparais 2 programmes C censés faire la même chose, l'un écrit par un étudiant du premier groupe, l'autre écrit par un étudiant du second groupe, il n'y avait pas photo : le second a fait un programme de très loin plus lisible, plus clair, mieux structuré, et en plus avec moins de bugs visibles par une simple relecture de code !" C'est hors-sujet. :D Qu'un langage puisse amener plus naturellement une méthodologie algorithmique est indéniable. Il n'en reste pas moins qu'un étudiant qui apprend un langage proche de la machine sait davantage comment elle fonctionne, et quelles sont les limites réelles. Le problème, si tant est que je puisse le considérer, entre tes deux groupes est simplement lié à l'enseignant sur les methodes algorithmiques. Le langage n'a rien à voir avec la façon dont on structure. Essayer de justifier ce point de vue en prenant à témoin ce type d'expérience est malhonnête. Je pourrais tenir le même discours exactement opposé. "Moi aussi. Tous ceux que j'ai vu faire cela avaient démarré avec C. Parce que dans les langages les plus évolués, normalement, il n'y a pas à bidouiller. C'est beaucoup plus carré, et si tu essaies de bidouiller, tu te fais jeter par le compilateur." Confusion. On ne parle pas de bidouillage du langage (j'y viendrais après), mais bien de "spaghettis algorithmiques" visant à manipuler des données dont on n'a pas vraiment idée de leur nature. Mais je suppose que tu l'avais bien compris. De plus, désolé de te faire de la peine, mais lorsque j'étais encore en IUT, le premier langage appris, c'était le Pascal (et c'est le cas dans de nombreuses écoles d'ingé) Le C ne venait qu'en seconde année. Les bidouilles "pour que ca marche", car de vrais principes liés au stockage des données ou des adresses n'a pas été bien compris, c'est monnaie courante. "Bien oui, pour allouer de la mémoire dans le tas, on fait un NEW. En C, on fait un malloc d'un nombre d'octets, c'est complètement différent, c'est vrai Pascal est tellement stupide et tordu que ce mécanisme a été repris dans les langages plus récents, comme C++ ou Java... " En Pascal, il n'est en général pas nécessaire d'allouer la mémoire pour les variables. :D NEW est donc un concept inhabituel dans ce langage. En C, toute variable doit être allouée. Malloc fait pour ainsi dire partie de la philosophie attachée aux pointeurs. Mais là encore, tu avais bien compris ce que je voulais dire! ;) "Si tu n'as pas eu de chance, ce n'est pas ma faute. Dans le Pascal que j'ai utilisé pendant des années, il y avait une fonction pour obtenir l'adresse sur n'importe quelle variable, une autre pour typer une adresse quelconque, une autre encore pour faire des copies de blocs mémoire, etc. Mais je ne les ai vues et utilisées que très tard, quand j'ai commencé à faire de la programmation système." Oula tu viens de t'enfoncer jusqu'aux genoux. :sweat: Effectivement, des EXTENSIONS de langage au PASCAL de base ont été rajoutées pour pallier à ses insuffisances, preuve flagrante que le concept même du langage n'avait pas une philosophie "proche machine". Cela a d'ailleurs été fait avec le TURBO PASCAL de Borland, qui était réputé ne pas être un "vrai pascal" à l'époque.(sic). D'ailleurs, les charmantes instructions dont tu parles galvaudaient l'idée même du pointeur puisqu'elles étaient dédiées à INTEL (segment:offset) et donc incompatibles avec de nombreuses plateformes. En C ANSI (celui de base, encore intact), la notion d'adresse et de pointeur s'affranchit de la plateforme de développement (et du processeur). Enormément de langage ont à ce point évolué que leur nom ne représentait plus rien. Le cobol est devenu objet, alors que le Basic devenait GFA Basic (pour n'en citer qu'un). Or ce dernier s'apparente plus à du Pascal qu'à du Basic, tel qu'il fut défini à l'origine. Il n'en reste pas moins qu'apprendre à manipuler une adresse est immédiat en C et pas du tout en Pascal, puisque le sujet est l'apprentissage (excuse moi d'y revenir...). Je me rappelle comment ces instructions faisaient peur à nombre d'étudiants. "Dommage, nous ne sommes encore pas d'accord. Pour moi, il est plus lisible de faire des affectations. Et c'est encore mieux quand on peut écrire, comme en Ada: monTableau(1..5) := monAutreTableau(3..7); Bref, pouvoir écrire le plus souvent possible ce qu'on veut faire et non comment le faire. Et c'est ça, semble-t-il, notre point d'achoppement. Je prétends qu'il vaut mieux pouvoir écrire ce qu'on veut faire et non comment le processeur devra le faire, et toi, tu sembles prétendre le contraire. C'est, je le crains, un débat sans fin. " Je n'ai jamais prétendu qu'il ne pouvait pas être utile d'utiliser un langage simplifiant l'écriture, par rapport à l'exemple, de kilos-octets de données avec de simples affectations, comme on le ferait en basic. (Procès d'intention). Par contre, la personne qui a commencé par un langage de cette nature (désolé de devoir recentrer encore sur l'objet du post) n'a pas du tout conscience de ce qui se passe, et n'aura de fait aucune idée des conséquences de telles instructions en terme de coût pour la machine, tant en vitesse qu'en mémoire. Les langages qui prémachent tout, appris en 1er langage, créent une masse d'informaticiens qui programment sans avoir aucune idée des ressources en jeu, et qui vont utiliser 10 fois plus de ressources qu'un programmeur qui connait les conséquences d'une "affectation". Le plus triste, c'est qu'avant, les limitations en mémoire et vitesse obligeaient encore à une prise de conscience, mais c'est de moins en moins vrai, car la vitesse et la mémoire pallie nombre d'horreurs! "Ha... Désolé, je n'utilise pour ainsi dire jamais de tableaux à taille fixe. J'ai vu trop souvent la borne maximum être dépassée... Ce que les anglophones appellent la scalability (jamais pu trouver une traduction à la fois simple, concise et satisfaisante, jusqu'à présent ). Donc j'utilise quasiment toujours des tableaux dynamiques. Et alors là, le coup de la constante symbolique définie en #define, tu peux l'oublier... Il vaut mieux créer une structure stockant le pointeur, la taille courante, et la taille allouée... Mais bon, je fais ça une fois tous les 3 ans, dans un module à part, et puis après j'oublie. Après, j'ai une librairie de gestion de tableaux dynamiques bien propre, sans bugs (parce que testée et archi-testée), et bien isolée du reste du code (d'où debug bien plus facile si jamais moi ou quelqu'un d'autre y retrouve une erreur). " Tout d'abord je parlais de chaines de caractères dans mon exemple (mais c'est un détail). Enfin, je préfère un programme qui tient compte des contraintes de la machine sur laquelle il se trouve plutôt qu'un programme qui essaie de le faire même lorsqu'il n'a plus de place. Sous Windows, tu crées donc des programmes capable de swapper à mort en effondrant le système... Et sous Ms/Dos natif, eh bien tu jettes tes programmes! Ca me fait penser aux philosophes de l'informatique qui finissent par dire que c'est la faute à la machine qui n'est pas assez bien "dimensionnée". Alors qu'à la base, tout programme informatique industriel doit être pensé avec les limites techniques de la machine. Ca permet de changer de philosophie de travail (comme par exemple, créer un fichier de dédoublonnage, plutot qu'une table en mémoire, pour ne pas exploser cette dernière car on n'avait pas pensé au problème avant). Donc je n'oublie pas mes #define car ils permettent de poser les bonnes questions avant! Et pas de se dire, c'est pas mon problème, ca s'allouera tout seul. Les programmes qui ne gèrent pas de limites sont des plaies pour l'informatique! :lol: (Et pour le coup, on sort totalement du débat sur la méthodologie du non-écrasement par constante, impérative en C, ne t'en déplaise) "Toutes ces études montrent qu'on n'a pas beaucoup progressé en matière de qualité de code. Globalement, dans l'industrie, la moyenne est autour de 15 à 50 bugs par millier de lignes de code. Les projets avec 10 fois plus de bugs ont rarement vu le jour, ils plantaient trop souvent. Les projets avec 10 fois moins de bugs sont encore assez rares (malheureusement). " Tout est une question d'apprentissage. Et on peut faire dire n'importe quoi à des études. Quant à évaluer les bugs d'un projet je serais curieux de savoir qui a fait ça et avec quels moyens, surtout sur des millions de lignes. En outre, tu as avancé qu'une ligne d'un langage "évolué" est composée de plusieurs lignes d'un langage de bas niveau, en argumentant sur le principe que pour faire "la même chose", le risque de bug augmentait donc pour le langage de bas niveau. L'objet d'un langage est bien d'être adapté à ce qu'on souhaite faire et de faciliter la vie (mais je n'ai pas prétendu le contraire). Bref, je n'ai pas raconté qu'il fallait tout développer en C ou en Asm, loin de là, mais qu'un langage de bas niveau permet d'appréhender mieux les limites tecbniques de la machine et sa compréhension globale. Que tu essayes de me faire dire indirectement autre chose, c'est t'éloigner du sujet d'origine. L'asm ou le C sont très bien adaptés pour faire des systèmes ou du temps réel, par exemple, mais certe pas pour de la gestion, par exemple (bien que cela soit "possible" ). Coriace, le bestiau... |
| BifaceMcLeOD | [citation][nom]LogonSystem a écrit[/nom]Whoupss...Si on se lance dans les citations...alors...
:sarcastic: C'est pourtant exactement ce que j'ai fait au cours de ma formation personnelle... Et ça ne m'a pas semblé si compliqué. Dès que l'on accepte de ne pas voir le lien tout de suite avec ce qu'on a appris avant.
|
| Mandrix | Je pense pas que le fait que chacun défende sa paroisse fasse avancer le débutant, qui doit se trouver (à la lecture de tous ces topics) un peu paumé.
Pour résumé, on peut dire qu'y a pas de recette miracle (sinon ca se saurait). Un bon analyste-programmeur (pour moi), c'est qqun qui a vu suffisament de trucs différents pour faire la part des choses. Qque chose d'important qu'il faut signaler, c'est que qd un projet informatique se casse la gueule, c'est jamais pour des pointeurs mal gérés ou des conneries de syntaxe, c'est principalement un problème de conception, et pas de prog. Donc il me semble bon de rappeler qu'il ne sert à rien d'être un dieu en C++ ou en asm, si c'est pour coder un truc mal modélisé. Et pour ça, je recommanderait des langages type L4G, mettant l'accent principalement sur la modélisation.(ex: Rational Rose, Visual Studio Analyzer, AMC Designer, ...) Pardon, je sors un peu du sujet purement programmation, mais il me semblait nécessaire de rappeler ce point important à mes yeux. |
| wouatouwouatou | Hé, oui... c encore moi.. j'ai vraiment rien a faire :D:D
Je rajouterai donc qu'il vaut mieux se pencher sur le plus de langage possible afin de pouvoir en choisir une specifique et qu'on aime bien... Je dis pas quil faille tout connaitre sur tout mais un minimum pour pouvoir se faire une idée... par soi même, car kiokon entende c tjrs un avis perso des autres... et les avis objectifs c dur en prog.. :D |
| Aricoh | Et je confirme ce qui a été dit ici (enfin, je crois :D )
Quand on a appris un autre langage avant, apprendre le C et surtout sa notion de pointeurs, eh bien ça deviens tout d'un coup moins drôle et surtout moins évident ! |
| Aricoh | Si je peux apporter un peu d'eau au moulin ...
j'ai commencé il y a 1 an en apprenant QBasic (je sais, c'est vieux) avec des bouquins "bon marché", le genre de livres qui se contentent de te montrer un exo tout fait en te demandant ensuite de le taper sur ton clavier. 1) la première chose que tu apprend à faire, c'est taper le code "ouais, j'ai tapé mon premier programme", mais tu sais pas pour autant programmer 2) ce genre de langage (tjs pour les bouquins dont je parle) est vite, trop vite assimilable et on te montre pas assez en détails telles ou telles choses. Moralité, tu crois que tu connais plein de trucs mais y a que la surface ... Je croyais tout connaître des boucles, il m'a fallu passer en C pour comprendre que ... j'étais très loin du compte. Enfin bon, j'arrête mon blabla "qu'y a que moi qui comprend :lol:", juste pour dire : - qu'il faut super bien se documenter dès le départ, de préférence avec des bouquins proposant des exercices à chaque notion enseignée (idéal) - qu'il faut passer par autre chose que du langage fournissant du pré-machage de boulot, comme VB6 par exemple. Faute de quoi, je pense qu'on passe à côté de beaucoup de notions ! |
| wouatouwouatou | j'etais reticent a repondre, car deja trop de topic sur ce sujet.. mais bon... comme jai rien dautre a fair :D
Je dirais juste : La prog du debut c vraiment selon chacun... |
| LogonSystem | Tout à fait HelloWorld... :p |
| HelloWorld | ca sent le souffre ici !!!
je sort mon casque bleu et souhaite dire ceci : à mon avis y'a pas une logique (vous en etes bien la preuve : vous vous gueulez dessus à coup de c'est logique ;)) mais une logique par programmeur. Et donc, chaque langage, avec sa logique, correspond mieux ou pas du tout à tel ou tel programmeur. Je me souviens encore d'un prof que je considerais comme une "bête" car il maitrisait l'ADA et le Pascal d'une maniere deconcertante faire une erreur grossiere en C ... :??: "ah décidement je me ferais jamais au C !" qu'il avait dit ... je pense que l'apprentissage de la programmation est beaucoup influencé par le langage initial : moi j'ai commencé par le C et depuis je rapporte tout à ce langage. En passant à VB, quand j'ai découvert les Collection, le type Variant, je me suis demandé instantanement ce qui se passait derriere, comment VB il gerait ce truc, manipulait des pointeurs ... ceci parce que je suis attaché au C, a la prog bas niveau et que j'aime bien savoir ce qui se passe. le Pascal a selon moins une philosophie (:D) differente et j'ai pas trop accroché ... alors certains vont trouver logique de commencer par l'assembleur pour bien comprendre ce qui se passe ... d'autres pas du tout ... moi l'assembleur m'est parsonnelement vite venu car j'avais bien compris les pointeurs, et j'etais tres penché sur le cote bas niveau mais j'ai vu des potes se casser mechament les dents la dessus, et ne rien comprendre du tout ... sont ils plus mauvais maintenant ? ben ... on pourrait dire oui : ils se fouttent royalement de la gestion memoire, ne se posent pas de question d'optimisation, tant que ca finit par donner un resultat juste, alors le temps + la memoire que ca prend, on s'en tamponne. Mais d'un autre cote ils sont bcp + à l'aise avec les bases de donnees et tout le tsoin tsoin -trucs que je desteste- car c'est tout du haut niveau. Moi, quand on faisais de la base de donnees, j'arraitais pas d'essayer de piger commen Horacles il se gerait les requetes, comment il enregistrait ca sur le disque ... "eux" biens sur ne savaient pas me repondre mais ils ont avance + vite que moi et je sais d'ailleurs pas faire grand chose :D de meme le C++ ca me botte pas trop, mais la par contre y'en a qui ont fait capo aussi, avec les histoires de constructeurs par recopie et tout ca ... au final, on sait tous a peu pres ecrire un programme, avec notre langage fétiche ... |
| LogonSystem | Whoupss...Si on se lance dans les citations...alors...
Citation
|
| BifaceMcLeOD |
[edit]--Message édité par BifaceMcLeOD--[/edit] |
| HelloWorld | "Parceque si c'est de l'ADA pur et dûr, les gars qui ont pondus ça, ben c'est des génies... Car à la connaissance, en ADA pour accéder aux mode graphiques c'est quasi la même merde qu'en ASM...)"
en ADA, Aonix (www.aonix.fr) a développé un generateur d'interface pour windows, proche de VB ou Delphi, qui permet de creer facilement et rapidement une interface ... |
| El_gringo | avec ce joyeux bordel, tu te rend compte déja de l'informatique, une multitude de choix ...Quel que soit le problème posé, t'as plein de façon plus ou moins correctes de le résoudre, reste à trouver la meilleure
Perso, j'te conseille le C pour commencer à apprendre les bases (genre les if, while,...) si tu les connais pas déja. Après si tu veux pas être un programmeur obsolète, apprend la programmation par objet, et pour ça, le Java c vraiement le top, c simple, clair et pratique. bonne chance...(y a du boulot, allez, à tes bouquins, et à ton clavier !) |
| LogonSystem | BiFaceMCLEOD...
Tu as parfaitement raison lorsque tu dis que certains langages "imposent" par leur nature une certaine méthodologie (bien qu'on puisse faire des "porcheries" avec n'importe quel langage... (d'autant le goto existe aussi en C, et que cette instruction est une porte ouverte à toutes les dérives)) Le Basic de l'oric (eh oui c'est vieux), contenait meme une instruction POP permettant à la fonction C d'oublier l'adresse de retour de la fonction B pour revenir à la fonction A... Bref, on peut être porkasse avec n'importe quel langage. :crazy: Là ou je ne te suis pas du tout, c'est sur l'argumentaire qui consiste à dire que parcequ'il y a des gens qui utilisent mal une notion simple (tu en conviens), il faut leur donner d'autres moyens de faire des conneries. Bref, si la personne ne pige pas ce qu'est la mémoire, sa déclaration, et qu'un octet est un octet, c'est qu'elle n'a rien compris. Je ne vois pas non plus pourquoi une notion simple "beaucoup utilisée" deviendrait complexe ? Bien au contraire. Le C oblige à avoir de la rigueur et à comprendre comment fonctionne la mémoire. Je préfère un mec qui plante 100 fois son programme au début mais qui fini par comprendre ça qu'un autre qui fait des déclarations en pascal sans savoir ce qu'il fait car le langage protège la mémoire de ses bêtises de programmation. Enfin, pour ce qui concerne les listes chainées, elles sont infiniment plus logiques (ne serait ce qu'en terme de déclarations) en C qu'en pascal ou, si je me rappelle bien, la syntaxe n'est pas évidente (il faut redéclarer le type dans le type ou un truc du genre). En outre, cela ne permet nullement au programmeur de comprendre le principe de la mémoire. Il a l'impression de manipuler une notion abstraite et complexe, et j'en ai eu souvent la preuve en IUT. Les mecs arrivaient à s'en sortir intellectuellement avec la théorie, mais pas parcequ'ils pigeaient vraiment ce qui se passait. Par contre, en C, une adresse est une adresse, et la mémoire devant être déclarée, il n'y a rien de "magique" ou d'ambigu...Enfin, c'est mon opinion :p Le C oblige à avoir de la rigueur et à avoir de la méthodologie. Notamment, il implique l'utilisation de constantes, qui protègent de tous les écrasements mémoire. Mais il faut de tout pour faire un monde. Certaines personnes se foutent de savoir ce qui se passe dans leur machine et veulent développer rapidement.. Tout reste à savoir à quelle catégorie de "curieux" on appartient. |
| BifaceMcLeOD | LogonSystem> Je ne dis pas que les pointeurs sont en eux-mêmes un concept complexe, par contre, ce que je prétends, ce que ce concept, quand il est beaucoup utilisé, devient extrêmement complexe à gérer. Y compris par les professionnels -- alors qu'ils sont quand même censés savoir ce qu'il font. La meilleure preuve, c'est que dans un programme C ou C++ de l'industrie, statistiquement, au moins 40% des bugs sont des bugs liés à la gestion mémoire et à une mauvaise utilisation des pointeurs.
D'où, aussi (pour partie), le succès récent de Java, qui, masquant les pointeurs, rend la programmation moins "dangereuse". J'entends par là qu'il est plus facile de faire un programme 100% sans bugs. Parce que l'immense majorité des bugs mémoire ne peuvent tout simplement pas exister. Quand tu dis que les pointeurs dans Pascal ne sont pas naturels, c'est complètement faux. Cela fait partie de la définition du langage, au même titre que dans C, C++ ou Ada (mais pas Fortran, Cobol ou Basic). Mais Pascal et Ada utilisent une syntaxe moins compacte que celle de C (et par conséquent C++) pour exprimer les pointeurs. Ce qui n'est pas un mal à mon sens (mais c'est une opinion personnelle ;) ). La différence entre Pascal et C, c'est que l'un utilise les pointeurs à tout bout de champ, alors que l'autre réduit naturellement l'utilisation des pointeurs à celle de l'algorithmique. Tu m'expliques comment gérer de façon performante une vraie liste chaînée, une table de hachage ou un arbre de recherche sans pointeurs ? Impossible. Mais ce sont des structures de données classiques que l'algorithmique décrit avec des pointeurs. Donc, transcrits en Pascal, tu utiliseras des pointeurs aussi. Une fois que tu sais faire une liste chaînée avec des pointeurs en Pascal, tu as compris le concept de pointeurs, la gestion mémoire, ce qu'est un tas (heap), et là tu peux passer à C sans problème. Enfin, concernant ta (courte) remarque sur la programmation structurée, je suis d'accord, dans tous les langages, mêmem l'assembleur, on peut programmer structuré. On peut même programmer orienté objet en assembleur. Mais ça ne vient pas naturellement (en particulier dans les langages type Fortran, Cobol ou Basic à numéros de lignes). D'où l'utilité d'un langage qui impose des contraintes de programmation au programmaeur débutant. Parce que seul un compilateur peut lui imposer ce genre de choses. Si le compilateur ne le fait pas, personne ne le fera, et on constatera un peu plus tard que le type en question programme comme un cochon (et je suis poli). Et puis il faut remettre cela dans le contexte : il y a plein de gens sur ce forum qui préconisent de commencer l'apprentissaqge de la programmation par un langage objet. Evidemment que tous les langages objets utilisent les concepts des langages procéduraux. Mais ils en ajoutent d'autres. Ce que je réponds à ces personnes est donc : ne pensez pas à la POO pour le moment, utilisez seulement un langage procédural (et strictement procédural). C'est plus simple. De toute façon, la POO viendra en temps utile, et de toute façon, tout ce que vous avez appris avec le langage procédural vous servira en POO. |
| Je@nb | Ben moi G commencé il y a 2 mois par le Pascal et je peux dire que C très bon pour commencer. De toute façon, il y a pas besoin d'incurgiter ne tonne de choses d'un coup. Et ce qu'on apprend dans un langage, on ne le perd jamais. Alors autant commencé par un langage où on se sent à l'aise. Avec le Pascal, je découvre de nouvelles choses à chaque fois que j'ouvre l'éditeur.
De toute façon, il faut avoir des projets. Moi j'en ai pas. Si qqn a une idée, ce serai bien. (facile de préférence). De plus je l'étudie en cours d'IESP (enseignement de détermination en 2de) et C bien de voir qu'on sait des choses alors que les autres sont paumés. |
| LogonSystem | Eh bien...Chacun défend sa paroisse becs et ongles...
Certainement le pascal et le basic sont des langages bien plus simples à apprendre... Mais... SEULEMENT AU DEPART! En affranchissant le programmeur de savoir ce qu'est la mémoire ou un pointeur (qui n'est que le numéro de la case mémoire), et qui pourtant est un concept simplissimo (n'en déplaise à BifaceMcLEOD), on forme des gens qui auront dix fois plus de mal APRES à comprendre ces concepts. Alors que l'inverse est totalement faux. J'ai fait l'expérience de former des gens à l'informatique en commençant, non pas par des langages ultra-interprétés qui prémachent tout, mais par des langages proche de la machine, et ils n'ont pas eu la moindre difficulté pour l'apprendre. Maintenant, on prend une personne qui a appris le basic et le pascal... Et bien il faut s'accrocher pour lui faire comprendre ce qu'est la mémoire, que des octets sont lus par le processeur et que c'est ça qui se passe réellement dans la machine. Et ayant commencé par le basic, le pascal, ect... j'ai eu un mal fou avec l'asm, qui est pourtant la base de tous ces langages. Une personne qui apprend directement le bas niveau n'a plus aucun problème conceptuel, et sait ce que la machine ou un langage peut faire ou ne pas faire. Ca me fait penser, tout ça, au débat en algorithmie sur la récursivité. La récursivité peut être apprise de manière très simple, SI on a pas eu AVANT un apprentissage classique. APRES, allez comprendre la chose simplement... Pas évident! N'importe quel prof. d'informatique algorithmique vous le confirmera... Pour celui qui a écrit qu'on peut aussi bien gérer les pointeurs en pascal, c'est vrai, mais ce n'est pas "naturel" dans ce langage et les déclarations sont merdiques. Bref, gérer des pointeurs, c'est possible en quasiment tous les langages, même en basic, mais ce n'est pas la nature du langage. Enfin, pour ce qui est de la programmation structurée (j'ai lu ça aussi) ou les méthodes de programmation, elles ne dépendent pas du langage utilisé. On peut programmer structuré, même en Cobol. |
| MagicBuzz |
|
| haahhahahaha | :lol: :lol: :lol: |
| rufo | et WinDev 5.5 ? c'est pas mal. C'est un langage de programmation tout en français.
ex: ouvre Mafenetre() x est un entier //déclaration d'un entier sinon, y'a Delphi (pascal objet) |
| MagicBuzz | BifaceMcLeOD > Merci pour ces percisions :jap:
JosyX > C'est bien tu as le mérites d'avoir dis ce que tu penses... |
| BifaceMcLeOD | magicbuzz> Des compilateurs Ada gratuits, ça fait longtemps que ça existe. Un des plus connus est le GNAT, qui est basé sur le compilateu GNU C.
Des bibliothèques de code Ada générales, on en trouve aussi très facilement sur le Web. La communauté Ada est assez active de ce point de vue. Enfin, des librairies qui interface des API existantes, ça aussi ça existe. Je connais une interface Ada avec les API Java de Sun (eh oui, car un compilateur Ada générant du bytecode existe aussi !). Une interface texte avec la librarie Curses, une interface Ada Win32, une interface Ada pour X/Window, .... tout ça, ça existe (tout n'est pas forcément gratuit, bien sûr, mais Windows non plus, officiellement, ce n'est pas gratuit :D ). |
| JosyX | magic buzz >> espece de larve , on t a appris a t adresser aux gens ?
tu crois qu un mec qui debute va se mettre a un langage avec le quel il va rien pouvoir faire quand il voit des outils comme delphi , builder , et VC++ ............. le mec il sait qu'une bonne partie des applis qui tourne en ce moment c'est du C (c++) et que les jeux (opengl , directx ...) utilise ce langage, ca le motive. Super motivant de faire de l ADA :-( . Que certains propose le pascal je veux bien .... Puis commencer le C++ sans avoir fais du C c'est super pour le debutant , il ouvre un livre est apres avoir vu cout<<helloworld on lui parle de classe , de constructeur , de fonctions inline pire encore , de surcharge d operateur et de polymorphisme et au bout de 2 semaine le mec il abandonne. Le C est a mon avis accessible aux debutants motivés , plus que le c++. :gun: |
| MagicBuzz | chapeau bas :jap: |
| kadreg |
[edit]--Message édité par kadreg--[/edit] |
| MagicBuzz |
|
| haahhahahaha |
|
| haahhahahaha |
|
