Discussion :

[marsupial]

Je ne donnerai pas mon vote, juste mon parcours de "programmeur" amateur.

Basic en autodidacte : nul car on ne sait pas ce qu'on fait
Assembleur à l'école sur machine automatisée : trop fastidieux
Langage C en formation professionnelle : la balade

Alors je m'interroge sincèrement. S'agit-il du C qui est adapté ou faut-il commencer par des langages nullissimes pour apprendre à apprécier un bon langage de programmation ? La réponse à cette question a déjà été donnée : il faut comprendre ce qu'on fait sans pour autant avoir à redémontrer à chaque fois le moteur à explosion et la roue lorsqu'on veut faire un pas pour être un codeur correct.

De plus, la plupart, si ce n'est tous, des langages ont été créés pour répondre à un but précis mais avec un socle commun : la machine qu'elle soit matérielle ou logicielle. Donc la comprendre reste essentiel pour obtenir le meilleur résultat. L'orientation actuelle et proche de nous sont les mégadonnées via les objets connectés. Celles-ci donneront deux orientations : leur collecte puis leur traitement. Les deux cas sont distincts : l'un demandera de comprendre le matériel, l'autre le logiciel.

De ce second constat, je m'interroge encore plus sur le langage adapté à l'apprentissage du développement.

[polaroid62]

Le fonctionnel c'est rajouter une couche de complexité à quelque chose de non trivial à la base. Penser fonctionnel ne vient pas naturellement. C'est en ça que proposer un langage fonctionnel pour des débutants est aberrant. Après évidemment si dans le bagage du débutant tu mets la récursivité...

En effet je pense qu'il doit venir plus tard par exemple en commençant un apprentissage en Ruby et en passant ensuite à Elixir qui sera une parfaite transition et pour ceux qui viennent de ROR ils utiliseront Phoenix.

Le C ou le C++ tout des tutoriels , pour le C l'ouvrage de Mathieu Nebra et pour le C++ le livre d'apprentissage de la programmation de Stroustrup sont bons je trouve.

[el_slapper]

Le débat est complètement foireux parcequ'il manque 2 choses essentielles :

(1)Quel est le but du jeu?
(2)Quel sont les études sérieuses sur le sujet?

Je n'ai rien sur le point 2, donc toute intervention de ma part sera dogmatique, voire religieuse. Pareil pour tout le monde.

Mais en plus, chacun a sa propre idée de ce que devrait être le point 1. Par exemple, Joel Spolsky, comme certains sur ce forum, est un grand fan du C pour débuter. Pour une raison bien précise : ça fait fuir les gens. Son objectif est de selectionner et de garder les meilleurs, tout en dégoutant les autres, qui sont la majorité.

D'autres ont au contraire pour objectif d'amener tout le monde à un niveau minimal pour survivre, et à ce titre vomissent sur C. Ils préfèreront des langages "gentils".

Il est bien possible que les uns et les autres aient raison, mais je constate qu'ils n'ont pas d'étude sérieuse pour appuyer leurs dires(même si j'ai tendance à les croire, une vérification systématique serait la bienvenue), mais il est surtout certain qu'ils ne peuvent pas se comprendre : leurs objectifs sont opposés.

Il y a peu, un ami à moi se plaignait de ce que "c'était trop difficile" de faire des macro sous EXCEL. Que l'interface était pourrie. Qu'il était scandaleux qu'il faille "apprendre des trucs" pour faire marcher "un truc simple". Qu'il ne devrait pas avoir besoin de "faire appel à des professionnels". Si on se place dans cette optique, le but du jeu et d'avoir des langages très simples, accessible à tous - quitte à monter en difficulté ensuite. Mais est-ce le but du jeu pour tout le monde? Cette approche est-elle la bonne pour des professionels de l'informatique? Et, d'ailleurs, est-ce seulement possible de faire des langaes simples accessibles à tous?

Je n'ai pas les réponses à toutes ces questions. Mais il faut y répondre avant de poser la sempiternelle question "quel langage pour débuter?". Pour débuter quoi? quelques automatisation EXCEL? Une carrière dans les drivers bas niveaux? Autre chose?

