+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 13 PremièrePremière ... 2345678910 ... DernièreDernière
Affichage des résultats 101 à 120 sur 247
  1. #101
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 183
    Points : 8 332
    Points
    8 332

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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.

    Citation Envoyé par deadalnix
    Pour moi, il est indispensable pour se dire programmeur de connaitre plusieurs langages.
    Là je te rejoins complètement !

    --
    Jedaï

  2. #102
    Membre expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 502
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Algérie

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 502
    Points : 5 701
    Points
    5 701

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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 ?


    Citation Envoyé par Mac LAK Voir le message
    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.


    Citation Envoyé par Mac LAK Voir le message
    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)
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  3. #103
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par Jedai Voir le message
    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.

    Citation Envoyé par Jedai Voir le message
    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.

    Citation Envoyé par hegros Voir le message
    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...

    Citation Envoyé par hegros Voir le message
    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.

    Citation Envoyé par hegros Voir le message
    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.

    Citation Envoyé par hegros Voir le message
    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.

  4. #104
    Expert Confirmé Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2009
    Messages
    1 911
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : juin 2009
    Messages : 1 911
    Points : 3 058
    Points
    3 058

    Par défaut

    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)

  5. #105
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 183
    Points : 8 332
    Points
    8 332

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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ï

  6. #106
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 223
    Points : 17 607
    Points
    17 607

    Par défaut

    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  7. #107
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 183
    Points : 8 332
    Points
    8 332

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    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ï

  8. #108
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 223
    Points : 17 607
    Points
    17 607

    Par défaut

    Citation Envoyé par Jedai Voir le message
    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...

    Citation Envoyé par Jedai Voir le message
    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...


    Citation Envoyé par Jedai Voir le message
    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


    Citation Envoyé par Jedai Voir le message
    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 ?
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  9. #109
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par jabbounet Voir le message
    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.

    Citation Envoyé par Jedai Voir le message
    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.

    Citation Envoyé par Jedai Voir le message
    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.

  10. #110
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 183
    Points : 8 332
    Points
    8 332

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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).

    Citation Envoyé par Mac LAK Voir le message
    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).

    Citation Envoyé par Mac LAK Voir le message
    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ï

  11. #111
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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.


    Citation Envoyé par Jedai Voir le message
    "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.

    Citation Envoyé par Jedai Voir le message
    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...

    Citation Envoyé par Jedai Voir le message
    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...

    Citation Envoyé par Jedai Voir le message
    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.

  12. #112
    Membre habitué
    Inscrit en
    juillet 2009
    Messages
    192
    Détails du profil
    Informations personnelles :
    Âge : 21

    Informations forums :
    Inscription : juillet 2009
    Messages : 192
    Points : 109
    Points
    109

    Par défaut

    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.

  13. #113
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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

    Citation Envoyé par Mac LAK Voir le message
    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

  14. #114
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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 !

  15. #115
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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.

    Citation Envoyé par Mac LAK Voir le message
    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...

    Citation Envoyé par Mac LAK Voir le message
    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 !

    Citation Envoyé par Mac LAK Voir le message
    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...

  16. #116
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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.
    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...

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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.

  17. #117
    alex_pi
    Invité(e)

    Par défaut

    Citation Envoyé par Mac LAK Voir le message
    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)
    Citation Envoyé par Mac LAK Voir le message
    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


    Citation Envoyé par Mac LAK Voir le message
    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"

    Citation Envoyé par Mac LAK Voir le message
    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...


    Citation Envoyé par Mac LAK Voir le message
    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.

    Citation Envoyé par Mac LAK Voir le message
    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.

    Citation Envoyé par Mac LAK Voir le message
    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.


    Citation Envoyé par Mac LAK Voir le message
    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.

  18. #118
    Membre Expert Avatar de I_believe_in_code
    Inscrit en
    décembre 2008
    Messages
    220
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : décembre 2008
    Messages : 220
    Points : 1 024
    Points
    1 024

    Par défaut

    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)

  19. #119
    Membre Expert Avatar de chaplin
    Inscrit en
    août 2006
    Messages
    1 214
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 1 214
    Points : 1 570
    Points
    1 570

    Par défaut

    Citation Envoyé par F.Saad Voir le message
    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 ?

  20. #120
    Inactif
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 894
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 894
    Points : 4 855
    Points
    4 855

    Par défaut

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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".

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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 ?

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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é ?).

    Citation Envoyé par alex_pi Voir le message
    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...

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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).

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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.

    Citation Envoyé par alex_pi Voir le message
    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...

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •