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

[Jedai]

Envoyé par Mac LAK

Par exemple, tu n'as pas idée à quel point il est difficile parfois de faire comprendre à un script-fan en quoi la chaîne "123" est différente de l'entier 123... Alors que c'est d'une évidence crasse pour quelqu'un qui a débuté avec du Pascal ou de l'Ada.

Quelqu'un qui a débuté par PHP (langage horrible s'il en est) ne fera pas la différence, mais en Python ou en Perl, "123" et 123 ne sont pas la même chose (bien que Perl permette plus facilement de passer de l'un à l'autre, surtout si on n'active pas les pragmas stricts). Connais-tu vraiment bien les langages de script autres que PHP ? (Je sais que tu ne connais pas bien Perl...)

Par ailleurs, pour en revenir à l'un de mes dadas, il existe des alternatives aux langages de script tout aussi haut niveau, tout aussi concis, à typage statique et à performances bien supérieures : les langages fonctionnels type OCaml ou Haskell. A mon avis ils sont excellents pour débuter, formant de bonnes habitudes au niveau des types et offrant d'excellentes facilités pour l'expression d'algorithmes et de structures de données complexes. Cela évite également le choc de découvrir le paradigme fonctionnel pour un programmeur impératif endurci. Comme pas mal je suis plutôt partisan de découvrir le bas-niveau par un bon cours d'architecture de la machine (et éventuellement un cours de systèmes d'exploitation) plutôt que de souffrir avec des langages de bas-niveau (ou "médians" selon MacLak qui dans la plupart de ses discussions semble situer ce milieu bien plus bas que moi ou d'autres le ferait, tendance naturelle je suppose dans un programmeur qui fait surtout du bas-niveau) inadéquats pour apprendre la programmation.

Envoyé par deadalnix

Pour moi, il est indispensable pour se dire programmeur de connaitre plusieurs langages.

Là je te rejoins complètement !

--
Jedaï

[hegros]

Envoyé par Mac LAK

C'est surtout, comme je l'ai déjà dit, que trouver un "bon" programmeur C est plutôt difficile... C'est pas les postes qui manquent, ce sont les gens compétents pour les remplir.

Ce qui est difficile est plus lié au domaine (l'avionique, la biologie tout ce qu'il est possible d'imaginer) qu'à la maîtrise du langage C en lui même. Sorti du contexte du domaine et des technologies associées "un bon programmeur C" ne veut rien dire c'est un programmeur des bancs de l'école.


Est-ce vraiment des gens compétents en C qui manque ou alors des gens avec une double compétences ?

Envoyé par Mac LAK

Ce que tu dis est vrai, mais beaucoup de langages que tu cites, bien que très utilisés, sont je pense peu propices à former quelqu'un au développement... Je trouve PHP très sympa, mais commencer par ce langage, c'est du suicide algorithmique !

Je ne te contredirais pour dire que le premier langage à apprendre pour un débutant c'est celui de l'algorithme sans aucun doute qui s'abstrait du langage. Du coup avec une bonne base algorithme pour former une personne au développement web cela ne me semble pas du suicide bien que par rapport au web c'est insuffisant.

Envoyé par Mac LAK

Or, ton message laisserait présupposer que commencer par du PHP ou du C serait une option "viable", parce que demandés en entreprise... C'est à mon sens justement l'erreur de beaucoup de débutants, qui se font éclater ensuite en entretien ou, pire, en période d'essai...

Pour le C c'est à demi-tranchant. Pour une personne dont sa formation principale est l'informatique alors c'est bien-entendu faux puisque connaître ce langage parfaitement n'est pas suffisant pour occuper un emploi dans les milieux où il est utilisé. Pour une personne de formation du métiers où ce langage est largement utilisé alors cela peut effectivement être déterminant pour l'emploi (à tort ou raison)

[Mac LAK]

Envoyé par Jedai

Connais-tu vraiment bien les langages de script autres que PHP ?

C'est pareil en Javascript notamment, tu passes d'une représentation chaîne à entière automatiquement. T'as des principes similaires en shell Unix, en batch DOS, en LUA aussi (au moins en partie).
C'est plutôt les langages de script qui ne le permettent pas que je trouve rares.

Envoyé par Jedai

Comme pas mal je suis plutôt partisan de découvrir le bas-niveau par un bon cours d'architecture de la machine (et éventuellement un cours de systèmes d'exploitation) plutôt que de souffrir avec des langages de bas-niveau (ou "médians" selon MacLak qui dans la plupart de ses discussions semble situer ce milieu bien plus bas que moi ou d'autres le ferait, tendance naturelle je suppose dans un programmeur qui fait surtout du bas-niveau) inadéquats pour apprendre la programmation.

Le médian, c'est quand le bas niveau reste accessible sans être constamment présent, et le haut niveau également accessible sans être là non plus constamment présent. Si t'as une autre définition, n'hésites pas, j'avoue que je serais curieux de savoir comment tu définis un accès direct au matériel en Haskell ou en Prolog, par exemple...

Un cours d'archi ou de systèmes ne te donnera jamais la base bas niveau correcte pour pouvoir réellement en faire un jour. Il y a une nette différence entre savoir "intellectuellement" ce qu'est un mot-machine et l'avoir pratiqué réellement, par exemple, et c'est pareil pour la gestion mémoire et tout ce que l'on peut "reprocher" au bas niveau.

Encore une fois, ce que je conteste, c'est l'approche "intégriste" pour un débutant, c'est à dire à trop haut ou trop bas niveau.

Faut être pas bien cuit pour ne pas comprendre que sans langages de haut niveau, pas de compilateurs bas niveau performants, et que sans librairies bas niveau optimisées, pas de langages de haut niveau avec un niveau de réactivité décent. Les deux sont importants, pour ne pas dire cruciaux, et se couper volontairement de la moitié de l'informatique par volonté de porter des œillères est idiot.

Envoyé par hegros

Sorti du contexte du domaine et des technologies associées "un bon programmeur C" ne veut rien dire c'est un programmeur des bancs de l'école.

J'aurais plutôt tendance à dire qu'il y a des façons de coder en C "scolaires" qui ne sont pas franchement souhaitables en milieu professionnel... Et qu'un "bon" programmeur (quel que soit le langage, d'ailleurs...) doit surtout et avant tout considérer le langage comme un outil docile, et non pas comme un ennemi personnel dédié à lui pourrir la vie...

Envoyé par hegros

Est-ce vraiment des gens compétents en C qui manque ou alors des gens avec une double compétences ?

Ben quand le gus arrive avec comme unique bagage C et développement Web, et qu'il est mauvais en C, ça n'aide pas spécialement... Il a bien une double compétence, mais aux antipodes l'une de l'autre, donc la deuxième est inutilisable, pour nous en tout cas.

Envoyé par hegros

Du coup avec une bonne base algorithme pour former une personne au développement web cela ne me semble pas du suicide bien que par rapport au web c'est insuffisant.

Sauf que là, on passe alors dans un tout autre axe de formation au développement, et justement, non liée à un langage. L'exemple de PHP que je donnais, c'est que ce langage est justement permissif et donc ne contraint pas le développeur à utiliser les "bonnes" manières en interdisant les mauvaises, comme la plupart des langages de script d'ailleurs.

Envoyé par hegros

Pour une personne de formation du métiers où ce langage est largement utilisé alors cela peut effectivement être déterminant pour l'emploi (à tort ou raison)

Là, tu abordes effectivement un autre type de débutant, dont on a très brièvement parlé dans ce sujet : le reconverti. Dans ce cas particulier, à condition d'avoir une expérience métier plus que significative, il peut effectivement démarrer par un langage moins didactique... En espérant que l'expérience métier lui a appris les bonnes bases d'algo et/ou de systèmes, sinon, c'est mort.

[jabbounet]

J'aurais plutôt tendance à dire qu'il y a des façons de coder en C "scolaires" qui ne sont pas franchement souhaitables en milieu professionnel... Et qu'un "bon" programmeur (quel que soit le langage, d'ailleurs...) doit surtout et avant tout considérer le langage comme un outil docile, et non pas comme un ennemi personnel dédié à lui pourrir la vie...

