Reprise du message précédent :

magicbuzz a écrit a écrit : de koi tu parles ?

 
je sais jsuis partit en couille  

 
mouai...
vu l'interface on doit pas pouvoir faire grand chose
c pas comme 3ds max ou autocad

T sûr et certain que c'est du 100% ADA ???
Et pas plutôt une base en ADA (calculs faits par le moteur 3D et cnie) interfacé avec un petit bout d'un autre langage ?
 
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...)

 
Oui. J'ai bossé dedans.
 

 
J'ai fouillé partout, j'ai trouvé que de l'Ada.
 

Et en plus, ça tourne sous Windows et Unix.  
 
Oui, c'est des fous-furieux

[edit]--Message édité par kadreg--[/edit]

chapeau bas

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++.

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 ).

BifaceMcLeOD > Merci pour ces percisions
 
JosyX > C'est bien tu as le mérites d'avoir dis ce que tu penses...

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)

Ca me rappelle le Logo ça

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.

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> 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.

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.  
 
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    
 
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.

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 !)

"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 ...

Je n'ai pas dit cela.
La définition d'un pointeur est simple, je suis d'accord, mais pas leur utilisation.
Ce que j'essaie de dire, c'est que ce qui rend la programmation extrêmement complexe (et ce n'est pas moi qui le prétends, ce sont les physiologistes), c'est que le nombre d'informations à mémoriser par le cerveau à un instant donné pour écrire un code correct est souvent supérieur à ce que le cerveau est capable de mémoriser (en général 5 à 9 informations élémentaires selon les individus, dans la mémoire à court terme). Tout le travail du programmeur est d'essayer de réduire cette complexité, de limiter le nombre d'informations nécessaires pour écrire un code correct à un niveau acceptable pour son cerveau.
 
En particulier, les effets de bords de telle ou telle instruction font partie de ces informations à mémoriser. Or le principe même des pointeurs est de provoquer un effet de bord. Un, qui devient très vite plusieurs. Il faut effectivement beaucoup de maîtrise, pour "maîtriser" tous les effets de bords d'une instruction donnée, dès lors qu'elle génère un effet de bord.
 
Or pour un débutant, la complexité en jeu est au-delà de tout ce dont son cerveau est capable. Tout simplement parce qu'il est humain.
 

Pas moi. Parce que le second gars aura écrit un programme qui tourne, dans toutes les situations, et en moins de temps (donc qui aura coûté moins cher à écrire pour une entreprise). Et surtout qui sera plus sûr, donc le coût de maintenance sera plus faible.
 

N'importe quoi. Tu définis un type structure et un type pointeur sur structure, c'est tout :

Et on l'utilise comme suit :

 
Je ne vois pas en quoi c'est plus compliqué qu'en C :

utilisé comme suit :

 
C'est même plus facile en Pascal, car ou peut utiliser le type pointeur dans le type record. Alors qu'en C, il faut se taper le "struct machin*" dans la définition du type struct, même si on ne voudrait utiliser que les types définis par typedef.
 

Encore une fois, je ne vois aucune différence entre le C et la Pascal. J'ai fait beaucoup de programmation système en Turbo-Pascal, et j'ai effectivement fait de la gestion mémoire comme je l'aurais fait en C.
 
Par contre, si, il y a plein de choses magiques en C. Par exemple, le fait qu'un tableau se manipule comme un pointeur, ce n'est pas du tout intuitif. D'ailleurs regarde le forum, tu trouveras de nombreuses questions sur ce sujet.

Beaucoup moins que d'autres langages.
 

Alors là, tu me fais carrément rigoler... Protection des écrasements mémoire par la déclaration de constantes ?
A se demander si tu as déjà vraiment programmé...
Je préfère croire que tu as du mal t'exprimer parce que là, c'est un peu gros quand même...
 
Pour info, j'ai participé plusieurs années au développement d'un logiciel (de gestion de bases de données), écrit en C et C++, de l'ordre d'un million et demi de lignes de code, alors les écrasements mémoire, les risques liés au C, au C++, aux pointeurs, ... je connais un peu.
 
De toute façon, si on a inventé des langages comme Java ou Ada, alors que C existe et semble aussi bien, c'est bien qu'il y a une raison, non ? Tu la connais ? Si la réponse est non, je vais te la dire. Toutes les études ont montré que quel que soit le langage utilisé, les programmeurs, aussi expérimentés soient-ils, font des erreurs de programmation. Et quel que soit ce langage, le nombre d'erreurs qu'il font, rapporté aux nombre de ligne de code qu'ils écrivent, reste le même. Donc si on peut écrire un programme dans un langage en 2000 lignes de code, alors qu'un autre langage permet d'écrire la même chose en 500 lignes, alors le second programmes contiendra 4 fois moins d'erreurs de programmation... Curieux, non ?

[edit]--Message édité par BifaceMcLeOD--[/edit]

Whoupss...Si on se lance dans les citations...alors...
 
Citation

 
Je ne vois pas ce que les physiologistes viennent faire la-dedans. Sortir un argument du genre "de toute façon le cerveau est limité" pour justifier les effets de bords est absolument hors-sujet et surtout faux. Ou alors, pour ma part, je ferais plus d'erreurs en c qu'en pascal, ce qui n'est pas le cas.
 
Citation

 
Pas du tout! La complexité est plus grande lorsqu'on a pris des "mauvais plis". Apprendre l'assembleur directement lorsqu'on ne connait rien d'autre est hyper simple. (je peux en juger par l'expérience). Apprendre l'assembleur lorsqu'on a pratiqué le basic est infiniment plus dur. Si tu veux causer apprentissage (au delà des théories fumeuses sur la complexité du cerveau), il te suffit d'en faire l'expérience par toi-même en formant 2 novices. Et tu verras bien! Ca rejoint ce que je disais sur la récursivité d'ailleurs. Tout prof d'algorithmique te confirmera qu'il serait préférable de commencer par la récursivité, car l'algorithmie, telle qu'elle est apprise ensuite, rend la chose difficile à appréhender.
 
Citation

 
L'objectif, ce n'est pas qu'un "programme fonctionne à tous prix" mais qu'une personne acquière une connaissance lui permettant de comprendre ce qu'elle manipule. Si tu veux argumenter sur les coûts de maintenance, je réponds simplement que le programmeur A aura "peut-être" (et tu ne l'as pas prouvé) plus de difficultés à comprendre dans son apprentissage, mais le programmeur B va réussir à pondre de la merde qui marchera mais qui va certainement coûter plus cher en maintenance plus tard!
En outre le sujet du post, c'est l'apprentissage, et pas les coûts en entreprise d'un informaticien déjà formé. Donc, hors sujet la remarque.
Pour revenir sur les étudiants, j'en ai vu des tonnes "bidouiller" jusqu'à ce que leur "spaghetti" fonctionne car ils ne pigeaient qu'à moitié ce qu'ils faisaient, en général car ils n'avaient pas compris des "principes simples"
 
Enfin, pour les déclarations PASCAL/C, tu oublies juste de préciser un détail. La déclaration C n'a rien d'inhabituel dans le langage. C'est même du classique de chez classique et toute variable est définie de la sorte. En PASCAL, c'est un type bien particulier. Tu as certainement de meilleurs souvenirs que moi en Pascal, mais il me semble qu'il fallait faire un NEW ou un truc du genre. Et je persiste à dire que ça reste une notion plus difficule à piger dans ce langage. (Evidemment pas pour un mec qui sait ce qu'est un pointeur à la base, mais je te rappelle qu'on parle d'apprentissage)
 