[Mat.M]

Cependant, en POO il est très facile de se planter (multiplication des classes, gestion des effets de bords en tous genres : exceptions, multi-threading...). Donc à mon avis, il faut prendre du recul...

Pas forcèment si tu sais un minimum concevoir quelque chose de simple dès le départ...seulement on est vite contraint de monter une usine à gaz..
tu n'as pas besoin de faire 50 classes pour un traitement en particulier.

Le problème c'est qu'en entreprise plutôt que de mettre les choses à plat et de faire une bonne analyse avec une bonne architecture , eh bien on demande aux gens de faire des développements le plus rapidement possible résultat ça fait des projets totalement ingérables.

et en procédural on fait des tonnes de copier-coller et du travail de cochon......
je viens de travailler sur un middleware de logistique développé avec un AGL RAD procédural qui ne supporte pas la POO, pour les demandes client c'était que des copier-coller ça multiplié par des heures et des heures résultat l'entreprise perd son temps et de l'argent au lieu de faire correctement des agrégats de données et de traitements corrects et fonctionnels, bref d'avoir un framework digne de ce nom.
Je veux pas faire un débat sur la POO mais il y a un paquet de gens qui pensent que c'est là pour faire joli, qui pondent des lignes de code comme on respire , pareil pour l'interface utilisateur.
Résultat ça fait des gros programmes lourdingues , difficiles à débuger parce que le code est répliqué partout à cause de copier-coller immondes.

