Langage pour débuter : C, Pascal, Ada, Fonctionnels ?

[vg-matrix]

Envoyé par deadalnix

Comme précité, que penses tu d'ADA pour débuter ?

pour vos interventions, à vrai dire j'ai fais un tour du côté de l'ADA et je valide vos avis mais vu qu'il est si je peux me permettre de dire ainsi " l'amélioration du Pascal " il est donc claire que vous optez pour le Pascal (en prenant en compte la majorité des avis actuels).

C'est vrai que débuter en C doit s'accompagner d'une grande rigueur car je me suis aperçu qu'en cherchant à faire fonctionner les codes à tout prix nous sommes souvent amenés à gribouiller un peu. Résultat on viole totalement la norme.

Toute fois j'ai l'impression que le C a peu de partisans

[jabbounet]

disons que il ne faut pas le voir en premier car il a tendance a donner de mauvaises habitudes.

[Mat.M]

Envoyé par vg-matrix

tout le monde, j'aimerais avoir votre avis sur le langage à apprendre pour débuter la programmation.

Selon vous faut-il apprendre le C ou le Pascal?

je vais te répondre d'un point de vue pratique : oui il vaut mieux commencer par Pascal qui est très structuré parfaitement académique.
Maintenant avec des concepts académiques et de la prose en alexandrins on ne fait pas grand chose.
il y a plus de codes sources en C/C++ qu'en Pascal
quand tu fais de la programmation Windows ou appeler des API Windows ( et tu seras amené un jour à en faire ) le SDK est en C , faire le portage vers le Pascal n'est pas forcément aisé.
Même pour un projet avec ERP auquel j'ai participé il y avait des appels d'API Windows.
des SDK comme ceux de Direct X sont en C++.
Pareils pour de nombreux autres SDK surtout ce qui touche le bas-niveau , acquision de données temps-réel.
J'avais bossé sur un projet multimédia avec une carte de réception satellite le SDK n'était exclusivement en C++

Ceci dit Delphi reste un superbe outil pour faire notamment des applis de gestions voire d'autres types d'applis comme les jeux.

[Luc Hermitte]

Envoyé par vg-matrix

J'ai entendu que le C étant réputé [...] il est beaucoup plus conseillé dans les débuts de programmation histoire de données de bonnes habitudes aux programmeurs.

Qu'en dites-vous?

Que je ne comprends pas d'où cette idée reçue peut bien venir.
L'essentiel des cours de C pour débutants vont simplifier quantité de choses et au final on fait semblant de programmer au pays magique où les erreurs n'existent pas (pas de tests sur les retours de fonctions, des casts parce que cela permet de faire tomber le programme en marche, ...). Je ne vois nulle bonne habitude là dedans. Bien au contraire.

Ada est très bien pour un public futur-pro. Delphi (évolution de Pascal) sera plus "sympa" pour des amateurs.

Maintenant, il y a une mode à abandonner ces langages au profit de langages comme le Python. Ne connaissant pas grand chose de ce dernier, je me contente de rester dubitatif.

[jabbounet]

python c'est rigolo mais faut pas casser les indentations....

[vg-matrix]

Envoyé par Luc Hermitte

L'essentiel des cours de C pour débutants vont simplifier quantité de choses et au final on fait semblant de programmer au pays magique où les erreurs n'existent pas (pas de tests sur les retours de fonctions, des casts parce que cela permet de faire tomber le programme en marche, ...).

C'est malheureusement le cas pour ceux qui débutent par le C.

Puisque je déteste les métaphores moisies, je vais en faire une : conseiller à un débutant en programmation de commencer par l'assembleur et le C pour "comprendre comment ça marche", c'est un peu comme si à quelqu'un qui demande comment apprendre à conduire, on lui répondait "Commence par démonter la voiture, apprendre à faire des vidanges, changer un carburateurs, puis conduis une voiture où pour démarer il faut faire toucher des fils, pour accélérer il faut rêgler manuellement l'ouverture de la valve d'essence, et comme ça tu pourras vraiment savoir conduire".

Je trouve ça super con :-\ Quand on veut débuter, on commence par des choses simples, qui marchent, genre une voiture avec direction assistée et qui ne calle pas trop facilement. Un langage avec GC est le minimum vital, et ne pas avoir à se prendre la tête avec des pointeurs est indispensable.
C'est après seulement, quand on s'est familiarisé avec les notions de bases de boucles, de variables, de fonctions etc. qu'on peut commencer à mettre les mains dans le cambouis et à se demander comment ça fonctionne sous le capot.