Citation

 
Personne n'a raconté qu'on ne pouvait pas toujours arriver à tout faire dans un langage. Mais tout dépend du prix qu'il faut y mettre. L'instruction INLINE faisait bien partie du turbo pascal et permettait de tout faire, à condition d'avoir pigé certaines "notions" (on y revient). J'avais même créé des fonctions appelées en pascal mais écrite en assembleur...
 
Il est beaucoup moins aisé de manipuler la mémoire en pascal qu'en C, ne t'en déplaise. C'est faisable mais pour quelqu'un qui a parfaitement pigé ce qu'est la mémoire et qui connait très bien le langage. Sur le Pascal que j'ai appris c'était la merde pour obtenir l'adresse d'une variable (il fallait faire un union ou un truc du genre).  
 
Que le contenu d'un tableau puisse se manipuler comme un pointeur
n'est effectivement pas très logique en C. Mais c'est une des rares choses et c'est uniquement lié à la façon dont cela a été implémenté. Un programme lisible ne devrait jamais utilisé l'affectation "=" pour déplacer des éléments d'un tableau en C,
et y privilégier le memcpy, qui est bien plus logique.
 
Citation

 
Et pourtant, tu devrais t'y mettre, tu ferais moins d'erreurs.
Avec un zest de méthodologie...  
P'tit exemple :
constante    
#define DEF_SIZ_NAMEPART   10
declaration    
char namepart1[DEF_SIZ_NAMEPART+1];
utilisation    
namepart1[0]=0; strncat (namepart1, xxx, DEF_SIZ_NAMEPART);
 