pas si docile que ça quand tu travaille avec des developpeurs indiens et que tu dois repasser dirriere et que tu ne connais pas bien le langage utilisé. (ce n'est pas du C dont je parle car l'a j'aurais su me débrouiller)

[Jedai]

Envoyé par Mac LAK

Le médian, c'est quand le bas niveau reste accessible sans être constamment présent, et le haut niveau également accessible sans être là non plus constamment présent. Si t'as une autre définition, n'hésites pas, j'avoue que je serais curieux de savoir comment tu définis un accès direct au matériel en Haskell ou en Prolog, par exemple...

Voyons, explore un peu la hiérarchie Foreign.* et tu verras qu'Haskell n'est pas si dépourvu dans ce domaine que tu sembles le penser. Tu as même des librairies comme Harpy qui te permettent d'intégrer de l'assembleur (x86) dans tes programmes Haskell, LLVM a également des bindings permettant de générer du code de bas niveau (et la puissance d'Haskell permet d'exprimer ça de façon élégante et suffisamment légère pour qu'il s'agisse d'une option sérieuse même pour des besoins limités, on n'est pas en train de parler de génération de code par LLVM en C ou C++).

Si tout ça est du chinois pour toi, tu peux toujours me demander de te montrer un code qui exécute une opération particulière de bas niveau (je ne garantis rien, ça dépendra de si j'ai le temps et de l'ambition de ta demande).

--
Jedaï

[gorgonite]

concernant Haskell, je considère que les type class et les monades ne sont pas des notions de débutant... sauf si l'on considère qu'il est normal de commencer l'info juste après une aggreg de maths

[Jedai]

Envoyé par gorgonite

concernant Haskell, je considère que les type class et les monades ne sont pas des notions de débutant... sauf si l'on considère qu'il est normal de commencer l'info juste après une aggreg de maths

Tu exagères légèrement non ? Pour ton info je n'avais pas une aggreg de maths sous le bras quand j'ai commencé Haskell et je m'en suis très bien tiré, comme d'ailleurs un grand nombre de débutants Haskell aux notions mathématiques réduites. Les typeclass ne sont vraiment pas durs à comprendre (tant qu'on n'essaie pas d'expliquer toutes les extensions qui tournent autour du premier coup), plus simple que la POO à mon humble avis. Les monades sont plus problématiques, mais pas si complexes non plus (du moins à utiliser, il est plus difficile d'apprendre à les repérer et les créer). Une bonne partie des difficultés de l'apprentissage d'Haskell viennent aussi des habitudes impératives de ceux qui l'abordent habituellement (programmeurs expérimentés intéressés par l'élargissement de leur horizon qu'Haskell leur apporte).

Il y a quelques cours d'initiation à la programmation qui utilisent Haskell, ils marchent plutôt pas mal.

--
Jedaï

[gorgonite]

Envoyé par Jedai

Tu exagères légèrement non ? Pour ton info je n'avais pas une aggreg de maths sous le bras quand j'ai commencé Haskell et je m'en suis très bien tiré,

je grossis (beaucoup) les traits bien entendu...

Envoyé par Jedai

Les typeclass ne sont vraiment pas durs à comprendre (tant qu'on n'essaie pas d'expliquer toutes les extensions qui tournent autour du premier coup), plus simple que la POO à mon humble avis.

selon moi, la complexité est proche de la POO à la Java...

Envoyé par Jedai

Les monades sont plus problématiques, mais pas si complexes non plus (du moins à utiliser, il est plus difficile d'apprendre à les repérer et les créer).

je parlais de les créer et les comprendre un peu plus que la simple utilisation de IO bien entendu

Envoyé par Jedai

Il y a quelques cours d'initiation à la programmation qui utilisent Haskell, ils marchent plutôt pas mal.

se limitent-ils à un sous-ensemble proche de caml ?
as-tu des liens ?

[Mac LAK]

Envoyé par jabbounet

pas si docile que ça quand tu travaille avec des developpeurs indiens et que tu dois repasser dirriere et que tu ne connais pas bien le langage utilisé. (ce n'est pas du C dont je parle car l'a j'aurais su me débrouiller)

C'est un peu le souci avec le développement externalisé... Reste à savoir pour quelle raison on le fait : les coûts, bien sûr. Qu'est-ce qui fait augmenter ces coûts ? Le fait que les débutants soient "inutilisables" pour ce boulot (cf. discussion dans son ensemble), les "pros" trop chers, et les assistants techniques sont souvent les deux à la fois (débutants ET chers).
Pour ma part, je fais partie des rares qui préfèrent former des débutants que d'externaliser. Hélas, je n'ai pas toujours le dernier mot à ce sujet.

Envoyé par Jedai

Voyons, explore un peu la hiérarchie Foreign.* et tu verras qu'Haskell n'est pas si dépourvu dans ce domaine que tu sembles le penser. Tu as même des librairies comme Harpy qui te permettent d'intégrer de l'assembleur (x86) dans tes programmes Haskell, LLVM a également des bindings permettant de générer du code de bas niveau (et la puissance d'Haskell permet d'exprimer ça de façon élégante et suffisamment légère pour qu'il s'agisse d'une option sérieuse même pour des besoins limités, on n'est pas en train de parler de génération de code par LLVM en C ou C++).

c'est pas avoir accès à deux ou trois trucs bas niveau (ou linker une DLL écrite en langage de bas niveau) qui peut faire dire que ton langage est "bas niveau"... Du moins, pas au sens où l'on peut l'avoir dans de "vrais" langages médians comme Ada ou Pascal.

Envoyé par Jedai

Une bonne partie des difficultés de l'apprentissage d'Haskell viennent aussi des habitudes impératives de ceux qui l'abordent habituellement (programmeurs expérimentés intéressés par l'élargissement de leur horizon qu'Haskell leur apporte).

Ben tu vois, une bonne partie des problèmes d'apprentissage en Pascal ou en Ada vient du fait que les gens ont "peur" de l'ordinateur, et/ou le considèrent comme une sorte de Dieu babylonien destiné à leur pourrir l'existence... Mais une fois cette peur de l'inconnu franchie, les concepts de ces deux langages sont suffisamment proches de la logique humaine "classique" (c'est à dire celle de gens n'ayant pas forcément un bagage math très important) pour que ce soit "naturel" de programmer avec, avec comme seule contrainte réelle l'apprentissage de la rigueur.

Couplé aux possibilités multi-paradigmes (et "multi-hauteur") de ces langages, cela en fait définitivement pour moi les meilleurs langages pour débuter.

Surtout qu'il n'y a pas besoin de "packages" supplémentaires (ou de librairies tierces) pour utiliser ces multiples paradigmes : tout est natif.

[Jedai]

Envoyé par Mac LAK

Bon, je suis un peu moqueur, je le reconnais... Mais c'est pas avoir accès à deux ou trois trucs bas niveau (ou linker une DLL écrite en langage de bas niveau) qui peut faire dire que ton langage est "bas niveau"... Du moins, pas au sens où l'on peut l'avoir dans de "vrais" langages médians comme Ada ou Pascal.

Très bien, j'admets qu'Ada ou Pascal peuvent être plus adaptés à des programmes bas-niveau qu'Haskell, mais je reste sceptique sur ton affirmation qu'Haskell ne sait pas faire de bas-niveau du tout (à part "deux ou trois trucs" non-définis).

Envoyé par Mac LAK

Ben tu vois, une bonne partie des problèmes d'apprentissage en Pascal ou en Ada vient du fait que les gens ont "peur" de l'ordinateur, et/ou le considèrent comme une sorte de Dieu babylonien destiné à leur pourrir l'existence... Mais une fois cette peur de l'inconnu franchie, les concepts de ces deux langages sont suffisamment proches de la logique humaine "classique" (c'est à dire celle de gens n'ayant pas forcément un bagage math très important) pour que ce soit "naturel" de programmer avec, avec comme seule contrainte réelle l'apprentissage de la rigueur.

"Naturel" ? Es-tu certain que tu veux entrer dans ce débat ? Le paradigme impératif n'est pas si "naturel" que ça, l'idée que "f(5)" ne renvoie pas toujours la même chose est souvent surprenante pour les débutants, l'affectation est une opération difficile à comprendre pour certains (surtout avec l'emploi de l'opérateur "=" par C, Pascal ou Ada sont heureusement plus propre à cet égard).

Envoyé par Mac LAK

Couplé aux possibilités multi-paradigmes (et "multi-hauteur") de ces langages, cela en fait définitivement pour moi les meilleurs langages pour débuter.

Surtout qu'il n'y a pas besoin de "packages" supplémentaires (ou de librairies tierces) pour utiliser ces multiples paradigmes : tout est natif.

Haskell supporte les paradigmes impératif et fonctionnel, bien qu'il soit notamment orienté fonctionnel et qu'une partie importante de son intérêt soit la capacité à distinguer par les types le code pur et le code impur (avec effets de bord), les objets sont rarement nécessaire grâce aux typeclass et types existentiels. Ada et Pascal ne supportent pas le paradigme fonctionnel si bien que ça non plus contrairement à ce que tu sembles penser (quelle est ton expérience réelle avec le paradigme et les langages fonctionnels ?). Ni Haskell, ni Ada/Pascal ne supporte le paradigme logique (encore qu'il soit relativement facile d'écrire un DSL pour ça en Haskell).

--
Jedaï

[Mac LAK]

Envoyé par alex_pi

Et j'avoue être de ceux qui pensent qu'apprendre à un débutant à coder de façon élégante, lisible, modulaire et correcte est vraiment bien plus important que de lui apprendre à "définir un accès direct au matériel"...

Oui, je sais. Je ne suis toujours pas d'accord, un ordinateur n'est pas une télé avec un clavier, il est important de savoir un peu comment ça marche à l'intérieur.
De plus, coder de façon "élégante, lisible, modulaire et correcte" est possible dans absolument tous les langages, notamment en Pascal et en Ada que je défends en tant que langages d'initiation.

Envoyé par Jedai

"Naturel" ? Es-tu certain que tu veux entrer dans ce débat ? Le paradigme impératif n'est pas si "naturel" que ça, l'idée que "f(5)" ne renvoie pas toujours la même chose est souvent surprenante pour les débutants

Si ta fonction ne renvoie pas toujours le même résultat pour les mêmes entrées, faudrait peut-être voir à virer les variables globales / statiques du code, non ? Mais bon, redevenons sérieux : tu as des exemples de fonctions (en programmation impérative) qui ne renvoient pas les mêmes données avec les mêmes entrées ? N'oublie pas que l'environnement fait partie des entrées, si tu l'utilises dans ta fonction...

Moi, au contraire, j'ai toujours eu plus facile d'expliquer le principe des fonctions en donnant l'analogie d'une fonction mathématique (f(a) est constant tant qu'on ne modifie pas "a" ni "f", dans le cadre commun accessible à la plupart des gens) que d'expliquer qu'une fonction est un programme et que son fonctionnement est altéré par d'autres fonctions qui n'ont à priori rien à voir dans l'affaire... La plupart des gens pensent plus facilement en séquentiel (=impératif, donc) qu'en fonctionnel.

Envoyé par Jedai

l'affectation est une opération difficile à comprendre pour certains (surtout avec l'emploi de l'opérateur "=" par C, Pascal ou Ada sont heureusement plus propre à cet égard).

Oui, cela fait partie des raisons qui font que je n'apprécie pas le C en tant que langage de débutant : sa syntaxe n'est pas la plus claire du monde, loin de là... Pour la plupart des gens, un "=" tout seul est forcément un test d'égalité, et non pas une affectation, on est bien d'accord là-dessus.

Pour le reste, autant j'ai pu croiser des personnes ayant des difficultés avec les pointeurs (surtout quand ils sont mal expliqués, d'ailleurs...), autant je n'ai jamais rencontré de personnes ayant des difficultés avec l'affectation, ni avec le paradigme impératif. Là encore, tout est affaire d'explications !! Tu as l'analogie avec les recettes de cuisine (pour le paradigme) ou les étiquettes / boîtes (pour les affectations), le tout est de "démystifier" les concepts derrière pour les expliquer aux étudiants.

Or, j'ai quand même rencontré bien plus de profs trop dans leur sphère pour descendre au niveau de leurs étudiants que de bons pédagogues : le nombre hallucinants de "cours officieux" que j'ai pu faire dans ma scolarité me l'a démontré à de nombreuses reprises...

Envoyé par Jedai

Ada et Pascal ne supportent pas le paradigme fonctionnel si bien que ça non plus contrairement à ce que tu sembles penser (quelle est ton expérience réelle avec le paradigme et les langages fonctionnels ?).

Houlà, attention, relis mieux : j'ai dit qu'ils permettaient une APPROCHE du paradigme fonctionnel, pas qu'ils le supportaient dans son entièreté. C'est très différent.
Quant à ce que j'ai pu bouffer en fonctionnel... Lambda-calcul "théorique", Lisp, Scheme, et j'ai même bouffé du Prolog pour taper dans le dernier paradigme. Mais au moins, contrairement à beaucoup, j'ai fait mon choix en toute connaissance de cause, en sachant ce que je laissais de côté. Alors que ta manière d'approcher l'initiation au développement voudrait leur faire ignorer l'aspect bas niveau... Moi, je cherche à leur ouvrir l'esprit à tous les aspects / niveaux du développement, peux-tu en dire autant ? Non.

J'ai trouvé tous ces langages intéressants, bien qu'assez limités souvent à un domaine plus ou moins restreint, mais j'en ai toujours retiré un point important : un solide bagage mathématique est souvent nécessaire pour comprendre ces langages. Et c'est exactement pour ça que je ne les conseille pas pour un débutant.

Après, chacun voit midi à sa porte : pour ma part, en projet de maîtrise, on avait un sujet commun (compression de Huffman), à implémenter au choix en Scheme ou en Ada. Au final ? Certes, il y avait plus de lignes de code en Ada qu'en Scheme... Mais 90% des programmes Ada ont été terminés bien avant ceux en Scheme, et étaient plus efficaces à tout point de vue. Sans compter que la plupart de ceux qui avaient choisi Scheme se ont quand même pas mal galéré pour réussir à faire leur programme, alors que ceux qui avaient choisi Ada ont obtenu le résultat très vite, et ont soit été libres de "pousser" plus loin, soit d'être tranquilles et de pouvoir passer à autre chose...

Envoyé par Jedai

Ni Haskell, ni Ada/Pascal ne supporte le paradigme logique (encore qu'il soit relativement facile d'écrire un DSL pour ça en Haskell).

Et il est possible de câbler un interpréteur Prolog dans un programme C/C++, tout comme on le fait pour beaucoup de langages de script... Est-ce du natif pour autant ? Bien sûr que non, c'est même au contraire de la programmation avancée en C.
L'ouverture impérative, OO, bas niveau et haut niveau du Pascal et de l'Ada sont NATIVES, il est trivial de passer de l'un à l'autre ou au contraire de s'isoler dans l'un de ces aspects. La seule et unique contrainte (impérative, d'ailleurs), c'est le programme principal, réduit à un "Init / run / done" en mode OO complet...


Comme je l'ai déjà dit et répété des dizaines de fois : être extrémiste et/ou faire du prosélytisme pour l'ultra-bas (ou ultra-haut) niveau n'apporte RIEN DE BIEN. Apprenez aux étudiants un langage médian, montrez-leur des portes vers chaque "univers" de la programmation, et foutez-leur la paix dans leurs choix par la suite.

Je ne défends pas le bas niveau par "intégrisme", mais parce que certains voudraient faire croire qu'il ne sert à rien, ce qui est une bêtise sans nom... Les deux aspects du développement ont leur avantages, inconvénients, et rôle. Dénigrer l'un des deux est stupide, et pousser les étudiants vers un seul de ces aspects est encore plus stupide. Laissez-les choisir ce qu'ils aiment faire, mais pour ça, il est crucial de leur offrir ce choix, d'où ma position d'utiliser des langages médians pour débuter la programmation.

[F.Saad]

En tant que débutant moi meme.
je crois savoir ce qu'on veut. (nuance, vouloir/Avoir besoin).
Le petit newbie a besoin de premièrement apprendre un truc rapide, genre qu'il voit qu'au bout d'une semaine, il peut commencer a faire des trucs.
Après il pourrait revenir sur les même chapitres mais avec des cours plus approfondies, sinon çà ne l'intéressera pas.

Mais bon, la je parle des autodidactes.
donc pour moi, C# All the way grace au modos de la séction. que je remercie au passage.
et puis toujours du C#, je ne vois pas l'intérêt de passer a un autre langage pour un débutant.

Envoyé par Mac LAK

Si ta fonction ne renvoie pas toujours le même résultat pour les mêmes entrées, faudrait peut-être voir à virer les variables globales / statiques du code, non ? Mais bon, redevenons sérieux : tu as des exemples de fonctions (en programmation impérative) qui ne renvoient pas les mêmes données avec les mêmes entrées ? N'oublie pas que l'environnement fait partie des entrées, si tu l'utilises dans ta fonction...

Justement, en Haskell, tu es dans la monade IO qui fait passer l'environnement en argument. Tu vois, tu penses déjà Haskell

Envoyé par Mac LAK

Moi, au contraire, j'ai toujours eu plus facile d'expliquer le principe des fonctions en donnant l'analogie d'une fonction mathématique (f(a) est constant tant qu'on ne modifie pas "a" ni "f", dans le cadre commun accessible à la plupart des gens) que d'expliquer qu'une fonction est un programme et que son fonctionnement est altéré par d'autres fonctions qui n'ont à priori rien à voir dans l'affaire...

Donc on est d'accord, l'approche fonctionnelle est la plus naturelle. Le débat est clos \o/ Il faut faire commencer les débutants par un langage fonctionnel.
CQFD

[Mac LAK]

Envoyé par alex_pi

Justement, en Haskell, tu es dans la monade IO qui fait passer l'environnement en argument. Tu vois, tu penses déjà Haskell

L'environnement, c'est vaste... Ce n'est pas que l'environnement dans le genre "variables d'environnement". Si tu préfères, remplaces-le par "contexte système", c'est à dire peu ou prou la somme de l'état logiciel de la machine (= ce qui est sauvé sur ton dur en mode Hibernation), plus l'état électronique courant de la machine (= non sauvable).

Tu crois sincèrement que le concept d'environnement en tant que paramètre d'une fonction est "nouveau" et introduit par les langages fonctionnels comme Haskell ? J'ai du mal à croire que tu puisses être sérieusement convaincu de ceci, alors que c'est une base commune de tous les langages bas niveau depuis qu'ils existent...

Envoyé par alex_pi

Donc on est d'accord, l'approche fonctionnelle est la plus naturelle. Le débat est clos \o/ Il faut faire commencer les débutants par un langage fonctionnel.
CQFD

J'attends toujours l'exemple d'une fonction déclarée impérativement et renvoyant des valeurs différentes lorsqu'on l'appelle avec les mêmes arguments, puisque cela semble être "difficile" à comprendre pour les débutants... J'avoue que pour moi aussi d'ailleurs, j'ai même hâte de voir ça.

Tout comme il va être difficile de montrer qu'un appel de fonction (ou de procédure) n'est pas un branchement inconditionnel, une des quatre bases de la programmation impérative... Éventuellement suivi (dans le cas d'une fonction) d'une assignation, autre base de ladite programmation impérative.

L'approche est bien plus impérative que fonctionnelle, car elle se base sur une séquentialité d'opération élémentaires parmi les quatre de base (affectation, saut conditionnel, saut inconditionnel, boucle de répétition). Les gens le comprennent en général comme "Faire l'opération X et la récupérer", au milieu d'un ensemble d'opérations totalement séquentielles... La fameuse "recette de cuisine", donc, et "juste" la base de l'algorithmique.

Pour introduire le concept de fonction, pour ma part, j'utilisais l'analogie suivante : "Prendre une casserole"... Ce qui sous-entends, derrière, "Aller jusqu'au meuble à casseroles, ouvrir la porte, prendre la casserole, refermer la porte, revenir à la gazinière". Totalement impératif, donc... Et c'est pourtant une fonction / procédure !

Envoyé par Mac LAK

J'attends toujours l'exemple d'une fonction déclarée impérativement et renvoyant des valeurs différentes lorsqu'on l'appelle avec les mêmes arguments, puisque cela semble être "difficile" à comprendre pour les débutants... J'avoue que pour moi aussi d'ailleurs, j'ai même hâte de voir ça.

Bon, j'avoue, j'ai qu'un exemple super compliqué qui me vient en tête

Code :

1
2
3
int get_fst(int *t){
  t[0];
}

Bon après, j'avoue, c'est tiré par les cheveux.

Envoyé par Mac LAK

Tout comme il va être difficile de montrer qu'un appel de fonction (ou de procédure) n'est pas un branchement inconditionnel, une des quatre bases de la programmation impérative... Éventuellement suivi (dans le cas d'une fonction) d'une assignation, autre base de ladite programmation impérative.

Ah oui, "on peut compiler un langage fonctionnel vers un langage impératif, donc ça n'apporte aucun concept nouveau". C'est sûr...

Envoyé par Mac LAK

L'approche est bien plus impérative que fonctionnelle, car elle se base sur une séquentialité d'opération élémentaires parmi les quatre de base (affectation, saut conditionnel, saut inconditionnel, boucle de répétition).

Oui, c'est vrai, la notion de fonction est vachement plus impérative que fonctionnelle. Euuuh, atta, pourquoi les gens appellent le fonctionnel fonctionnel ? Pwah, pure coïncidence !

Envoyé par Mac LAK

Les gens le comprennent en général comme "Faire l'opération X et la récupérer", au milieu d'un ensemble d'opérations totalement séquentielles... La fameuse "recette de cuisine", donc, et "juste" la base de l'algorithmique.

Quand tu dis "les gens", tu ne parlerais pas, par le plus grand des hasards, des "gens qui ont programmé en impératif toute leur vie et n'ont jamais touché à un langage fonctionnel" ? Eux je veux bien croire qu'il voient une "fonction" comme un truc impératif. Moi, je vois une fonction comme quelqu'un chose qui attends des valeurs en entrée, et produit une valeur en sortie, et ce en appliquant d'autres fonctions aux valeurs d'entrées et en combinant les résultats.

Typiquement, je préfère dire "la hauteur d'un arbre, c'est le max de la hauteur de ses fils, plus un" que "pour calculer la hauteur d'un arbre, assigne une variable h à 0, puis déréférence le pointeur sur la tête de l'arbre, puis...." J'ai du mal à voir le moindre argument en faveur de la seconde approche, surtout pour un débutant...

[Mac LAK]

Envoyé par alex_pi

Bon, j'avoue, j'ai qu'un exemple super compliqué qui me vient en tête

Code :

Bon après, j'avoue, c'est tiré par les cheveux.

C'est surtout faux : "t" est un pointeur, donc il faut avec traîner l'environnement qui va avec... Donc, la mémoire aux alentours de "t", notamment la première valeur.
Au passage, il faut écrire "return (*t);" et non pas "t[0]", hein...

Envoyé par alex_pi

Ah oui, "on peut compiler un langage fonctionnel vers un langage impératif, donc ça n'apporte aucun concept nouveau". C'est sûr...

Dans ce cas de figure, c'est un concept impératif, celui de sous-programme, qui est traduit par le concept de fonction ou de procédure. Je te rappelle qu'une procédure est une fonction ne retournant aucune valeur...

Envoyé par alex_pi

Oui, c'est vrai, la notion de fonction est vachement plus impérative que fonctionnelle. Euuuh, atta, pourquoi les gens appellent le fonctionnel fonctionnel ? Pwah, pure coïncidence !

Je le répète : la notion de sous-programme réalisée par une fonction est une notion impérative, puisque l'on AFFECTE le résultat d'une fonction à quelque chose, ou que l'on BRANCHE vers une procédure.
Deux concepts totalement impératifs...

Envoyé par alex_pi

Quand tu dis "les gens", tu ne parlerais pas, par le plus grand des hasards, des "gens qui ont programmé en impératif toute leur vie et n'ont jamais touché à un langage fonctionnel" ? Eux je veux bien croire qu'il voient une "fonction" comme un truc impératif. Moi, je vois une fonction comme quelqu'un chose qui attends des valeurs en entrée, et produit une valeur en sortie, et ce en appliquant d'autres fonctions aux valeurs d'entrées et en combinant les résultats.

Je parle des étudiants (ou condisciples si tu préfères) que j'ai cotoyés tout au long de ma formation, ainsi que les débutants (inclus les stagiaires) que j'ai rencontrés pendant ma carrière, plus mes collègues... Y compris un pourtant fan de métaprogrammation.

Envoyé par alex_pi

Typiquement, je préfère dire "la hauteur d'un arbre, c'est le max de la hauteur de ses fils, plus un" que "pour calculer la hauteur d'un arbre, assigne une variable h à 0, puis déréférence le pointeur sur la tête de l'arbre, puis...." J'ai du mal à voir le moindre argument en faveur de la seconde approche, surtout pour un débutant...

La plupart des gens (au sens ci-dessus) à qui on explique ça te demanderont pourquoi tu utilises un truc aussi bordélique qu'un max de tous les fils alors qu'il est si simple de parcourir l'arbre... Même si ça revient exactement au même au final, il n'y a pas trente-six manières de calculer la hauteur d'un arbre. Ni d'ailleurs d'arbres dans tous les algos...

Et même si on utilise un arbre : en langage impératif, si on n'est pas complètement inconscient des performances et que l'on a besoin de la hauteur, alors on maintient la hauteur dans les attributs de l'arbre. Il n'y a alors même pas besoin de faire une fonction de calcul de la hauteur, on renvoie simplement l'attribut correspondant.

Envoyé par Mac LAK

Moi, au contraire, j'ai toujours eu plus facile d'expliquer le principe des fonctions en donnant l'analogie d'une fonction mathématique (f(a) est constant tant qu'on ne modifie pas "a" ni "f", dans le cadre commun accessible à la plupart des gens)

Envoyé par Mac LAK

C'est surtout faux : "t" est un pointeur, donc il faut avec traîner l'environnement qui va avec... Donc, la mémoire aux alentours de "t", notamment la première valeur.

Donc en fait par 'f(a) est constant tant qu'on ne modifie pas "a" ni "f"', tu voulais en réalité dire 'f(a) est contant tant qu'on l'exécute dans un environnement identique, c'est à dire finalement au même moment dans la même exécution du même programme'. Oui bon effectivement, quand on appelle f sur une valeur a qu'une fois, on a le même résultat.

Non parce que bon, la "mémoire aux alentours de "t", c'est une notion assez floue quand même. Parce que si on a un tableau de tableau, et qu'on prend la somme de tous les éléments, la "mémoire aux alentours", elle peut aller loin. Et si c'est une liste chaînée, en fait ça peut être absolument n'importe où en tout petit bouts. Donc sérieusement, arrête deux secondes la mauvaise foi et admet que dans un monde impératif, deux appels successifs sur le même argument peut parfaitement et plus que couramment retourner deux résultats différents ! Je te rappelle qu'on est dans une discussion"quel langage pour un débutant", et je ne pense pas que dire à un débutant "toute fonction, quelle qu'elle soit a

Envoyé par Mac LAK

Au passage, il faut écrire "return (*t);" et non pas "t[0]", hein...

Ok, j'ai oublié le return, et le type de mon argument aurait du être "int i[]". Mais je maintiens le "i[0]" pour une fonction "get_fst"

Envoyé par Mac LAK

Dans ce cas de figure, c'est un concept impératif, celui de sous-programme, qui est traduit par le concept de fonction ou de procédure.

Uniquement parce que tu ne travaille qu'avec des langages impératifs et a été formaté à penser "sous programme" pour une fonction ! Une fonction, mathématiquement c'est quelque chose qui prend des arguments et en retourne d'autres. Et son comportement ne devrait dépendre que de ces arguments justement. Quand on parle de la fonciton Zeta de Riemann, elle ne change pas de valeur quand elle est appelé sur 42 suivant la couleur du ciel... Et ça n'a pas à être défini par un "processus calculatoire" en sous étapes d'affectation de variable...

Envoyé par Mac LAK

Je le répète : la notion de sous-programme réalisée par une fonction est une notion impérative, puisque l'on AFFECTE le résultat d'une fonction à quelque chose, ou que l'on BRANCHE vers une procédure.
Deux concepts totalement impératifs...

Nan mais sérieusement, il faut quand même arrêter le craquage quoi... Déjà on n'affecte pas systématiquement le résultat d'une fonction. Généralement on le passe à une autre fonction. Et en fonctionnel, on n'affecte jamais quoique ce soit. On défini une variable en fonction du résultat d'une fonction. Ne pas confondre.

Ensuite on ne "branche pas" vers une fonction, on l'appelle

Pour une procédure, bien sûr que c'est impératif, puisqu'une fonction sans valeur de retour n'a aucun intéret s'il n'y a pas d'effet de bord.

Envoyé par Mac LAK

La plupart des gens (au sens ci-dessus) à qui on explique ça te demanderont pourquoi tu utilises un truc aussi bordélique qu'un max de tous les fils alors qu'il est si simple de parcourir l'arbre...

Gni ??? Tu définis comment toi la hauteur d'un arbre ? Sans max ? Je veux vraiment bien voir ça.

Et juste pour info, en CAml, voila la définition de la hauteur d'un arbre

Code :

1
2
3
4
5
type arbre = Feuille | Noeud of arbre * int * arbre

let rec hauteur a = match a with
 | Feuille -> 0
 | Noeud (g, _, d) -> max (hauteur g) (hauteur d) + 1

Qui se lit "la hauteur d'une feuille est 0 et celle d'un noeud est le max de la hauteur du fils gauche et de la hauteur du fils droit, plus 1". Niveau bordélique, on fait pire pour moi. Et je pense que pour un débutant, pouvoir écrire l'algorithme directement, c'est un vrai plus.

Envoyé par Mac LAK

Ni d'ailleurs d'arbres dans tous les algos...

Moi je connais plus d'algo qui parlent d'arbre que d'algo qui demandent à ce qu'on gère la mémoire à la main. Donc il me semble plus adapté pour un débutant d'avoir un langage qui permet d'exprimer facilement des algos sur les arbres qu'un langage qui permet de gérer sa mémoire à la main.

Envoyé par Mac LAK

Et même si on utilise un arbre : en langage impératif, si on n'est pas complètement inconscient des performances et que l'on a besoin de la hauteur, alors on maintient la hauteur dans les attributs de l'arbre. Il n'y a alors même pas besoin de faire une fonction de calcul de la hauteur, on renvoie simplement l'attribut correspondant.

Alors là, c'est bon, je suis tué Je montre un exemple d'algorithme, et AHAH, tu me montres qu'il y a des cas où l'algo ne sert à rien. Bam
Bon après, on me souffle à l'oreillette qu'utiliser un entier de plus à chaque noeud peut avoir un impact sur "les performances" dont on ne doit pas être "complètement inconscient". Mais au chipote.

[I_believe_in_code]

Votre débat n'a rien à voir avec le topic dont le titre est "Langage pour débuter".
Sachant qu'une application n'a jamais BESOIN d'être entièrement impérative ni BESOIN d'être entièrement fonctionnelle, sachant que certaines notions sont plus aisées à saisir dans une logique impérative et d'autre dans une logique fonctionnelle, il me semble qu'il faut, quel que soit le langage qu'on choisit pour des débutants, faire écrire à ces débutants du code impératif et du code fonctionnel, et ce en montrant bien que certains appels de fonctions ont des effets de bord (et ce que cela implique) et que d'autres n'en ont pas (et ce que cela implique).

Pour des débutants il vaut mieux parler d'effets de bord, plutôt que de "paradigme impératif vs paradigme fonctionnel", qui tient plus de la querelle de théoriciens.

Pour en revenir strictement au sujet du débat, je pense que LISP est un excellent langage aussi bien pour débuter l'apprentissage de la programmation que pour voir, plus tard, certains aspects avancés (macros puissantes, CLOS,
boucle read-eval, persistance des données, fonctions de première classe, etc)

[chaplin]

Envoyé par F.Saad

En tant que débutant moi meme.
je crois savoir ce qu'on veut. (nuance, vouloir/Avoir besoin).
Le petit newbie a besoin de premièrement apprendre un truc rapide, genre qu'il voit qu'au bout d'une semaine, il peut commencer a faire des trucs.
Après il pourrait revenir sur les même chapitres mais avec des cours plus approfondies, sinon çà ne l'intéressera pas.

Mais bon, la je parle des autodidactes.
donc pour moi, C# All the way grace au modos de la séction. que je remercie au passage.
et puis toujours du C#, je ne vois pas l'intérêt de passer a un autre langage pour un débutant.

Après avoir fait du C#, voudrais tu encore changer de langage ?

[Mac LAK]

Envoyé par alex_pi

Donc en fait par 'f(a) est constant tant qu'on ne modifie pas "a" ni "f"', tu voulais en réalité dire 'f(a) est contant tant qu'on l'exécute dans un environnement identique, c'est à dire finalement au même moment dans la même exécution du même programme'. Oui bon effectivement, quand on appelle f sur une valeur a qu'une fois, on a le même résultat.

Décidément... Et après, c'est à moi que tu reproches de la mauvaise foi...
Oui, l'exécution d'un code est reproductible à l'infini tant que l'environnement (y compris réduit à quelques octets de mémoire épars) reste identique. C'est juste le principe de base des tests et de la validation.

Envoyé par alex_pi

Non parce que bon, la "mémoire aux alentours de "t", c'est une notion assez floue quand même.

Mets des lunettes alors, ou nettoie ton écran. Ta fonction déréférence un pointeur, donc forcément, la mémoire déréférencée fait partie de l'environnement de la fonction. En l'occurrence, sur l'exemple précis, l'environnement se limite très exactement à l'int situé à l'adresse "t".

Envoyé par alex_pi

Parce que si on a un tableau de tableau, et qu'on prend la somme de tous les éléments, la "mémoire aux alentours", elle peut aller loin.

Et tant que tu ne changeras pas ce tableau, la somme restera constante... Je ne vois vraiment pas le problème, en fait, sauf que tu essaies de faire croire qu'un code impératif retourne des valeurs plus ou moins "aléatoires" à données d'entrée égales.
Tu as mal compris le concept d'effet de bord de l'impératif, je pense, tu devrais réviser un peu.

Envoyé par alex_pi

Donc sérieusement, arrête deux secondes la mauvaise foi et admet que dans un monde impératif, deux appels successifs sur le même argument peut parfaitement et plus que couramment retourner deux résultats différents !

Donnes-moi des exemples (sans utiliser "rand()" ou des fonctions d'horloge bien sûr), alors ! Non, ce n'est pas "courant". C'est toi qui est de mauvaise foi en ne sachant pas ce qu'est l'environnement d'une fonction. Ou alors, t'as jamais réussi à le comprendre, d'où ta "haine" des langages bas niveau et impératifs ?

Envoyé par alex_pi

Je te rappelle qu'on est dans une discussion"quel langage pour un débutant", et je ne pense pas que dire à un débutant "toute fonction, quelle qu'elle soit a

Et on ne saura jamais la suite...

Envoyé par alex_pi

Ok, j'ai oublié le return, et le type de mon argument aurait du être "int i[]". Mais je maintiens le "i[0]" pour une fonction "get_fst"

C'est standard, ça, "fst" ? Moi, je ne connais pas.
A moins que tu ne veuilles dire "get_first" ? Houlà, mais tu codes crade !!! "GetFirst", ou mieux : "Get(Tab,Index)".
Et après, ça donne des leçons sur l'impératif...

Envoyé par alex_pi

Uniquement parce que tu ne travaille qu'avec des langages impératifs et a été formaté à penser "sous programme" pour une fonction !

Pour être strict, un sous-programme, c'est une "procédure"... Une fonction sans retour, donc.

Envoyé par alex_pi

Une fonction, mathématiquement c'est quelque chose qui prend des arguments et en retourne d'autres.

Yep. On n'est pas en maths, là, on est en informatique, au fait...

Envoyé par alex_pi

Et son comportement ne devrait dépendre que de ces arguments justement.

Elle dépend de ses arguments uniquement, au sens large. Si tu utilises des ressources globales et/ou externes, elles font partie des paramètres de ta fonction également, même s'ils ne sont pas explicites.

Sinon, j'avoue que je serais assez surpris de voir ta fameuse "constance" des résultats en Haskell sur une lecture de fichier ou une réception de socket, par exemple... Toujours les mêmes paramètres, et résultats différents à chaque fois, ça doit t'agacer...

Envoyé par alex_pi

Et ça n'a pas à être défini par un "processus calculatoire" en sous étapes d'affectation de variable...

Et le résultat, t'en fais une guirlande ? Soit tu l'utilises (ce qui revient peu ou prou à une affectation, même si c'est juste "affecté à un paramètre de fonction"), soit tu ne l'utilises pas (et dans ce cas, pourquoi l'avoir calculé ?).

Envoyé par alex_pi

Nan mais sérieusement, il faut quand même arrêter le craquage quoi... Déjà on n'affecte pas systématiquement le résultat d'une fonction. Généralement on le passe à une autre fonction. Et en fonctionnel, on n'affecte jamais quoique ce soit. On défini une variable en fonction du résultat d'une fonction. Ne pas confondre.

Ne pas confondre, en effet... L'utilisation d'une fonction dans le domaine impératif n'est pas le même qu'en domaine fonctionnel. Et l'appel d'une fonction n'est en rien contradictoire avec le paradigme impératif...

Envoyé par alex_pi

Ensuite on ne "branche pas" vers une fonction, on l'appelle

Le terme "branchement" est le terme "consacré"... Cela peut aussi bien recouvrir un saut (JMP) qu'un appel (CALL). Dans tous les cas, le PC (Program Counter) est modifié, c'est ça la définition d'un branchement.
Tu as aussi des branchements dans les boucles, les sorties de boucles, les retours de procédures / fonctions, les tests... "Branchement" est le terme générique recouvrant tout ça.

Envoyé par alex_pi

Pour une procédure, bien sûr que c'est impératif, puisqu'une fonction sans valeur de retour n'a aucun intéret s'il n'y a pas d'effet de bord.

Sauf que l'effet de bord en question peut être voulu, décorrélé de l'environnement précédent, concurrent, ou même "neutre" pour la machine (cas d'une attente par exemple).

Envoyé par alex_pi

Gni ??? Tu définis comment toi la hauteur d'un arbre ? Sans max ? Je veux vraiment bien voir ça.

Encore une fois, le troll reparaît... C'est la manière d'expliquer l'opération qui est trop mathématique pour la plupart des gens. Je l'ai bien dit : cela revient à la même chose au final car il n'y a pas beaucoup de manières de calculer la hauteur d'un arbre.

Envoyé par alex_pi

Niveau bordélique, on fait pire pour moi. Et je pense que pour un débutant, pouvoir écrire l'algorithme directement, c'est un vrai plus.

Moi, je trouve ça au contraire bien trop théorique et "matheux" pour la plupart des débutants... Qui comprendront bien mieux un algorithme itératif, même s'il revient exactement au même au final.
Question de pédagogie, la fameuse "recette de cuisine"... Pendant que toi tu t'escrimeras à demander à l'apprenti de blanchir le chou, moi j'irais lui expliquer qu'il faut le tremper dans l'eau bouillante quelques minutes, et que le terme consacré est "blanchir".
Et pendant que le tien sortira son pot de peinture blanche en désespoir de cause, le mien se tapera un bon repas.

Envoyé par alex_pi

Moi je connais plus d'algo qui parlent d'arbre que d'algo qui demandent à ce qu'on gère la mémoire à la main. Donc il me semble plus adapté pour un débutant d'avoir un langage qui permet d'exprimer facilement des algos sur les arbres qu'un langage qui permet de gérer sa mémoire à la main.

C'est lié à ton domaine d'activité, et/ou au domaine de prédilection de tes langages... Moi, c'est exactement le contraire, j'utilise assez rarement des arbres en fait. C'est souvent trop lent, comme les listes chaînées, c'est réservé à certains usages particuliers.

Envoyé par alex_pi

Alors là, c'est bon, je suis tué Je montre un exemple d'algorithme, et AHAH, tu me montres qu'il y a des cas où l'algo ne sert à rien. Bam
Bon après, on me souffle à l'oreillette qu'utiliser un entier de plus à chaque noeud peut avoir un impact sur "les performances" dont on ne doit pas être "complètement inconscient". Mais au chipote.

J'adore le fait que tu ne saches apparemment pas lire tous les mots d'une phrase, on sent bien le goût du troll derrière... Je me recite donc : "si on n'est pas complètement inconscient des performances et que l'on a besoin de la hauteur" (j'ai mis du gras aux endroits importants).

En gros : si tu as besoin de la hauteur une fois tous les 36 du mois (chargement / sauvegarde par exemple), inutile de coder ça dans l'arbre, et on se fiche un peu de l'algo utilisé de toutes façons.
Si tu t'en sers sans arrêt, l'overhead de l'ajout de la hauteur dans la structure de l'arbre sera amplement compensé par la réduction de temps de calcul de la hauteur.



Et, au fait, tu arrives à battre Delphi (vilain langage impératif dérivé du Pascal) côté nombre de lignes écrites pour résultat produit ? Le record à battre est un programme fonctionnel et interactif avec zéro ligne de code écrite par le développeur...