et c'est devenu quasiment le standard dans l'industrie (C++, Java, C#...)

tout à fait ; si c'est devenu un standard c'est pas pour faire joli c'est pour être fonctionnel..
or beaucoup de gens pensent que c'est là pour faire joli.

Donc je persiste dans mes propos apprenez à structurer et bâtir convenablement un programme avant d'apprendre un langage de programmation sinon vous allez à la catastrophe...

[escartefigue]

Bonjour,

Le sondage ne prévoit que des langages du monde distribué, or, il existe aussi les langages mini-système et mainframe qui représentent une part très importante du parc applicatif en France comme à l'étranger.
Donc si on retient le critère opérationnel, j'aurais proposé COBOL et RPG dans la liste pour ne citer qu'eux.
Une remarque sur la forme aussi, une faute malheureusement courante dans le titre : le verbe débuter est intransitif, on ne peut donc pas dire "débuter la programmation"

[Luc Hermitte]

Le sondage ne prévoit que des langages du monde distribué, or, il existe aussi les langages mini-système et mainframe qui représentent une part très importante du parc applicatif en France comme à l'étranger.
Donc si on retient le critère opérationnel, j'aurais proposé COBOL et RPG dans la liste pour ne citer qu'eux.

Ce qui soulève une autre question évoquée par certains : faut-il commencer par un langage applicabilité immédiate en industrie (et former des ouvriers du développement diront certains), ou faut-il commencer par des langages a faible taux de pénétration en industrie ?

Je suis plus gêné par l'absence des anciens mastodontes de l'enseignement pour ma part : LISP ou Scheme, Pascal ou Ada.

[polaroid62]

Le milieu pro c'est vague entre la start-up et une industrie qui bosse sur du mainframe en Cobol. On doit je pense apprendre des concepts et suivre un schéma allant dans ce sens après y a les goûts de chacun , je connais un mec qui ne jure que par le fonctionnel pour tout travail : site web , applis mobiles ... mais est ce recommandé de commencer par ça ?

[esperanto]

Ce qui soulève une autre question évoquée par certains : faut-il commencer par un langage applicabilité immédiate en industrie (et former des ouvriers du développement diront certains), ou faut-il commencer par des langages a faible taux de pénétration en industrie ?

Je suis plus gêné par l'absence des anciens mastodontes de l'enseignement pour ma part : LISP ou Scheme, Pascal ou Ada.

Moi aussi j'aurais voté Pascal sans hésiter. Pourquoi? Tout simplement parce que le langage a été conçu pour ça : il ne prétend ni avoir la meilleure API ni les meilleures performances, mais il permet d'introduire tous les concepts importants au fur et à mesure :
- les structures de contrôle : procedure et function, c'est quand même plus lisible que void quand on a jamais écrit un programme, de même que begin et end plutôt que { et }. Cela dit j'aurais préféré la syntaxe Ada avec les "end if" ça montre mieux qu'on ferme les structures comme des poupées russes, alors qu'avec un simple end on peut en oublier et le compilateur aura du mal à savoir ce qu'on a oublié de fermer...
- déclaration de variables et typage fort (il n'y a pas longtemps j'ai dû aider un débutant formé en Python, langage que je maîtrise mal; certes la syntaxe "wysiwyg" oblige à écrire proprement, mais son programme était bourré d'erreurs sur les variables globales, remplies dans une fonction mais utilisées dans une autre appelée avant...)
ensuite, pour les adeptes de concepts plus avancés:
- les pointeurs : ils existent en Pascal mais sans toute l'arithmétique du C; ça limite quand même pas mal le risque de pointer sur une zone qu'on ne connaît pas, celle qui héberge le système par exemple...
- les modules : on ne passe pas par un préprocesseur bas-niveau (voir la discussion sur C++ récemment) mais on fait bien de la compilation séparée. Par contre c'est vrai qu'on aurait pu séparer mieux l'interface de l'implémentation, j'ai souvent eu des cas insolubles de références mutuelles entre modules...
- les objets : héritage simple et une syntaxe qui les montre clairement comme une extension de la notion de structure. Dommage quand même qu'on accède aux objets par valeur plutôt que par référence, celui qui passe ensuite à Java regrettera forcément de ne plus avoir cette possibilité...
En gros, presque tout ce qui existe en Pascal se retrouve ensuite dans d'autres langages, souvent avec une syntaxe plus courte donc plus agréable à écrire mais moins lisible. L'inverse n'étant vraie pour pratiquement aucun d'entre eux.

[Luc Hermitte]

- les pointeurs : ils existent en Pascal mais sans toute l'arithmétique du C; ça limite quand même pas mal le risque de pointer sur une zone qu'on ne connaît pas, celle qui héberge le système par exemple...

- les objets : héritage simple et une syntaxe qui les montre clairement comme une extension de la notion de structure

Le Pascal que tu décris ressemble furieusement au TurboPascal de Borland pour les objets (je n'ai pas suivi Lazarus). Et ... non seulement il supportait très bien l’arithmétique des pointeurs (à contrario d'Ada où j'avais été frustré lorsque je l'avais découvert)(je ne dis pas que la syntaxe était propre, il fallait caster le pointeur sur une structure avec deux entiers dedans) et ce avant que la couche objet ne soit rajoutée dans TP5.5, mais en plus on pouvait à l'époque aller taper n'importe où en mémoire ... grâce à l'OS qui ne cloisonnait rien.

Pour le deuxième point, voir l'héritage comme juste une extension de structure est une grossière erreur. Mais d'époque. Les markéteux voulaient nous vendre l'héritage comme un moyen de faire de la réutilisation de code -- comme si les fonctions ne le permettaient pas. Alors que l'objectif premier et de permettre d'avoir des données de sous-types substituables dans les expressions qui attendent des données du type parent. Cela a donné de belles horreurs par la suite : Des rectangles qui dérivent de carrées, ou des listes triées qui dérivent de listes.

[esperanto]

il supportait très bien l’arithmétique des pointeurs (à contrario d'Ada où j'avais été frustré lorsque je l'avais découvert)(je ne dis pas que la syntaxe était propre, il fallait caster le pointeur sur une structure avec deux entiers dedans)

Je ne l'ai jamais fait, je ne savais même pas qu'il permettait cette bidouille. En tout cas pour moi ça revient à dire qu'il ne supportait pas directement l'arithmétique des pointeurs (on ne pouvait pas écrire ^ptr+1) mais que certains adeptes du C avaient trouvé une astuce (non standard, non portable) pour faire la même chose au prix d'un peu plus de code.

Pour le deuxième point, voir l'héritage comme juste une extension de structure est une grossière erreur.

Tu as mal compris, j'avais écrit "une syntaxe qui les (je voulais dire les objets) montre clairement comme une extension de la notion de structure : en gros en Pascal un objet c'est un "record" avec des procédures dedans en plus.
Mais quand j'ai eu des cours de Pascal à la fac (alors que je le maniais déjà à titre perso depuis pas mal d'années) on nous a d'abord enseigné les structures, puis l'encapsulation (obligation de créer des accesseurs plutôt que d'accéder directement aux données) et seulement après la notion d'héritage.

(je n'ai pas suivi Lazarus).

Alors je viens de jeter un coup d’œil rapide à l'état du marché, les deux compilateurs libres existant actuellement (Gnu Pascal et Free Pascal, le second étant la brique de base de lazarus).
Le premier essaie de donner priorité aux standards, le second se veut compatible avant tout avec TP5 et Delphi.
Mais en regardant de plus près je constate que les deux ont adopté à peu près les mêmes possibilités à savoir un type "object" style TP5 (accédé directement comme une structure) et un type "class" accédé par référence, inspiré de Delphi. J'aurais préféré qu'ils se limitent au second choix, quitte à ajouter des directives l'autorisant localement pour la compatibilité.

Quoi qu'il en soit ils existent et donc la disparition de Borland n'est pas une excuse pour abandonner Pascal au profit de Python ou Caml (choix fréquents, le premier maintenant qu'on veut enseigner la programmation au lycée, le second plutôt quand tu arrives à la fac où des chercheurs enseignent la pure théorie).

[kolodz]

Il est dommage qu'on ne parle que des langages pour adultes ! Ou visant un objectif de production.

Il existe des langages purement destiné à l'apprentissage pédagogique de la programmation. Commet Algoid ou Scratch :

Exemple de Scratch :


Au passage, il y a le Mix-teen le 6 décembre à Lyon :
http://mixteen.github.io/
Si vous voulez donner envie à vos enfants !

Cordialement,
Patrick Kolodziejczyk.

Source :
http://scratch.mit.edu/
http://www.algoid.net/help.php?name=...N&mobile=false

[NUMB3R]

Pour la rigueur du code et des syntaxes je pencherai (avec un petit pincement au coeur) pour le C qui après des pénibles moment permet à l'apprenant de serner le concept. Ensuite il pourra très vite passer à Java ou C++ qui illustre mieux les concepts de POO et ont l'avantage d'avoir une communauté bien garnie.

[GPPro]

Pour la rigueur du code et des syntaxes je pencherai (avec un petit pincement au coeur) pour le C qui après des pénibles moment permet à l'apprenant de serner le concept. Ensuite il pourra très vite passer à Java ou C++ qui illustre mieux les concepts de POO et ont l'avantage d'avoir une communauté bien garnie.

La syntaxe est les dernier des soucis quand on veut enseigner le développement...

[DevTroglodyte]

Le C est un peu trop abrupt pour débuter la programmation... Il faut commencer par les bases : de l'algo, couplé a des softs genre scratch (pour les petits ou les non matheux) ou algobox, puis un langage type Pascal pour causer plus en détail avec la machine. Puis du C/C++ pour approfondir ça, mettre les mains de le cambouis (pointeurs, structures, je sais pas besoin du C pour ça mais bon...), etc. Puis autre chose selon ce qu'on veut faire (même si dans l'idéal, faudrait toucher à un peu tout). Mais commencer par du C, c'est un bon moyen pour en dégoûter pas mal...

[Luc Hermitte]

La syntaxe est les dernier des soucis quand on veut enseigner le développement...

+1, et je rajouterai.
Et côté rigueur, ce n'est pas comme si on ne voyait jamais des "p=realloc(p, ...);", des "int s = sizeof(T);", des "T* p; printf("%x", p);", des "while (!feof(f)) {read(f, ...); ...}", et j'en passe des plus belles. Mais ce n'est pas comme si je ne m'étais pas déjà exprimé longuement sur la gestion des cas dégradés qui ne peut qu'être absente d'un cours de C pour des débutants il y a une page (ou 2?) de cela.

Mais bon, dans un an encore quand de nouveaux posteurs débarqueront dans le fil, il y en aura de moins en moins qui auront pris la peine de lire tout l'échange ....

EDIT/PS: DevTroglodyte, C et C++ sont deux langages différents. "C/C++" est un très mauvais dialecte du C++ : c'est le dialecte inmaintenable. En production, un code C++ maintenable n'a pas un seul delete. En C++14, il ne devrait pas contenir un seul new. C'est dire à quel point il est nécessaire qu'un cours de C++ se distingue d'un cours de C si on veut inculquer ce genre de bonnes pratiques propres au C++. Dans un cours avancé, new et delete doivent être vus, mais dans un cours niveau 1, leur présentation peut être retardée très longtemps. Mais bon, on commence à sortir du cadre de cette discussion, à moins que l'on veuille présenter en quoi le C++ pourrait (ou pas être adapté à des cours débutants).

[el_slapper]

De même, on peut dire que COBOL a été (est reste) un "standard" notamment dans le domaine des banques et assurances...

Ce n'est pas parceque certaines personnes ont fait des choes formidables qu'elles ont toujours raison. Bien des langages anciens qui semblaient inexpugnables ont disparu(genre le Forth). COBOL est un langage de niche, très utile pour du traitement comptable de masse, très inutile ailleurs.

Dire qu'il corrompt l'esprit est un ânerie. COBOL est un outil, rarement utile, mais très utile quand on a besoin de lui.

Il a disparu de tous les autres domaines d'activité pour d'excellentes raisons. Il survit dans celui-ci pour d'excellentes raisons aussi. Edsger Dijkstra peut cracher comme il veut sur ce qu'il veut, il ne dispose ni de la science infuse, ni d'études scientifiques solides pour soutenir son propos.

[DevTroglodyte]

Mais bon, on commence à sortir du cadre de cette discussion, à moins que l'on veuille présenter en quoi le C++ pourrait (ou pas être adapté à des cours débutants).

Bah faut voir, c'est ce qu'on m'a enseigné à l'IUT après le passage (obligé) algo puis Pascal. Du code C avec des morceaux de C++, dans des fichiers .cpp Bon après, ça n'a duré que 6 mois, on a enquillé sur du java ensuite. Quoique j'en ai refait à la fac, en cours de compilation et en système surtout.

[codec_abc]

Parce que quand on voit la proportion de -1 par nombre de posts, ça fait plus penser à une "guerre de religion" qu'à un débat constructif et argumenté...

C'est assez souvent le cas j'ai l'impression. D'ailleurs il sert à quoi le -1 ? Moi je le voyais comme un moyen de signaler un post à troll ou de mauvaise fois, mais j'ai l'impression que certaines personnes l'utilisent juste pour dire qu'ils ne sont pas d'accord avec l'auteur du post. Si c'est l'usage qui à été prévu c'est stupide car dans un débat il y a très peu de chance que tout le monde ait le même avis.

[Luc Hermitte]

J'utilise le -1 pour les très grosses bêtises récurrentes qui sont non argumentées ou qui ne s'inscrivent pas dans un débat.

Genre:
Post1: un truc faux/aberrant est dit. Soit
Post2: un réponse argumentée au post 1 est donnée.
Pot 50: La même chose que le post 1 est dite, mais sans argument ou prise en compte du post 2 => je lui refile un -1 sans plus hésiter, et un message qui reprend plus ou moins patiemment le contenu du Post 2.

@DevTroglodyte, je comprends bien, mais c'est un truc que l'on n'arrête pas de critiquer ailleurs: http://www.codergears.com/Blog/?p=867

[codec_abc]

+1, et je rajouterai.
Et côté rigueur, ce n'est pas comme si on ne voyait jamais des "p=realloc(p, ...);", des "int s = sizeof(T);", des "T* p; printf("%x", p);", des "while (!feof(f)) {read(f, ...); ...}", et j'en passe des plus belles. Mais ce n'est pas comme si je ne m'étais pas déjà exprimé longuement sur la gestion des cas dégradés qui ne peut qu'être absente d'un cours de C pour des débutants il y a une page (ou 2?) de cela.

Il existera probablement jamais un langage qui empêchera le développeur (et surtout le développeur débutant) d'écrire des horreurs s'il en a envie ou s'il ne s'évertue pas à écrire du code propre.