Bref, pour commencer, fuir le C, et pas l'inverse

[Mac LAK]

Envoyé par alex_pi

Un langage avec GC est le minimum vital, et ne pas avoir à se prendre la tête avec des pointeurs est indispensable.

Pas d'accord... Un GC, c'est la porte ouverte au je-m'en-foutisme sur la libération mémoire, et la notion de pointeur reste importante quoi que l'on dise : il est fondamental de comprendre ce que c'est, même si c'est pour éviter de l'utiliser derrière (en fonction de ses goûts personnels et de ce que l'on veut faire en programmation bien sûr).


Comprendre la machine, sans aller trop loin... Pour reprendre ton analogie, à l'auto-école, t'as en général une voiture à boîte manuelle et non pas automatique, tu n'as pas d'ordinateur de bord, de GPS, ni d'assistance au créneau. L'assistance que tu as, c'est en général sur la direction, et le moniteur à côté, point barre.
Et si ton moniteur est compétent, il t'apprendra en plus à changer une roue, une ampoule et à faire le plein et les niveaux.

Libre à toi après d'acheter une voiture "toute assistée" et de payer quelqu'un pour l'entretenir, ou d'acheter une épave de 1950 et de la retaper toi-même. Au moins, tu le feras en connaissance de cause, car tu auras touché un peu aux deux mondes...


Bref, un langage avec des pointeurs, mais non omniprésents. Avec une gestion mémoire manuelle, mais sans cas vicieux de libération / fuite. Strict et rigide pour éviter d'apprendre à patcher plus qu'à programmer.
Mais sûrement pas un langage à typage dynamique et/ou GC automatique, en tout cas. Ni du C ou de l'assembleur, d'ailleurs : débuter par l'ASM, ça allait dans les années 80, quand il n'y avait pas grand-chose d'autre. Actuellement, c'est un non-sens.

Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique. Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?

Je n'ai *jamais* compris l'intéret d'emmerder le débutant avec une gestion manuelle de la mémoire. La moralité, ça va être qu'il aura la moitié de ses programmes où il se prendra des crash (ceux où il aura fait des free au mauvais endroit) et l'autre moitié avec des mem-leak à tout va. Et au final il préferera la seconde catégorie parce qu'au moins ça ne plante pas.

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

Et en plus, ça interdira au débutant un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas à faire une gestion manuelle de la mémoire là dessus. Est ce que devoir avoir compris les magic pointeur avant de coder est vraiement indispensable...

Je ne vois vraiment pas ce que pour un débutant, avoir à gérer sa mémoire à la paluche apporte sur le plan pédagogique

[Luc Hermitte]

Il le faut, mais pas dessuite.
Cela peut être fait avec un second langage, ou tardivement dans des langages comme Pascal/Ada.

[jabbounet]

Envoyé par alex_pi

Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique. Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?

je ne suis pas non plus pour le java en premier langage , il cache trop de problématique derrière une apparente simplicité.
Ce n'est pas tout de faire de l'algorithme, il faut aussi comprendre comment marche la machine et l'os qui est dessus, sinon on risque de faire de choses qui vont heurter son fonctionnement normal et au final avoir des trucs qui rament.