Tu es gentil de me servir ton expérience sur des millions de lignes de code en C.    
Mais ce n'est pas un jeu dans lequel j'ai envie de rentrer, car on n'est pas à la maternelle à comparer nos billes, mais mon expérience n'a rien à envier à la tienne.
 
Quant à "tes études" sur le rapport du nombre de bugs/lignes qq soit l'aptitude des développeurs, cite les moi, car là, c'est à moi de rigoler. Je peux trouver sans problème des gens qui feront des programmes de 500 lignes 4 fois plus truffés de conneries que dans un autre programme de 2000 lignes. Un programmeur sur un langage X ne se comporte pas de la même façon sur un langage Y. Un programme de gestion n'est pas un programme de jeu. Bref, inepte!
 
Mais merci de m'apprendre qu'un programmeur fait des erreurs...
Je ne m'en serais jamais douté tout seul. (et je ne m'exclue nullement du lot)

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
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 ...

Tout à fait HelloWorld...

j'etais reticent a repondre, car deja trop de topic sur ce sujet.. mais bon... comme jai rien dautre a fair
 
Je dirais juste : La prog du debut c vraiment selon chacun...

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 ", 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 !

Et je confirme ce qui a été dit ici (enfin, je crois )
 
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 !

Hé, oui... c encore moi.. j'ai vraiment rien a faire 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..

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.

[citation][nom]LogonSystem a écrit[/nom]Whoupss...Si on se lance dans les citations...alors...
 

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 ?
 

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.
 

Tu es gentil, j'en ai formé des dizaines, des débutants...
 

Ecoute, j'ai eu l'occasion d'observer pendant plusieurs années, des centaines d'étudiants débutants en informatique. Et de discuter longuement avec leurs enseignants. Certains étudiants commençaient par C, d'autres par Ada. Je peux te dire que les seconds ont avancé beaucoup plus rapidement que les premiers, comprenant les concepts du langage et les utilisant correctement beaucoup plus vite. Les seconds ont eu le temps de maitriser Ada, puis C, lorsque les premiers continuaient péniblement à essayer de comprendre ce qu'ils faisaient en C.
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 !
 

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.
 

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...
 

Effectivement, tu n'en démordras pas. Tu sembles avoir un a priori sur l'utilisation strictement algorithmique des pointeurs. Pourtant, j'ai vu plein d'étudiants comprendre progressivement la puissance des pointeurs ainsi, et quand il s'est agi de passer au C, ils n'ont eu aucune difficulté, puisqu'ils avaient déjà assimilé.
 

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.
 

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:

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.
 

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).
 

Je te parle d'études extensives faites par des chercheurs au sein de très grosses populations de programmeurs. Et ces études ont été effectuées dans les années 60, puis 70, refaites dans les années 80 et 90.
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).
 
Mais le plus intéressant, c'est que ces études montrent clairement que ce ratio reste constant quel que soit le langage utilisé. Qu'on écrive de l'assembleur ou dans un 4GL.
D'où l'utilité de ce que j'avance. Il faut mieux comprendre ce qu'on veut faire, et enseuite utiliser un langage qui permet d'exprimer ce qu'on veut faire plustôt qu'un langage qui permet d'exprimer comment la machine va le faire. Parce que "ce qu'on veut faire", c'est souvent beaucoup plus court à écrire. Plus lisible (on ne se perd pas dans les détails), et plus facile à rédiger sans erreur.