sans compter que c'est un peu l'usine pour faire ton programme tu te retrouve vite a assembler un tas de composants (avec tout un tas d'acronyme ejb, struts, spring, jboss, pojo....) bref il faut s'acheter un dictionnaire français/java pour savoir ce que l'on fait. et ensuite tu te rend parfois compte que tu aurais été plus vite en le codant toi même et que cela aurai mieux répondu a ton besoin et ce surtout si tu débute ou l'on te confie des truc simple au début

Je n'ai *jamais* compris l'intérêt d'emmerder le débutant avec une gestion manuelle de la mémoire. La moralité, ça va être qu'il aura la moitié de ses programmes où il se prendra des crash (ceux où il aura fait des free au mauvais endroit) et l'autre moitié avec des mem-leak à tout va. Et au final il préferera la seconde catégorie parce qu'au moins ça ne plante pas.

Avant d'expliquer l'allocation dynamique tu commence par faire du statique.
et tu commence doucement a expliquer ce qu'est une mémoire comment elle fonctionne et qu'elle a ses limitation et ensuite ce qu'est une allocation dynamique.

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

beaucoup de programmeur codent comme de cochons, mais j'en connais quelque uns (dont moi) qui n'acceptent pas de considérer que le programme est valide s'il subsiste un leak dessus surtout en C/C++.

Ceci dit ce n'est surtout pas parceque tu as un GC que tu ne dois pas t'occuper de ta mémoire, ce serai un erreur. j'ai déjà eu des soucis de memoire avec des programme java de gens oubliant de dereferencér des objets (mem-leak) ou des personnes se retrouvant a dé-référencer trop tôt des objets et avoir un tas de nullpointer exeption (free).....

L'idée que l'on a pas a s'occuper de la mémoire en java est selon moi un peu fausse.

[Mac LAK]

Envoyé par alex_pi

Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique.

Le typage statique demande un minimum de réflexion de la part du développeur... Et plus il est strict, plus il doit réfléchir.

Envoyé par alex_pi

Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?

Justement : c'est un échec à la compilation, et non pas à l'exécution, qui se produit avec un typage statique... Les erreurs de typage dynamique sont en général assez infectes à lever, et dans le pire des cas on a un débutant qui ne comprends même pas la différence entre un nombre (variable entière) et sa représentation textuelle (variable chaîne contenant la représentations ASCII du nombre en question)...

Envoyé par alex_pi

Je n'ai *jamais* compris l'intéret d'emmerder le débutant avec une gestion manuelle de la mémoire.

Moi, si... Pour avoir vu (et déplanté) un paquet de code C/C++ provenant de "spécialistes Java", d'ailleurs. Ils ne savent pas ce qu'est la gestion mémoire, et n'arrivent souvent pas à l'assimiler naturellement...
J'ai même vu des horreurs sans nom, dans le genre classe C++ complexe sans destructeur implémenté, alors que la classe allouait à tout va !! Et, ô surprise, c'était un fervent défenseur du Java...

Envoyé par alex_pi

La moralité, ça va être qu'il aura la moitié de ses programmes où il se prendra des crash (ceux où il aura fait des free au mauvais endroit) et l'autre moitié avec des mem-leak à tout va. Et au final il préferera la seconde catégorie parce qu'au moins ça ne plante pas.

La plupart des langages ont un GC "global" au programme, c'est à dire que l'allocation se fait dans une zone réservée par le runtime... Une fuite mémoire peut exister, certes, mais sans mettre en péril le système d'exploitation. Ce n'est pas "propre", certes, mais c'est un moindre mal.

De l'autre côté, il y a des habitudes, notamment les bonnes, à prendre dès le départ. Sinon, les développeurs ne les prennent JAMAIS, parce que c'est "trop contraignant". Parmi ces habitudes, on a :

• Documenter son code,
• Le tester un minimum sérieusement,
• Savoir à l'avance ce que l'on va faire, et non pas "bidouiller" en avançant à tâtons,
• Vérifier la libération de ce que l'on a alloué.

Envoyé par alex_pi

Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..

C'est un fait. Combien, parmi ces "débutants", on commencé par un langage "académique", toutefois ? Moi aussi, je connais hélas trop cette situation... J'y vois des gens ayant débuté par du Java, du Basic (Visual ou non), des langages interprétés, etc. Et, bien sûr, ceux qui n'ont démarré qu'avec le C, et n'ont jamais connu d'autre langage !!

Ceux ayant débuté par des langages plus stricts sans être trop lourds (Pascal, Ada en tête de liste) ont en général bien moins de mauvaises habitudes... Ou, pour être plus précis, leurs erreurs d'allocation/libération restent dans des limites "acceptables", c'est à dire qu'elle ne crashent pas le programme dans les 10 minutes suite à une fuite mémoire plus proche de la chute d'eau que du robinet qui goutte.

Envoyé par alex_pi

Et en plus, ça interdira au débutant un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas à faire une gestion manuelle de la mémoire là dessus.

Lesquels ? L'algorithmique, ça s'apprend par le commencement, pas par la fin... Tu arrives à accepter, toi, qu'un stagiaire passe une heure à trouver une librairie pour faire un tri au lieu de l'implémenter lui-même ? Surtout quand ça porte à l'origine sur un tableau d'une vingtaine d'éléments, trié une seule fois ?

Envoyé par alex_pi

Est ce que devoir avoir compris les magic pointeur avant de coder est vraiement indispensable...

Utiliser les "smart pointers" est néfaste en soi pour un débutant, car cela le fait ignorer un mécanisme crucial qui n'existera pas toujours sur les plate-formes qu'il sera amené à utiliser. L'embarqué se porte bien, très bien même... Et là dessus, tu as rarement une usine à gaz type JRE pesant plus lourd que la capacité mémoire disponible pour faire n'importe quoi n'importe comment... Et de toutes façons, les performances exigées mettent hors concours tout ce qui n'est pas langage compilé natif.

Or, à force d'apprendre le développement "façon assisté", tu vois de moins en moins de développeurs réellement compétents dès qu'il s'agit de développement bas niveau, temps réel ou embarqué... Certes, ils savent faire de belles IHM en Java et ouvrir tout plein de communications TCP/IP en même temps, ou se connecter à une BDD. Mais ils sont infoutus de faire un système d'acquisition temps réel, un driver ou un module exigeant des performances sévères.

Envoyé par alex_pi

Je ne vois vraiment pas ce que pour un débutant, avoir à gérer sa mémoire à la paluche apporte sur le plan pédagogique

Je ne vois vraiment pas pourquoi on apprends aux gamins à se brosser les dents dès qu'ils savent tenir debout, alors qu'on se fiche complètement des dents de lait : il ne faut s'en occuper que quand leur dentition définitive pousse !

Ah, on me souffle que c'est pour leur en donner l'habitude, parce que ça ne devient pas un réflexe quand c'est appris "trop tard"... Tiens donc...

[FR119492]

Bonjour à tous.
Je pense que tout dépend du type d'informaticiens qu'on veut former:

• Si on veut des informaticiens "rentables" après une formation de durée limitée (1 ou 2 ans), il est plus efficace de commencer par un langage de haut niveau, qui va lui mâcher le travail.
• Pour une formation de niveau académique, il faut commencer par la base, c'est-à-dire l'assembleur et présenter ensuite les langages de plus haut niveau comme une amélioration du confort du programmeur.

Jean-Marc Blanc

[Mac LAK]

Envoyé par FR119492

Pour une formation de niveau académique, il faut commencer par la base, c'est-à-dire l'assembleur et présenter ensuite les langages de plus haut niveau comme une amélioration du confort du programmeur.

Mouais, enfin bon, faut pas déconner non plus : démarrer par l'ASM, c'est quand même un peu hardcore comme méthode... Connaître l'architecture d'un processeur, c'est important, mais de là à lui causer en patois local, il y a une marge !!! Surtout que les assembleurs sont quand même assez différents d'une gamme de processeur à l'autre... C'était assez facile de passer du Z80 au x86, mais celui qui passe du PowerPC à un processeur ARM va moins rigoler.

Un langage de trop haut niveau est néfaste pour débuter : cela ne donne pas les bonnes habitudes, et le mot "rentable" dépend beaucoup du domaine d'activité (dans le mien, un spécialiste Java est juste un boulet dans 99% des cas par exemple).
De même, démarrer par un langage de trop bas niveau est tout aussi néfaste, car cela revient souvent à apprendre à bidouiller plutôt qu'à développer.

Il faut un juste milieu.

[jabbounet]

Clair l'assembleur nécessite un peu de savoir comment est fait un microprocesseur et c'est un peu trop pointu pour débuter a mon avis.

Envoyé par Mac LAK

Un langage de trop haut niveau est néfaste pour débuter : cela ne donne pas les bonnes habitudes

Mais euh, pourquoi ? J'ai commencé par caml, et je n'ai pas vraiment l'impression que ça m'ai donné de mauvaises habitudes. Et pourtant, dans la catégorie "langage de haut niveau", ça écrase largement java.

Bien au contraire, son typage m'a donné un paquet de bonnes habitudes comme éviter d'être tenté toutes les deux minutes de faire des casts ultra sordide, ou encore m'inciter à utiliser les rares possibilités offerte par le système de type des autres langages.
Et le fait que ce soit "haut niveau" m'a habitué à d'abord penser aux algorithmes, à leur complexité, à la qualité des structures de données, etc, avant de me demander si je vais pouvoir échanger le contenu de deux variables en 2 ou 3 instructions comme je vois tellement de débutant en C faire sur ce forum (et de moins débutants), ou comment optimiser le prélude d'une boucle au lieu de m'intéresser à son corps.
Débuter avec un langage de haut niveau permet de se concentrer sur ce qui est important plutôt que de se prendre la tête inutilement avec des détails d'implémentation et de gestion mémoire sans intérêt.

Il est quand même nettement plus intéressant (et finalement valorisant) de comprendre ce qu'est une fonction, une boucle (même si c'est pas indispensable:p), une liste, un tableau, un arbre, un tas, etc, avant d'avoir à se demander ce que peut valoir le code d'erreur retourné par un malloc qui foire, d'avoir à chercher pendant des heures d'où vient ce signal 11 qu'on s'est pris dans les dents ou comment se pointeur a pu se retrouver à 0 avant qu'on le dé-référence.

Je reste vraiment persuader qu'un langage de haut niveau est beaucoup plus pédagogique que le C, mais ceci est un troll sans fin

[Mac LAK]

Comme je l'ai déjà dit plusieurs fois, le langage initial permet de prendre de bonnes habitudes dès le départ. Ni plus, ni moins.
Que la libération des ressources devienne un réflexe et non pas une corvée.
Que l'on pense ses algorithmes proches de la machine au lieu d'essayer de faire comprendre l'humain au CPU (ce qui en général finit en usine à gaz...).
Que l'on sache ce qu'EST une machine, et savoir comment elle fonctionne, plutôt que de systématiquement croire que c'est une entité maléfique devant être debuggée par un chaman.

Et une fois le "mauvais pli" pris (souvent, hélas, pendant les études), c'est trop tard : le "développeur" n'a jamais ces réflexes, ce qui coûte du temps de relecture, correction, ou pire, maintenance. Ou d'investir pour pallier des erreurs qui ne devraient JAMAIS être commises.

Envoyé par alex_pi

Je reste vraiment persuader qu'un langage de haut niveau est beaucoup plus pédagogique que le C, mais ceci est un troll sans fin

Que le C, oui, la cause est entendue. Qu'il soit "plus pédagogique" que Pascal ou Ada, ça reste à démontrer... Et pour l'instant, de ce que j'ai pu en voir à titre professionnel, démarrer par Java (ou plus haut niveau encore) est néfaste côté habitudes.