"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.    
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.  
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.    
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.    
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!    
(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...

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...    
 
Je noterai cependant tes phrases suivantes :

Ta première phrase est ce que je m'escrime à te faire comprendre depuis le début. Par contre, tu te trompes complètement sur l'origine du problème. Les 2 groupes suivaient les mêmes cours d'algorithmique, avec les mêmes supports de cours. Mais l'un des 2 groupes avait beaucoup plus de mal que l'autre à transcrire ses algorithmes dans le langage de programmation. Parce qu'ils se perdaient dans les détails (clairement, les pointeurs, inévitables en C, au cas où j'aie besoin de mettre les points sur les i). Cést pour cela que je parle de complexité inhérente au langage C et à ses pointeurs.
 

MAIS ON S'EN FOUT !!! Pour un débutant, on s'en fout. Le plus important pour un débutant, c'est qu'il structure son esprit de telle sorte qu'il puisse commander la machine de la manière la plus simple et logique possible. Le fait même que ce genre d'outils existe montre que c'est une opération que la machine sait faire.
La première étape de l'apprentissage de la programmation, c'est de savoir concevoir des algorithmes corrects. Le langage n'est là que pour permettre de faire vérifier à l'étudiant qu'il a bien conçu son algorithme. Le langage est un moyen d'expression, pas une fin.
 
Ce genre de considération sur le caractère optimisé d'un programme ou d'une instruction viendra bien assez tôt !!! Surtout que souvent, les idées préconçues sur le caractère lent ou rapide d'une instruction donnée sont complètement faux, dès qu'on commence à faire des mesures fiables et précises. J'ai eu l'occasion de le constater (au bas mot) des centaines de fois ! Donc c'est la dernière chose à faire regarder par un débutant. Sauf évidemment si on le destine à faire des programmes temps-réel dans les 2 mois qui suivent, mais je ne m'adresse pas (j'en conviens) à ce public-là. Je m'intéresse aux programmeurs généralistes (donc capables de programmer dans n'importe quel domaine).
 
 
Ha, au fait, juste une petite précision technique...

Encore une fois, tu commets une erreur (grave, à mon sens).
Car là encore, il n'y a aucune différence entre Pascal et C. Dans les 2 cas, toute variable déclarée sera automatiquement allouée par le compilateur, et ce même compilateur prendra en charge sa désallocation (sur la pile, en général). Donc si tu déclares n de type entier, C et Pascal alloueront automatiquement la mémoire nécessaire pour un entier. Si tu déclares p de type pointeur sur entier, C et Pascal alloueront automatiquement la mémoire nécessaire pour un pointeur sur entier. Et dans les 2 langages, l'allocation comme la désallocation de la mémoire pointée par un pointeur doit être prise en charge par le programmeur. Avec malloc/free en C, avec New/Release en Pascal. "malloc fait pour ainsi dire partie de la philosophie attachée aux pointeurs", tout comme New en Pascal. La seule différence, c'est qu'on n'utilise pas New aussi souvent que malloc. Et c'est précisément ce que je reproche au C : on est obligé d'utiliser malloc beaucoup plus que de raison.
 

C'est encore faux. Ce n'est pas parce que Turbo Pascal n'a pas été porté sur d'autres plate-formes que l'idée de pointeur y était galvaudée. Elle ne l'était pas plus que dans les implémentations de C sur cette même plate-forme. Encore une fois, tu confonds concept et implémentation. Et en plus tu te trompes. Ces fonctions manipulaient des données de type "Pointer" abstrait, qui correspondait très précisément au type "void*" de C...

je lis qq réponses et je constate que personne n'a parlé de php.
 
la programmation ... j'ai commencé par le pascal, enchainé sur l'assembleur, puis le c, enfin le c++. j'ai également touché au java et à python. puis j'ai eu à réaliser pour un projet un site avec un forum, un agenda, etc ... je me suis donc mis à php & mysql.
 
franchement, php est LE langage le plus convivial et accessible qu'il m'ait été donné d'utiliser. j'ai réalisé le site en un temps record, j'étais tout content
 
bon évidemment tu ne précises pas ce que tu veux faire, tu veux juste 'apprendre à programmer'. mouais
pour débuter facilement, tente le php. les exemples fourmillent sur le web, la doc sur le site est magnifique et profite des commentaires de tous les utilisateurs (si tu ne parles pas anglais tu vas souffrir par contre ... mais tout bon programmeur est bilingue )
 
tu peux chopper apache et mysql, les installer sur ton dur, et bosser en local. c'est ce que j'ai fait en suivant le tutorial de zonesuivante.com, maintenant fermé. je te conseille de créer un ptit site tout simple, ou tu peux par ex poster des news, laisser un message dans un guestbook, etc ... ensuite tu pourras te mettre doucement au le c / c++, la syntaxe étant quasi identique.

je lis un peu des diatribes au dessus ...
 
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 ?

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 ...

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.

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...
 
PS : Pas mal le concours de "celuiQuiMetLePlusDeCitationDansUneSeuleReponseMemeSiC'estPasTresConstructif"...

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

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  

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    )
 
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]

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
 
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
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)