Ne pas apprendre à libérer sa mémoire dès le départ, c'est s'exposer à ne JAMAIS le faire... Et ça se vérifie sans arrêt, tout comme ne compter que sur le compilo ou la puissance de la machine pour optimiser un programme ou algo.
C'est comme ça qu'on a de "jeunes diplômés" qui pensent avoir l'idée du siècle en voulant mettre du Java dans une carte embarquée temps réel, en croyant que "rajouter un CPU" ou "2 Go de RAM" n'aura aucune influence ni sur le coût de la carte, ni sur le temps de développement... Et tout ça parce qu'ils trouvent le C (ou le C++) "trop dur" avec tout ces pointeurs tout vilains...

[jabbounet]

Que le C, oui, la cause est entendue. Qu'il soit "plus pédagogique" que Pascal ou Ada, ça reste à démontrer... Et pour l'instant, de ce que j'ai pu en voir à titre professionnel, démarrer par Java (ou plus haut niveau encore) est néfaste côté habitudes.

perso je pense quand même qu'une syntaxe de ce type (que l'on retrouve en pascal ou ada)

Code :

1
2
3
4
5
if ((a equal b) and (c not equal d)) then
   something
else
   somethin_else
endif

est beaucoup plus lisible pour un nouveau que

Code :

1
2
3
4
5
if ((a == b) && (c !=  d)) {
   something
} else {
  somethin_else
}

Autrement quid d'un langage de script pour démarrer ?

[Luc Hermitte]

En Pascal, on va utiliser = et <> (et := pour l'affectation). Et il est un peu plus verbeux avec ses begin/end
En Ada, on va utiliser = et /= (et := pour l'affectation)
Et en C++ (je n'ai jamais vérifié pour le C, mais cela devrait être bon aussi), and , not, or, et xor sont supportés.

[jabbounet]

je ne sais plus cela fait tres longtemps que je n'ai pas fait d'ada....

avec le temps on enjolive un peu les choses ,

mais avoir 'then else endif' à la place de '{ } else { }' me semble déjà plus lisible.