Journal Python comme premier langage de programmation ?

Posté par pmoret (site web personnel) le 22 juillet 2014 à 14:19. Licence CC By‑SA.

Étiquettes :

juil.

2014

Un récent article recensait quel langage est étudié en premier dans le cursus universitaire aux Etat-unis. Il en ressort que Python est le langage le plus utilisé, devant Java, Matlab et C/C++. Ce n'est pas vraiment une surprise, au vu de la popularité du langage et de sa relative simplicité d'apprentissage.

Si je devais apprendre à programmer aujourd'hui je pense que je choisirais Scala, parce qu'il élégant, statiquement typé et combine les notions de programmation fonctionnelle et orientée-objet. Et vous autres ?

# Ça a marché pour moi

Posté par Kekun (site web personnel, Mastodon) le 22 juillet 2014 à 14:43. Évalué à 10. Dernière modification le 22 juillet 2014 à 14:44.

Quand j'ai voulu apprendre à programmer en autodidacte, je me suis cassé les dents sur le C : les pointeurs me perdaient.

Plus tard j'ai retenté le coup avec Python 3 et ça a été un succès, ça m'a permis dans un premier temps d'apprendre les bases de la programmation imprative (découpage en fonctions, affectation, typage…) pour ensuite retourner vers le C avec une compréhension d'une partie de ses concepts de base, me permettant de me concentrer sur d'autres points comme la gestion de la mémoire, la compilation…

Je suis ensuite retourné vers Python pour apprendre les bases de la POO, que j'ai ensuite pû approfondir avec Vala.

Je recommande fortement Python pour débuter.
- [^] # Re: Ça a marché pour moi
  
  Posté par Maxime (site web personnel) le 22 juillet 2014 à 15:31. Évalué à 2.
  
  C'est une question que je me pose régulièrement. J'aime beaucoup le Python, et c'est le langage que j'utilise le plus en ce moment. Mais je ne suis pas sûr que ce soit une bonne idée de commencer par ce langage pour une raison toute bête : comment tu peux intéresser tes étudiants au C et au Java lorsqu'ils ont commencé par le Python ? Si c'est pour se retrouver avec des étudiants démotivés… Alors qu'au contraire si tu commences avec un langage un peu pénible comme l'Ada (désolé pour les gens que je froisse :D), tu as tout ce dont tu as besoin pour leur apprendre les concepts de base et ils apprendront avec joie le C, le Java et le Python plus tard, comme des grands.
  
  Un autre point qui m'embête si c'est pour enseigner à de futurs développeurs : tu ne te rends pas du tout compte de la complexité algorithmique des méthodes utilisées. Quel est le temps pour l'insertion d'un nouvel élément dans une liste ? Pour la suppression ? Pour accéder à un élément par son indice ?
  - [^] # Re: Ça a marché pour moi
    
    Posté par Kekun (site web personnel, Mastodon) le 22 juillet 2014 à 15:46. Évalué à 8.
    
    comment tu peux intéresser tes étudiants au C et au Java lorsqu'ils ont commencé par le Python ?
    
    Peut-être penses-tu ça parce que tu préfères les langages interprétés et dynamiquement typés à ceux compilés et statiquement typés ?
    Personnellement j'aime avoir un compilo pour trouver mes erreurs idiotes plutôt que de m'arracher les cheveux à chaque erreur en runtime.
    Bien sûr ça n'enlève pas toutes les erreurs de runtime, mais rien que celles de syntaxe et de type, ça aide pas mal.
    
    Analogie à 2 francs : mon premier langage est le français et pourtant j'aime bien l'anglais pour ce qu'il a à offrir (cela dit, lui aussi je l'ai commencé en autodidacte).
    
    Alors qu'au contraire si tu commences avec un langage un peu pénible comme l'Ada (désolé pour les gens que je froisse :D)
    
    C'est ce qui était fait lors de ma L1 : on nous faisait étudier le OCaml (désolé pour les gens que je froisse moi aussi =p ).
    En seconde année on étudiant entre autre Scheme (bien mieux reçu dans l'ensemble), et il me semble que sur conseil des étudiants ils sont passés à Scheme comme premier langage en L1 aussi.
    Avant OCaml, le premier langage était MatLab, je n'en ai entendu que de mauvais retours.
    
    Un autre point qui m'embête si c'est pour enseigner à de futurs développeurs : tu ne te rends pas du tout compte de la complexité algorithmique des méthodes utilisées.
    
    Certes mais là on parle d'initiation à la programmation, il faut bien sûr en complément étudier l'algorithmique, ce qui est heureusement fait dans toute école d'informatique digne de ce nom. Après, est-ce qu'un autodidacte l'apprendrait de lui même… à voir.
  - [^] # Re: Ça a marché pour moi
    
    Posté par CHP le 22 juillet 2014 à 16:09. Évalué à 8.
    
    comment tu peux intéresser tes étudiants au C et au Java lorsqu'ils ont commencé par le Python ?
    
    En les confrontant à des problématiques pour lesquels ils auraient besoin des pointeurs ? Pour Java, aucun espoir : comment peut-on s'y interesser ?
    - [^] # Re: Ça a marché pour moi
      
      Posté par devnewton 🍺 (site web personnel) le 22 juillet 2014 à 17:27. Évalué à 3.
      
      Pour Java, aucun espoir : comment peut-on s'y interesser ?
      
      Quand on doit faire aboutir un projet et pas juste jouer avec un toy language!
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Ça a marché pour moi
        
        Posté par Maxime (site web personnel) le 22 juillet 2014 à 18:12. Évalué à 4.
        
        Tu es trop impatient, encore quelques jours à attendre :).
        
        [^] # Re: Ça a marché pour moi
        
        Posté par devnewton 🍺 (site web personnel) le 22 juillet 2014 à 22:05. Évalué à 4.
        
        Le journal et la quasi totalité des commentaires sont des trolls, je me suis cru presque en week end!
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Ça a marché pour moi
        
        Posté par reynum (site web personnel) le 23 juillet 2014 à 10:00. Évalué à 1.
        
        Le journal et la quasi totalité des commentaires sont des trolls
        
        Pourquoi ?
        Parce qu'ils considèrent ~~à raison~~ le Java comme langage dépassé et de seconde zone ?
        :-D
        
        kentoc'h mervel eget bezan saotred
# Hop

Posté par Marotte ⛧ le 22 juillet 2014 à 14:50. Évalué à 6.

Si je devais apprendre à programmer aujourd'hui je pense que je choisirais Scala, parce qu'il élégant, statiquement typé et combine les notions de programmation fonctionnelle et orientée-objet.

C'est purement hypothétique comme réflexion… Parce que si tu commences à apprendre à programmer tu n'as absolument aucune idée de ce que sont un typage statique et la programmation fonctionnelle ou procédurale ;)

Quand tu apprends à programmer tu ne choisis pas le langage !

Pour ma part j'ai découvert la programmation en QBasic, puis Pascal (ensuite sous Delphi), Javascript, PHP, C/C++, Python. Je ne suis pas programmeur, je code juste quelque petit truc par ci par là, le plus souvent en shell. Le python c'est bien, j'ai un projet en cours pour occuper mon temps libre, c'est en python…

Je dirais que Javascript peut-être un bon candidat pour initier à la programmation. L'environnement est facile à installer (en fait il est déjà installé sur quasiment n'importe quel PC…) et, justement, il n'est pas typé statiquement ce qui permet de mettre de côté les problématiques de types dans un premier temps pour se concentrer sur les principes de base, notamment l'algorithmie.
- [^] # Re: Hop
  
  Posté par Maxime (site web personnel) le 22 juillet 2014 à 15:51. Évalué à 5.
  
  Qu'est-ce qui fait que tu recommanderais plutôt le Javascript et non le Python ? En dehors de l'installation, je ne vois que des avantages par rapport au Javascript pour l'apprentissage. Tes arguments marchant aussi avec le Python.
  - [^] # Re: Hop
    
    Posté par Marotte ⛧ le 22 juillet 2014 à 16:54. Évalué à 3.
    
    En dehors de l'installation
    
    En effet c'est sûrement le seul avantage de Javascript sur Python. Avec Javascript, un élève très motivé qui veut apprendre à programmer pourra aisément s'entraîner chez lui (même s'il n'a que l'ordinosaure de tata Michu ou la tablette de son grand frère Kévin à sa disposition), alors qu'installer un interpréteur Python et son environnement mette en jeu des compétences qui ne sont pas à proprement parler de la programmation.
    
    Bon, plus j'y réfléchis et plus je me dis que s'il ne s'agit que d'apprendre les fondamentaux de la programmation il suffit d'avoir l'interpréteur Python tout seul, pas besoin de configurer un environnement complet, donc mon argument est vraiment faible… De plus je ne sais pas si l'installation d'un environnement Python est toujours si compliqué que ça (sous Windows), je ne l'utilise que via cygwin, et encore, en interactif vite fait, sinon je code sous GNU/Linux évidement ^{^}
    - [^] # Re: Hop
      
      Posté par claudex le 22 juillet 2014 à 17:01. Évalué à 7.
      
      JavaScript a quand même des erreurs de conception (double vs tripe égal par exemple) qui ne le rende pas propice à l'apprentissage de l'informatique de mon point de vue. En plus, si tu veux utiliser le langage pour d'autre cours (faire des fichiers, du réseau), ça devient compliqué.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Hop
        
        Posté par mael le 23 juillet 2014 à 16:09. Évalué à 1.
        
        JavaScript a quand même des erreurs de conception (double vs tripe égal par exemple)
        
        En quoi c'est une erreur de conception ?
        
        [^] # Re: Hop
        
        Posté par Zylabon le 23 juillet 2014 à 17:57. Évalué à 4. Dernière modification le 23 juillet 2014 à 18:00.
        
        Parce que == n'est pas une relation d'égalité mais d'équivalence, c'est plus faible que l'égalité.
        ajout : Du moins j'espère que c'est une relation d'équivalence (symétrique, transitive, et réflexive), parce que si c'est même pas ça c'est vraiment un gros bug de conception.
        
        Please do not feed the trolls
        
        [^] # Re: Hop
        
        Posté par Moonz le 23 juillet 2014 à 18:51. Évalué à 5. Dernière modification le 23 juillet 2014 à 18:55.
        
        symétrique, transitive, et réflexive
        
        == n’est pas réflexif pour NaN déjà (ça m’a fait tout drôle quand je suis tombé sur le cas)
        
        js> NaN == NaN false js> NaN === NaN false
        
        Pour la transitivité…
        
        js> [0] == false true js> false == "" true js> [0] == "" false
        
        Mais je te rassure, == est bien symétrique (enfin, je crois)
        
        [^] # Re: Hop
        
        Posté par Michaël (site web personnel) le 23 juillet 2014 à 23:41. Évalué à 4.
        
        == n’est pas réflexif pour NaN
        
        C'est le choix de l'IEEE pour définir l'égalité des flottants, ça n'a absolument rien à voir avec Javascript. Pour tous les gens qui ignorent que == n'est pas réfléxif en IEEE ce comportement n'a aucune importance, et pour les autres, c'est le comportement à suivre!
        
        [^] # Re: Hop
        
        Posté par Renault (site web personnel) le 23 juillet 2014 à 23:42. Évalué à 5.
        
        == n’est pas réflexif pour NaN déjà (ça m’a fait tout drôle quand je suis tombé sur le cas)
        
        C'est normal que Nan == Nan ou NaN === NaN renvoient faux, c'est dans la norme IEEE 754 cette exigence.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 juillet 2014 à 19:06. Évalué à 3. Dernière modification le 25 juillet 2014 à 19:07.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Hop
        
        Posté par Moonz le 23 juillet 2014 à 19:05. Évalué à 10. Dernière modification le 23 juillet 2014 à 19:08.
        
        Et tu as d’autres propriétés rigolotes si tu t’attends à ce que les opérateurs de comparaisons en Javascript se comportent comme en maths…
        
        js> [1,2] >= [1,2] true js> [1,2] <= [1,2] true js> [1,2] == [1,2] false
        
        Le plus test le plus rigolo que j’ai fait ce soir AMHA :
        
        js> [1,2] == [1,2] false js> [1,2] == "1,2" true
        
        [^] # Re: Hop
        
        Posté par mael le 23 juillet 2014 à 21:04. Évalué à 0.
        
        Parce que == n'est pas une relation d'égalité mais d'équivalence, c'est plus faible que l'égalité.
        
        Je ne vois pas en quoi c'est un défaut de conception en soi. L'opérateur "==" a des propriétés, du moment qu'elles sont clairement définies, je ne vois pas bien le défaut le conception. Le problème vient du fait que cet opérateur a des comportements bizarres dans certains cas. Mais son existence, et le fait qu'il ne compare pas une stricte égalité, ne constituent pas une erreur de conception, à mon avis.
    - [^] # Re: Hop
      
      Posté par Albert_ le 22 juillet 2014 à 17:28. Évalué à 7.
      Euh c'est ironique?
      
      anaconda : https://store.continuum.io/cshop/anaconda/
      
      canopy : https://www.enthought.com/products/canopy/
      
      python(x,y) : https://code.google.com/p/pythonxy/
      
      et pour tablette:
      
      https://play.google.com/store/apps/details?id=com.hipipal.qpyplus&hl=fr
- [^] # Re: Hop
  
  Posté par Thomas Douillard le 23 juillet 2014 à 09:30. Évalué à 7.
  
  J'ai fait tester javascript en premier langage à des biologistes. Ben c'est une catastrophe de leur expliquer pourquoi parfois mais pas toujours 1 + 1 = 11. Donc le typage, t'es confronté très vite au problème quoi qu'il arrive.
- [^] # Re: Hop
  
  Posté par keyser.dyson le 25 juillet 2014 à 20:10. Évalué à -1.
  
  C'est purement hypothétique comme réflexion… Parce que si tu commences à apprendre à programmer tu n'as absolument aucune idée de ce que sont un typage statique et la programmation fonctionnelle ou procédurale ;)
  
  Lol. La machine à remonter le temps pour aller tuer son père.
# Ruby

Posté par xcomcmdr le 22 juillet 2014 à 14:54. Évalué à 3. Dernière modification le 22 juillet 2014 à 14:55.
Au moins aussi facile que Python, et c'est un langage où on se répète très peu.

On peut aussi faire très rapidement des logiques du genre "de 23 à 45, afficher 'truc'" avec l'opérateur .. (son nom m'échappe pour le moment).

C'est un des exemples qui montre que la syntaxe Ruby ne se met pas en travers de la productivité. On montre aussi souvent celui-ci exemple :
```
 var=2
 4.times do |x| 
   puts x=x*var
 end
```
4.times do |x| … Une simplicité enfantine! Quand on m'a montré ça pour la première fois j'ai fait "wooh!" :)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Ruby
  
  Posté par barmic le 22 juillet 2014 à 15:19. Évalué à 3.
  
  Je me souviens un jour être tombé sur une page qui montrait plus de 5 façons d'écrire une même. Chacune portait un sens particulier, j'avais trouvé ça génial comme expressivité, mais je ne l'ai jamais retrouvée :(
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Ruby
    
    Posté par pmoret (site web personnel) le 22 juillet 2014 à 15:21. Évalué à 5.
    
    Tu connais Perl ?
    - [^] # Re: Ruby
      
      Posté par barmic le 22 juillet 2014 à 16:44. Évalué à 3.
      
      Oui et je l'apprécie beaucoup, pourquoi ? (mais il n'y a pas autant de boucle en perl qu'en ruby et ils ont malheureusement viré une construction que je trouvais génial (le given/when)).
      C'est pas parce que je dis du bien d'un langage que j'ai quoi que ce soit contre les autres.
      
      J'ai même pas dis qu'il était génial, j'ai dis qu'il avait pleins de manières d'écrire des boucles et que ça donnait une grande expressivité (je n'ai jamais vraiment codé en Ruby, je ne vais pas juger le langage).
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Ruby
  
  Posté par Adrien le 22 juillet 2014 à 15:42. Évalué à 9.
  
  Ruby n'apporte que peut d'avantage par rapport à Python. J'aime beaucoup ruby, notamment sa syntaxe, mais il faut se rendre à l'évidence : Python est nettement plus répandu, et ça facilite beaucoup de choses. Les différences entre les deux langages sont peut marqués (on pourrait très certainement faire ton exemple en python, de façon aussi simple).
  
  Python a pour lui une utilisation massive, donc avec plein de bibliothèques, que ruby n'a pas forcément. Je pense par ex. à Numpy/Scipy/Matplotlib, très utile pour les scientifiques, ou l'intégration dans de gros outils propriétaires.
  
  Le choix de ruby dépend vraiment de l'environnement dans lequel tu travailles. Pour un usage occasionnel, multi-fonction, python semble mieux adapté.
  - [^] # Re: Ruby
    
    Posté par zul (site web personnel) le 22 juillet 2014 à 15:55. Évalué à 3.
    
    L'avantage de Ruby, c'est qu'il est objet de base, et pas une évolution d'un langage impératif en langage objet (avec tous les vieux trucs qu'ils n'ont pas voulu cassé), donc il est un peu moins inconsistent.
    - [^] # Re: Ruby
      
      Posté par totof2000 le 22 juillet 2014 à 17:45. Évalué à 4.
      
      Par exemple, en Python, je déteste la soi-disante bonne façon de faire en python : utiliser type(instance) plutôt que instance.type(), qui est beaucoup plus logique d'un point de vue POO. Et en ce moment, je passe mon temps à chercher quelle idée saugrenue est passée par les développeurs de Python pour ne pas implémenter correctement la logique objet et passer par des horreurs pareilles.
      - [^] # Re: Ruby
        
        Posté par lolop (site web personnel) le 23 juillet 2014 à 08:07. Évalué à 5.
        
        Si vraiment tu en as besoin… l'introspection via objet.__class__ te donne directement l'information.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Ruby
        
        Posté par totof2000 le 28 juillet 2014 à 15:15. Évalué à 2.
        
        Je sais mais c'est stupide de devoir passer par cette méthode "spéciale" entourée de __
      - [^] # Re: Ruby
        
        Posté par feth le 23 juillet 2014 à 09:35. Évalué à 4.
        
        Python apporte la notion de protocole : « Si ça fait coincoin et que ça flotte, je peux en faire du confit ». En plus de l'objet ; et puis il faut pas être maniaque, juste pouvoir relire 1000 fois sans effort.
        len(machin) renvoie un entier, et on le voit tout de suite. Après, si tu tiens à faire "machin.len()", tu peux.
        
        [^] # Re: Ruby
        
        Posté par zul (site web personnel) le 23 juillet 2014 à 09:50. Évalué à 4.
        
        Le duck typing, ça existe dans tous les langages dynamiques, faut arrêter de planer :)
        
        Et non, tu ne peux pas pour la bibliothéque standard. Tu peux appeller foo.len() mais la bonne façon de faire en Python, c'est de définir cette méthode et d'appeller len(ton_foo). Va essayer d'expliquer rationnellement ça à quelqu'un! (IMHO, ils auraient du supprimer (quasi) toutes les built-in fonctions).
        
        [^] # Re: Ruby
        
        Posté par feth le 23 juillet 2014 à 16:00. Évalué à 3.
        
        Les protocoles, ça n'est pas pratique que pour les "builtin". Ça permet de savoir si un objet est une collection dénombrable (collections.iterable), ça permet d'utiliser la notation indexée (plop[machin]) de façon parfois créative, mais en général lisible et concise quand on implémente __setitem__ etc.
        Je pense que le pragmatisme de Python choque facilement quand on essaie de plaquer trop rapidement un modèle théorique externe -principe de moindre surprise et de plus grande ergonomie possible, surtout pour le relecteur (et en même temps, Python est tout à fait cohérent avec lui-même).
        
        [^] # Re: Ruby
        
        Posté par zul (site web personnel) le 23 juillet 2014 à 16:14. Évalué à 2. Dernière modification le 23 juillet 2014 à 16:15.
        
        Tu m'explique en quoi overwriter __setitem__(self, idx, value), c'est plus "malin" que d'overwriter [](idx, value) ? À par évidemment que le second est plus logique puisque tu appelle foo[x] …
        
        Je pense que le pragmatisme de Python choque facilement quand on essaie de plaquer trop rapidement un modèle théorique externe -principe de moindre surprise et de plus grande ergonomie possible, surtout pour le relecteur (et en même temps, Python est tout à fait cohérent avec lui-même).
        
        Pour moi, ça en fait quand même des défauts importants pour l'enseignement (des défauts tout court en fait imho mais bon). Après tu peux trouver ça super cool, super consistent, moi je trouve plein de petits détails pas "logiques", "surprenants" et donc "error-prone" quand tu ne fais pas que du Python.
        
        [^] # Re: Ruby
        
        Posté par feth le 23 juillet 2014 à 16:27. Évalué à 3.
        
        Je pense qu'on peut discuter longtemps… il n'est pas très facile de rechercher dans un corpus de code les def [](value), comparé aux __setitem__ + __getitem__ qui ne sont pas ambigus : on sait lequel est un observateur et lequel est un opérateur.
        
        [^] # Re: Ruby
        
        Posté par lolop (site web personnel) le 23 juillet 2014 à 16:45. Évalué à 10.
        
        On parle d'apprentissage de la programmation, de premier langage, et vous partez dans des problématiques de syntaxe pour redéfinir des opérateurs… franchement, le mec qui arrive dans son apprentissage au moment où il a besoin de redéfinir [], que ça s'écrive def [](value) ou bien __setitem__(self, idx, value)…
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Ruby
        
        Posté par feth le 23 juillet 2014 à 17:42. Évalué à 2.
        
        T'as bien raison :-)
        
        [^] # Re: Ruby
        
        Posté par Troy McClure (site web personnel) le 23 juillet 2014 à 12:01. Évalué à 4.
        
        Et si je m'amuse à faire coin coin pendant que je barbote dans la piscine, que va-t-il m'arriver ?
        
        [^] # Re: Ruby
        
        Posté par CHP le 23 juillet 2014 à 16:02. Évalué à 10.
        
        PAN PAN
      - [^] # Re: Ruby
        
        Posté par Bram le 19 août 2014 à 20:55. Évalué à 0.
        
        Mitshuhiko (flask, jinja2, werkzeug) explique très bien le rationnel derrière ce choix: http://lucumr.pocoo.org/2011/7/9/python-and-pola/ (anglais).
  - [^] # Re: Ruby
    
    Posté par totof2000 le 22 juillet 2014 à 17:42. Évalué à 2.
    
    Ruby n'apporte que peut d'avantage par rapport à Python.
    
    Pour avoir codé dans les 2 langages, Ruby est beaucoup plus cohérent, et ne te bloque pas avec une pseufdo "bonne manière" de faire.
    
    Python est nettement plus répandu, et ça facilite beaucoup de choses.
    
    Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil, ça se saurait, surtout en informatique.
    
    Les différences entre les deux langages sont peut marqués
    
    A l'"usage" si : on est plus vite usé à trouver la "bonne manière" de faire en python (qui défie bien souvent la logique du problème en cours de traîtement) que de faire la même chose en Ruby.
    
    (on pourrait très certainement faire ton exemple en python, de façon aussi simple).
    Ca je demande à voir.
    
    Le choix de ruby dépend vraiment de l'environnement dans lequel tu travailles. Pour un usage occasionnel, multi-fonction, python semble mieux adapté
    
    Le problème est qu'on trouve duy python partout pour des usages non occasionels, parce que l'on fait faire du dev a des personnes dont ce n'est pas le métier. Et côté lisibilité de code, on trouve plein d'horreurs issues de copier/coller pris sur le net, sans aucune réflexion sur ce qui est fait. J'en subis tous les jours en ce moment. La seule différence avec Perl, c'est que le code python est mieux indenté.
    - [^] # Re: Ruby
      
      Posté par rakoo (site web personnel) le 22 juillet 2014 à 18:07. Évalué à 8.
      
      Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil
      
      Si on reste dans le contexte "Premier langage pour apprendre la programmation", ie le sujet du 'nal, ça a du sens de chercher un langage plus répandu.
      - [^] # Re: Ruby
        
        Posté par totof2000 le 22 juillet 2014 à 18:22. Évalué à 6.
        
        Si on reste dans le contexte "Premier langage pour apprendre la programmation", ie le sujet du 'nal, ça a du sens de chercher un langage plus répandu.
        
        Je ne vois pas le rapport : ce n'est pas parce qu'un langage est répandu qu'il va faciliter l'apprentissage de la programmation. A une époque, le C était l'uin des langages les plus répandu, mais pas forcément le meilleur pour apprendre la programmation.
        
        [^] # Re: Ruby
        
        Posté par rakoo (site web personnel) le 22 juillet 2014 à 23:32. Évalué à 4.
        
        Ça dépend où tu arrêtes l'apprentissage, pour moi l'intérêt qu'il soit répandu est que tu trouveras plus facilement des libs pour aller plus loin et, surtout, de l'aide. Je pars du principe que l'apprentissage ne s'arrête pas au cours, mais c'est peut-être parce que dans le cas de la programmation je suis biaisé…
    - [^] # Re: Ruby
      
      Posté par Maxime (site web personnel) le 22 juillet 2014 à 18:27. Évalué à 10.
      
      Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil, ça se saurait, surtout en informatique.
      
      Le fait qu'il soit très utilisé renforce l'intérêt d'un langage :
      - Communauté pour pouvoir t'aider
      - Beaucoup de tutos et autres docs
      - Pleins de libs pour t'éviter de devoir réinventer la roue 36 milles fois
      - Outillage dédié au langage
      - etc.
      
      Un exemple classique est le Java. C'est un langage pas trop mal mais s'il est si souvent utilisé aujourd'hui c'est parce qu'il est beaucoup utilisé (ayé, me suis fork-bombé le cerveau). Ce que je veux dire par là c'est qu'on va souvent choisir le langage parce qu'on sait que :
      - Si jamais quelqu'un d'autre doit reprendre le projet, il y a plus de chance qu'il connaisse le Java que le Ruby
      - Il existe une lib pour faire une des fonctionnalités dont j'ai besoin
      - Si j'ai besoin d'aide je peux facilement demander à un collègue
      - On m'impose tel ou tel outil et je peux pas utiliser mon langage préféré
      
      Bref, on peut avoir un outil/produit tout juste potable mais qui devient un bon produit/outil juste parce qu'il est plus répandu. Ici on parle d'un langage pour apprendre, et dans ce cas, pouvoir trouver facilement de la doc et de l'aide sur le net c'est un argument de poids.
      - [^] # Re: Ruby
        
        Posté par totof2000 le 22 juillet 2014 à 19:50. Évalué à 0.
        
        Le fait qu'il soit très utilisé renforce l'intérêt d'un langage :
        
        En théorie, c'est vrai mais en pratique, si je prends le cas python :
        
        Communauté pour pouvoir t'aider
        
        Communauté qui passe son temps à t'engueuler parce que tu veux faire les choses d'une façon qui n'est pas "la bonne façon", qui ne répond pas à ton besoin mais à côté.
        
        Beaucoup de tutos et autres docs
        
        Dans le cas de python, c'est vrai. Mais en pratique, il vaut mieux un ou deux bon bouquins qu'un tas d'infos dispersées partout sur le web. Par exemple, si on parle du Javascript, on trouve plein de tutos qui au final n'apprennent pas grand chose parce que ne font que survoler les choses. Beaucoup de bruit.
        
        Pleins de libs pour t'éviter de devoir réinventer la roue 36 milles fois
        
        Pour apprendre, je vois plutôt ça comme un frein …
        
        Outillage dédié au langage
        
        Pour apprendre, pas besoin de plein d'outils : un éditeur de texte, un interprêteur ou un compilateur, et zou. Ah si : l'éditeur devrait si possible permettre d'accéder à une aide en ligne, mais pas plus. Mais là je parle du cas ou l'on veut apprendre. Ensuite on peut passer à des IDE plus sophistiqués.
        
        Un exemple classique est le Java. C'est un langage pas trop mal mais s'il est si souvent utilisé aujourd'hui c'est parce qu'il est beaucoup utilisé (ayé, me suis fork-bombé le cerveau). Ce que je veux dire par là c'est qu'on va souvent choisir le langage parce qu'on sait que :
        [ … ]
        
        Là tu sors du cadre initial : l'apprentissage. Pour apprendre tu te fiches royalement qu'il y ait plein de libs, Je doute également que quelqu'un reprenne ton projet de Hello World, de tri à bulle, ou de calcul de suite de Fibonacci. Certes tu pourras demander de l'aide, et c'est le seul point avantageux que je vois dans ceux que tu cites.
        
        [^] # Re: Ruby
        
        Posté par claudex le 22 juillet 2014 à 20:01. Évalué à 6.
        
        Dans le cas de python, c'est vrai. Mais en pratique, il vaut mieux un ou deux bon bouquins qu'un tas d'infos dispersées partout sur le web.
        
        Ah non pas du tout, il faut mieux pouvoir copier-coller son erreur dans Google pour comprendre où est son problème (on peut aussi appliquer la solution aveuglément mais c'est valable pour tout). Si tu ne peux pas le faire, ça complique beaucoup la tâche.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Ruby
        
        Posté par Maxime (site web personnel) le 22 juillet 2014 à 22:06. Évalué à 3.
        
        Dans mon message, je n'ai fait que répondre à :
        
        Si le fait qu'un outil/produit plus répandu en faisait un bon produit/outil, ça se saurait, surtout en informatique.
        
        Et je t'ai donné une liste d'avantages induis par la popularité d'un outil pour montrer que cela peut transformer un outil moyen en un bon outil grâce aux à-côtés.
        
        Je ne me suis pas limité au cas précis d'un langage pour l'apprentissage. Et du coup, toute ta contre-argumentation sur le fait que tel ou tel argument n'est pas valable pour l'apprentissage n'est pas forcément pertinente pour la simple raison que ce n'était pas des arguments en ce sens. Autre conséquence, lorsque tu dis :
        
        Là tu sors du cadre initial : l'apprentissage.
        
        Et bien oui, je suis d'accord, je suis sorti dès le début. Je pense d'ailleurs que le Java n'est pas un bon langage pour l'apprentissage, donc vraiment, ce n'était pas l'objectif. Seule la fin de mon message concerne le sujet initial.
        
        [^] # Re: Ruby
        
        Posté par totof2000 le 28 juillet 2014 à 15:20. Évalué à 2.
        
        Et bien oui, je suis d'accord, je suis sorti dès le début. Je pense d'ailleurs que le Java n'est pas un bon langage pour l'apprentissage, donc vraiment, ce n'était pas l'objectif. Seule la fin de mon message concerne le sujet initial.
        
        +1 pour cette précision qui permet de remettre dans le bon contexte tes propos.
        
        [^] # Re: Ruby
        
        Posté par barmic le 23 juillet 2014 à 00:10. Évalué à 7.
        
        Pour apprendre tu te fiches royalement qu'il y ait plein de libs, […]
        
        Je ne suis pas d'accord. Je pense que le fait de pouvoir faire plus ou moins n'importe quoi assez facilement avec un langage donne de l'intérêt à un langage. Le fait de pouvoir, sans y passer la moitié de sa vie, faire un programme qui répond à des requêtes HTTP, un autre qui va aller manipuler des fichiers calc et qui crée de zoli csv et de piloter un petit robot. Le tout sans (trop) entendre perpétuellement des remontrances types c'est moche/tu gère mal la mémoire/tu libère rien/etc c'est sacrément motivant pour s'y mettre.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Ruby
  
  Posté par potate le 22 juillet 2014 à 20:24. Évalué à 2.
```
puts x=x*var
```
  Pourquoi réaffecter x ?
  
  Sinon, la version en python, puisque on en parle au-dessus :
```
var=2
for x in range(4):
    print(x*val)
```
  (sans la réaffectation, qui nécessiterait une ligne supplémentaire)
  - [^] # Re: Ruby
    
    Posté par djibb (site web personnel) le 22 juillet 2014 à 21:36. Évalué à 2.
    
    val=2
    print([x*val for x in range(4)]) ?
    - [^] # Re: Ruby
      
      Posté par LeBouquetin (site web personnel, Mastodon) le 22 juillet 2014 à 22:13. Évalué à 4.
      Bonne remarque !
      
      Entre
      
      var=2 for x in range(4): print(x*val)
      
      et ça
      
      val=2 print([x*val for x in range(4)])
      
      je trouve la première construction largement plus simple à maintenir, et en plus c'est maintenable par des personnes qui ne connaissent pas python !
      
      La seconde construction est typique des "pythoneries" qui m'agacent. (en terme de perf, c'est peut-être mieux, j'en sais rien… mais en général si on code en python, la perf n'est pas la question).
      
      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
      - [^] # Re: Ruby
        
        Posté par Zylabon le 22 juillet 2014 à 22:41. Évalué à 5. Dernière modification le 22 juillet 2014 à 22:41.
        
        et en plus c'est maintenable par des personnes qui ne connaissent pas python !
        
        Est-ce que l'on a envie que des personnes qui ne connaissent pas python le maintiennent ?
        
        la pythonerie n'est qu'un ersatz de prog fonctionnelle. Regardez : c'est beau, concis, vraiment typé, sans variable, et l'implémentation colle parfaitement à la description de l'algorithme "multiplier par val les nombres entre 0 et 3".
        
        let val = 2 in fmap (*val) [..3]
        
        Please do not feed the trolls
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 juillet 2014 à 23:55. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Ruby
        
        Posté par Seb (site web personnel) le 22 juillet 2014 à 22:43. Évalué à 4.
        
        Le résultat n'est pas le même surtout.
        
        L'équivalent de la list comprehension du dessus serait plutôt :
        
        val = 2 l = [] for x in range(4): l.append(x * val) print(l)
        
        À choisir, ma préférence va pour la list comprehension pour ce genre de constructions simples (moins de bruits autour).
        À noter que je maintiens du code Python au quotidien, mon avis est un peu biaisé.
      - [^] # Re: Ruby
        
        Posté par totof2000 le 28 juillet 2014 à 15:24. Évalué à 4.
        
        c'est maintenable par des personnes qui ne connaissent pas python !
        
        Quelle idée stupide !!! Te viendrait-il à l'idée de faire maintenir ta voiture par quelqu'un qui ne connait pas la mécanique automobile ?
    - [^] # Re: Ruby
      
      Posté par Maxime (site web personnel) le 23 juillet 2014 à 17:58. Évalué à 2. Dernière modification le 23 juillet 2014 à 17:59.
      J'aurais plutôt fait comme ça :
      
      val = 2 print('\n'.join([str(x*val) for x in range(4)]))
      - [^] # Re: Ruby
        
        Posté par Moonz le 23 juillet 2014 à 18:53. Évalué à 4.
        
        Quitte à faire du python 3, tu peux virer []
        
        print('\n'.join(str(x*val) for x in range(4)))
        
        [^] # Re: Ruby
        
        Posté par Maxime (site web personnel) le 24 juillet 2014 à 17:08. Évalué à 3.
        
        Quitte à faire du python 3, tu peux virer []
        
        Tu peux le virer en Python 2 aussi.
- [^] # Re: Ruby
  
  Posté par Nicolas Blanco (site web personnel) le 24 juillet 2014 à 18:33. Évalué à 0.
  
  On va arreter tout de suite les trolls Ruby/Python.
  En quoi est ecrit linuxfr.org ? Voila. CQFD.
  Si vous voulez hacker le site le plus moulant de France, vous savez ce qui vous reste a faire.
  - [^] # Re: Ruby
    
    Posté par claudex le 24 juillet 2014 à 18:51. Évalué à 10.
    
    On remarquera aussi qu'il a relativement peu de contributeurs. CQFD.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Ruby
      
      Posté par totof2000 le 28 juillet 2014 à 15:26. Évalué à 4.
      
      PArce qu'il n'yen a pas besoin : ça marche très bien avec peu de contributeurs … CQFD.
- [^] # Re: Ruby
  
  Posté par steph1978 le 25 juillet 2014 à 15:47. Évalué à 1.
  
  Question de goût
  Moi je trouve ça moche.
  En quoi times doit être un attibut de 4 ?!
  Et puis il faut vraiment faire "put foo = bar" pour faire une affectation ?!
  - [^] # Re: Ruby
    
    Posté par freeze le 25 juillet 2014 à 16:04. Évalué à 1.
    
    puts c'est comme puts() en C, ça permet juste d'afficher les différentes valeurs calculées.
  - [^] # Re: Ruby
    
    Posté par groumly le 29 juillet 2014 à 16:53. Évalué à 3.
    
    Times est une methode de int, 4 est un int, donc times est une methode de 4.
    Ca prend un block en parametre, et l'execute n fois, en passant l'index en parametre au block.
    
    Perso je trouve ca super lisible, quand la semantique de l'algo y correspond. C'est vachement plus lisible qu'un for en tout cas.
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Apprendre a programmer pour quel utilisation?

Posté par reno le 22 juillet 2014 à 15:07. Évalué à 4.

Pour un hobby? Python me parait bien adapté..

Et si je suis d'accord avec toi que Scala me parait mieux adapté pour programmer des gros programmes, comme premier langage Python a des avantages.

Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..
- [^] # Re: Apprendre a programmer pour quel utilisation?
  
  Posté par pmoret (site web personnel) le 22 juillet 2014 à 15:19. Évalué à 2.
  
  Oui, justement pour une didactique Scala me paraît bien adapté:
  - Parce qu'on a une syntaxe moins "verbeuse" qu'en Java
  - On a un REPL
  - Bien que fortement typé, on en souffre pas inutilement parce qu'il a une bonne inférence de type, des conversions implicites.
  - On peut aller pas à pas vers des notions de programmation fonctionnelle, orientée objets, concurrente, parallèle.
  Ce qui permet en plus d'apprendre un langage d'acquérir des notions conceptuelles qui se retrouvent ensuites dans d'autres langages. Mais, on n'a pas ici de gestion de la mémoire, des pointeurs, etc.
- [^] # Re: Apprendre a programmer pour quel utilisation?
  
  Posté par davandg le 22 juillet 2014 à 16:37. Évalué à 4.
  
  Python a un avantage pratique. Il y a des milliers de bibliothèques, ça peut remplacer les macro excells, c'est assez simple, c'est libre et multiplatforme.
  
  Python couvre tout ce qu'un étudiant (pas forcement en informatique) peut vouloir/avoir besoin de faire : des stats, des graphs, de l'algo, des scripts a-la-bash…
  - [^] # Re: Apprendre a programmer pour quel utilisation?
    
    Posté par pmoret (site web personnel) le 22 juillet 2014 à 16:52. Évalué à 3.
    
    Oui effectivement, je n'ai pas précisé dans le journal, mais l'article parle de cursus en informatique, et comme j'ai moi-même étudié cette discipline j'avais d'abord envisagé la question dans ce contexte. C'est vrai qu'un langage comme Python est très utile pour les étudiants de toutes disciplines.
    Je pense que pour un cursus en informatique, il est important d'introduire beaucoup plus de concepts, et je ne suis pas sûr que Python soit idéal. De toutes manières plusieurs langages doivent être enseignés dans une telle formation…
    - [^] # Re: Apprendre a programmer pour quel utilisation?
      
      Posté par claudex le 22 juillet 2014 à 17:03. Évalué à 5.
      
      Mais faut-il apprendre tous ces concepts dès le début ? Je ne crois pas. De plus avoir des bibliothèques, ça permet de l'utiliser d'autres cours, par exemple, les stats.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Apprendre a programmer pour quel utilisation?
      
      Posté par keyser.dyson le 25 juillet 2014 à 20:18. Évalué à 0.
      
      Je pense que pour un cursus en informatique, il est important d'introduire beaucoup plus de concepts, et je ne suis pas sûr que Python soit idéal.
      
      De ce point de vue, le meileur est le Lisp alors. Il fait tout.
- [^] # Re: Apprendre a programmer pour quel utilisation?
  
  Posté par totof2000 le 22 juillet 2014 à 17:48. Évalué à 4.
  
  Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..
  
  Ce n'est pas forcément un inconvénient, surtout pour un premier langage.
  
  il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python
  
  Ca permet d'apprendre aux débutants à automatiser ses tests.
  - [^] # Re: Apprendre a programmer pour quel utilisation?
    
    Posté par Zylabon le 22 juillet 2014 à 22:54. Évalué à 4.
    
    Je dirai que son principal inconvénient est d'être dynamiquement typé: il y a pas mal de cas (spécialement quand tu es débutant d'ailleurs!) ou le compilateur aurait pu te signaler des erreurs qui ne se voient qu'à l'exécution en Python..
    
    Ce n'est pas forcément un inconvénient, surtout pour un premier langage.
    
    Non… Pour un premier langage si on a certaines ambitions dans la discipline, il faut quelque chose qui ne donne pas de mauvaises habitudes. De plus, on ne peut pas programmer sans typer, au moins dans tête. C'est terrible, les étudiants… "Bon, alors, pour cet algorithme, je vais prendre une variable x… Qui vas contenir, heuuu un entier ? une liste ? bah j'm'en fous, je verrais bien, ho, le compilateur s'en fous aussi cool ! J'ai fini ! Je test ! MONSIEUR ÇA MARCHE PAS !"
    
    Ca permet d'apprendre aux débutants à automatiser ses tests.
    
    Ouai, faudrait déjà qu'ils apprennent a faire des tests manuels… C'est difficile de faire des tests, beaucoup plus que de coder proprement.
    
    Please do not feed the trolls
    - [^] # Re: Apprendre a programmer pour quel utilisation?
      
      Posté par keyser.dyson le 25 juillet 2014 à 20:20. Évalué à 1.
      
      MONSIEUR ÇA MARCHE PAS !"
      
      Celui la ne fera jamais de programmation sérieusement.
      
      Dans quel but le former? Mis à part le fait qu'il soit un cadre en vue d'un diplome.
# BASIC !

Posté par Yth (Mastodon) le 22 juillet 2014 à 15:41. Évalué à 5.

Bah quoi, ça a marché pour moi hein…
Aaaah, recopier les listings des programmes de Jeux & Stratégies sur l'Apple IIe de ma grand-mère, voire les caractères s'ébattre à l'écran, en couleur, et s'imaginer les guerre brutales de robots programmés par nos soins, ou affronter les dangers du désert en quête d'une oasis pour ne pas périr de soif…

Hmm, bref, non, pas le BASIC, oubliez ça tout de suite…

A mon avis Python c'est très bien, facile d'approche, on peut entrer directement dans le vif du sujet. Ou sinon le C, justement pour comprendre la mémoire et les pointeurs.
Et puis on ne programme pas vraiment avant son premier vrai segfault ( :D ).

Yth.
- [^] # Re: BASIC !
  
  Posté par Benbben le 22 juillet 2014 à 17:31. Évalué à 7.
  
  Aaaah, recopier les listings des programmes …
  
  Ah la formation par l'exemple, au début tu recopies lettre à lettre, puis mot à mot, tu t'arraches les yeux pour retrouver une erreur, tu cherches dans la manuel papier, trois heures de programmation pour une heure de jeu !
  
  Mes neveux m'ont demandé, "tonton apprends nous à faire des jeux ..", mais ils veulent faire GTA directement et en cinq minutes, alors il sont déçu quand au bout d'une heure ils affichent un pauvre carré au milieu de l'écran.
  
  Bref maintenant il faut un truc qui affiche rapidement un truc visible à l'écran, et si possible joli, sinon ils zappent …
  - [^] # Re: BASIC !
    
    Posté par Maxime (site web personnel) le 22 juillet 2014 à 18:33. Évalué à 3.
    
    Aaaah, recopier les listings des programmes …
    
    J'ai moi aussi appris par le Basic sur une vieille machine en recopiant des listings. Sauf que je ne connaissais pas le raccourci permettant de stopper l'exécution d'un programme parti en boucle infinie. Et je n'avais aucun moyen de sauvegarde (en dehors de mon cahier de texte sur lequel je sauvegardais mes listings perso). Au moins il fallait réfléchir à deux fois avant de lancer un programme !
    - [^] # Re: BASIC !
      
      Posté par Yth (Mastodon) le 22 juillet 2014 à 22:37. Évalué à 2.
      
      La grande époque du bouton reset…
      J'avais un double lecteur de disquettes 5"1/4, une disquette pour l'OS avec BASIC, et une pour sauvegarder les fichiers, le graaand luxe !
      
      Yth.
      - [^] # Re: BASIC !
        
        Posté par Maxime (site web personnel) le 22 juillet 2014 à 23:09. Évalué à 2.
        
        Moi je n'avais qu'un lecteur de cassette qui ne marchait plus… C'était quelque chose de charger un programme enregistré sur une cassette !
        
        Disons que l'ordinateur était plus vieux que moi… Donc forcément…
- [^] # Re: BASIC !
  
  Posté par keyser.dyson le 25 juillet 2014 à 20:22. Évalué à 1.
  
  Jeux & Stratégies sur l'Apple IIe
  
  A la la. Tu me fais rêver.
# Templeet comme premier langage de programmation ?

Posté par Benoît Sibaud (site web personnel) le 22 juillet 2014 à 16:01. Évalué à 10. Dernière modification le 22 juillet 2014 à 16:01.

Si je devais apprendre à programmer aujourd'hui je pense que je choisirais Templeet, parce qu'il fait réviser la typographie, le comptage de caractères ouvrants et fermants, et parce qu'il permet d'écrire des choses compliquées. Et en plus il est dispose d'une très bonne coloration syntaxique dans Vim, réalisée par NoNo qui a depuis cédé aux sirènes rouges pourpres vermillons. Enfin on devient rapidement un des experts mondiaux sur le sujet.
# Python

Posté par claudex le 22 juillet 2014 à 16:10. Évalué à 3.

Python ou Ruby me semble plus adapté, ils très répandu, ce qui veut dire qu'on trouve facilement de l'aide sur Google (bien plus qu'avec Scala), ce qui est très important quand on débute. Et il ne demande pas de compilation, ce qui est aussi intéressant quand on débute parce que ça fait une source d'erreur en moins (les options à passer ou les oubli de recompilation).

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# En France

Posté par davandg le 22 juillet 2014 à 16:27. Évalué à 10. Dernière modification le 22 juillet 2014 à 16:27.

En France, depuis la rentrée 2013, toutes les prépas enseignent le python[source].

Préparez-vous à voir débarquer des ingénieurs pythoneux !
- [^] # Re: En France
  
  Posté par Snark le 24 juillet 2014 à 17:21. Évalué à 3.
  
  Je vais commenter un petit peu puisque je fais partie de ceux qui se sont portés volontaires pour cet enseignement.
  
  Je trouve que le choix de python avec sa syntaxe minimale, ses types de base faciles d'utilisation, son introspection et ses bibliothèques de tracé et de calcul scientifique est un bon choix : les étudiants n'ont pas trop de choses à apprendre sur le langage avant de commencer à faire des choses qui tiennent un petit peu la route. Les choses devraient aussi bien se passer en seconde année pour les rudiments de programmation objet.
  
  Ce qui peut inquiéter un peu pour leur avenir en programmation en Grande École, c'est qu'on ne fait aucune gestion de la mémoire et qu'on ne gère pas du tout les erreurs. Il est vrai qu'il s'agit essentiellement d'une initiation dont le but est de leur donner des rudiments…
# Pour initier un enfant

Posté par Anthony Jaguenaud le 22 juillet 2014 à 17:03. Évalué à 4.

J'ai commencé à 12 ans avec du BASIC-A. Puis, Pascal, ASM, le C à la FAC, puis Clisp, prolog (est-ce un langage ?)

Pour mon fils, je me demande entre du logo, un basic, il y avait linotte ou scratch aussi. J'aime bien le principe de scratch, c'est de l'algo visuel, mais je ne suis pas certains de la pertinence de ne pas taper réellement le code, de devoir faire de l'animation, etc.
- [^] # Re: Pour initier un enfant
  
  Posté par Kekun (site web personnel, Mastodon) le 23 juillet 2014 à 07:32. Évalué à 3.
  
  Plus haut je dis avoir commencé avec du C puis du Python mais maintenant que j'y repense c'est faux.
  
  Quand j'étais tout gamin je bidouillais du Basic (quelle version par contre…) et je me suis ensuite tourné vers The Game Factory puis sa suite Multimedia Fusion.
  
  Et justement, ces deux derniers permettent de faire du développement graphique.
  Basiquement, tu définie, dessine et anime sprites et décors, tu les place sur un scène, puis tu défini leur interactions dans un tableau à double entrées.
  Les colonnes sont les types d'objets, et les lignes sont les conditions, par exemple "si un Bonhomme est sur le sol et si la touche espace est pressée", au milieu on trouve les effets de ces conditions, par exemple sur la ligne précédente et sous la colonne Bonhomme on aurait "saute -50".
  
  C'est une approche très intéressante pour un enfant car c'est très intuitif, on n'écrit pas la moindre ligne de code, et ça permet d'avoir très rapidement un rendu amusant (typiquement, créer son propre jeu).
  par contre là ou ça s'est avéré problématique pour moi : j'ai eu énormément de mal à faire la transition vers du vrai code (et me suis cassé les dents sur le C).
  
  D'après mon expérience, je dirais que les outils de développement purement graphiques sont bien pour un enfant, mais il faudra ensuite le soutenir lors de la transition vers des langages plus classiques et tout de même bien plus austères.
- [^] # Re: Pour initier un enfant
  
  Posté par keyser.dyson le 25 juillet 2014 à 20:29. Évalué à 5.
  Après scratch, racket est pas mal.
  
  http://racket-lang.org/
  
  On peut faire:
```
(circle 50)
```
  Et ça dessine un cercle. Après, le langage est super. C'est un Scheme.
  - [^] # Re: Pour initier un enfant
    
    Posté par Anthony Jaguenaud le 27 juillet 2014 à 22:13. Évalué à 3.
    
    Merci, je vais jeter un coup d’œil.
    - [^] # Re: Pour initier un enfant
      
      Posté par jseb le 29 juillet 2014 à 21:24. Évalué à 3.
      
      Moi j'ai jeté un coup d'œil. J'ai installé le pack avec l'IDE, et j'ai commencé à lire la doc rapidement. Et puis je me suis calmé et j'y suis revenu plus méthodiquement. La doc est vraiment de qualité, très pédagogique. Un vrai bonheur.
      
      Je trouve le langage en lui-même vraiment excellent. C'est comme ça qu'on devrait apprendre l'informatique aux enfants, pas en leur parlant de HTML.
      D'ailleurs, je suis loin de l'enfance, et je sens que je vais apprendre un tas de trucs aussi (je ne connais pas du tout les langages fonctionnels).
      
      Merci au posteur qui m'a permi de découvrir ça!
      
      Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
      - [^] # Re: Pour initier un enfant
        
        Posté par keyser.dyson le 31 juillet 2014 à 01:37. Évalué à 1.
        
        C'est moi le fautif.
        
        Pour être honnête, je ne l'ai pas utilisé. J'ai regardé des vidéos et des sources.
        
        J'espère que tu ne m'en veux pas. "Les conseilleurs ne sont pas les payeurs".
        
        J'avais trouvé que l'auteur de ce langage (un australien) était très gentil et très chaleureux. Ca m'avait frappé.
        
        Il y a aussi le "look 'n feel" des machines 8-bit. Tu tappes des commandes graphiques et ça marche direct. De nos jours, on a complètement perdu ça.
        
        D'ailleurs, je suis loin de l'enfance, et je sens que je vais apprendre un tas de trucs aussi (je ne connais pas du tout les langages fonctionnels).
        
        Ce que j'aime bien aussi avec les Lisps est qu'ils font du "lambda calcul" depuis le début sans être "hipster" comme on peut le voir parfois chez les gens qui font du Haskell ou d'autres langages à la mode.
  - [^] # Re: Pour initier un enfant
    
    Posté par Anthony Jaguenaud le 31 juillet 2014 à 09:27. Évalué à 2.
    
    J'ai regardé. Je testerai avec mon fils à son retour de chez ses grand parent. Il y a plusieurs langage en un. On choisi le langage au début. Il y a même datalog un simili prolog. Je trouve ça bien par contre pour expliquer un peu l'informatique à un enfant, en plus ça a un côté magique l'ordinateur qui déduit seul.
    - [^] # Re: Pour initier un enfant
      
      Posté par Zylabon le 31 juillet 2014 à 10:40. Évalué à 3.
      
      Pour les gosses ya ça aussi :
      
      C'est du lambda calcul expliqué avec des œufs et des alligators.
      
      http://worrydream.com/AlligatorEggs/
      
      Ça amuse les vieux aussi :)
      
      Please do not feed the trolls
# Premier langage? Javascript! Première plate-forme,

Posté par fredoche le 22 juillet 2014 à 17:15. Évalué à 8.

Ça a déja été proposé un peu plus haut, mais personnellement, je choisirait javascript comme premier langage pour donner le gout de la programmation à des étudiants qui n'y connaissent rien.
Pour plusieurs raisons:
- L'interpréteur est disponible sur tous les navigateurs, il suffit d'appuyer sur f12 pour avoir à sa disposition un éditeur, un debuggeur, etc.
- Pour faire des interface graphiques, pas besoin de se débattre dans tel ou tel toolkit pas forcément portable: html, css et ça y est votre hello world est disponible sur pc, tablettes.
- Le fait de travailler au sein du web permet de partir d'un élément avec lequel les étudiants sont déja familiers.
- De formidables bases de connaissance pour approfondir, comme khanacademy.

Je me rappelle de mes premiers cours d'info, en 2001. C'était le C, avec l'argument fallacieux que le C était bon car il était portable, performant, ce qui n'est pas pertinent pour une introduction. On galérait déja pas mal avec les bases d'algorithmie, et voila que le prof nous noie avec les notions de gestion mémoire, notion absente même dans la plupart des livres sur les bases de l'algorithmie. Puis, arrive le moment où l'on a du faire des GUI, en décrivant la disposition des widgets décrite de façon très fastidieuse en C.

Évidemment, la plupart des étudiants a été découragée, et a bien vite fait de choisir des cours les éloignant de la programmation le plus possible.

Maintenant que tous les navigateurs proposent une sorte d'IDE intégré, je n'ai aucun mal à imaginer le fun qu'aurait été de faire les meme projets en javascript, dans un navigateur web. Et éventuellement, une fois les concepts généraux sur l'algo et la programmation acquis, de retourner, pour l'embarqué, pour du spécifique, au C, à l'assembleur, ou à autre chose selon les besoin ou l'environnement, scala, java, ruby, etc.
L'important, c'est de susciter l'intérêt pour la matière, d'avoir le minimum de frustration à l'usage, et de frein à l'approfondissement.
- [^] # Re: Premier langage? Javascript! Première plate-forme,
  
  Posté par claudex le 22 juillet 2014 à 17:41. Évalué à 7.
  
  Je suis d'accord mais, comme je l'ai déjà écrit, JavaScript a de gros problèmes de conception qui n'en font pas un bon langage pour débuter (va expliquer la distinction double/triple égal à quelqu'un qui ne connaît pas la programmation).
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Premier langage? Javascript! Première plate-forme,
    
    Posté par fredoche le 23 juillet 2014 à 04:31. Évalué à 2.
    
    Le double ou triple égal, c'est un détail, tu peux très bien expliquer dès le départ que == c'est mauvais et qu'il ne faut pas l'utiliser, que le mot clé with est interdit, au même titre qu'on décourage les goto dans la plupart des langages.
    - [^] # Re: Premier langage? Javascript! Première plate-forme,
      
      Posté par freeze le 23 juillet 2014 à 07:02. Évalué à 3.
      
      Tu peux toujours le dire, mais si ça compile, même par erreur, ils vont le découvrir et se croire plus malin que toi parce que … ça marche.
    - [^] # Re: Premier langage? Javascript! Première plate-forme,
      
      Posté par Dr BG le 23 juillet 2014 à 08:44. Évalué à 7.
      
      Mouais pas convaincu, une erreur extrêmement courante des débutants est déjà de confondre = et == en C ou Java…
    - [^] # Re: Premier langage? Javascript! Première plate-forme,
      
      Posté par claudex le 23 juillet 2014 à 11:00. Évalué à 7.
      
      Un langage avec des truc "à ne pas utiliser mais on ne peut pas vous dire pourquoi", ça ne me semble pas adapté à l'apprentissage.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par pmoret (site web personnel) le 23 juillet 2014 à 11:16. Évalué à 0.
        
        Un langage avec des truc "à ne pas utiliser mais on ne peut pas vous dire pourquoi", ça ne me semble pas adapté à l'apprentissage.
        
        Cela me paraît inévitable. Ou alors on retombe dans un langage simplifié uniquement dédié à l'apprentissage. Le mieux, pour moi, c'est un langage ou on peut introduire les concepts petit à petit.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par claudex le 23 juillet 2014 à 12:16. Évalué à 3.
        
        Sauf que le concept de comparaison d’égalité mais pas vraiment (le == vs ===), il n'a jamais besoin d'être appris.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par papatte3 le 23 juillet 2014 à 13:44. Évalué à 1.
        
        Sauf que le concept de comparaison d’égalité mais pas vraiment (le == vs ===), il n'a jamais besoin d'être appris.
        
        C'est pas faux, mais dans la grande majorité des langages il y a des subtilités, en particulier l'égalité qui ne marche en général pas de façon "intuitive" pour les pointeurs, références ou objets.
        
        Pour moi ça relève du point de détail. Par contre je vois deux autres défauts :
        
        Le modèle objet par prototype qui est plus "ouvert" et donc plus difficile à comprendre comment utiliser que le modèle par classes
        
        Les messages d'erreur imbitables, en particulier si tu utilises un framework où tu peux te retrouver avec une erreur dans un bout privé du framwork et une stack trace qui ne remonte pas jusqu'à ton appli
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par lolop (site web personnel) le 23 juillet 2014 à 16:47. Évalué à 4.
        
        Si tu en es à utiliser un framework, tu n'es plus dans une phase d'apprentissage de la programmation.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Antoine le 23 juillet 2014 à 15:36. Évalué à 2.
        
        Ah bon, c'est inévitable d'avoir des bugs de conception énormes ?
      - [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par barmic le 23 juillet 2014 à 12:15. Évalué à 3.
        
        C'est quand même un peu ce qui se passe en mathématiques, non ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par claudex le 23 juillet 2014 à 12:22. Évalué à 3.
        
        Ça ne m'est jamais arrivé en math de mal écrire mon 3 et de faire une somme par erreur.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par barmic le 23 juillet 2014 à 14:17. Évalué à 2.
        
        Oulà t'en fait pas tu as écris pleins de bugs en mathématiques. Ça ne se voit pas parce que ça ne s’exécute pas, mais des approximations et des imprécisions tu en a fait au moins une bonne partie de ta scolarité. Je présume que des erreurs purs en dures tu en a aussi fait des tas (je ne présume pas de ton niveau).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par papatte3 le 23 juillet 2014 à 14:56. Évalué à -1.
        
        Oulà t'en fait pas tu as écris pleins de bugs en mathématiques.
        
        [++++]
        
        Genre l'axiome du choix qui a longtemps été utilisé implicitement avant d'être formalisé.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par claudex le 23 juillet 2014 à 15:08. Évalué à 4.
        
        Ça ne se voit pas parce que ça ne s’exécute pas
        
        C'était ce que je sous-entendais. L'humain qui les lis a suffisamment de jugeotte pour interpréter correctement et une erreur du style du double égal au lieu du triple n'a pas du tout le même impact que dans un programme.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Marotte ⛧ le 31 juillet 2014 à 23:19. Évalué à 2.
        
        une erreur du style du double égal au lieu du triple n'a pas du tout le même impact que dans un programme.
        
        J'ai dû arrêter mon apprentissage des mathématiques trop tôt parce qu'il faut que tu m'expliques le concept de double ou triple égal en mathématique… En math il y a l'égalité, point barre.
        
        En mathématique le 2 entier est égale au 2 réel… C'est bien l'informatique qui introduit cette notions de type qui fait que "2" peut être différent de "2" si l'un est un entier et l'autre un réel.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par tyoup le 01 août 2014 à 06:27. Évalué à 2.
        
        En mathématique le 2 entier est égale au 2 réel… C'est bien l'informatique qui introduit cette notions de type qui fait que "2" peut être différent de "2" si l'un est un entier et l'autre un réel.
        
        En mathématiques les entiers naturels, les entiers relatifs, les rationnels, le réels, les complexes, etc ont des types fondamentalement différents.
        
        Les entiers relatifs sont des classes d'équivalence d'une relation définie sur des couples d'entiers naturels : la différence. -2 de Z par exemple est équivalent à l'ensemble de toutes les différences (0; 2), (1; 3), (2; 4),… Intuitivement 0 - 2 = 1 - 3 = 2 - 4 = … 1 de Z est différent de 1 de N car c'est aussi un ensemble de différences. Les rationnels sont définis comme des classes d'équivalence de la relation quotient, les complexes sont des classes d'équivalence de polynômes modulo X² + 1.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Ytterbium le 01 août 2014 à 08:14. Évalué à 2.
        
        Je ne suis pas allé jusque là en math, mais du coup comment définit-on les réels transcendants qui ne sont pas solution de polynômes ?
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Shuba le 01 août 2014 à 16:11. Évalué à 2.
        
        Les réels peuvent se définir comme le plus petit espace complet comprenant les rationnels. Un espace complet c'est un espace où les suites de Cauchy convergent. Une suite de Cauchy c'est une suite dont l'écart entre deux termes d'indice supérieur à N tend vers 0 quand N tends vers l'infini.
        
        On peut montre que certaines suites de Cauchy n'ont pas de limite dans les rationnels, et on peut alors introduire les réels comme limite de ces suites. On peut alors redéfinir les opérations usuelles sur les réels, montrer que c'est un ensemble indénombrable, etc.
        
        Après ce n'est qu'une construction possible, il en existe d'autres. Pour les transcendants tu peux montrer qu'ils existent par la suite (et même que quasiment tous les réels sont transcendants).
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Marotte ⛧ le 02 août 2014 à 02:15. Évalué à 3.
        
        Si on considère que ℕ est inclue dans ℝ j'ai du mal à concevoir que l'élément que l'on appelle, que l'on note "2", ne soit pas le même dans chacun de ces ensembles. Mais j'avoue que j'ai une conception bizarre (et certainement inexacte) des mathématiques…
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par tyoup le 02 août 2014 à 12:27. Évalué à 3.
        
        En théorie ils n'ont pas le même type, après on peut par abus de langage les considérer identiques car mathématiquement il y a un homomorphisme qui permet de le justifier traduisant ainsi toute propriété de N dans Z+ et ainsi de suite.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Zylabon le 01 août 2014 à 17:12. Évalué à 2.
        
        Ça dépend aussi de la sémantique qu'on prête à a = b. Personnellement j'aime bien : a = b si toute propriété de a est une propriété de b et réciproquement.
        
        Please do not feed the trolls
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par tyoup le 02 août 2014 à 00:54. Évalué à 2.
        
        1 / 2 = 2 / 4 pourtant 1 / 2 est irréductible alors que 2 / 4 ne l'est pas.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Zylabon le 02 août 2014 à 14:06. Évalué à 3.
        
        En effet d'après cette définition ce qu'on note = sur Q n'est qu'une relation d'équivalence.
        
        De même pour R car 1 = 1.0 = 1.00 = 0.99999…
        
        Please do not feed the trolls
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par claudex le 02 août 2014 à 10:30. Évalué à 3.
        
        Je n'ai pas dit que ce genre d'erreur existait mais qu'on pouvait en faire de comparable.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Premier langage? Javascript! Première plate-forme,
    
    Posté par barmic le 23 juillet 2014 à 14:19. Évalué à 3.
    
    Euh personnellement c'est surtout le fait que c'est un langage fortement asynchrone qui me semble difficile à appréhender pour débuter.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Premier langage? Javascript! Première plate-forme,
      
      Posté par claudex le 23 juillet 2014 à 15:08. Évalué à 3.
      
      Ça me semble plus facilement contournable.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par barmic le 23 juillet 2014 à 15:24. Évalué à 4.
        
        Clairement pas. Faut pas croire que les étudiants ne regardent QUE ton cours. Au contraire, ils ne t'écoutent pas et ils regardent sur internet quand ils ont besoin.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par claudex le 23 juillet 2014 à 15:27. Évalué à 4.
        
        Et ceux qui regarderont ailleurs ne seront sans doute pas ceux qui ont le plus besoin des cours et d'un langage pas trop compliqué. Du coup, ça ne me dérange pas.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par Dr BG le 23 juillet 2014 à 15:43. Évalué à 2.
        
        En première année, je n'ai pas trop l'impression (sauf ceux vraiment intéressés, mais ce n'est généralement pas une majorité). S'ils ne suivent pas le cours, ils recopient (bêtement) ce qu'un camarade à fait, mais ils ne font pas trop l'effort de chercher.
        
        [^] # Re: Premier langage? Javascript! Première plate-forme,
        
        Posté par keyser.dyson le 25 juillet 2014 à 20:36. Évalué à -1.
        
        Oui.
        
        Au final, ça ne sert à rien. Ils perdent leur temps.
- [^] # Re: Premier langage? Javascript! Première plate-forme,
  
  Posté par xcomcmdr le 22 juillet 2014 à 17:49. Évalué à 5.
  
  je choisirait javascript comme premier langage pour donner le gout de la programmation à des étudiants qui n'y connaissent rien.
  
  Ou pour les en dégoûter, au choix.
  
  En tout cas, on a trouvé comment faire des amoureux de Javascript : en faire leur premier langage. :/
  
  Quitte à vouloir faire du Javascript à la fin, autant préférer CoffeeScript.
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Premier langage? Javascript! Première plate-forme,
    
    Posté par fredoche le 23 juillet 2014 à 04:34. Évalué à 2.
    
    J'aime beaucoup coffeescript, mais il n'est pas disponible à froid dans n'importe quel navigateur, ou sinon on pourrait citer n'importe quel langage qui possède un compilateur vers JS. Cela va à l'encontre des avantages cités plus haut.
# Mon expérience

Posté par Dr BG le 22 juillet 2014 à 18:00. Évalué à 9. Dernière modification le 22 juillet 2014 à 18:02.

Je me suis posé la question il y a quelques années quand on m'a demandé de faire le cours d'initiation à l'algorithmique et à la programmation pour des élèves ingénieurs en prépa intégrée (sup). Ils ne se destinaient pas forcément à être informaticiens, l'école étant généraliste.

J'ai opté pour le D pour les raisons suivantes :
- syntaxe proche des langages les plus utilisés que sont le C et Java ;
- ramasse miette ;
- gestion des chaînes de caractère moins chiantes ;
- passage de paramètre qui me semble plus simple qu'en C sans avoir à introduire les références et les pointeurs (pas au programme).
- les objets n'étant pas au programme, le code simple écrit en D n'oblige pas à créer des classes comme en Java si on ne fait pas de code objet.
- je voulais un langage compilé pour montrer la différence entre un code source qui est lu par l'humain, et le code machine qui est lu par l'ordinateur, et que donc il faut faire du code lisible pour les humains !

Donc globalement, cela permettait de faire des petites choses basiques comme on les ferait en C, avec un langage plus moderne avec lequel on ne se prend pas la tête sur des détails, tout en ayant un syntaxe moins lourde que Java.

Je crois que maintenant, mon choix se porterait sur le Dart :
- comme pour le D, la syntaxe est très proche des langages les plus répandus, donc pas déroutant ;
- permet de faire du code client web ou serveur ;
- environnement de développement fourni (Dart Editor) ;
- types vérifiés statiquement (même si le langage est dynamique) ;
- ramasse miette ;
- comme pour le D, pas besoin de classe quand on ne fait pas d'objet.

Je trouve en effet que c'est pas mal d'avoir un IDE et une vérification statique car il faut voir le temps perdu par les débutant pour des erreurs complètement bêtes (manque de point-virgule, typo dans le nom d'une variable ou d'un mot clé… ).

J'ai aussi donné des TP d'info à des L1 math/info et bio en C (enfin, un mix C/C++ pour prendre le plus simple des deux mondes) ou JavaScript. Pour le C+ (comme on disait :-), il y a quand même quelques détails bas niveau relou sur lesquels ils butent. Quant au JavaScript, ils prennent vite de mauvaise habitudes : ils voient que leur code fonctionne sans avoir besoin de suivre les règles qu'on leur a donné, puis ils ne comprennent pas pourquoi leur programme suivant ne fonctionne pas (erreurs classiques et relou sur les types).

Pour ce qui est de la profusion de doc, je ne pense pas que ça soit un critère super important car la majorité des étudiants n'ont pas encore l'habitude de se documenter par eux-même, donc même s'il y en a, ils ne la lisent pas !
- [^] # Re: Mon expérience
  
  Posté par Dr BG le 22 juillet 2014 à 20:06. Évalué à 3.
  
  /o\ Toutes ces fautes /o\
  
  Et dire qu'on laisse des quasi-analphabètes enseigner, quelle honte !
  - [^] # Re: Mon expérience
    
    Posté par Maclag le 22 juillet 2014 à 20:51. Évalué à 7.
    
    C'est pour ça qu'il parle de D ou Dart comme premier langage, pas le Français.
    
    ---------> [ ]
- [^] # Re: Mon expérience
  
  Posté par fearan le 23 juillet 2014 à 09:39. Évalué à 3.
  
  ramasse miette ;
  
  C'est justement l'une des features que je ne recommande pas pour commencer. Obliger aux apprenants à se poser la question de la visibilité et la durée de vie d'un objet est, de mon point de vue, essentiel, sinon ils ne prendrons jamais les bons réflexes.
  
  Pour ça le c++ (notamment le dernier avec le shared_ptr inclus de base) me parait un bon choix; tu as accès au structures classiques, les destructeurs (pour tracer la destruction par exemple). Suffit de commencer par une petite partie du C++ (pas de pointeur de fonction, pas d'écriture de template, les new que dans des scoped_ptr ou shared_ptr, et il est possible d'enrichir peu a peu la connaissance du langage (const par exemple).
  
  Bref avec un seul langage il est possible de voire beaucoup d'aspects de la programmation, par contre il faudrait lui adjoindre une bibliothèque graphique simple.
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Mon expérience
    
    Posté par Dr BG le 23 juillet 2014 à 09:44. Évalué à 4.
    
    Sauf qu'on ne fait pas d'objet pour un premier cours de programmation, c'est vu plus tard.
    - [^] # Re: Mon expérience
      
      Posté par fearan le 23 juillet 2014 à 10:36. Évalué à 3.
      
      ça tombe bien, en c++ tu n'es nullement obligé de faire de l'objet pour faire un truc de base. Avec ce petit avantage par rapport au C : le type std::string; tu peux avoir des tableaux de taille variable (std::vector), des tableaux associatifs std::mapstd::string,int, des collections std::set…
      
      La sortie se fait assez simplement std::cout << "Hallow World " << 42 << std::endl;
      la lecture se fait tout aussi simplement int plop; std::cin >> plop;
      
      Enfin bref comme je l'ai dit il est inutile d'apprendre tout le C++ d'un bloc (de toute façon personne humainement normalement constitué ne maitrise le C++) , il vaut mieux y aller progressivement, en fonction de ce qui est nécessaire d'apprendre.
      
      Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # Re: Mon expérience
        
        Posté par Dr BG le 23 juillet 2014 à 10:52. Évalué à 2.
        
        Enfin bref comme je l'ai dit il est inutile d'apprendre tout le C++ d'un bloc
        
        Oui bien sûr, d'ailleurs je disais qu'on faisais les premiers TP en C++ très basique codé comme du C mais en moins relou. Mais je trouvais cependant que le D était bien plus simple : une sorte de meilleur des mondes entre le C++ et le Java.
        
        Je répondais au fait que tu disais qu'il était essentiel d'apprendre le cycle de vie d'un objet, ce qui n'est pas au programme au tout début.
        
        [^] # Re: Mon expérience
        
        Posté par fearan le 23 juillet 2014 à 11:30. Évalué à 2.
        
        Je répondais au fait que tu disais qu'il était essentiel d'apprendre le cycle de vie d'un objet, ce qui n'est pas au programme au tout début.
        
        d'un objet non, d'une donnée oui. Tu vois la visibilité des variables, le passage en paramètre, la limitation des scope (for( int i = 0…)
        i n'est plus visible/vivant après le for (sauf si le compilo ne respecte pas la norme). Si tu déclare dans le main
        
        auto revenu=42;
        
        il n'est pas visible de la fonction Tartempion, a moins de le passer en paramètre. Même si c'est des type primitifs, la question se pose quand même. J'ai dit objet j'aurai du dire variable.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Mon expérience
        
        Posté par Dr BG le 23 juillet 2014 à 11:39. Évalué à 3.
        
        Ok, mais que change la présence d'un ramasse-miette là-dedans ?
        
        Il peuvent faire l'expérience de la porté des variables (ça fait partie du programme), sans avoir à gérer la mémoire à la main (ça ne fait pas partie du programme).
  - [^] # Re: Mon expérience
    
    Posté par Thomas Douillard le 23 juillet 2014 à 10:49. Évalué à 3.
    
    Pas besoin de pointeur pour apprendre le concept de scope, il suffit de déclarer une variable locale dans une fonction et d'essayer d'accéder à sa valeur dans une autre.
# Pascal...

Posté par rewind (Mastodon) le 22 juillet 2014 à 18:46. Évalué à 6.

Franchement, dans les réponses que je lis, le plus souvent c'est [mon langage préféré] qui revient le plus souvent. Avec la supposition non-dite : s'ils commencent par ça, ils continueront. Mais ça n'est pas du tout la question posée.

Étant enseignant-chercheur en informatique et enseignant la programmation en L1 à des étudiants qui ne se destinent pas forcément à l'informatique, la question du langage de programmation à utiliser en première année se pose régulièrement. Et personne n'est d'accord évidemment.

Mon avis, c'est qu'il faut bannir tout langage à typage dynamique. Pourquoi ? Parce que choisir le bon type, ça fait partie de l'apprentissage en informatique, c'est aussi important que la structure du programme. Et quand le type est écrit à côté du nom de la variable, c'est plus simple. Autre inconvénient à mon sens : le fait que les objets dans ces langages soient le plus souvent accédés via des références complexifie la compréhension. Alors que reste-t-il ? Et bien pas grand chose. À l'heure actuelle, nous utilisons Java, mais il a aussi de nombreux défauts (le principal à mon sens étant d'être trop verbeux pour faire un simple hello world).

Après, on peut prendre le problème à l'envers : de quelles fonctionnalités a-t-on besoin ? Pas grand chose au final : les structures de contrôle usuelles, les types de bases, les entrées-sorties. Et c'est sans doute ce dernier point le plus problématique. Pascal (puisque c'est ce que j'ai mis dans le titre) avait l'avantage d'offrir tout ça de manière simple et efficace. Malheureusement, il est un peu daté maintenant. Mais il manque le nouveau Pascal qui permettrait de faire des choses simples. Le moins pire à mon sens, ça serait… C++. Pas tout C++ mais le sous-ensemble de C++ qui permet ce que j'ai décrit précédemment. Pour le coup, les entrées-sorties sont assez simples. Mais ça n'est pas très satisfaisant.

De toute façon, une fois ces bases acquises, généralement, on change de langage et on passe à d'autres langages pour apprendre d'autres paradigmes et d'autres algorithmes, donc le premier langage importe assez peu au final, il ne dure pas très longtemps.
- [^] # Re: Pascal...
  
  Posté par Antoine le 22 juillet 2014 à 19:24. Évalué à 2.
  
  Autre inconvénient à mon sens : le fait que les objets dans ces langages soient le plus souvent accédés via des références complexifie la compréhension. Alors que reste-t-il ? Et bien pas grand chose. À l'heure actuelle, nous utilisons Java, mais il a aussi de nombreux défauts (le principal à mon sens étant d'être trop verbeux pour faire un simple hello world).
  
  Heu… Java aussi utilise des références. Sauf pour les types valeurs (int, etc.). Mais qui ont aussi des versions objet (Integer, etc.). Avec toute la complexité qui s'ensuit (tiens, si je créais une liste d'entiers ?), supérieure à celle d'un langage où tout est objet.
  - [^] # Re: Pascal...
    
    Posté par rewind (Mastodon) le 22 juillet 2014 à 21:31. Évalué à 3.
    
    Heu… Java aussi utilise des références. Sauf pour les types valeurs (int, etc.). Mais qui ont aussi des versions objet (Integer, etc.). Avec toute la complexité qui s'ensuit (tiens, si je créais une liste d'entiers ?), supérieure à celle d'un langage où tout est objet.
    
    On n'utilise pas les objets, juste les types de base, ça suffit. Quant aux listes, ça n'est pas au programme de L1 ;)
    
    D'ailleurs quand je vois plusieurs personnes parler d'algorithmes évolués, ce n'est pas au programme de l'apprentissage de base de la programmation, on attends un peu avant d'aborder les structures de données un peu complexes (car récursives) et les algorithmes qui vont avec. Enfin, après il faudrait définir où s'arrête l'apprentissage de base. Dans la vraie vie, on n'utilise pas qu'un seul langage de programmation pour l'apprentissage, heureusement !
    - [^] # Re: Pascal...
      
      Posté par devnewton 🍺 (site web personnel) le 23 juillet 2014 à 09:44. Évalué à 2.
      
      Quant aux listes, ça n'est pas au programme de L1
      
      Tu fais comment pour faire autre chose qu'un hello world like?
      
      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
      - [^] # Re: Pascal...
        
        Posté par Dr BG le 23 juillet 2014 à 09:45. Évalué à 6.
        
        Avec des tableaux :-)
      - [^] # Re: Pascal...
        
        Posté par rewind (Mastodon) le 23 juillet 2014 à 11:27. Évalué à 3.
        
        On arrive à faire des jeux de plateaux (sans stocker le plateau), des jeux de devinettes (genre le pendu), des jeux de cartes avec un nombre de cartes assez petit, etc. On y arrive très bien. On voit le type chaîne de caractères à la fin qu'on peut utiliser comme container aussi si vraiment il y a besoin mais on arrive à faire plein de choses sans ça.
- [^] # Re: Pascal...
  
  Posté par totof2000 le 22 juillet 2014 à 19:41. Évalué à 3.
  
  Franchement, dans les réponses que je lis, le plus souvent c'est [mon langage préféré] qui revient le plus souvent. Avec la supposition non-dite : s'ils commencent par ça, ils continueront
  
  Faux : je n'ai pas cité mon langage préféré.
  
  Mon avis, c'est qu'il faut bannir tout langage à typage dynamique. Pourquoi ? Parce que choisir le bon type, ça fait partie de l'apprentissage en informatique,
  
  Ca c'est bien une idée de prof dans sa tour d'ivoire. Le typage, c'est un concept difficile à apprendre pour "des étudiants qui ne se destinent pas forcément à l'informatique". Le typage est une notion difficile que la majorité ddes personnes ne faisant pas d'informatique ne comprend pas.
  
  Alors certes, je ne dis pas qu'il ne faut pas l'apprendre, mais il faut rester simple : par exemple, un type numérique et un type texte ça suffit pour apprendre à programmer. Et je ne connais pas vraiment de langage qui ait un typage aussi simple (le basic dans mes souvenirs ou le type texte était suffixé par un $ dans le nom de la variable ?)
  
  Autre inconvénient à mon sens : le fait que les objets dans ces langages soient le plus souvent accédés via des références complexifie la compréhension
  
  Là je suis d'accord avec toi : ça c'est une plaie (va expliquer pourquoi par exemple lorsque je modifie le tableau a, b est aussi modifié : en fait quand on regarde un peu plus haut, on voit qu'à un moment, il y a eu un truc du genre a = b ).
  
  Après, on peut prendre le problème à l'envers : de quelles fonctionnalités a-t-on besoin ? Pas grand chose au final : les structures de contrôle usuelles, les types de bases, les entrées-sorties.
  
  Qu'entends-tu par "entrées-sorties" ?
  
  Pascal (puisque c'est ce que j'ai mis dans le titre) avait l'avantage d'offrir tout ça de manière simple et efficace. Malheureusement, il est un peu daté maintenant.
  
  C'est à dire ? Même s'il n'est pas beaucoup utilisé, ça n'enlève rien à ses qualités pédagogiques non ?
  
  C++. Pas tout C++ mais le sous-ensemble de C++ qui permet ce que j'ai décrit précédemment.
  
  Tu délires là non ? C++ pour apprendre ? Il y a bien plus simple aujourd'hui. Tu veux dégouter tes étudiants de la programmation ?
  
  De toute façon, une fois ces bases acquises, généralement, on change de langage et on passe à d'autres langages pour apprendre d'autres paradigmes et d'autres algorithmes, donc le premier langage importe assez peu au final, il ne dure pas très longtemps.
  
  Personnellement ,j'ai appris la programmation avec le BASIC : tu peux lui reprocher touis les défauts que tu veux, mais il y avait au moins les critères que tu citais : un typage simple, structures de controle, et enttrées sorties.
  
  Question : que manque-t-il à Pascal à tes yeux pour un premier langage
  - [^] # Re: Pascal...
    
    Posté par rewind (Mastodon) le 22 juillet 2014 à 21:27. Évalué à 7.
    
    Ca c'est bien une idée de prof dans sa tour d'ivoire. Le typage, c'est un concept difficile à apprendre pour "des étudiants qui ne se destinent pas forcément à l'informatique". Le typage est une notion difficile que la majorité ddes personnes ne faisant pas d'informatique ne comprend pas.
    
    Tour d'ivoire ? Je ne suis pas pédagogue, je suis enseignant, je suis au contact direct des étudiants, je vois sur quoi ils ont des difficultés et ce qui est plus facile à apprendre pour eux, avec des gammes de niveaux très étendues (j'ai des étudiants qui ne comprennent pas le principe d'une boucle while). Alors je crois que la tour d'ivoire, elle est loin.
    
    Alors certes, je ne dis pas qu'il ne faut pas l'apprendre, mais il faut rester simple : par exemple, un type numérique et un type texte ça suffit pour apprendre à programmer. Et je ne connais pas vraiment de langage qui ait un typage aussi simple (le basic dans mes souvenirs ou le type texte était suffixé par un $ dans le nom de la variable ?)
    
    Comment tu fais comprendre la division entière avec un seul type numérique ? Il y a une grosse quantité de problème qui nécessite de faire la différence entre entiers et réels, et c'est important de le faire dès le début. La programmation, c'est autant savoir choisir les bons types que de choisir les bons algorithmes.
    
    Qu'entends-tu par "entrées-sorties" ?
    
    Taper un truc au clavier, afficher sur l'écran. Pour faire des programmes un minimum interactifs, pas juste des calculs.
    
    Tu délires là non ? C++ pour apprendre ? Il y a bien plus simple aujourd'hui. Tu veux dégouter tes étudiants de la programmation ?
    
    C'est quoi que tu ne comprends pas dans «sous-ensemble» ? Évidemment qu'on ne va pas leur montrer le template metaprogramming ! On va se contenter, je répète, des types de bases, des structures de contrôles usuelles et des entrées-sorties (cin, cout pour C++). Il y a quoi de difficile là dedans ? Rien.
    
    Question : que manque-t-il à Pascal à tes yeux pour un premier langage
    
    Il se traîne des trucs qui ne sont plus d'actualité, genre le fait de devoir déclarer ses variables à part, au début.
    - [^] # Re: Pascal...
      
      Posté par totof2000 le 28 juillet 2014 à 15:45. Évalué à 2.
      Tour d'ivoire ? Je ne suis pas pédagogue, je suis enseignant, je suis au contact direct des étudiants, je vois sur quoi ils ont des difficultés et ce qui est plus facile à apprendre pour eux, avec des gammes de niveaux très étendues (j'ai des étudiants qui ne comprennent pas le principe d'une boucle while). Alors je crois que la tour d'ivoire, elle est loin.
      
      Désolé pour cette façon de m'exprimer, je me rends compte que ma façon de m'exprimer ait pu t'offenser, ce n'était pas le but. Celà dit j'ai quand même un peu de mal avec "e ne suis pas pédagogue, je suis enseignant". Un enseignant ne doit-il pas être pédagogue ?
      
      Comment tu fais comprendre la division entière avec un seul type numérique ? Il y a une grosse quantité de problème qui nécessite de faire la différence entre entiers et réels, et c'est important de le faire dès le début. La programmation, c'est autant savoir choisir les bons types que de choisir les bons algorithmes.
      
      Si tu introduis ça au début, pur des personnes qui ne continueront probablement pas à faire de la programmation, tu les dégoutes. Maintenant, j'ai peut-âtre été trop restrictif dans les types de base, et je t'accorde que différencier décimal/entier serait prebablement pertinent. Comme tu parlais de C/C++, j'avais à lesprit la totalité des types C/CPP (int, short , long, float, double, etc ….) qui sont difficiles à appréhender quand tu commences à programmer.
      
      C'est quoi que tu ne comprends pas dans «sous-ensemble» ? Évidemment qu'on ne va pas leur montrer le template metaprogramming ! On va se contenter, je répète, des types de bases
      
      Déjà les types de base en C++ sont déjà trop complexes :
      
      int : contient un entier de taille normale, positif ou négatif. short int : contient un entier de petite taille, positif ou négatif. long int : contient un entier de grande taille (32 bits), positif ou négatif. long long int : contient un entier de plus grande taille (64 bits), positif ou négatif. unsigned int : contient un entier de taille normale, positif ou nul. unsigned short int : contient un entier de petite taille, positif ou nul. unsigned long int : contient un entier de grande taille (32 bits), positif ou nul. unsigned long long int : contient un entier de plus grande taille (64 bits), positif ou nul.
      
      Il y a quoi de difficile là dedans ? Rien.
      
      Pour toi, rien. Pour des personnes pour qui la programmation n'est qu'un sujet qu'ils vont aborder sans continuer : tout. Et je suis quasiment convaincu qu'à un moment tu vas devoir sortir de ton sous-ensemble. C++ est un langage complexe, sans même aborder les templates. Par contre je le verrais bien comme second langage, lorsque les notions de base algorithmiques seraient acquises.
      - [^] # Re: Pascal...
        
        Posté par Marotte ⛧ le 28 juillet 2014 à 23:19. Évalué à 2.
        
        Déjà les types de base en C++ sont déjà trop complexes :
        
        Je ne suis pas sûr que l'on puisse parler de types de base pour ceux que tu cites (long long, unsigned int, etc…)
        
        Si je devais enseigner la programmation (le b-a ba) à l'aide du langage C++ je me limiterais à char, int, float et bool. Et pour pouvoir faire quelques exercices intéressants sans avoir à aborder les pointeurs je présenterais string également, comme un type de base.
        
        On peut dire aux élèves de commencer tous leurs programmes par ces lignes :
        
        #include <string> #include <iostream> using std::string;
        
        sans forcément à avoir à expliquer ces lignes (tout en se laissant la possibilité de répondre au curieux qui va te poser la question…)
        
        string, int et float suffisent largement comme types disponibles pour débuter l'apprentissage de la programmation, quelque soit le langage.
        
        [^] # Re: Pascal...
        
        Posté par Tit le 29 juillet 2014 à 09:40. Évalué à 1.
        
        string, int et float suffisent largement
        
        Ce serait quand même bien triste de se passer des booléens, non?
        
        [^] # Re: Pascal...
        
        Posté par Benoît Sibaud (site web personnel) le 29 juillet 2014 à 10:42. Évalué à 8.
        
        true
        
        [^] # Re: Pascal...
        
        Posté par Moonz le 29 juillet 2014 à 11:03. Évalué à 1.
        
        Non, FileNotFound
        
        [^] # Re: Pascal...
        
        Posté par Marotte ⛧ le 29 juillet 2014 à 11:35. Évalué à 2.
        
        C'est pour ça que j'avais indiqué bool comme type de base dans un premier temps…
        
        Je l'ai omis dans la dernière phrase parce que l'on peut très bien, si je ne m'abuse, utiliser un int pour faire de la logique booléenne :
        
        #include <iostream> using namespace std; int main (int argc, char** argv) { int b = 0; if (b) { cout << "vrai " << endl;} else { cout << "faux " << endl; } b = 1; if (b) { cout << "vrai " << endl; } else { cout << "faux " << endl; } int a = 0; if (b || a) { cout << "vrai " << endl; } else { cout << "faux " << endl; } if (b && a) { cout << "vrai " << endl; } else { cout << "faux " << endl; } a = 1; if (b || a) { cout << "vrai " << endl; } else { cout << "faux " << endl; } if (b && a) { cout << "vrai " << endl; } else { cout << "faux " << endl; } return 0; }
        
        faux vrai vrai faux vrai vrai
        
        [^] # Re: Pascal...
        
        Posté par rewind (Mastodon) le 29 juillet 2014 à 12:15. Évalué à 2.
        
        Je préfère leur montrer le type booléen et leur expliquer les expressions booléennes avec un vrai type booléen, et leur dire ensuite qu'en C, on représente un booléen avec un entier. Le type booléen existe dans quasiment tous les langages (et même en C d'ailleurs depuis C99 même si l'usage fait que personne ne l'utilise) donc autant leur montrer.
        
        [^] # Re: Pascal...
        
        Posté par groumly le 29 juillet 2014 à 16:56. Évalué à 2.
        
        C'est pas un char en C (donc tronque au 8 bits de poids faible)?
        Avec la bonne blague ou 512 est false.
        Objective c fait ca en tout cas, ca peut faire de bonnes surprises.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Pascal...
        
        Posté par Zylabon le 29 juillet 2014 à 17:47. Évalué à 2.
        
        Non, pas en C, ça se comporte bien :) même avec des entiers plus gros qu'un mot machine.
        
        Please do not feed the trolls
        
        [^] # Re: Pascal...
        
        Posté par groumly le 29 juillet 2014 à 19:22. Évalué à 2.
        
        Aaaah, je me rappelle de l'histoire maintenant.
        Next a introduit BOOL dans objc au debut des annees 90, qui est en fait un typedef sur unsigned char, donc avec le comportement decrit au dessus.
        Ils l'ont utilise un peu partout, et quand c99 a introduit boolean (ou bool? Mon c est assez mauvais je doit avouer), ils se sont fait baiser par la compat binaire, donc impossible de changer les api existantes, et la coherence avec l'existant les a force a continuer a utiliser BOOL.
        
        Bref, au final ca doit exister aussi en C, juste vachement moins vicieux vu qu'on s'attend pas a ce qu'un unsigned char puisse recevoir n'importe quelle valeur differente de 0.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Pascal...
        
        Posté par rewind (Mastodon) le 29 juillet 2014 à 12:12. Évalué à 3.
        
        Un enseignant ne doit-il pas être pédagogue ?
        
        Tout dépend de ce que tu mets dans la pédagogie. Là, on a devant nous des étudiants, pas des enfants, donc ils savent déjà apprendre, notre mission est de leur apprendre à apprendre. Certes il faut un peu de pédagogie mais il faut surtout de la méthode et de l'efficacité.
        
        Si tu introduis ça au début, pur des personnes qui ne continueront probablement pas à faire de la programmation, tu les dégoutes.
        
        J'ai devant moi des étudiants scientifiques (qui vont aller après dans des filières diverses : physique, chimie, maths, sciences de l'ingénieur) et quand il néglige les cours d'informatique en L1, je les mets en garde : ils en auront besoin plus tard, quoi qu'il fasse. Et quand je regarde les programmes des différents filières, il y a de la programmation à un moment donné parce que la plupart des sciences utilisent maintenant fortement l'informatique (au même titre que les maths). Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.
        
        Maintenant, j'ai peut-âtre été trop restrictif dans les types de base, et je t'accorde que différencier décimal/entier serait prebablement pertinent. Comme tu parlais de C/C++, j'avais à lesprit la totalité des types C/CPP (int, short , long, float, double, etc ….) qui sont difficiles à appréhender quand tu commences à programmer.
        
        Il ne faut pas leur apprendre les types de C/C++, il faut leur apprendre les types ! Donc, entiers (de diverses tailles, mais int suffit dans 90% des cas), flottants (double dans 90% des cas), char pour manipuler des caractères ASCII, booléen pour calculer des expressions booléennes. Déjà avec ça, on a du boulot. Parce que choisir le bon type parmi ces 4 familles, c'est parfois compliqué. Surtout char en fait, il est très bien parce qu'il permet d'expliquer qu'on peut représenter un truc abstrait (un caractère) par un entier, suivant une norme qu'on se définit. Et qu'on peut faire pareil après, par exemple pour dire que 1 veut dire oui et 2 veut dire non. C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.
        
        [^] # Re: Pascal...
        
        Posté par totof2000 le 29 juillet 2014 à 13:07. Évalué à 3.
        
        C'est aussi important que le code en lui-même et c'est souvent plus difficile d'ailleurs.
        
        C'est le genre de choses que j'éviterais d'aborder dans un premier temps. Et maintenant je me souviens pourquoi je n'avais pas traité la différence entier/décimal : la programmation avec des décimaux est compliquée. Et balancer toutes ces problématiques d'un coup risque de poser problème. Personnellement, lorsque j'ai appris le C, j'ai été un peu noyé sur plein de notions assez abstraites, mais comme l'informatique était mon métier, ce n'est pas grave : j'ai eu du temps pour comprendre (il m'a fallu environs 1 semestre pour assimiler les notions de base en C ). Dans le cas cité par l'auteur du journal, je ne pense pas que ce soit popssible d'aborder les choses de la même façon.
        
        Donc des scientifiques qui en continueront pas à faire de la programmation, ça n'existe pas. Ils continueront, quoi qu'il arrive. Donc autant commencer sur de bonnes bases.
        
        Oui, mais il ne faut pas introduire trop de concepts à la fois pour éviter de noyer sous une masse d'information imbitable. C'est pour ça qu'à mon avis, se limiter à 1 seul langage pour apprendre la programmation, ce n'est pas une bonne idée.
        
        Quelque part, je rejoins le point de vue de je ne sais plus qui plus bas qui parlait d'assembleur. Programmer sans avoir de notion sur la façon dont fonctionnent les processeurs, leur façon d'adresser la mémoire et la façon de représenter les données en interne est difficile. Faut-il aller jusqu'à l'assembleur ? Difficile à dire, parce qu'on ne peut comprendre certaines problématiques de la programmation que si l'on sait ce qui se passe à bas niveau. Mais d'un autre côté, pour des personnes n'ayant pas l'informatique comme enseignement principal, c'est difficile de placer le curseur au bon endroit pour ne pas les dégouter.
        
        [^] # Re: Pascal...
        
        Posté par lasher le 29 juillet 2014 à 17:21. Évalué à 2.
        
        C'est le genre de choses que j'éviterais d'aborder dans un premier temps. Et maintenant je me souviens pourquoi je n'avais pas traité la différence entier/décimal : la programmation avec des décimaux est compliquée.
        
        Pas vraiment. Les problèmes d'arrondis ne deviennent une gêne que si tu as besoin d'afficher plus de 2 décimales avec printf (genre printf("Temperature: %.2f\n", temperature);). Dans ce cas, tu n'as pas besoin d'embêter les élèves avec les histoires de « on ne compare pas deux nombres flottants par l'égalité » et autres trucs importants pour l'analyse numérique, mais pas tellement pour une initiation à la programmation.
        
        […] il ne faut pas introduire trop de concepts à la fois pour éviter de noyer sous une masse d'information imbitable. C'est pour ça qu'à mon avis, se limiter à 1 seul langage pour apprendre la programmation, ce n'est pas une bonne idée.
        
        Je ne pense pas que rewind indique qu'il faille apprendre un seul langage. Dans certaines facs, les 2 premières années sont passées à apprendre l'algo/prog avec un même langage, et la troisième année ils en voient un autre. C'est pas forcément idiot. Cependant, les élèves qui suivent des études scientifiques à la fac doivent bien commencer quelque part. C ou C++ (version light) ne sont pas forcément de mauvais choix. De toute manière, les élèves qui font de la physique devront bien apprendre à manipuler R ou matlab, ou même Fortran (et s'ils ont de la chance, Python+les bonnes bibliothèques). Les élèves qui sont en bio apprendront Python ou Perl s'il font de la génomique/génétique, etc. Ce ne sera pas forcément pendant les 3 premières années de licence, mais ça finira nécessairement par arriver.
        
        Pour un élève en informatique, comme je l'ai dit ailleurs, il est important selon moi que sur trois ans, il ait vu au moins 2 paradigmes de programmation (impératif, objet, fonctionnel), ce qui signifie au moins deux langages, et probablement en pratique 2,5 (genre ils commencent avec C, et embrayent ensuite avec C++ ou Java pour voir comment fonctionne la POO, puis font peut-être du Scheme ou OCaml).
    - [^] # Re: Pascal...
      
      Posté par totof2000 le 28 juillet 2014 à 15:49. Évalué à 2.
      
      Il se traîne des trucs qui ne sont plus d'actualité, genre le fait de devoir déclarer ses variables à part, au début.
      
      Est-ce vraiment si important que ça lorsqu'on initie quelqu'un à la programmation ? Tu n'aurais pas d'autres éléments ?
      - [^] # Re: Pascal...
        
        Posté par rewind (Mastodon) le 29 juillet 2014 à 12:17. Évalué à 1.
        
        La règle qui dit qu'on déclare une variable au plus près de sa première utilisation et dans la portée minimum est maintenant une des règles fondamentales de la programmation dans n'importe quel langage, ça évite tout un tas d'erreur. Donc se traîner des limitations techniques qui empêchent de bien programmer, oui ça me paraît important.
        
        [^] # Re: Pascal...
        
        Posté par totof2000 le 29 juillet 2014 à 13:11. Évalué à 3.
        
        La règle qui dit qu'on déclare une variable au plus près de sa première utilisation et dans la portée minimum est maintenant une des règles fondamentales de la programmation dans n'importe quel langage
        
        En quoi Pascal transgresse-t-il cette règle ?
        
        La portée minimum d'une variable est la fonction/procédure, et tu la déclares au plus près de sa première utilisation dans la portée minimum, soit au début de la fonction. Si tu abordes un autre langage ou tu peux faire plus fin, tu le précises … Il n'y a pas de contradiction : c'est comme ça que j'ai appris.
  - [^] # Re: Pascal...
    
    Posté par Pierre Roc le 22 juillet 2014 à 21:27. Évalué à 4.
    
    Pourquoi pas le C++ ?
    
    Y’a tout ce qu’il faut.
    
    Typage statique : écrire « int n » ce n’est ni plus ni moins que l’équivalent en mathématique de « soit n ∈ ℕ ». Si les étudiants ne sont pas dans un cursus spécialisé, il me semble qu’à un certain niveau dans une filière technique/scientifique c’est jouable.
    
    I/O simplifiées (par rapport au C, ou même des langages comme Python – cf. la discussion sous un autre journal sur comment on doit écrire les chaînes de caractères) et unifiées (on écrit dans un fichier comme on écrit sur cout/cerr). Je reconnais que les << & >> c’est assez spécial et surtout très spécifique à ce langage, mais c’est plutôt intuitif !
    
    Espace de nom : permet de limiter la casse par rapport aux variables globales, histoire d’éviter d’avoir des signatures de fonctions à rallonge.
    
    Pas de gestion des pointeurs : pour les tableau il y a le type std::array<T,n>, que les étudiants peuvent apprendre sans chercher à comprendre comme ça marche sous le capot (ie. les templates). Par qu’il faut bien voir que la seule raison pour laquelle on a littéralement fait chier toute une génération d’étudiants avec les pointeurs, c’est parce que c’est le seul moyen en C de traiter des tableaux.
    
    Et surtout pas de problème de passage par référence/par valeur. Au besoin on peut introduire le &, plus facile à appréhender dans un premier temps que les pointeurs. Et il est explicite, ce qui en terme didactique est beaucoup mieux que tous les langages du style Python/Java/etc. Et ça pour moi c’est un truc crucial : c’est une question de rigueur, car l’un dans l’autre il faudra bien finir par leur expliquer, en TP, à ces étudiants pourquoi certaines variables sont modifiées dans les fonctions et pourquoi pas d’autres, alors que vous venez de leur expliquer en cours magistral pendant deux heures ce qu’est la programmation “fonctionnelle” (du moins à mon époque on apprenait le C comme un langage fonctionnel : pas de variable globale, la question ne se posait même pas pour static, etc.)
    
    Au final le C++ est le seul langage, à ma connaissance (C++/Java/Python donc pas les trucs confidentiels), qui offre un traitement simple et propre de la gestion des variable sans se préoccuper des questions de mémoire. Tout cela parce que c’est le seul à respecter un principe de base de la programmation fonctionnelle (pas d’effet de bord des fonctions).
    
    Compilo avec messages d’erreurs et quantité de bugs évités ainsi. En théorie, au niveau débutant on ne se prend pas dans la gueule les messages abscons (assez typiques quand on s’amuse avec les templates par exemple). Et puis parce que savoir ce qu’est un code source, un compilateur et un exécutable, c’est pour moi un point essentiel d’apprentissage de l’informatique. Y compris et surtout! pour ceux qui ne se destinent pas à être programmeur.
    
    Pourvu qu’on se restreigne aux notions simples le C++ fait l’affaire.
    
    Et au moins le jour où y’a besoin d’attaquer l’objet, on n’est pas dépaysé. On peut même imaginer une introduction en douceur avec la classe string, nécessairement abordée assez tôt dans l’apprentissage, parce que c’est bien utile… et sans aborder l’objet proprement dit, les étudiants peuvent avoir un aperçu de l’utilité de la chose.
    - [^] # Re: Pascal...
      
      Posté par lasher le 23 juillet 2014 à 00:52. Évalué à 4.
      
      Comme l'expliquait rewind, de toute manière tu ne veux pas enseigner tout le langage aux élèves de 1è année, c'est tout simplement impossible. Donc personnellement, C, C++, Perl, Python, Ruby, Scheme, Scala, OCaml, F#, etc., je m'en cogne un peu. :-)
      
      Choisir un langage « suffisamment » fortement typé aide les élèves à trouver leurs erreurs à la compilation, du coup C++ n'est pas forcément une mauvaise idée, mais très honnêtement, Scala non plus, ni F#, ni OCaml, ni C (qui est faiblement typé, mais si on dit aux élèves qu'il faut mettre -Wall -Wextra -pedantic sur la ligne de compilation sinon on n'aidera pas, les élèves finissent par piger), etc.
      
      Tu parlais des espaces de nommages : ça va passer à la trappe chez les élèves de 1è année. Ce sera déjà bien s'ils comprennent la notion de programmation modulaire (découper le programme en fonctions, etc.).
      
      Pas de gestion des pointeurs : pour les tableau il y a le type std::array, que les étudiants peuvent apprendre sans chercher à comprendre comme ça marche sous le capot (ie. les templates)
      
      J'ai tendance à bien aimer la notion d'enseigner « C + STL » aux élèves, mais j'avoue que même dans un commentaires à côté, j'ai un peu surestimé ce qu'on apprenait aux étudiants de fac classique en 1è année. Du coup, même du « C + cout/cin » et std::string c'est généralement suffisant.
      
      Et surtout pas de problème de passage par référence/par valeur.
      
      Ce n'est un réel problème que si tu désires discuter de la différence. En tant que prof, tu édictes les règles. Si tu dis « tout paramètre est copié lorsqu'il est passé à une fonction, sauf les tableaux qui eux seront modifiés pour de bon », les élèves accepteront la règle. Ils demanderont peut-être pourquoi, mais la réponse que je donnerais c'est « pour simplifier les choses dans un premier temps, et dans quelques semaines, on reviendra sur le sujet ».
      
      Pourvu qu’on se restreigne aux notions simples le C++ fait l’affaire.
      
      Oui, mais n'importe quel langage fait l'affaire dans ce cas. La question pour moi est de savoir quel langage il faut choisir lorsque les trucs de base (structures de contrôles, algos simples, etc.) ont été acquis : est-ce qu'on approfondit avec le même langage, ou bien est-ce qu'on change au risque de perdre encore quelques semaines à apprendre un nouveau langage ?
      - [^] # Re: Pascal...
        
        Posté par lendemain le 23 juillet 2014 à 11:53. Évalué à 1.
        
        Si c'est te typage qui te fait choisir un langage l'enseignement, je te conseille de regarder du coté des assertions (contrats, post/preconditions) c'est plus précis que le typage, plus simple à expliquer le concept (juste un 'if').
    - [^] # Re: Pascal...
      
      Posté par Antoine le 23 juillet 2014 à 04:05. Évalué à 3.
      
      Typage statique : écrire « int n » ce n’est ni plus ni moins que l’équivalent en mathématique de « soit n ∈ ℕ »
      
      Jusqu'au jour où il y a un débordement… Donc non, ça n'a rien à voir.
      (d'ailleurs ce serait plutôt « n ∈ ℤ », mais bon, vu le problème que je viens de mentionner, on n'est plus à ça près)
      - [^] # Re: Pascal...
        
        Posté par lasher le 23 juillet 2014 à 06:27. Évalué à 1.
        
        Pas tout à fait : le compilateur raisonne bien en termes d'entiers « infinis » et lorsqu'il raisonne lors de la phase d'analyse sémantique ou bien lors des phases d'optimisation dans le middle-end. Par exemple :
        
        float f = fabs(some_float); if (f > 0) { // always true -- compiler should be able to simplify branch /* ... */ } else { /* ... */ }
        
        ou bien
        
        int a = ..., b = ...; if (a > 0 && b > 0 && a+b < 0) { /* not possible, a > 0, b > 0 → a+b > 0, ALWAYS ! */ }
        
        Un compilateur aura le droit d'optimiser ces branchements car fabs est une fonction de la libC, donc « magique » et que dans le deuxième cas, le compilateur ne considère pas les limites « physiques » des entiers considérés, mais juste les relations entre eux.
        
        [^] # Re: Pascal...
        
        Posté par Matthieu Moy (site web personnel) le 23 juillet 2014 à 09:42. Évalué à 2.
        
        Euh, non, dans le deuxième cas le compilateur est en droit d'optimiser parce que a+b qui déborde est un comportement indéfini.
        
        La même chose avec des unsigned int (arithmétique modulo 2ⁿ⁾ et le compilateur n'a plus le droit (enfin, sur cet exemple en particulier, a+b 1 && b > 1 && a+b < 2) par exemple).
        
        Un compilateur qui optimise avec une sémantique différente de celle de l'exécution ne serait pas très utile…
        
        [^] # Re: Pascal...
        
        Posté par lasher le 23 juillet 2014 à 17:09. Évalué à 2.
        
        Ah tiens oui. My bad (histoire d'ajouter une pointe de mauvaise foi : mais même ainsi, il raisonne en termes d'entiers relatifs « infinis », au point qu'on pourrait presque parler « d'implementation defined » au lieu de « undefined behavior » :P).
        
        [^] # Re: Pascal...
        
        Posté par Matthieu Moy (site web personnel) le 23 juillet 2014 à 17:25. Évalué à 2.
        
        Oui, tu peux parler d'entiers infinis, vu que sur l'intervalle -2ⁿ .. 2ⁿ - 1, ça coïncide avec les entiers, et en dehors de l'intervalle, le compilateur a le droit de faire ce qu'il veut. Mais uniquement avec les entiers signés.
        
        Lire par exemple ceci, très intéressant sur les undefined behavior et leurs conséquences : http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 23 juillet 2014 à 09:28. Évalué à 5.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 23 juillet 2014 à 15:44. Évalué à 3.
        
        Je pense que tu as complètement loupé le sens du post (mais l'as-tu ?). C'est évidement d'une équivalence conceptuelle qu'il s'agit. L'important c'est l'association d'une variable à un type.
        
        Raté. ℕ et ℤ sont des ensembles, pas des types. Un entier dans ℕ est également dans ℤ, et aussi dans l'ensemble des rationnels, des réels, etc.
        Alors qu'un entier en C est soit signé soit non signé, pas les deux à la fois (et ce n'est pas un flottant non plus).
        
        Donc non seulement l'analogie est foireuse, mais elle montre de plus combien il est dangereux pour la compréhension des débutants d'essayer d'établir de telles analogies.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 23 juillet 2014 à 19:45. Évalué à 2. Dernière modification le 23 juillet 2014 à 19:47.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 23 juillet 2014 à 19:55. Évalué à 4.
        
        Les types sont des ensembles (ou plutôt des algèbres = ensemble + opération sur les éléments de l'ensemble) !
        
        Si on veut, sauf que les opérateurs en question ne correspondent pas aux opérateurs mathématiques courants (l'addition informatique sur deux entiers 32 bits n'est pas l'addition au sens mathématique, et l'addition au sens mathématique ne peut être définie de l'ensemble des entiers 32 bits dans lui-même). Donc on revient toujours aux problèmes sus-mentionnés, et à la conclusion qu'expliquer l'informatique par les maths est une mauvaise idée.
        
        Et il ne s'agit là que de l'exemple des entiers, avec les flottants IEEE c'est encore plus rigolo…
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 23 juillet 2014 à 20:17. Évalué à 1. Dernière modification le 23 juillet 2014 à 20:21.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pascal...
        
        Posté par lasher le 23 juillet 2014 à 22:20. Évalué à 5.
        
        […] passer par les math est une très bonne idée.
        
        Pas d'accord, et en tout cas pas pour un cours de débutants. Selon moi, une des raisons pour lesquelles les langages fonctionnels ont tant de mal à décoller, c'est en grande partie dû au fait que l'approche pour enseigner la programmation avec ces langages n'est pas pragmatique. Il ne faut pas nier les origines « matheuses » derrière les langages fonctionnels, mais il est à mon avis plus indiqué pour les gens « normaux » (càd : pas forcément très matheux) qu'on leur apprenne à faire des choses pratiques avec les langages. Un exemple de tentative est Land of Lisp ou Practical Common LISP, qui ne sont pas parfait, mais qui essaient d'enseigner LISP d'une façon pragmatique et didactique plutôt que faire dans l'habituelle programmation de fonctions mathématiques genre factorielle ou nombres de Fibonacci (non pas que je sois contre leur utilisation, mais il me semble que c'est pas forcément le meilleur moyen d'enseigner la récursivité à des gens).
        
        Après les gens qui ont un esprit « orienté maths » n'ont souvent que très peu de problèmes pour passer du fonctionnel à l'impératif ou l'objet, mais c'est une tournure d'esprit que tout le monde n'a pas.
        
        [^] # Re: Pascal...
        
        Posté par Pierre Roc le 23 juillet 2014 à 23:48. Évalué à 4.
        
        Bon, tout un fil parce que j’ai (semi-)merdé. :)
        
        Mais effectivement l’idée que je voulais exprimer, c’était qu’un typage statique permettait de déclarer explicitement les variables, l’ensemble auquel elle appartient, et donc les opérateurs qui s’appliquent. Au passage, en math, un ensemble muni d’opérations est une structure algébrique : groupe (mathématiques) anneau (mathématiques) corps (mathématiques) avec les bonnes propriétés.
        
        Fondamentalement, vu que je viens des math, j’ai appris l’informatique à travers les mathématiques, en voyant très tôt la représentation informatique des nombres et ses limitations. Mais fondamentalement, oui j’ai plutôt tendance à considérer mes variables informatiques comme des variables mathématiques tout ce qu’il y a de plus standard (ai fait pas mal beaucoup d’analyse numérique…), et à bien avoir conscience des limites que l’informatique impose aux calculs numériques (c’est surtout pour les flottants que c’est plus problématique, et en théorie vaut mieux avoir des notions de calcul différentiel si on veut traiter cela proprement).
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 24 juillet 2014 à 01:17. Évalué à 2.
        
        C'est ainsi, c'est la définition même de type ! Ce n'est pas un point négociable : c'est une définition.
        
        J'adore les arguments qui se contentent de dire "c'est comme ça".
        
        Sauf que, non, il n'y a pas de définition de type qui fasse autorité et qui comporte également cette notion ensembliste.
        
        Ainsi Wikipédia (http://fr.wikipedia.org/wiki/Langage_de_programmation) dit :
        
        « Chaque donnée a une classification, celle-ci influe sur la plage de valeurs possibles, les opérations qui peuvent être effectuées, et la représentation de la donnée sous forme de bits. Chaque langage de programmation offre une gamme de types primitifs, incorporés dans le langage. Certains langages offrent la possibilité de créer des nouveaux types. »
        
        où l'on ne parle pas d'ensembles du tout. Mieux, chaque donnée a une classification (non plusieurs), donc on voit tout de suite qu'une définition ensembliste ne s'accorderait pas à la réalité.
        
        Mais ça, je l'avais déjà expliqué au-dessus…
        
        [^] # Re: Pascal...
        
        Posté par Thomas Douillard le 24 juillet 2014 à 10:45. Évalué à 3.
        
        Mieux, chaque donnée a une classification (non plusieurs), donc on voit tout de suite qu'une définition ensembliste ne s'accorderait pas à la réalité.
        
        C'est trivialement faux en POO ou dans tous les systèmes de typages dans lesquelles on a des sous types : uns donnée d'un certain type à aussi le type des types parents. Pour le typage structurel aussi, et ça reste du typage : une donnée peut avoir autant de types qu'on veut.
        
        [^] # Re: Pascal...
        
        Posté par barmic le 24 juillet 2014 à 11:16. Évalué à 3.
        
        Même en POO il n'y a pas vraiment d'ensemble c'est des arborescences ce qui n'est pas pareil.
        Tu fait comment la différence entre 2 classes en POO ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pascal...
        
        Posté par freeze le 24 juillet 2014 à 11:21. Évalué à 2.
        
        Ça me chatouille cette distinction que vous faites entre les ensembles et les arborescences.
        
        De mon point de vue, en considérant les branches filles comme des sous-ensembles de l'ensemble correspondant au noeud courant, c'est assez équivalent. Il y a moins de richesse avec l'arborescence, mais on peut bien faire une correspondance entre l'arborescence de classes et … une logique ensembliste.
        
        Pourriez-vous m'éclairer ?
        
        [^] # Re: Pascal...
        
        Posté par Thomas Douillard le 24 juillet 2014 à 11:35. Évalué à 3.
        
        Ben conceptuellement une classe c'est pas loin d'une définition d'ensemble en intension : soit Point l'ensemble des couples d'entiers munis d'une opération translation, …
        
        Ensemble de données manipulé : l'ensemble des couples d'entiers.
        
        Arborescence : soit PointSymétrisé le même jeu de données pour lequel on a une opération "symétrique" qui associe à chaque point un symétrique.
        
        PointSymétrisé est un sous type de point : on peut faire avec un point symétrisé sans soucis tout ce qu'on fait avec un point.
        
        On peut facilement construire une arborescence de type en utilisant la relation "est un sous-type de" telle que vaguement définie dans la phrase d'avant.
        
        Tu peux répondre, les deux types manipulent le même ensemble de couple si on oublie les opérations, et tu auras raisons. Après je sais plus très bien de quoi on parlait, mais on a une arbo, des ensembles, et on a une relation qui semble émerger entre les ensembles associés au types des différents noeuds de l'arborescence, qui semble dire que le jeu de données manipulées par un sous type doit être un sur-ensemble du jeu de données manipulé par le type de base. je crois que si t'es intéressé pour étudier conceptuellement les realations entre ces notions, tu peux regarder des trucs comme Principe de substitution de Liskov;
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 24 juillet 2014 à 23:24. Évalué à 1.
        
        C'est trivialement faux en POO ou dans tous les systèmes de typages dans lesquelles on a des sous types
        
        Faudrait apprendre à lire le contexte d'une discussion. Ici on parle d'une variable entière en C ou C++, un entier ne peut pas être à la fois signé ou non-signé dans ces langages.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 juillet 2014 à 00:10. Évalué à 0.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 25 juillet 2014 à 01:16. Évalué à 3.
        
        Et donc ? Il y a deux variables dans ton code, l'une est signée, l'autre pas.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 juillet 2014 à 08:54. Évalué à -1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 juillet 2014 à 09:02. Évalué à 0. Dernière modification le 25 juillet 2014 à 09:03.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Pascal...
        
        Posté par Antoine le 25 juillet 2014 à 17:18. Évalué à 2.
        
        L'opérateur de comparaison va effectuer une conversion implicite avant de comparer les deux valeurs (qui sont bel et bien de types différents)… Essaie encore.
        
        [^] # Re: Pascal...
        
        Posté par tyoup le 25 juillet 2014 à 07:10. Évalué à 2.
        
        Pourquoi n'explique-t-on pas que les int sont des classes d'équivalence dans Z modulo 2³² ?
        
        [^] # Re: Pascal...
        
        Posté par lasher le 25 juillet 2014 à 17:35. Évalué à 3.
        
        Sans doute parce que je n'avais pas abordé les anneaux, groupes et corps avant la fin de ma 1è année d'IUT, et que (par exemple) les IUT génie informatique acceptent aussi les candidatures venant de sections sciences économiques et sociales (à raison).
        
        [^] # Re: Pascal...
        
        Posté par tyoup le 26 juillet 2014 à 12:43. Évalué à 2.
        
        Ahlala fut un temps c'était au programme du bac A si j'en crois les livres de mes parents.
        
        [^] # Re: Pascal...
        
        Posté par lasher le 28 juillet 2014 à 23:56. Évalué à 2.
        
        Oui mais ça ne veut rien dire. « De mon temps », on abordait l'arithmétique en spé maths en Terminale S (donc du coup je savais déjà ce qu'était un groupe en arrivant en IUT), mais désormais une partie de l'arithmétique est enseignée en Seconde si j'ai bien compris (ou peut-être même en 3è). Ce qui change d'une décennie à l'autre, c'est dans quel ordre on voit les sujets en maths.
        
        [^] # Re: Pascal...
        
        Posté par Michaël (site web personnel) le 29 juillet 2014 à 06:42. Évalué à 7.
        
        Il y a des systèmes d'arithmétique modulaire que les gens connaissent bien, dans la vie quotidienne: les calculs de calendrier (heures, minutes, secondes, semaines, …), les preuves par 9, les calculs “numérologiques” aussi modulo 9, et la “ploume”.
        
        On peut donc aussi parler d'arithmétique modulaire sans forcément avoir survécu à un cours d'algèbre élémentaire.
        
        [^] # Re: Pascal...
        
        Posté par Aluminium95 le 30 juillet 2014 à 19:04. Évalué à 0.
        
        Faux, au contraire les types fournissent une théorie alternative à celle des ensembles: wikipedia
        
        D'ailleurs, la plus grande différence est que contrairement aux ensembles, on ne peut pas faire de "sous-types" (comme une partie d'un ensemble).
        
        Ainsi tu ne peux pas faire des fonctions qui travaillent sur les réels privés des rationnels sauf si tu crées un nouveau type pour les représenter (ou que tu plantes si une condition n'est pas vérifiée).
        
        [^] # Re: Pascal...
        
        Posté par Zylabon le 30 juillet 2014 à 21:04. Évalué à 2.
        
        Je ne comprend pas de lien entre le propos, la référence, et la conclusion.
        
        Ainsi tu ne peux pas faire des fonctions qui travaillent sur les réels privés des rationnels sauf si tu crées un nouveau type pour les représenter (ou que tu plantes si une condition n'est pas vérifiée).
        
        Oui, il suffit de le faire. On a le droit, ainsi on créé un type T = R\Q, clairement T est un sous ensemble de R. Si tu as une instance de T tu peux la passer sans risque à une fonction qui veut une instance de R.
        
        Il y a plein de langages de programmations qui autorise le programmeur à exprimer cette relation, en prog objet on appelle ça l'héritage. (Toute instance de T est une instance de R).
        
        Please do not feed the trolls
        
        [^] # Re: Pascal...
        
        Posté par tyoup le 31 juillet 2014 à 00:01. Évalué à 0.
        
        Il y a plein de langages de programmations qui autorise le programmeur à exprimer cette relation, en prog objet on appelle ça l'héritage. (Toute instance de T est une instance de R).
        
        Un carré est un rectangle ?
        Un rectangle est un carré ?
        
        [^] # Re: Pascal...
        
        Posté par Zylabon le 31 juillet 2014 à 00:45. Évalué à 2.
        
        Je ne comprend pas :
        
        Un carré est un rectangle ?
        
        Oui
        
        Un rectangle est un carré ?
        
        Non
        
        Please do not feed the trolls
        
        [^] # Re: Pascal...
        
        Posté par tyoup le 31 juillet 2014 à 01:36. Évalué à 0.
        
        Le carré est caractérisé par une dimension : mettons x.
        Le rectangle est caractérisé par deux dimensions : mettons x et y.
        On peut voir le rectangle comme étant un carré auquel on ajoute une dimension.
        
        [^] # Re: Pascal...
        
        Posté par Aluminium95 le 31 juillet 2014 à 10:37. Évalué à 1.
        
        Bon, je me suis mal exprimé. Il y a une théorie différente et alternative pour parler des types qui est bien plus commode qu'une simple analogie avec des ensembles.
        
        En effet :
        1. Dans l'exemple avec R\Q, tu n'as pas l'inclusion dans la majorité des langages (sauf prolog peut être d'après tes dires). De même pour les "unsigned int" et les "int" en C comme cité plus haut. Ce que tu as c'est une identification (un morphisme injectif canonique) entre les "unsigned int" et "int".
        2. La théorie des ensemble ne prend nullement en compte la notion d'homogénéité : tu peux faire une union de n'importe quoi (là ou les types demandent une union étiquetée).
        
        Mais en effet une notion basique d'ensembles et une analogie approximative suffisent très largement pour une initiation à l'informatique !
    - [^] # Re: Pascal...
      
      Posté par Michaël (site web personnel) le 24 juillet 2014 à 00:18. Évalué à 10.
      
      Pourquoi pas le C++ ? Y’a tout ce qu’il faut.
      
      Il y en a un peu plus, je vous le laisse?
      
      Le moto de Perl “there is more than one way to do it” s'applique à C++ en ajoutant “and none of them is right, nor is it obviously wrong!”.
  - [^] # Re: Pascal...
    
    Posté par barmic le 23 juillet 2014 à 00:23. Évalué à 6.
    
    Le typage est une notion difficile que la majorité ddes personnes ~~ne faisant pas d'informatique~~ ne comprend pas.
    
    La quantité de développeurs qui ne savent pas se servir correctement du typage de leur langage favori est hallucinant. Alors comprendre celui d'un autre langage…
    
    Sérieusement demande à des gens ce qu'est un typage fort/faible, dynamique/statique et de l'inférence de type.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Pascal...
      
      Posté par Michaël (site web personnel) le 24 juillet 2014 à 00:19. Évalué à 4.
      
      La quantité de développeurs qui ne savent pas se servir correctement du typage de leur langage favori est hallucinant.
      
      Elle est sérieusement concurrencée par celle de développeurs C++ qui ne savent pas ce qu'est l'héritage.
  - [^] # Re: Pascal...
    
    Posté par lasher le 23 juillet 2014 à 00:32. Évalué à 4.
    Ca c'est bien une idée de prof dans sa tour d'ivoire. Le typage, c'est un concept difficile à apprendre pour "des étudiants qui ne se destinent pas forcément à l'informatique".
    
    Tu n'es pas obligé de donner un cours sur la théorie des types et le lambda calcul. Si on parle (comme semble l'indiquer le journal) d'étudiants en informatique, de toute manière, en trois ans il serait bon qu'ils voient au final 2 ou 3 paradigmes (procédural classique, objet, et fonctionnel), l'ordre important finalement relativement peu pour peu que l'équipe enseignante prenne sur elle de fournir des primitives suffisantes ou une progression spécifique dans l'apprentissage du langage si le langage de base + bibliothèque standard ne suffisent pas dans le cas du premier langage.
    
    On peut imposer des standards de code si on utiliser un langage dynamique, au moins au début, par exemple la notation hongroise¹. La notion de typage n'est pas compliquée à apprendre à quiconque a pigé l'une des bases fondamentales des exercices qu'on faisait en physique, de la 4è jusqu'en Seconde, et au-delà pour ceux qui ont suivi une section scientifique : il faut une homogénéité des unités, et donc, s'il est possible d'ajouter des objets (au sens « théorie des langages du terme », pas POO) qui sont de type fruits ensemble, on ne peut pas additionner des fruits et des boulons. Par contre si je suis déjà dans le contexte des fruits et que je veux « zoomer », je dois faire la distinction entre des oranges et des pommes.
    
    On n'est pas obligé d'utiliser des explications théoriques, et on peut rester très terre à terre, en expliquant que certains langages refusent de compiler/faire tourner un programme si on n'a pas garanti que les variables qu'on fait interagir entre elles ne correspondent pas aux mêmes choses (au même type) qu'on veut représenter, alors que d'autres sont plus permissifs et autorisent d'additionner des choux et des carottes, mais que le résultat n'est pas forcément celui auquel on s'attend.
    
    Lorsque j'étais en IUT, nous avons commencé l'algo/prog par l'apprentissage du C. Nous n'avons vu les pointeurs que très tard : nous avions commencé en Septembre, et nous n'avons commencé à voir les pointeurs qu'à partir de Décembre je pense. Du coup nous passions les structures par valeur, comme des gros bourrins, et nous avions tout plein d'algos qui se contentaient d'utiliser des tableaux et des tableaux d'indices, ainsi que des chaînes de caractères (qui n'étaient donc que des tableaux elles-mêmes). Pour déclarer des chaînes, on nous faisait passer par des typedefs :
```
typedef char CH20[21];

CH20 une_chaine_de_vingt_chars;

/* le reste */
```
    Sans forcément nous donner le vocabulaire à l'époque, ou alors en passant², on nous avait dit deux choses : (1) on nous expliquerait plus tard ce qui se cache sous le string (i.e. pourquoi déclarer un tableau de 21 chars et pas 20), et (2) que les tableaux qu'on passait par des fonctions étaient modifiés « pour de bon » si les fonctions appelées les modifiaient.
    
    Qu'entends-tu par "entrées-sorties" ?
    
    Je me permets de répondre: en intro à l'algo/prog, il faut pouvoir lire l'entrée du clavier, écrire sur un écran, puis un peu plus tard faire de même avec des fichiers.
    
    Tu délires là non ? C++ pour apprendre ? Il y a bien plus simple aujourd'hui. Tu veux dégouter tes étudiants de la programmation ?
    
    C'est parce que tu penses à C++ tel qu'il est utilisé professionnellement. Tu n'es absolument pas obligé d'apprendre C++ avec les templates. En fait, tu peux parfaitement faire du C++ qui ne soit que « C + STL », en rappelant bien à tes élèves que si jamais ils ont des erreurs bizarres à la compilation, c'est sans doute qu'ils ont mal écrit la ligne qui déclare/définit un conteneur STL utilisé, genre
```
#include <iostream>
#include <vector>

// pas besoin d'expliquer les espaces de nommage; il suffit de dire que c'est pour raccourcir les noms des fonctions
using namespace std; 

// ...

struct foo 
{
    // contenu
};

int
main(void)
{
    vector<fooo> foovec;
    // on fait quelque chose avec foovec, reste du code, etc.
}
```
    Un petit aparté : cette notation ne dit pas qu'il faut rajouter un i_ devant tous les entiers déclarés int en C ou C++ par exemple (le compilateur pourra tout de suite détecter les transtypages illégaux, ou bien émettre un warning en cas de possible troncature, etc.). Par contre, si j'ai une structure foo, préfixer mes variables de type foo par un truc du genre f_ ou foo_ etc. Dans un langage au typage dynamique qui ne propose pas de façon simple de déclarer les types, utiliser i_ prend alors du sens, comme dans my $i_counter = 3;. ↩
    
    Du genre on nous expliquait que les variables étaient copiées lors d'un appel de fonction, sans forcément nous parler du passage par valeur vs. passage par référence. ↩
    - [^] # Re: Pascal...
      
      Posté par xcomcmdr le 23 juillet 2014 à 09:37. Évalué à 4. Dernière modification le 23 juillet 2014 à 09:38.
      
      Je vois pas l'intérêt de la notation hongroise dès lors qu'on a un IDE moderne, quel que soit le langage.
      Et surtout pas dans l'exemple i_counter : ouais, c'est sûr qu'un compte sera pas un string, hein.
      
      99% du temps la notation hongroise, c'est Captain Obvious (aka Captain Noise pour du code).
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: Pascal...
        
        Posté par rewind (Mastodon) le 23 juillet 2014 à 11:35. Évalué à 7.
        
        Un IDE ?? Chez nous, on a décidé de ne pas leur mettre un IDE entre les mains avant le master. Un IDE cache beaucoup trop de choses qu'il est nécessaire de comprendre dans l'apprentissage.
        
        [^] # Re: Pascal...
        
        Posté par devnewton 🍺 (site web personnel) le 23 juillet 2014 à 15:12. Évalué à 1.
        
        Ce n'est pas parce que tu as galéré avec ed et gcc dans ta jeunesse qu'il faut faire subir le même sort aux nouvelles générations!
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Pascal...
        
        Posté par claudex le 23 juillet 2014 à 15:26. Évalué à 4.
        
        Et pourtant vous leur faite faire du Java, ce n'est pas très gentil. (mais c'est un faux espoir de leur "cacher l'ide", je me souviens que chez nous il n'a pas fallu 2 semaines pour que l'usage soit répandu au moins quand on bossait chez nous)
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Pascal...
        
        Posté par gnx le 24 juillet 2014 à 01:12. Évalué à 3.
        
        Oui, et non seulement ça cache beaucoup de chose mais conséquemment ça induit énormément en erreur sur ce qui se passe sous la surcouche, ça génère beaucoup d'idées fausses pour un débutant qui ne peut pas connaître les idées « vraies », alors que pour un non-débutant complet, ça peut déjà rendre confuses des choses pourtant pas très compliquées (là où 15 lignes de Makefile ordonnées logiquement suffiraient, le machin va laisser entrevoir 200 lignes imbittables pleines d'options de compilation et autres étapes inutilement verbeuses) ou bien entraîner des comportements néfastes (quand je coche les cases 3,4 et 7 de cette fenêtre, et que je place le fichier toto avant le fichier tata, ça compile, sinon non, mais je ne sais pas pourquoi), sans compter que, de fait, lorsqu'on utilise un IDE, on se rend compte qu'on est complètement paumé lorsque l'on est obligé de s'en passer ou que l'on doit règler un problème non prévu dans le comportement général de l'IDE.
        
        Et puis, pour un débutant, ajouter les bugs de l'IDE aux bugs de son programme alors qu'il n'est pas capable de déterminer d'où les problèmes viennent, ça peut compliquer énormément les choses. Et pour ajouter à la confusion, on lui cache plus ou moins les différentes étapes de compilations, lien, exécution, etc. des fois que ça pourrait l'aider à comprendre quel genre d'erreur est signalée.
        
        [^] # Re: Pascal...
        
        Posté par devnewton 🍺 (site web personnel) le 24 juillet 2014 à 11:15. Évalué à 2. Dernière modification le 24 juillet 2014 à 11:15.
        
        Je ne sais pas trop de quels IDE tu parles, mais les bons ne te cachent pas cmake ou maven, au contraire. C'est juste un énorme aide à la saisie.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Pascal...
        
        Posté par claudex le 24 juillet 2014 à 11:23. Évalué à 2.
        
        Comme il parlait de Java, prenons Eclipse ou Netbeans. Par défaut, ils font du Ant sans que tu n'en sache rien.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Pascal...
        
        Posté par devnewton 🍺 (site web personnel) le 24 juillet 2014 à 11:38. Évalué à 0. Dernière modification le 24 juillet 2014 à 11:39.
        
        Si tu crées un projet Maven (en général menu New project => Maven => Java Application), je te garantie que tu es au courant.
        
        Ce n'est pas le choix par défaut, c'est regrettable pour les autodidactes, car ant est has been, mais un cours classique avec prof explique la chaîne de construction de projet en leçon 1.
        
        Et encore, la leçon 1 devrait plutôt porter sur la gestion de version.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Pascal...
        
        Posté par claudex le 24 juillet 2014 à 11:43. Évalué à 6.
        
        Donc, à des gens qui n'ont jamais programmé ou à peine, tu commence par leur imposer git et maven ?
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Pascal...
        
        Posté par devnewton 🍺 (site web personnel) le 24 juillet 2014 à 12:09. Évalué à -1.
        
        Ca te semble difficile? Attends de voir la tronche du débutant devant un cours de C qui commence avec vim, make et gcc.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Pascal...
        
        Posté par claudex le 24 juillet 2014 à 12:12. Évalué à 5.
        
        Attends de voir la tronche du débutant devant un cours de C qui commence avec vim, make et gcc.
        
        Les cours de C débutant que j'ai vu, c'est avec un éditeur de texte graphique et juste GCC.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Pascal...
        
        Posté par lasher le 24 juillet 2014 à 00:09. Évalué à 2.
        
        C'est pas complètement débile d'utiliser une convention pour aider à la lecture (ou à l'auto-complétion !) dans beaucoup de cas. J'ai vu pas mal de gens utiliser des préfixes du genre m_ pour une méthode d'instance, s_ pour une méthode de classe, _ pour un membre privé (ou protégé), etc.
        
        Concernant les types dans un langage faiblement ET dynamiquement typé, je trouve au contraire que c'est loin d'être con, s'il y a potentiellement une ambiguïté sur la façon dont on compte se servir de la valeur :
        
        my @valeurs = get_valeurs(); # Je sais, c'est pas très idiomatique, mais j'fais c'que j'veux !@#$ my $distribution = 0; for my $i (@valeurs) { $distribution += $i; } # Pour le moment, $distribution est un int $distribution /= @valeurs; # PAF! $distribution devient float ou double! $distribution = int($distribution); # troncature, et $distribution redevient un int
        
        Il y a de très bonnes raisons pour lesquelles une valeur devrait être flottante mais doit être représentée sous forme entière (parce que dans la vie réelle, il n'existe pas de version fractionnaire de la quantité modélisée par exemple). Le principe est évidemment d'appliquer les règles de préfixage avec parcimonie : une variable de compteur de boucle n'a pas besoin d'être préfixée, puisque généralement « allouée » au début de la boucle, puis mise à la poubelle à la fin : son contexte est clair et non-ambigu. Mais lorsqu'on parle de variables qu'on passe en paramètre à des fonctions, etc., préfixer les noms de variables peut être utile pour lever les ambiguïtés.
      - [^] # Re: Pascal...
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 00:23. Évalué à 3.
        
        99% du temps la notation hongroise, c'est Captain Obvious (aka Captain Noise pour du code).
        
        C'est surtout Captain Wrong vue que lorsque le programme évolue les types changent sans que l'expression des traitements ait forcément à être modifiée.
        
        C'est du moins ce à quoi sert la surcharges des opérateurs en C++ et utiliser la notation hongroise en C++ montre surtout qu'on n'a rien compris!
        
        [^] # Re: Pascal...
        
        Posté par lasher le 24 juillet 2014 à 23:31. Évalué à 2.
        
        Selon moi, utiliser la notation hongroise dans le contexte de langages à typage dynamique et faible, c'est une façon de définir une autre forme d'interface : pour reprendre un exemple que j'avais donné en Perl, si j'ai un truc du genre :
        
        my $i_var = 10; $i_var += $valeur_flottante;
        
        … Alors je m'attends à ce que la prochaine fois que je cherche à lire $i_var, j'aie bien fait attention à le lire en tant qu'entier :
        
        un_petit_calcul(int($i_var));
        
        Évidemment mon exemple est trivial, mais comme l'explique groumly ailleurs, l'idée c'est quand même aussi d'ajouter une certaine sémantique qui ne peut être capturée par le compilateur. Dans le cas de langages fortement typés, préfixer par i_, f_, etc. ne sert à rien (le compilateur a déjà les infos pour te gueuler dessus). Dans des cas plus complexes, du genre :
        
        sub construire_type1 { return { Champ1 => valeur1(), Champ2 => valeur2(), ... }; } sub construire_type2 { return { AutreChamp1 => valeur1(), AutreChamp2 => valeur2(), ... }; } my $foo = construire_type1(); my $bar = construire_type2(); # du temps passe... $foo = $bar; # MAIS C'EST PAS BIEN ! C'EST PAS LES MÊMES TYPES ! :(
        
        sub construire_type1 { return { Champ1 => valeur1(), Champ2 => valeur2(), ... }; } sub construire_type2 { return { AutreChamp1 => valeur1(), AutreChamp2 => valeur2(), ... }; } my $t1_foo = construire_type1(); my $t2_bar = construire_type2(); # du temps passe... $t1_foo = $t2_bar; # MAIS C'EST PAS BIEN ! C'EST PAS LES MÊMES TYPES ! Mais bon au moins c'est plus visible
        
        Ça reste un exemple abstrait, et bien entendu un bon choix pour nommer les variables va très certainement aider à ne pas se planter, avec ou sans préfixes. Mais parfois il est facile de faire des bourdes pour des types qui sont très proches, parce qu'on a mal lu la doc, etc. Et dans un langage dynamique, ça a tendance à avoir des effets plutôt très indésirables (genre une partie des champs est commune à deux types, et au début, tout à l'air de fonctionner, et ensuite des bugs apparaissent « silencieusement » …)
      - [^] # Re: Pascal...
        
        Posté par groumly le 24 juillet 2014 à 01:52. Évalué à 6.
        
        La notation hongroise, c'est surtout ajouter de la semantique a ta variable, plus que le type (qui existe aussi, mais a commence dans des languages avec 1 seul type, forcemment, t'as besoin de preciser dans ce cas quand tout est un byte).
        
        En gros, tu prefixes un int avec d pour indiquer un delta, sz pour indiquer une zero terminated string en c parce que ca fait une grosse difference, et que le type char * ne te permet pas de les differencier.
        Repeter le type dans un langage type, c'est juste debile, ide ou pas.
        Dans un langage dynamique, c'est pas forcemment delirant.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
- [^] # Re: Pascal...
  
  Posté par flan (site web personnel) le 22 juillet 2014 à 19:44. Évalué à 2.
  
  Perso, je pencherais pour OCaml, même si j'ai plutôt tendance à faire du Python ou du C chez moi.
  
  Le Caml impose une certaine rigueur et de bien comprendre ce qu'on fait, alors qu'un langage à typage dynamique permet plus facilement de faire des choses qui tombent en marche.
  - [^] # Re: Pascal...
    
    Posté par Dr BG le 22 juillet 2014 à 20:00. Évalué à 4.
    
    Perso, Ocaml a beau être l'un de mes langages préféré (si ce n'est le premier, même si je ne le pratique pas assez à mon goût), ce n'est pas celui que je choisirai pour débuter. Tout simplement parce que l'on début généralement l'apprentissage de l'algorithmique et de la programmation par des programmes impératifs. Même si on peut faire de l'impératif avec Ocaml, ce n'est pas la meilleure façon de l'utiliser, et je ne pense pas que ce soit le langage le plus simple pour ça (manipuler les références…).
- [^] # Re: Pascal...
  
  Posté par rakoo (site web personnel) le 23 juillet 2014 à 00:14. Évalué à 3.
  Et ben pour le coup je vais citer mon langage préféré du moment, mais qui a l'avantage de répondre au cahier des charges: Golang.
  
  Je pense que Go remplacerait avantageusement C++ ici:
  - extrêmement simple, la spec tient sur une page. Pas besoin de la lire, c'est juste pour dire que c'est extrêmement simple à apprendre pour quelqu'un qui sait déjà programmer, donc plus simple que C++ pour un débutant complet
  - il a toutes les fonctionnalités "standard" attendues d'un langage impératif tout en gardant une syntaxe assez proche (c'était d'ailleurs un des buts des créateurs: un langage qui ressemble au C)
  - la distinction est claire entre valeurs et référence, modulo les appels de fonctions qui se font tous avec .. À part ça les signatures des fonctions indiquent clairement ce qui est attendu
  - typé, statiquement si les choses sont faites correctement
  - le compilateur est extrêmement rapide et affiche des erreurs de compilation sont (subjectivement) claires
  - une lib standard extrêmement fournie, il y a peu de chances qu'ils aient besoin d'une dépendance externe pour quoi que ce soit
  - s'ils veulent faire les choses proprement, il y a tout ce qu'il faut pour se faire ses tests (unitaires ou non), son benchmarking et même son profiling avec la librairie standard. Super intéressant pour comprendre pourquoi une fonction prend autant de temps, ou pour commencer à toucher du doigt les allocations mémoire et voir où partent les précieux octets de la RAM.
  Par contre, tout ce qui parle de concurrence (les channels, go) doit à mon avis être évité pour des débutants complets parce que ça ne leur apportera pas grand chose et ne se transposera pas facilement dans d'autres langages.
  - [^] # Re: Pascal...
    
    Posté par Zenitram (site web personnel) le 23 juillet 2014 à 08:41. Évalué à -1.
    
    J'ai aucun avis sur Go lui même, mais ça :
    
    extrêmement simple, la spec tient sur une page.
    
    C'est vraiment de la propagande pourrie.
    Je peux te mettre C++ sur une page aussi si tu as envie : C++ est extrêmement simple, c'est rakoo qui l'argumente, car la spec tient sur une page. Ben oui, tu écris ton "argument" comme si il n'y avait aucune limite à la taille (nombre de lignes?) de la page, donc je fais pareil… Go et C++, égalité sur son "extrème simplicité" avec les arguments à rakoo.
    
    Le reste du commentaire m'interessait pour me faire une opinion, mais comme le premier argument est d'une grande stupidité, comment croire le reste? A tous les coups, "une lib standard extrêmement fournie" va être la capacité à afficher du texte à l'écran, sans doute un écran capable d'afficher une page de 10000 lignes certes…
    - [^] # Re: Pascal...
      
      Posté par barmic le 23 juillet 2014 à 12:09. Évalué à 4.
      
      C'est surtout que ça ne veux rien dire. C'est pas parce qu'un langage est décris sur 140 caractères qu'il est simple. Ca peut vouloir dire qu'il n'est pas complètement défini (super \o/), qu'il est facile à implémenter, mais à utiliser non ça n'indique rien. Le malbolge est décris simplement et complètement, est-ce pour autant un langage simple ?
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Pascal...
  
  Posté par barmic le 23 juillet 2014 à 00:24. Évalué à 7.
  
  Pascal (puisque c'est ce que j'ai mis dans le titre) avait l'avantage d'offrir tout ça de manière simple et efficace. Malheureusement, il est un peu daté maintenant.
  
  Pourquoi pas ADA ?
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 23 juillet 2014 à 00:57. Évalué à 5.
    
    Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Pascal...
    
    Posté par Maxime (site web personnel) le 23 juillet 2014 à 08:16. Évalué à 6.
    
    Pourquoi pas ADA ?
    
    Histoire que ce soit dit : Le nom c'est Ada (du prénom de Lovelace) et non ADA. ADA c'est le loueur de véhicule.
    - [^] # Re: Pascal...
      
      Posté par claudex le 23 juillet 2014 à 11:06. Évalué à 10.
      
      Faire cette remarque pour un langage qui n'est pas sensible à la casse, c'est un peu fort.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Pascal...
  
  Posté par CHP le 23 juillet 2014 à 09:39. Évalué à 3.
  
  Pascal (puisque c'est ce que j'ai mis dans le titre) avait l'avantage d'offrir tout ça de manière simple et efficace. Malheureusement, il est un peu daté maintenant.
  
  Lapin comprit.
  
  Le but, c'est d'apprendre les bases de la programmation. Kestananafout' que ca soit un peu daté ?
  
  Pascal c'est très bien pour apprendre. On a (quasi) tous appris avec ca.
  - [^] # Re: Pascal...
    
    Posté par devnewton 🍺 (site web personnel) le 23 juillet 2014 à 09:46. Évalué à 5.
    
    Kestananafout' que ca soit un peu daté ?
    
    Trouver des docs à jour et une communauté active, c'est aussi important quand on commence.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Pascal...
      
      Posté par Thomas Douillard le 23 juillet 2014 à 10:54. Évalué à 0.
      
      Bof, autant c'était marrant de trouver plein de bidouilles en javascript pour faire une page web en 1998, il y avait une communauté active, autant c'est pas du tout une démarche utile pour apprendre les bases de la programmation.
      
      Peut être que ce qu'il faut, en fait, pour des étudiants qui vont utiliser l'informatique et pas des étudiants en informatique, c'est surtout leur présenter des applications dans leur domaine aux trucs qu'on leur apprend.
      - [^] # Re: Pascal...
        
        Posté par groumly le 23 juillet 2014 à 13:23. Évalué à 4.
        
        Ben disons que c'est pratique de trouver des infos sur google sur des problemes divers et varies (segfault, exception, plantages, etc.), ou encore de pouvoir rechercher comment faire certains trucs simples mais pas forcement evident (utilisation correcte de la lib standard, conversion entre certains typs, etc), ou tout simplement, se depanner sur la syntaxe du langage.
        
        C'etait pas un probleme pour moi en 99, on avait pas internet eud'facons (de mon temps! Salauds de jeunes), mais les usages ont un peu change de nos jours.
        Meme apres presque 10+ ans de carriere, je me ferais clairement pas chier a apprendre un langage qui n'a pas une bonne presence en ligne.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Pascal...
        
        Posté par Thomas Douillard le 24 juillet 2014 à 10:51. Évalué à 1.
        
        Ben après 10 ans de carrière tu sais très bien ce que tu cherches. Un étudiant il a pas besoin d'une forte présence en ligne, il a besoin d'un forum de débutant ou de poser des questions au binôme d'à côté.
  - [^] # Re: Pascal...
    
    Posté par Maclag le 23 juillet 2014 à 11:26. Évalué à 5.
    
    Il y a plusieurs types d'étudiants. Entre autres:
    -Ceux qui veulent devenir informaticiens, et qui sont donc prêts à apprendre N langages.
    -Ceux qui veulent juste pouvoir se débrouiller pour coder quelque chose occasionnellement.
    
    La deuxième catégorie va chercher un aspect pratique immédiat à ce que tu enseignes. L'aspect pratique du Pascal, une fois sorti du cours, c'est quoi au juste?
    - [^] # Re: Pascal...
      
      Posté par Tit le 23 juillet 2014 à 14:14. Évalué à 2.
      
      Par exemple tu peux faire des programmes évolués avec delphi ou lazarus, non?
      - [^] # Re: Pascal...
        
        Posté par lolop (site web personnel) le 23 juillet 2014 à 16:52. Évalué à 3.
        
        Tu peux. Mais la communauté n'est pas très importante.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Pascal...
    
    Posté par papatte3 le 23 juillet 2014 à 13:33. Évalué à 0.
    
    Le but, c'est d'apprendre les bases de la programmation. Kestananafout' que ca soit un peu daté ?
    
    Pascal c'est très bien pour apprendre. On a (quasi) tous appris avec ca.
    
    Pour un débutant, c'est quand même plus cool de faire une appli qui permet de faire d'afficher des trucs dans un navigateur web, voire faire assez facilement une appli qui sert à quelque chose dans le vrai monde que de faire du pascal.
    - [^] # Re: Pascal...
      
      Posté par Dr BG le 23 juillet 2014 à 13:47. Évalué à 5.
      
      Qu'est-ce qui empêche de faire un vrai programme en Pascal ?
      - [^] # Re: Pascal...
        
        Posté par papatte3 le 23 juillet 2014 à 14:06. Évalué à 0.
        
        Qu'est-ce qui empêche de faire un vrai programme en Pascal ?
        
        Un débutant complet Pascal ne va a priori pouvoir d'abord faire que des programmes en ligne de commande (qui n'est plus utilisée par personne sauf les gens du métier).
        
        Un débutant complet en js va pouvoir assez facilement faire des programmes avec des champs et des boutons, qui marchent dans un navigateur.
        
        [^] # Re: Pascal...
        
        Posté par Dr BG le 23 juillet 2014 à 14:15. Évalué à 4.
        
        Donc ce n'est pas spécifique à Pascal, mais à tout langage qui n'est pas JavaScript, ActionScript, Dart ou CoffeScript (ou tout autre langage produisant du JS).
        
        [^] # Re: Pascal...
        
        Posté par barmic le 23 juillet 2014 à 14:25. Évalué à 2.
        
        Non, tu as des langages mieux outillés que d'autres pour faire de l'IHM (web ou pas).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pascal...
        
        Posté par Tit le 23 juillet 2014 à 17:20. Évalué à 3.
        
        Il me semble que la plupart des langages ne sont pas directement outillés pour faire des ihm mais utilisent des modules, sur-couches, framaework etc.
        
        avec Pascal tu peux aussi faire des ihm avec lazarus aussi facilement je suppose qu'avec python (pour lequel il faut choisir si on va utiliser qt, gtk, tkinter etc.) Je ne crois pas qu'on peut évacuer pascal sur ce critère.
- [^] # Re: Pascal...
  
  Posté par keyser.dyson le 25 juillet 2014 à 20:49. Évalué à 0.
  
  Pour moi, c'est le Lisp.
  
  Je pense que c'est le meilleur langage pour débuter.
  
  Pas de "{};". Il suffit d'expliquer l'homoiconicité et les opérateurs.
  
  Ca ressemble à des maths.
  
  Pour des gens qui ont une formation scientifique, ça ne pose pas de problème. C'est une notation en plus.
  
  Il n'y a pas de grammaire compliquée a apprendre avec des cas particuliers. Tout est valable a tous les niveaux.
  
  Après, pour faire des choses, réaliser un projet, les choix sont ouverts. Ca dépends (Web ou pas, performant ou pas …).
  
  Un exercice après qui peut être fait dans n'importe quel langage est d'écrire un interpréteur Lisp.
  
  Je pense que ça peut passionner les élèves de leur faire prendre conscience qu'ils peuvent écrire leur langage et que c'est accessible.
  - [^] # Re: Pascal...
    
    Posté par lasher le 25 juillet 2014 à 21:41. Évalué à 4.
    
    Pour moi, c'est le Lisp.
    […] Ca ressemble à des maths.
    Pour des gens qui ont une formation scientifique, ça ne pose pas de problème. C'est une notation en plus.
    
    Perdu ! Lorsque j'étais en école d'ingénieur, beaucoup de gens en génie info avaient pris « structures de données » et « introduction à l'intelligence artificielle » comme cours de base en premier semestre. Parmi ces gens, beaucoup venaient de la prépa intégrée de l'école, et avaient clairement fait bien plus de maths que moi. Une bonne partie avait aussi suivi une UV d'initiation à l'algorithmique (en Pascal je crois). Bref. Les gens comme moi qui venaient d'IUT avaient clairement un avantage sur les gens qui n'avaient fait « que » des maths lorsqu'il s'est s'agit d'apprendre à programmer en Lisp. Pourtant ils apprenaient l'algo à part (et les TP de l'UV d'algo étaient en C, certes, mais ils n'ont commencé que tard d'une part, et ensuite les élèves voyaient C et Lisp de front, donc ils n'étaient pas pollués par la syntaxe de C à ce moment).
    - [^] # Re: Pascal...
      
      Posté par keyser.dyson le 25 juillet 2014 à 21:55. Évalué à 0.
      
      Mais ceux qui sortent d'IUT ont de toute façon un avantage puisqu'ils ont fait de la programmation.
      
      Non?
      - [^] # Re: Pascal...
        
        Posté par lasher le 25 juillet 2014 à 23:47. Évalué à 2.
        
        En terme d'expérience pratique oui, bien sûr. Mais la programmation n'est qu'une partie du cursus. Nous faisons énormément de génie logiciel aussi, et en règle générale d'analyse et conception de systèmes d'info. La programmation n'est qu'une portion (pas négligeable, mais pas majoritaire non plus — la plupart du temps le génie logiciel a un plus fort coefficient que les UV de programmation/algo pures) du programme.
        
        Ensuite, la plupart des gens qui arrivent en école d'ingénieur ont quand même fait un minimum d'algorithmique (à mon époque, les prépas MPSI faisaient soit du Caml light, soit du Pascal, et la prépa intégrée de mon école permettait aux étudiants de suivre une intro à l'algorithmique). Note : ayant fait un IUT, nous étions (à raison!) interdits d'UV de structures de données (car nous avions déjà vu 90%).
        
        Maintenant je peux te dire comment j'ai vécu la chose : je venais d'un monde purement impératif (C, C++, Java, Visual Basic/ASP, etc.), et là on me dit que la récursion c'est cool. Alors que, lorsque tu viens du monde du C, au contraire, t'as pas envie de faire de la récursion si tu peux l'empêcher, car tu vas dupliquer les variables, etc. Donc techniquement, il a fallu que j'arrive à me retourner le cerveau pour changer complètement mes habitudes, là où les autres de DEUG/prépa étaient relativement « vierges », voire avaient déjà vu des langages comme Scheme ou OCaml (bon ceux-là n'avaient pas de problème avec Lisp en général ;-)).
        
        Enfin, autant les langages comme OCaml, Scala, ou Haskell ont réellement une notation proche de ce que je ferais en maths, autant la syntaxe de Lisp c'est quasiment purement du lambda calcul, qui certes reste un domaine des maths, mais quand même, il est super restreint. J'ai fini par m'y faire à l'époque, et quelque part je trouvais ça rigolo de penser en récursif, mais très clairement, ça n'est pas très bien passé avec les gens qui avaient moins d'expérience pratique avec la programmation.
        
        [^] # Re: Pascal...
        
        Posté par keyser.dyson le 26 juillet 2014 à 18:10. Évalué à 1.
        
        Maintenant je peux te dire comment j'ai vécu la chose : je venais d'un monde purement impératif (C, C++, Java, Visual Basic/ASP, etc.), et là on me dit que la récursion c'est cool.
        
        Ca m'a fait rire de te lire. C'est vrai, c'est plutôt déconseillé comme tu l'expliques plus bas.
        
        La pile n'est jamais grande en C et en Python non plus.
        
        J'ai vu une video de Guido van Rossum qui justifie ce point. Je crois que c'est limité à 100 appels récursifs en Python.
        
        Je ne suis pas trop d'accord avec lui. Pour moi il n'y a pas de véritable raison technique à limiter la pile dans un interpréteur.
  - [^] # Re: Pascal...
    
    Posté par Zylabon le 26 juillet 2014 à 21:36. Évalué à 3.
    
    Pour moi, c'est le Lisp.
    
    Un lisp-1 alors, parce que lisp-2 c'est une atrocité. Les deux espaces de noms (pour les variables et les fonctions), les syntaxes cabalistique pour passer une fonction en paramétre. Ajoutez à ça la portée dynamique des variables et la nomenclature incohérente des fonction de la bibliothèque standard, et il devient criminel de faire découvrir la programmation avec Common Lisp.
    
    Il y a plein de Lisp magnifiques (Scheme par exemple), trop souvent on rencontre le pire de tous.
    
    Please do not feed the trolls
# un titre

Posté par Antoine le 22 juillet 2014 à 19:22. Évalué à 1.

Si je devais apprendre à programmer aujourd'hui je pense que je choisirais Scala, parce qu'il élégant, statiquement typé et combine les notions de programmation fonctionnelle et orientée-objet.

Mouarf. Sérieusement ? Si tu devais apprendre à programmer aujourd'hui, tu n'aurais aucune idée de ce qu'apportent le typage statique, la programmation fonctionnelle, etc. Tu ne pourrais donc pas te décider pour Scala selon ces critères.

(à moins que par apprendre à programmer tu voulusses en réalité dire enseigner la programmation ;))
# Ne pas commencer par coder

Posté par Denis Dordoigne le 22 juillet 2014 à 20:00. Évalué à 2.

Je pense qu'il faut apprendre les bases de l'algorithmique avant de commencer à coder, l'apprentissage du "je fais juste un truc qui marche" qu'on apprend de plus en plus à l'école donne des résultats catastrophiques dans le monde réel, notamment une consommation cpu et mémoire non maîtrisée par méconnaissance des concepts de complexité algorithmique et une croyance mythologique en les capacités du ramasse-miettes. Et je ne parle pas des architectures n-tiers qui n'ont aucun sens parce qu'on n'apprend pas non-plus à réfléchir à son architecture à l'école et on reproduit des technologies qu'on a vu sans se poser la question de leur intérêt dans un projet précis (si j'ai besoin de stocker une donnée je prends un SGBDR, si j'ai besoin de faire une fonction réutilisable je monte un webservice, …)

Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
- [^] # Re: Ne pas commencer par coder
  
  Posté par lasher le 23 juillet 2014 à 00:36. Évalué à 5.
  Pas d'accord. On peut parfaitement apprendre un langage au fur et à mesure des cours d'algo (c'est d'ailleurs comme ça que j'ai appris en IUT). L'important est d'adapter les algos au sous-ensemble du langage considéré. Ensuite, au fur et à mesure on peut ajouter des aspects du langage quand on veut aborder des structures de données plus compliquées — mais pour les algos de base (tri, comprendre le principe d'échange de variables, etc.), on peut se contenter d'un tout petit sous ensemble et faire déjà pas mal. À Versailles, si ça n'a pas changé, en L1 ils ont construit un environnement de travail au-dessus du C en utilisant la SDL, et tous les algos/problèmes à réaliser/résoudre sont faits en utilisant les « nouvelles » primitives (genre tracer_droite, afficher_point, etc.), et au fur et à mesure ils découvrent aussi la bibliothèque standard. Je sais qu'en 1è/2è année de fac à l'université de Rice (Houston,TX USA), ils utilisent Python, mais au moins en 2è année, ils demandent au élèves un truc qui peut sembler bizarre au début : ils ne peuvent écrire qu'une seule fois dans une variable, et doivent numéroter les variables s'ils veulent « écraser » la valeur. La finalité est de faire une intro à un style de programmation plus fonctionnel une fois qu'ils ont les bases (et parce que ça aide pour pas mal d'algos parallèles, qui sont ensuite enseignés en 3è et 4è années).
  
  Que ce soit la méthode à laquelle j'ai été sujet (sous-ensemble du C qu'on agrandit au fur et à mesure, quand la compréhension est suffisante) ou un langage avec de « nouvelles » primitives pour aider à faciliter certaines tâches¹, l'important c'est la notion de progression. En IUT, nous faisions tous nos exos d'algo en C sur papier, et c'était à nous d'aller ensuite sur les machines de la fac (ou chez nous) pour coder les programmes sur PC. Nous avions aussi des projets (3 en C en 6 mois) à effectuer en binôme.
  
  Il ne faut pas oublier que les algos et structures de données de bases sont vraiment simples :
  - Structures de contrôles (while, for, if/else do…while, switch)
  - Types composés (struct en C) et tableaux (et combinaison des deux)
  - Tris et recherche de tableaux (tri à bulle, recherche dichotomique)
  - Notion de « sauts » : break, continue, goto (avec les avertissements qui vont bien)
  - Tableaux d'indices (pour trier suivante différents critères sans toucher au tableau « lourd »)
  - Une fois que les pointeurs ont été vus : listes chaînées, arbres, et graphes.
  Rien que ça, ça prend beaucoup de temps à enseigner à des étudiants qui ne savent rien de la programmation. En IUT génie info en parallèle, les élèves font de la logique formelle, apprennent un peu d'archi des ordinateurs (logique de Boole, tableaux de Karnaugh, portes logiques), commencent à voir ce qu'est une base de données, et font pas mal de génie logiciel. En fac classique, en première année de cursus scientifique, à côté de l'intro à la programmation/algorithmique, il y a les maths, la physique, la chimie, la bio, etc.
  
  Bref, en un semestre, voir déjà les points que j'ai énumérés, c'est pas mal.
  1. Par exemple, j'aurais bien aimé qu'on m'expliquer que gets c'est mal, et qu'on me fournisse un truc genre getline ou lire_ligne qui me simplifie le travail, quitte plus tard à me le faire reprogrammer. ↩
  - [^] # Re: Ne pas commencer par coder
    
    Posté par Denis Dordoigne le 23 juillet 2014 à 02:28. Évalué à 2.
    
    En fait on est d'accord, ce que tu présentes est bien un enseignement de la programmation et pas un apprentissage au "juste marche".
    
    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
# Premier langage de programmation… pour qui ?

Posté par lolop (site web personnel) le 22 juillet 2014 à 20:23. Évalué à 5.

Pour des gens qui ne verront ça que comme des concepts (variable, boucle, fonction…) et un outil une fois au cours de leur cursus, un truc pratique qu'ils pourront réutiliser à l'occasion: Python, Ruby… Un langage où on peut faire facilement des choses intéressantes (voire utiles), avoir des résultats rapides et où les mêmes idiomes sont repris un peu partout.

Pour des gens dont l'informatique / le développement de logiciels va être un métier, alors plutôt quelque chose comme ADA, Pascal…. Un langage qui oblige à construire proprement, afin de rentrer dans le gras des types et des contraintes.

Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Fortran 2008

Posté par Denis Bernard (site web personnel) le 22 juillet 2014 à 21:46. Évalué à 7.

Je suis un pur autodidacte. Jamais eu une seule heure de cours d'informatique. J'ai débuté avec Basic à l'époque où lorsqu'on expliquait un algorithme dans un article ou un livre c'était toujours avec le langage Basic. Aujourd'hui c'est Python qui lui a succédé comme langage de démonstration. Quand je suis passé de MS-Windows à Linux en 95, je me suis mis au Fortran 77 car Basic n'était pas réellement disponible à l'époque dans le monde Unix. Ni en odeur de sainteté. C'était comme le Basic mais en plus ascétique !

Mais le Fortran du 21ème siècle a considérablement évolué comparé à celui des années 80. Il est devenu plus verbeux ; autant en fait que Basic, sinon plus. Fortran a ajouté à ses fonctionnalités d'antan les pointeurs, une très grande partie de la programmation orientée objet, les modules, etc. Et, surtout, il est capable d'interagir de plus en plus avec la lib C. Il peut aussi faire des appels à la ligne de commande (synchrones ou pas). Donc, on n'est plus totalement bridé quant à ce qui touche l'OS et l'on peut toujours utiliser les outils Posix à la ligne de commande si on ne veut pas s'embêter à la programmation mixte.

J'utilise Fortran pour mes besoins perso et jamais pour le calcul intensif. Juste comme remplacement du bon vieux Basic de derrière les fagots. J'ai essayé de m'initier au langage Python : pas réussi… Mais je sais qu'intellectuellement je ne suis pas une lumière. J'en conclue (hâtivement !) que Python doit être plus difficile d'apprentissage que ne l'était Basic. (Ce serait intéressant d'avoir l'avis de ceux qui ont appris ces deux langages de leur propre initiative et sans obligation professionnelle sous-jacente.)

Sous Linux, on a gfortran qui est totalement intégré dans GCC : aucune difficulté à l'installer ! Donc je ne vois pas pourquoi on n'envisagerait pas Fortran comme un langage d'apprentissage qui, contrairement aux langages d'origine universitaire, restera toujours utilisable dans la vraie vie.
- [^] # Re: Fortran 2008
  
  Posté par Yth (Mastodon) le 22 juillet 2014 à 22:42. Évalué à 5.
  
  J'ai suivi des cours d'info, mais après avoir appris tout seul dans l'ordre et pour le plaisir :
  BASIC, Pascal, C et Python, puis d'autres après parfois pour le boulot, parfois pour les cours (asm, caml, lisp, sql, bash, js, php, java, etc).
  Chaque changement de langage jusque Python a été une révolution pour moi, à la différence qu'entre le C et le Python, l'usage change et ça ajoute simplement une corde à mon arc (comme js, pas vraiment remplaçable dans un brouteur).
  
  J'ai trouvé le Python à la fois simple et évident à apprendre. Logique, clair et puissant. Aujourd'hui je dois faire du PHP, et (vivement que je change de taf) je regrette presque en permanence de ne pas faire de Python à la place.
  
  Maintenant j'ai aussi essayé Perl et Coffeescript par exemple (java aussi, mais j'ai dû bosser avec pendant 6 mois), et laissé tombé parce que la logique me semblait trop étrangère, ou l'intérêt à la limite de l'inexistant (mais pourquoi Coffeescript ?).
  
  Je crois simplement qu'on a des affinités, des goûts et des couleurs, et qu'être hermétique à un langage ne signifie pas qu'on a le cerveau plus lent qu'un autre.
  Juste orienté différemment.
  
  Yth.
  - [^] # Re: Fortran 2008
    
    Posté par Denis Bernard (site web personnel) le 22 juillet 2014 à 23:08. Évalué à 1.
    
    La question qui me brûle les lèvres (en se basant seulement sur ton expérience) : en supposant que tu n'aies que deux langages installés sur une machine, Basic et Python, lequel d'entre eux choisirais-tu pour initier un parfait débutant ?
    - [^] # Re: Fortran 2008
      
      Posté par coid le 22 juillet 2014 à 23:45. Évalué à 5. Dernière modification le 22 juillet 2014 à 23:49.
      
      J’ai aussi commencé par moi-même avec le Basic, le Pascal et même un peu d’assembleur, puis pas mal de C, un peu de Fortran, puis beaucoup de PHP, un chouïa de Javascript et divers autres trucs, et puis j’ai essayé Python : la révélation. Le reste paraît soudainement assez misérable.
      
      Je ne sais pas si Python est le plus adapté pour débuter en info, mais le Basic ma paraît franchement une mauvaise idée si on veut aller quelque part, ça donne trop de mauvaises idées, à moins que ce soit un Basic évolué.
      
      Avec tout ce qui est dit plus haut, le Go me paraît un bon compromis pour débuter. Semble assez simple, loin du bordel C++, c’est du typage statique. Ceci dit, je pense que Python est aussi un bon langage pour démarrer, le rapport puissance/puissance/lisibilité est juste merveilleux, mais ça ne permet pas d’aborder certains concepts avancés (pointeurs et toutes les question de gestion de mémoire), et cette simplicité évite malheureusement de peiner avec certains concepts quand même utiles à comprendre si on veut aller loin, tout simplement parce que Python masque beaucoup de difficultés qu’on aurait avec d’autres langages. On peut écrire en quelques lignes de Python l’équivalent de plusieurs centaines de lignes en C.
      
      Il y a un livre très simple pour les débutants en Python et en programmation :
      http://users.polytech.unice.fr/~helen/pythonCIP1/apprendre_python3Swinnen.pdf
    - [^] # Re: Fortran 2008
      
      Posté par Maxime (site web personnel) le 23 juillet 2014 à 08:29. Évalué à 5.
      
      J'ai également commencé par le Basic avant de faire du PHP, du C, du JS, de l'Ada, du Java et du Python (liste non complète).
      
      Si je devais choisir entre Basic et Python pour initier un parfait débutant, je choisirais sans hésitation le Python ! La syntaxe me paraît aussi simple et le langage offre beaucoup plus de choses. On est pas obligé d'user de toutes les astuces pour réduire le nombre de lignes.
      
      Le seul truc qui pourrait me faire choisir le Basic serait si le débutant apprend la programmation pour un objectif précis : faire une petite application graphique. Là dans ce cas, un visual basic pourrait être intéressant.
      
      Mais si c'est pour du long terme, entre Python et Basic, je prend le Python.
- [^] # Re: Fortran 2008
  
  Posté par keyser.dyson le 25 juillet 2014 à 20:56. Évalué à -3.
  
  Je pense que le Fortran est exclu juste car ça sent la poussière.
  
  C'est un langage connu pour être très performant.
  - [^] # Re: Fortran 2008
    
    Posté par Denis Bernard (site web personnel) le 25 juillet 2014 à 23:14. Évalué à 6.
    
    Ah, ah ! Celle-là je l'attendais. Pourtant javais bien précisé 2008 dans Fortran. Certes 1956, l'année de l'invention du premier langage de programmation (c. à d. un logiciel pour un mec infoutu de d'écrire une routine en assembleur), ça sent la naphtaline.
    
    Mais il y a eu la version normalisée de 1966, puis celle de 1977, et encore celle de 1990, et encore une fois de plus celle de 1995… et… et celle de 2003… et … 2008. Ouf ! En fait, c'est pire que ça : ce langage continue d'évoluer !
    
    Affirmer que Fortran sent la poussière témoigne d'une inculture crasse en matière d'informatique.
    - [^] # Re: Fortran 2008
      
      Posté par keyser.dyson le 25 juillet 2014 à 23:23. Évalué à 2.
      
      Je n'adhère pas à ça.
      
      J'ai vu des benchmarks et le Fortran et juste en dessous du C en vitesse.
      
      Je relayais l'image attachée au Fortran.
      
      J'aime le Lisp mais c'est aussi un langage qui sent le moisi. C'est pas du tout à la mode.
      
      Le Lisp est très standardisé aussi. Ils y des normes.
      - [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 26 juillet 2014 à 00:01. Évalué à 2.
        
        Ok. Le titre du journal était "Python comme premier langage de programmation ?". Tout le monde, je pense, est d'accord sur le fait que Python est bien aujourd'hui le premier langage que l'on enseigne aux étudiants. Mais aussi le point d'interrogation du titre posait la question de la pertinence de ce choix. Si Python a enterré Basic comme langage de début, je ne suis pas certain que l'on ait gagné au change.
        
        Autant Basic s'apprenait sans professeur (ils n'existaient pas encore !) autant Python, même avec des vrais prof, n'est pas vraiment maîtrisé par tous les étudiants (j'ai observé le cas dans ma famille).
        
        Quand je pense à Fortran comme langage pour débutant, c'est qu'il offre un large spectre en matière de programmation (impératif, pointeurs, opérateurs, POO, etc.). Donc, on peut débuter en impératif puis évoluer sur des typages plus ou moins sophistiqué, les opérateurs, etc. Et son apprentissage demeurera utile dans le futur car il se mixte très bien avec des bibliothèques en C et C++.
        
        [^] # Re: Fortran 2008
        
        Posté par keyser.dyson le 26 juillet 2014 à 17:57. Évalué à 1.
        
        Quand je pense à Fortran comme langage pour débutant, c'est qu'il offre un large spectre en matière de programmation (impératif, pointeurs, opérateurs, POO, etc.).
        
        Qu'est ce que tu fais en Fortran comme programme ?
        
        [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 26 juillet 2014 à 23:49. Évalué à 1.
        
        Qu'est ce que tu fais en Fortran comme programme ?
        
        Le moteur de blog statique : fBlog. Plus d'explications ici. Et comme démo, mes pages perso. Ça, c'est mon gros projet ! Avant j'avais fait d'autres bricoles de bien moindre envergure.
        
        J'ai déjà parlé de fBlog sur ce site ici, ici et ici. C'est toujours en phase Beta car je manque de retour d'expérience d'utilisateurs d'une part, et d'autre part j'ai encore pas mal de feuilles de style à pondre pour rendre ce moteur de blog attrayant.
        
        Mais tel quel, il est utilisable si l'on se donne la peine de personnaliser sa feuille de style. Son interface utilisateur, en mode console, est interactive et elle est réellement une grande fierté pour moi. Sinon il y a aussi la ligne de commande classique.
        
        [^] # Re: Fortran 2008
        
        Posté par keyser.dyson le 27 juillet 2014 à 18:16. Évalué à 2.
        
        Son interface utilisateur, en mode console, est interactive et elle est réellement une grande fierté pour moi.
        
        J'ai regardé un peu. Les sources aussi.
        
        Je n'ai pas vu de copie d'écran ni de video de l'interface. C'est dommage car c'est un plus. Les autres outils de blog statique que j'ai vu ne font pas ça.
        
        Sinon le statique est la bonne voie. J'ai moi aussi fait un outil similaire mais en PHP. Je tenais compte des types de fichier.
        
        Quand le logiciel tombait sur une image en parcourant l'arborescence, il générait une miniature avec ImageMagick et l'ajoutait à une gallerie.
        
        Quand c'était un PDF, il était converti en image etc …
        
        Avec "dot", je faisait un "sitemap" sous forme de diagramme à bulles.
        
        En statique on peut faire pleins de choses qu'on ne peut pas faire en dynamique.
        
        [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 27 juillet 2014 à 20:16. Évalué à 1.
        
        Je n'ai pas vu de copie d'écran ni de video de l'interface. C'est dommage car c'est un plus. Les autres outils de blog statique que j'ai vu ne font pas ça.
        
        Normalement, sur le site du projet fBlog hébergé par Sourceforge, il doit apparaître une galerie de photos dont une montrant le mode console interactif. Mais souvent, quand le site est chargé, cette galerie n'est pas visible. Je n'ai pas non plus mis de vidéo sur SourceForge (mais cette option y existe chez eux).
        
        Je vais donc faire une autre galerie de photos, prochainement, dans la documentation du projet. Il faudrait aussi que je fasse une vidéo…
        
        Sinon, le meilleur moyen de voir à quoi ressemble cette interface utilisateur est de compiler mon logiciel. C'est vraiment pas la mort : il suffit de suivre les indications du README !
        
        [^] # Re: Fortran 2008
        
        Posté par barmic le 27 juillet 2014 à 22:41. Évalué à 4.
        
        En statique on peut faire pleins de choses qu'on ne peut pas faire en dynamique.
        
        Comme quoi par exemple ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Fortran 2008
        
        Posté par Zylabon le 28 juillet 2014 à 10:25. Évalué à 2.
        
        Comme quoi par exemple ?
        
        Des pages portables, sans bug, script friendly… ?
        
        (sérieusement, j'ai eu la même pensée que toi, ça m'a fait rire)
        
        Please do not feed the trolls
        
        [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 28 juillet 2014 à 12:01. Évalué à 3.
        
        Comme quoi par exemple ?
        
        En statique, il n'y a pas de contrainte de temps pour générer les pages. Si l'on s'en fiche de mettre 1 minute pour générer les 100 billets avec un moteur de blog qui tourne sous bash (comme NanoBlogger), on peut fignoler ses pages avec des logiciels tiers (par ex. l'utilitaire "cal" pour avoir un calendrier).
        
        La même chose, en dynamique, imposerait d'avoir ces logiciels tiers installés sur le serveur en plus de la base de données et ça entraînerait un ralentissement dans la fabrication des pages générées à la volée.
        
        En statique, il n'y aucune obligation à ce que les pages soient fabriquées sur le serveur. Donc, on peut les faire sur sa machine chez soi tranquillement puis les uploader chez son hébergeur. En dynamique, si le site est hébergé sur un serveur dont on n'a que peu de contrôle, il est difficile de peaufiner ses pages. Le plus souvent, la personnalisation se limitera aux plugins qui sont livrées avec le CMS.
        
        [^] # Re: Fortran 2008
        
        Posté par barmic le 28 juillet 2014 à 14:10. Évalué à 3.
        
        En statique, il n'y a pas de contrainte de temps pour générer les pages. Si l'on s'en fiche de mettre 1 minute pour générer les 100 billets avec un moteur de blog qui tourne sous bash (comme NanoBlogger), on peut fignoler ses pages avec des logiciels tiers (par ex. l'utilitaire "cal" pour avoir un calendrier).
        
        Ça n'a rien avoir avec le fait que ce soit dynamique, c'est le fait que ce soit synchrone qui l'en empêche. On peut très bien faire des sites web asynchrones).
        
        La même chose, en dynamique, imposerait d'avoir ces logiciels tiers installés sur le serveur en plus de la base de données et ça entraînerait un ralentissement dans la fabrication des pages générées à la volée.
        
        Oui/non, ce n'est pas nécessaire, mais c'est compliqué (pour un petit site de faire des actions sur divers serveurs).
        
        En statique, il n'y aucune obligation à ce que les pages soient fabriquées sur le serveur. Donc, on peut les faire sur sa machine chez soi tranquillement puis les uploader chez son hébergeur. En dynamique, si le site est hébergé sur un serveur dont on n'a que peu de contrôle, il est difficile de peaufiner ses pages. Le plus souvent, la personnalisation se limitera aux plugins qui sont livrées avec le CMS.
        
        Si par fignoler tes pages, tu parle de reprendre à la main tes pages, tu n'es plus vraiment dans le moteur de blog statique. C'est très long à faire et relativement peu intéressant (il y a peu voir pas) de "fignolage" qui ne peut s'automatiser.
        
        Après faut pas non plus avancer des choses pour le principe. La contrainte de temps est très faible. Il faudrait faire des actions vraiment lourdes (compilation un peu grosse par exemple) pour que ça ai une vrai importance. Chose que tu ne peux pas faire en statique par définition (il t'est impossible de réagir à une action du client). Pour ce qui est de la forte charge, l'énorme majorité des gens qui utilisent un générateur de site statiques ont très peu de charge.
        
        Comprends bien que je ne dis pas que ça n'a pas d'intérêt, au contraire. Les moteurs de sites statiques sont simples et s'hébergent facilement notamment sur github.io.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 28 juillet 2014 à 17:17. Évalué à 1.
        
        Si par fignoler tes pages, tu parle de reprendre à la main tes pages, tu n'es plus vraiment dans le moteur de blog statique. C'est très long à faire et relativement peu intéressant (il y a peu voir pas) de "fignolage" qui ne peut s'automatiser.
        
        Non non, je ne parlais pas de fignolage manuel mais automatisé. Le fond de ma pensée est que, généralement, les moteurs de CMS/blog statiques sont bricolables plus aisément que ceux des CMS/blog dynamiques. Ces derniers nécessitent un plus haut niveau de compétence (ou plus de temps) pour créer le nouveau plugin qui va bien. Et, là encore en généralisant, lesdits plugins sont souvent faits par des tiers et accompagnés de leur propre feuille de style. Il n'est pas rare de voir des sites faits avec des CMS populaires traînant une dizaine de CSS (ou des polices) piochées de droite à gauche et mettant un temps fou à s'afficher.
        
        Dans l'absolu, je suis d'accord pour dire qu'il n'y a pas de différence de lag perceptible entre un bon site dynamique ou un bon site statique. Mais la pratique montre que bien des sites générés dynamiquement sont bien trop lents car surchargés de tout un tas de gadgets.
        
        [^] # Re: Fortran 2008
        
        Posté par keyser.dyson le 28 juillet 2014 à 18:23. Évalué à 0.
        
        Dans une page de "Liens", je faisais une capture d'écran des sites (avec URL2BMP à l'époque, sous windows).
        
        Mes pages était écrite dans un style entre markdown et wiki. Les mots entre crochets étaient clicquables. Le moteur cherchait la page la plus adéquate par rapport au mot.
        
        Je me suis amusé avec les fonctions de comparaisons de chaines de caractères style levenstein en PHP.
    - [^] # Re: Fortran 2008
      
      Posté par lasher le 25 juillet 2014 à 23:51. Évalué à 3.
      
      Hum. Autant je suis d'accord pour dire que la plupart des gens ont Fortran 66 ou Fortran 77 en tête lorsqu'ils parlent du langage, autant mon expérience (limitée, je l'admets) a été que oui, les codes qu'on me donnait à optimiser étaient faits en F77 ou F90. Pas de F95, et certainement pas F03 (F08 ne compte pas, vu qu'à l'époque j'étais en 2è année de thèse :)).
      
      Je suis certain que tout un tas de gens utilisent F95 ou même F03 dans les milieux du calcul scientifique, mais je n'en entendais pas parler (j'ai bossé avec des gens du CEA, de Dassault Aviation, et des boites allemandes). Par contre c'est sans doute lié à ce que je devais optimiser : les primitives de calcul en algèbre linéaire, des solveurs itératifs, etc.
      - [^] # Re: Fortran 2008
        
        Posté par Denis Bernard (site web personnel) le 26 juillet 2014 à 00:25. Évalué à 2.
        
        Une manière de voir l'évolution du langage Fortran à travers les âges est d'aller sur la page des cours de l'IDRIS.
        
        Par exemple, le cours "Fortran : apports de la norme Fortran 2003" donne une bonne idée du chemin parcouru depuis Fortran 77 ! Mais, attention, les exemples donnés ne sont pas tous exécutables avec le compilo libre gfortran (qui n'implémente pas encore la totalité de la norme 2003) ; mais avec le compilateur Intel, ça tourne.
        
        En matière d'optimisation, je n'ai pas le niveau pour en parler. Mais ce que je sais, c'est qu'avec gfortran qui est intégré dans gcc, il y a pas mal d'options de compilation. Et il y a aussi les mêmes outils de débogage que pour le langage C. Je sais que pour le compilo Intel il y a un profiler.
        
        J'insiste, vraiment, sur le fait que le langage Fortran évolue à toute vitesse actuellement ; et aussi gfortran.
# Le bon bash des familles

Posté par Anonyme le 23 juillet 2014 à 00:03. Évalué à 4. Dernière modification le 23 juillet 2014 à 00:07.

Personnellement, j'ai débuté la programmation en faisant des scripts bash tout connement.

L'avantage du bash étant qu'il permet de découvrir simplement les principes de programmations (variables, conditions, boucles, etc), tout en permettant de faire rapidement des choses très cool en s'interfaçant avec toute les applications en cli (j'ai appris la programmation en codant un serveur d'encodage vidéo pour mon téléphone portable de l'époque, et j'avais l'impression d'avoir fait un truc hyper classe, et je trouve ça vachement plus motivant que faire des write(1, "Hello World", strlen("Hello World"));.

Le bash a une syntaxe imbuvable, mais ce n'est justement pas un gros problème lorsqu'on débute vu qu'on a pas de référant et qu'on s'en accommode assez bien au final.

Ensuite, le php a quelque chose de bien que sa syntaxe est proche du C et qu'il permet d'aborder l'objet. Il est du coup plus simple de passer au C si on souhaite évoluer vers un langage plus bas niveau.

Je fais du python en ce moment, j'ai un peu l'impression que ce langage à le même effet que certains basic chez leurs utilisateurs, ils ont du mal à s'en passer et à aller vers autre chose (et quand ils le font, on les entends souvent râler que python ça serait mieux pour faire ci ou ça).
- [^] # Re: Le bon bash des familles
  
  Posté par lasher le 23 juillet 2014 à 00:55. Évalué à 9.
  
  Je trouve que bash est un très mauvais choix pour faire apprendre la programmation structurée aux étudiants. Il ne faut pas oublier qu'on essaie de leur inculquer quelques principes de base, comme la notion de portée des variables, etc. Et bash est très pénible pour ça.
  - [^] # Re: Le bon bash des familles
    
    Posté par Anonyme le 26 juillet 2014 à 11:39. Évalué à 1.
    
    Mon point de vue était surtout une approche auto-didacte. C'est certain qu'avec des étudiants, il vaut sans doute mieux avoir une approche plus pragmatique, mais je pense que c'est une introduction pertinente pour des enfants par exemple, ils peuvent tout de suite s'amuser à faire des choses concrète qu'un langage plus classique ne permettrait pas de faire.
- [^] # Re: Le bon bash des familles
  
  Posté par lolop (site web personnel) le 23 juillet 2014 à 08:22. Évalué à 3.
  
  ils ont du mal à s'en passer et à aller vers autre chose (et quand ils le font, on les entends souvent râler que python ça serait mieux pour faire ci ou ça).
  
  Est-ce toujours faux ?
  
  Je passe du Python au C++, et je râle parfois. Par exemple j'aimerais bien retrouver la séparation byte/unicode de Python3 dans le C++ avec un type chaîne correct. Par contre je suis heureux des dernières modifs dans la syntaxe du C++: les auto, les boucles for (x: collection), combinés aux conteneurs stl on retrouve de la programmation sympa.
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Le bon bash des familles
    
    Posté par David Demelier (site web personnel) le 23 juillet 2014 à 08:46. Évalué à 1. Dernière modification le 23 juillet 2014 à 08:49.
    Par exemple j'aimerais bien retrouver la séparation byte/unicode de Python3 dans le C++ avec un type chaîne correct.
    
    Tu veux dire std::u32string ?
    
    Et aussi std::codecvt_utf8 ?
    
    Pour ma part, j'utilise ce code pour faire la conversion UTF-8 UCS-4
```
#include <string>
#include <codecvt>

std::string toUTF8(const std::u32string &s)
{
        std::wstring_convert<std::codecvt_utf8<char32_t>, char32_t> cv;

        return cv.to_bytes(s);
}

std::u32string toUCS4(const std::string &s)
{
        std::wstring_convert<std::codecvt_utf8<char32_t>, char32_t> cv;

        return cv.from_bytes(s);
}

int main(void)
{
    return 0;
}
```
    git is great because linus did it, mercurial is better because he didn't
    - [^] # Re: Le bon bash des familles
      
      Posté par David Demelier (site web personnel) le 23 juillet 2014 à 09:05. Évalué à 1.
      
      EDIT: avec clang il faudra peut-être rajouter l'entête locale aussi.
      
      git is great because linus did it, mercurial is better because he didn't
    - [^] # Re: Le bon bash des familles
      
      Posté par Zenitram (site web personnel) le 23 juillet 2014 à 09:26. Évalué à 1. Dernière modification le 23 juillet 2014 à 09:27.
      
      Par exemple j'aimerais bien retrouver la séparation byte/unicode de Python3 dans le C++ avec un type chaîne correct.
      
      Tu veux dire std::u32string ?
      Et aussi std::codecvt_utf8 ?
      
      Tes deux exemples ne sont pas du C++ "courant" (qu'on est sûr de retrouver sur tout compilateur C++), car ils viennent de la dernière version de la norme…
      C'est un peu gros d' "oublier" de dire que ce que tu proposes n'est pas vraiment connu ni utilisable car pas dispo partout.
      
      PS : et puis, même pour moi qui ne fait quasiment que du C++, les noms sont moches et inretenables quand même… On ne peut pas dire que C++ aide à la comprehension, c'est quand même élitiste. Tu l'admets implicitement toi-même en trouvant nécessaire de devoir encapsuler le bousin dans des fonctions.
      - [^] # Re: Le bon bash des familles
        
        Posté par zul (site web personnel) le 23 juillet 2014 à 09:42. Évalué à 4.
        
        Oui enfin la séparation byte/unicode de Python3, bah c'est du Python3. Et comme dans plein d'endroits, on est bloqué par l'écosystème et on fait du Python2, bah tu es bien avancé.
        
        En l'occurence, même Visual Studio (2013) supporte ça donc c'est globalement moins un problème que Python.
        
        [^] # Re: Le bon bash des familles
        
        Posté par Zenitram (site web personnel) le 23 juillet 2014 à 09:46. Évalué à 4. Dernière modification le 23 juillet 2014 à 09:50.
        
        Oui enfin la séparation byte/unicode de Python3, bah c'est du Python3.
        
        J'ai lu "de Python3 dans le C++", et non pas "de Python dans le C++" ni "de Python3 dans le C++11"…
        
        En l'occurence, même Visual Studio (2013) supporte ça
        
        Je dois être unique, j'ai plein d'utilisateurs qui sont dans de veilles version de compilateur ou dont le matos est trop limité, déjà je suis heureux quand les wstrings sont présentes et fonctionnelles. Bon, certes, je ne m'amuserai alors pas à mettre Python3 sur ces machines ;-).
        
        Bref, il faut quand même savoir de quand c'est fait, quand j'ai lu sa phrase je me suis dit "oups j'ai loupé quelque chose", mais en fait non, je ne fais pas de C++11 mais du C++ (qu'on assimile plutôt à C++03 en 2014), je préviens juste que c'est trompeur.
        
        [^] # Re: Le bon bash des familles
        
        Posté par zul (site web personnel) le 23 juillet 2014 à 09:57. Évalué à 3.
        
        Dans mon monde à moi, on est plutôt à commencer à jouer avec les features de C++14. Mais bon, c'est sûr, clang / gcc c'est pas cher, ça ne doit pas être un outil très pro.
        
        Je dois être unique, j'ai plein d'utilisateurs qui sont dans de veilles version de compilateur ou dont le matos est trop limité,
        
        Non, je sais très bien que tu n'es pas unique (à utiliser des versions anti diluviennes de compilateur). Par contre, pour le "matos trop limité", il dit qu'il ne voit pas le rapport, C++11 ça ne prend pas plus de ressources à l'execution (et potentiellement un peu moins à la compilation sur certains projets (variadic templates vs preprocessed templates par exemple))
        
        [^] # Re: Le bon bash des familles
        
        Posté par lolop (site web personnel) le 23 juillet 2014 à 16:58. Évalué à 4.
        
        Si tu es en apprentissage, tu choisis Python3 sans problème d'écosystème.
        
        Et ensuite sbinaire.decode('utf-8'), et s.encode('utf-8'). simple. Et pour les fichiers, en spécifiant le paramètre encoding='utf-8' à l'ouverture, les opérations d'encodage/décodage sont automatiques.
        
        C++ s'est bien amélioré (et merci pour les pistes que tu donnes… elles me seront utiles), mais pour un premier langage, il y a encore une grande marge.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Le bon bash des familles
        
        Posté par David Demelier (site web personnel) le 23 juillet 2014 à 10:03. Évalué à 1.
        
        Tes deux exemples ne sont pas du C++ "courant" (qu'on est sûr de retrouver sur tout compilateur C++), car ils viennent de la dernière version de la norme…
        C'est un peu gros d' "oublier" de dire que ce que tu proposes n'est pas vraiment connu ni utilisable car pas dispo partout.
        
        Ça c'est ton problème si tu souhaites vivre dans le passé. Même VisualStudio 2012 accepte ce code (qui pourtant supporte très mal C++11).
        
        Moi personnellement, j'utilise les nouvelles technologies au maximum, et tant pis pour ceux qui supportent pas encore ça. Je ne suis pas un dinosaure :-).
        
        git is great because linus did it, mercurial is better because he didn't
    - [^] # Re: Le bon bash des familles
      
      Posté par keyser.dyson le 25 juillet 2014 à 20:57. Évalué à -2.
      
      Retour par valeur. Pas bon.
    - [^] # Re: Le bon bash des familles
      
      Posté par keyser.dyson le 28 juillet 2014 à 18:33. Évalué à 0.
      
      Je fais ça avec iconv():
      
      http://man7.org/linux/man-pages/man3/iconv.3.html
- [^] # Re: Le bon bash des familles
  
  Posté par Michaël (site web personnel) le 23 juillet 2014 à 23:49. Évalué à 1.
  Personnellement, j'ai débuté la programmation en faisant des scripts bash tout connement.
  
  C'est une recommendation originale, mais elle a plusieurs mérites:
  1. Transformer une ligne de commande en programme shell est super facile: il suffit de la retranscrire dans un fichier. Donc on apprend à programmer en disposant déjà d'un riche vocabulaire de fonctions élémentaires et on peut se concentrer sur la structure.
  2. Au passage on apprend à utiliser inteligemment son ordinateur en automatisant des traitements que l'on faisait pas à pas, et c'est une perspective qui manque à un très grand nombre de programmeurs…
  Je plussoie des deux mains!
  - [^] # Re: Le bon bash des familles
    
    Posté par Antoine le 24 juillet 2014 à 01:20. Évalué à 1.
    
    Transformer une ligne de commande en programme shell est super facile: il suffit de la retranscrire dans un fichier. Donc on apprend à programmer en disposant déjà d'un riche vocabulaire de fonctions élémentaires et on peut se concentrer sur la structure.
    
    Ça présuppose qu'on apprenne à programmer à des Unixiens barbus qui utilisent couramment la ligne de commande…
    (et ça devient cocasse quand certains de tes élèves sont habitués à zsh ou je ne sais quelle autre variation)
    - [^] # Re: Le bon bash des familles
      
      Posté par Michaël (site web personnel) le 24 juillet 2014 à 14:18. Évalué à 2.
      
      Ça présuppose qu'on apprenne à programmer à des Unixiens barbus qui utilisent couramment la ligne de commande…
      
      Ou bien ça suppose qu'on leur apprenne aussi la ligne de commande, genre au semestre d'avant.
      
      (et ça devient cocasse quand certains de tes élèves sont habitués à zsh ou je ne sais quelle autre variation)
      
      Donc c'est assez invraisemblable que les élèves s'intéressent à la ligne de commande mais s'il y en a, alors très certainement l'un fait du zsh? Cool!
  - [^] # Re: Le bon bash des familles
    
    Posté par keyser.dyson le 25 juillet 2014 à 21:01. Évalué à 0.
    Un script que j'ai fait hier
```
now=$(date +"toto)
```
    Faut mettre un balnc entre "date" et "+" car date est une commande.
    
    C'est pas terrible pour expliquer la programmtion.
    
    Je comprends l'aspect "disponibilité" que tu mets en avant.
# Pas de "bonne" réponse

Posté par Maclag le 23 juillet 2014 à 09:05. Évalué à 6.

Je ne crois pas qu'il y ait de bonne réponse. Tous les langages ont leurs spécificités, et tu ne peux pas tout voir en même temps.

L'idéal ce serait d'en voir plusieurs, et laisser les élèves choisir celui ou ceux qu'ils préfèrent.

Cas personnel: cycle ingé avec cours d'info en tronc commun (je ne suis pas et ne souhaitais pas partir vers l'info).

On avait des cours d'algorithmie en pseudo-langage. On implémentait en Pascal. J'aimais pas le Pascal: tous les cours m'ont semblé chiant à mourir.

Ensuite on a eu une initiation au C. Je n'aime pas le C: allouer la mémoire, surveiller les possibles dépassements, libérer la mémoire. J'ai l'impression que ce truc est fait pour qu'on fasse des boulettes. Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur, j'ai l'impression qu'il faut toujours beaucoup d'expérience pour ne pas écrire du code de merde. Trop de choses à surveiller et à retenir. Toujours est-il que ça ne m'a pas intéressé d'avantage à la programmation.

Mais je me suis toujours dit qu'un bon électronicien devait savoir pondre un minimum de code, alors j'en ai regardé d'autres, des langages.

Un jour j'ai découvert l'OCaml par moi-même: j'ai trouvé ça formidable. Rigoureux, puissant, bref: formidable, quoi. Puis je me suis rendu compte que c'était peu répandu, et que ça ne serait pas LE langage que j'apprendrais qui me servirait à tout et n'importe quoi (pas de lib pour ci, pas de binding pour ça, etc.). Alors j'ai laissé tomber aussi (snif!).

J'ai fait un tuto pour Python, qui comparé à OCaml me donnait une impression de manque de rigueur, mais Python, c'est un peu le truc tout-terrain: y'a des libs pour tout, des bindings pour tout, et on le retrouve du calcul lourd (numpy) au solutions de dév Android (j'ai vu des slides sur Pyotherside, ça a l'air prometteur).
Du coup voilà: je sais écrire des trucs simples en Python, mais si on m'avait fait des cours d'info en Python, j'aurais peut-être pas aimé non plus.

(Ah, je passe un apprentissage éclair de R pour un besoin précis, mais disons que R est un cas particulier).

Conclusion: faites en sorte que les élèves puissent essayer quelques langages différents le plus vite possible. Si le(s) prof(s) en connaissent plusieurs, pourquoi ne pas leur faire des séances découvertes de chaque avant de les laisser en choisir un individuellement pour les travaux pratiques?
C'est peut-être plus lourd, mais ça permettra peut-être aussi de couvrir plus de notions en comparant les approches et méthodes dans des séances de groupe.
- [^] # Re: Pas de "bonne" réponse
  
  Posté par Dr BG le 23 juillet 2014 à 09:23. Évalué à 4. Dernière modification le 23 juillet 2014 à 09:24.
  
  C'est déjà pas évident de les initier à un langage, alors plusieurs en même temps qu'ils apprennent les bases de l'algorithmique ça me paraît difficile.
  
  Généralement, au tout début, le but n'est pas d'apprendre un langage, mais de pouvoir mettre en pratique les algos. Donc il faut un truc simple (qui n'apporte pas de complication technique ou n'impose pas d'introduire d'autres concepts que ceux vus en algo) et il n'y a pas besoin de bibliothèque au début (vu que c'est à eux de tout faire).
  
  Mais il est effectivement intéressant de passer par plusieurs langages. En première année de fac, j'ai fait du Pascal au premier semestre, puis du Caml au second. Puis j'ai vu d'autres langages les années suivantes (C, C++, Java, Prolog, Eiffel…).
- [^] # Re: Pas de "bonne" réponse
  
  Posté par Renault (site web personnel) le 23 juillet 2014 à 09:47. Évalué à 2.
  
  Ensuite on a eu une initiation au C. Je n'aime pas le C: allouer la mémoire, surveiller les possibles dépassements, libérer la mémoire. J'ai l'impression que ce truc est fait pour qu'on fasse des boulettes. Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur, j'ai l'impression qu'il faut toujours beaucoup d'expérience pour ne pas écrire du code de merde. Trop de choses à surveiller et à retenir. Toujours est-il que ça ne m'a pas intéressé d'avantage à la programmation.
  Mais je me suis toujours dit qu'un bon électronicien devait savoir pondre un minimum de code, alors j'en ai regardé d'autres, des langages.
  
  Justement, tout dépend aussi du domaine.
  Si ta formation est orientée électronique, systèmes embarqués ou encore informatique industrielle le langage C et l'assembleur seront incontournables. Si la formation est orientée multimédia, développement Web ou encore serveurs d'applications il est clair que Python, Java, C++, JS et autres seront plus adaptés et incontournables.
  
  Il faut donc tenir compte de ça.
- [^] # Re: Pas de "bonne" réponse
  
  Posté par fearan le 23 juillet 2014 à 10:11. Évalué à 5.
  Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur,
  
  Au contraire, je l'imposerai a quiconque souhaitant devenir un gros programmeur, pas forcément pour l'utiliser en entreprise, mais j'en ai mare de voire des gens coder comme si la ram était infinie, ça marche bien sur les 2 jours de test, c'est validé en recette, puis dès qu'il y a un usage intensif, y a du java heap space ou autre erreur disant qu'il y a plus de mémoire (ou l'appli qui se fige en attendant que le ramasse miette récupère un peu de place).
  
  Le C (avec malloc et free), demande juste un peu de rigueur :
  - tu écris un malloc() => tu écris le qui va avec free(), et si tu ne le fais pas tu commente pour dire que l'ownership passe à telle fonction
  - tu récupères un pointeur ? as tu l'ownership dessus (=> free)
  - tu utilises un tableau combien de cases as tu besoins
  - tu fais une boucle quels sont les conditions / cas de sorties
  - …
  Bref la plus grande partie des écueils du C, soulèvent généralement une question qu'il est pertinente de se poser, et qu'il faut généralement se poser avant de prendre le clavier. Je croise bien trop souvent du code où ça a été écrit sans la partie réflexion avant, et où il y a verrue sur verrue pour adapter le code aux nouvelles demandes, alors qu'une écriture pensée, propre à l'origine n'aurait eu besoin que d'extensions.
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Pas de "bonne" réponse
    
    Posté par Thomas Douillard le 23 juillet 2014 à 11:03. Évalué à 2.
    
    Ben déja tu parles d'écrire des applis avec une grosse durée de vie et du trafic à l'utilisation, on est très loin de toucher à terme toutes les personnes qui vont subir des TPs de programmation au cours de leur cursus estudiantin.
    
    En plus tu noteras qu'ils ont un spécialiste d'optimisation de la JVM comme toi qui vont repasser derrière eux pour leur expliquer des trucs sur la gestion mémoire, donc là on est dans un environnement de techos plutôt pas mal organisé ou on a les moyens d'avoir une division des taches et des personnes aux compétences assez variées en informatique, donc tout le monde n'a pas besoin d'être expert en gestion mémoire.
    
    comme disait l'autre ''premature optimisation is the root of all evil'', si on parle d'apprendre les bases de la programmation, oui l'appentissage de comment écrire du code pour que la JVM puisse se débrouiller correctement avec en fonction du type d'appli que tu vas écrire est une premature optimisation qui va passer à des kilomètres de l'étudiant(e) qui va dans la plupart des cas subir le cours.
    - [^] # Re: Pas de "bonne" réponse
      
      Posté par fearan le 23 juillet 2014 à 13:26. Évalué à 3.
      
      Non la bonne conception est la base de toutes programmations, c'est un réflexe qu'il faut prendre dès le début. Ce n'est pas un problème d'optimisation, mais un problème général. Typiquement tu vas avoir un Set de session (ou une Liste) qui va stocker la collection de sessions, et en crée une à chaque nouvelle ouverture de sessions.
      
      Tu vois le problème? quelque soit les optimisations, tu finiras toujours par avoir un java heap space. Qui code en java et connait les java.lang.ref.WeakReference ? J'ai trop vu de personne penser que le ramasse miette était un outils formidable capable de deviner quand un objet ne sera plus référencé.
      
      Ce n'est pas une optimisation, je ne parles pas de grappillage d'un octet par ci par la, mais d'avoir une notion de qui possède quoi, quand créer quoi, quand détruire, attendre avant de le faire revient à dire jamais, les mauvaises habitudes restent.
      
      si on parle d'apprendre les bases de la programmation, oui l'appentissage de comment écrire du code pour que la JVM puisse se débrouiller correctement avec en fonction du type d'appli que tu vas écrire est une premature optimisation
      
      Non on parle de réflexes de programmation, de question à se poser avant même de coder, et ce quel que soit le langage, j'ai pris java heap space comme exemple, par ce que c'est ce a quoi j'ai été confronté plusieurs fois, mais j'ai eu la blague de plus de mémoire dispo sous python, de memory leak en C, C++… Il ne s'agit pas de politique spécifique de code (si pour toi faut attendre de plus avoir de mémoire pour se poser la question de l'appartenance des variables, j'espère ne jamais tomber sur ton code, ça doit ressembler un un plat de spaghetti)
      
      L'énorme avantage du C++, c'est que tu peux prédire lorsqu'un destructeur sera appelé, et tu peux suivre la séquence à l'aide de printf debugging.
      
      Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # Re: Pas de "bonne" réponse
        
        Posté par barmic le 23 juillet 2014 à 14:24. Évalué à 7.
        
        L'énorme avantage du C++, c'est que tu peux prédire lorsqu'un destructeur sera appelé, et tu peux suivre la séquence à l'aide de printf debugging.
        
        Il y a surtout 750 façon de gérer sa mémoire en C++ et un certain nombre de façon de se retrouver dans des cas indéfini quand tu as un mélange des genres.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 23 juillet 2014 à 15:04. Évalué à 2.
        
        Il y a surtout 750 façon de gérer sa mémoire en C++
        
        Ah? je suis curieux de voir l'énumération ;), et surtout dans quel cas tu te retrouves avec un mélange des genre lors de cours.
        
        Pour avoir fait pas mal de C++, et continuer à en faire tous les jours ouvrés, je n'ai pas vu de mélange des genre que tu évoques. Si tu parles des différentes façons d'implémenter l'operator new, j'ose espérer que le gars qui se permet de le faire sait ce qu'il fait, si c'est le mélange de shared_ptr (et leur contrepartie weak_ptr), auto_ptr, uniq_ptr, pointeur, référence, tu arrives toujours aux mêmes questions, et ce quel que soit le langage :
        * A qui appartient l'objet? (fait il bien le delete ?)
        * d'où vient il ? si c'est d'un autre objet/bibliothèque (via make, creat…), y'a t'il un transfert de propriété ?
        
        Ça fait 9 ans que je fais du C++ en milieu professionnel, je n'ai jamais eu de problème la dessus, et maintenant qu'on a les uniq_ptr et shared_ptr dans la stl, c'est encore plus simple.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par barmic le 23 juillet 2014 à 15:23. Évalué à 3.
        
        J'ai pas dis que ça n'était pas contournable, j'ai dis qu'il existe trop de solution.
        
        j'ose espérer que le gars qui se permet de le faire sait ce qu'il fait
        
        Justement on est entrain de parler de personne qui ne sait pas ce qu'il fait. Qui va potentiellement faire du free parce que c'est ce qu'il a vu qui marchait dans les exemples de la bibliothèque C qu'il essaie d'utiliser, de quelqu'un qui va voir en cours des méthodes pour ne jamais écrire de new/delete en cours et qui va trouver sur internet des exemples qui font le contraire parce que post C++11, etc.
        
        Ça fait 9 ans que je fais du C++ en milieu professionnel[…]
        
        Tu t'es pommé on est pas en milieu pro, mais en milieu universitaire. Quand tu apprend à cuisiner tu t'entraine un peu avec du poulet de batterie avant d'essayer de cuisiner du poulet de Bresse.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 23 juillet 2014 à 19:20. Évalué à 2.
        
        J'ai appris le C++ en IUT, et je n'ai pas vu les catastrophes que tu décris, j'ajouterai que pour les projet universitaire, il y a valgrind qui est plus que suffisant pour pointer les boulettes (ça marche aussi en milieu pro, mais faut pas être pressé ;) )
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par keyser.dyson le 27 juillet 2014 à 19:51. Évalué à 1.
        
        J'ai rajouté ça hier dans mes scripts de debugage:
        
        valgrind --leak-check=full --track-origins=no --undef-value-errors=no
        
        C'est juste pour savoir si il y a des leak ou pas.
        Ca booste carrément plus.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par lasher le 23 juillet 2014 à 22:11. Évalué à 4.
        
        Justement on est entrain de parler de personne qui ne sait pas ce qu'il fait.
        
        Non, on est en train de parler de gens qui sont débutants. Débutant ≠ débile. Évidemment les étudiants vont faire des erreurs, mais la plupart du temps il s'agit d'erreurs effectuées dans le cadre du sous-ensemble du langage utilisé pour les TP et projets.
        
        En IUT, mes profs d'algo/prog avaient surtout en horreur les gens qui « avaient déjà trop fait d'informatique ». :-) Parce qu'on avait des automatismes pas forcément géniaux. Par contre, aucun élève n'était pénalisé pour avoir utilisé des portions de langage qui n'avaient pas encore été vus en cours (mais se prenaient des remarques quand leur utilisation complexifiait la solution). C'est un peu comme en maths : si tu utilises une démonstration différente de celle du cours (car tu passes par des théorèmes/sous-démos différentes), mais qu'elle est correcte, un prof ne peut pas te pénaliser pour ça, mais peut commenter sur la complexité de la solution.
        
        Qui va potentiellement faire du free parce que c'est ce qu'il a vu qui marchait dans les exemples de la bibliothèque C qu'il essaie d'utiliser, de quelqu'un qui va voir en cours des méthodes pour ne jamais écrire de new/delete en cours et qui va trouver sur internet des exemples qui font le contraire parce que post C++11, etc.
        
        Juste un truc : c'est aussi pour ça qu'il y a des profs et chargés de TD : pour bien répéter à l'infini aux élèves qu'il faut utiliser new/delete lors des allocation dynamiques (une fois qu'on leur a appris ce que c'était). Lorsque j'apprenais le C, un de nos profs avait comme manie de nous répéter « mallocons, mallocons, freeons, freeon ! ».
        
        Si un élève commence à se ramener avec un code qui contient des malloc et des free dans un exercice noté ou un projet, ben on pénalise l'élève, car il a certes pris l'initiative de lire et reprendre du code pour résoudre une partie d'un programme à réaliser, mais il n'a pas été suffisamment rigoureux pour se demander ce que faisait le code ou même pourquoi les ordres d'allocation utilisaient un vocabulaire différent.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par barmic le 24 juillet 2014 à 00:41. Évalué à 2.
        
        pour bien répéter à l'infini aux élèves qu'il faut utiliser new/delete lors des allocation dynamiques (une fois qu'on leur a appris ce que c'était)
        
        Sauf que ce n'est presque plus le cas depuis C++11 et ce ne sera plus du tout le cas dès C++14.
        Comme quoi, oui, il y a au moins 4 niveau d'allocation dynamique de mémoire en C++ : *alloc/free, new/delete, RIIA et pointeurs intelligents. Beaucoup de ressources et de prof parlent du deuxième et un peu du 4ème niveau. C'est rare de parler de RIIA et les pointeurs intelligents sont surtout décris grâce à boost.
        
        Si un élève commence à se ramener avec un code qui contient des malloc et des free dans un exercice noté ou un projet, ben on pénalise l'élève, car il a certes pris l'initiative de lire et reprendre du code pour résoudre une partie d'un programme à réaliser, mais il n'a pas été suffisamment rigoureux pour se demander ce que faisait le code ou même pourquoi les ordres d'allocation utilisaient un vocabulaire différent.
        
        Ça c'est bien idiot et ça montre bien que ce qui est noté ce n'est pas la réflexion. On parle d'apprendre à gérer correctement la mémoire. Ce qu'il faut c'est résoudre la question de l'allocation et de la libération. Si l'étudiant utilise malloc/free n'est pas un problème tant que c'est cohérent dans son programme.
        
        Personnellement je trouve qu'il y a une trop grande focalisation sur la mémoire. Il faut utiliser le sacro saint RIAA ou pointeur intelligent et on tape sur les doigts de quiconque oserait faire autre chose, alors qu'il faudrait ouvrir les choses et dire qu'il n'y a pas que la mémoire qui touche à ces aspects allocation/libération les pools de thread par exemple, les pools de connexion, les API de bases de données, la gestion d'un cache,… A force de trop se focaliser sur la gestion de la mémoire direct, on crée des armées de développeurs qui pensent que même si les perf sont pas au rendez-vous et que ça prend plus de mémoire, il n'y a pas de possibilité d'avoir de fuite mémoire dès qu'il y a un gc.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par lasher le 24 juillet 2014 à 19:59. Évalué à 4.
        
        [à propos des allocations dynamiques] Sauf que ce n'est presque plus le cas depuis C++11 et ce ne sera plus du tout le cas dès C++14.
        
        C'est faux. Le monde n'arrêtera pas d'utiliser new/delete juste parce qu'une nouvelle norme sort. J'ai appris le C alors que ça faisait déjà 3 ans que C99 était sorti. Tu penses bien qu'on m'a appris le C89, et que j'ai dû me mettre à jour tout seul. Il faut gérer l'existant (i.e. le maintenir) bien plus qu'on ne crée de nouveaux programmes.
        
        [à propos de code C mélangé à du code C++ par un élève] Ça c'est bien idiot et ça montre bien que ce qui est noté ce n'est pas la réflexion. On parle d'apprendre à gérer correctement la mémoire. Ce qu'il faut c'est résoudre la question de l'allocation et de la libération. Si l'étudiant utilise malloc/free n'est pas un problème tant que c'est cohérent dans son programme.
        
        Je ne vois pas en quoi c'est idiot. Qu'un élève trouve de l'inspiration dans du code ailleurs (quel que soit le langage), soit. Maintenant, l'allocation dynamique explicite en C++ se fait par new et delete/delete [], et pas par malloc/free. Si tu mélanges les deux, ce n'est pas simplement un mauvais style de programmation : tu risques aussi potentiellement de mettre en branle une mécanique complexe avec possiblement deux gestionnaires mémoire. Que new/delete se servent la plupart du temps de malloc/free en sous-main n'est pas requis par la norme à ma connaissance, et ne devrait pas être supposé. Donc je persiste, un étudiant qui n'est pas foutu d'adapter un algo « pur C » en utilisant les new/delete qui vont bien sera pénalisé.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par keyser.dyson le 27 juillet 2014 à 19:58. Évalué à 0.
        
        http://www.stroustrup.com/bs_faq2.html#malloc
      - [^] # Re: Pas de "bonne" réponse
        
        Posté par Michaël (site web personnel) le 23 juillet 2014 à 23:56. Évalué à 2.
        
        L'énorme avantage du C++, c'est que tu peux prédire lorsqu'un destructeur sera appelé, et tu peux suivre la séquence à l'aide de printf debugging.
        
        La possibilité de faire du déboguage à coups de printf? (Vive le C++, au passage!) Vu qu'un programme assez gros mets plusiurs minutes à linker je ne suis pas sûr que j'aie envie d'appeler ça un avantage!
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par lolop (site web personnel) le 24 juillet 2014 à 08:29. Évalué à 5.
        
        Quand tu apprends la programmation avec un premier langage, tu ne fais pas un "programme assez gros", mais plutôt plein de petits.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 24 juillet 2014 à 09:38. Évalué à 2.
        
        Le printf debugging c'est un style de debuggage que ce soit a coup d'echo, std::cout, System.out.println, print… Souvent considéré comme néfaste, car il change le code exécuté, rendant les erreurs aléatoires différente de l'exécution traditionnelle (ce qui généralement est une invocation à valgrind)
        
        Dans les autres méthode utilisés tu as le TAF (Try And Fail) qui consiste à tester différents paramétrage / ordonnancement / Majuscule/minuscule, qui est très pratique lorsque tu découvres des classes graphique peu ou mal documentées.
        
        Enfin plusieurs minutes a linker ? Je ne sais pas sur quelle brouette tu bosses, mais sur un code déjà compilé 1 fois, avec tous les .o le link sur un petit projet d'1,3 million de ligne est inférieur à la minute.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 14:15. Évalué à 2.
        
        Souvent considéré comme néfaste, car il change le code exécuté, rendant les erreurs aléatoires différente de l'exécution traditionnelle (ce qui généralement est une invocation à valgrind)
        
        Le plus gros défaut c'est surtout que le travail de test et de debugging est essentiellement détruit après que le bug soit corrigé, alors que d'autres méthodes de débiguages (test unitaires p.ex.) créent plus de valeur car ils ne sont pas éphémères.
        
        Enfin plusieurs minutes a linker ? Je ne sais pas sur quelle brouette tu bosses, mais sur un code déjà compilé 1 fois, avec tous les .o le link sur un petit projet d'1,3 million de ligne est inférieur à la minute.
        
        De mémoire il s'agit d'environ 4,5 millions de lignes de code. Le problème vient de VS 2008 qui utilise un cache pour l'incremental linking dont la taille est limitée par l'OS (à cause d'une sorte de mmap vraismeblablement) et cette taille de cache est allégrement dépassée par le projet. Chaque linking repart donc de zéro et ça dure effectivement une poignée de minutes.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 24 juillet 2014 à 14:20. Évalué à 6.
        
        ah pardon, j'avais oublié que certains codaient sur un OS pas prêt pour le travail ;)
        (oui bon j'ai 8H d'avance ;))
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 16:30. Évalué à 2.
        
        XP en l'occurence — le même que chez les clients — bon il faut être honnête et se souvenir que l'OS est sorti en 2001!
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par lolop (site web personnel) le 24 juillet 2014 à 14:28. Évalué à 1.
        
        Une poignée de minutes… j'avais un projet C++ qui mettait 1h15 a compiler compètement sous Visual Studio (Windows 3.x)… le passage des 486 aux premiers Pentiums (buggés) a permis de réduire ce temps à 15minutes — un plaisir.
        
        Et à l'époque la compilation partielle était tellement mal gérée qu'on repartait très souvent en une régénération complète, pendant 1h15.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 16:29. Évalué à 2.
        
        Une poignée de minutes…
        
        Pour l'édition de liens!
        
        La compilation complète dure bel et bien une cinquantaine de minutes sur un quad-core avec deux Go de RAM — à mon avis le HD n'est pas un foudre de guerre et le système de fichiers à fragmentation accélérée n'aide pas non plus aux bonnes performances!
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par keyser.dyson le 27 juillet 2014 à 20:14. Évalué à 3.
        
        C'est une des justifications de Go.
        
        Rob Pike en avait marre de lancer des compilations interminables.
        
        Il dit par exemple que [#include "stdio.h"] ouvre 1000 fichiers. Les macros de gardes dans les includes ont des effets très limités.
        
        On peut lire aussi les articles de l'auteur du langage D à ce sujet. Il a des raisons similaires. On ne peut pas réellement accélérer la compilation a cause des includes et des macros. N'importe quelle ligne peut être modifiée par une macro qui a sont tour peut modifier les includes…
        
        Depuis que j'ai lu ça, je ne compile plus qu'un fichier. J'ai un "main.cpp" qui inclut un ensemble d'arborescence de sources. C'est structuré.
        
        Ca parait fou mais c'est beaucoup plus efficace. Tout est en mémoire. La compilation est ultra-rapide. Pas de link autre que avec les librairies standards.
        
        Pas besoin de make non plus. Gros avantage.
        
        Je pense qu'il y a une limite à cause de la mémoire. Je ne l'ai pas encore atteinte.
      - [^] # Re: Pas de "bonne" réponse
        
        Posté par Thomas Douillard le 24 juillet 2014 à 10:56. Évalué à 2.
        
        Typiquement tu vas avoir un Set de session (ou une Liste) qui va stocker la collection de sessions, et en crée une à chaque nouvelle ouverture de sessions.
        
        Je crois que tu te rend pas compte que non, c'est un cas d'utilisation non typique des étudiants qui apprennent à programmer. Apprendre à utiliser les bonnes structures de données et les bons algos, c'est un module en soi. Plein d'étudiants devront avoir les bases suffisantes pour faire du traitement de données basique et faire un graphique à la fin.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 24 juillet 2014 à 11:42. Évalué à 1.
        
        Le problème n'est pas le choix de la structure ou d'algo, mais la non libération de la ressources (par exemple le supprimer du Set/List en java), c'est une problématique avec toutes les ressources, tout comme on apprends à faire un close après un open, c'est exactement le même mécanisme. J'ai pris cet exemple parce que j'y ai été confronté récemment, mais le problème est présent a tous les niveau (par exemple pas de close d'une connexion ftp, ou d'un fichier)
        
        Si j'ai bien suivi, le but n'est pas d'apprendre à bidouiller, mais a programmer. La contrainte de devoir gérer manuellement les ressources permet de structurer, éviter d'avoir une représentation du dieu des pastafariens en guise de doc d'architecture.
        
        Bref un fois que t'a passé le passage obligatoire pseudo code sur feuille (ou tu peux dire trier le tableau trucmuch dans l'ordre croissant), tu peux ensuite passer à l'implémentation avec un langage quelconque et si tu utilises une ressources (un fichier par exemple), il faut la libérer après usage. C'est un réflexe qui se prends dès la première utilisation de ressource et qu'il faut pas attendre d'avoir un gros projet pour se la poser, c'est trop tard, les mauvaises habitudes ont la vie dure.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par Thomas Douillard le 24 juillet 2014 à 12:23. Évalué à 3.
        
        C'est un réflexe qui se prends dès la première utilisation de ressource et qu'il faut pas attendre d'avoir un gros projet pour se la poser, c'est trop tard, les mauvaises habitudes ont la vie dure.
        
        Bof, c'est des réflexes qui sont très dépendants de l'utilisation que tu as de l'ordi, la notion de libération de ressource n'a pas forcément énormément de sens pour programmer une feuille Excel par exemple, et pour récupérer un fichier par FTP on va pas forcément à une personne qui a juste des bases de programmation de coder la gestion de la connexion et sa libération, on va lui file une fonction genre ''récupérer données'' de plus haut niveau ou une commande genre wget qui va elle même fermer la connexion. C'est évidemment une règle de base de se préoccuper des "ressources", mais c'est difficile de tirer des recettes à partir de ce principe général qui soit utiles dans un contexte d'apprentissage des bases de la programmation, c'est très dépendant de la VM (au sens large) qui va être utilisée par la suite, et ça peut aller de la feuille excel ou tu peux parler de malloc/free ou de close ça n'a aucun sens à la JVM pour les informaticiens ou les problématiques seront pas les mêmes à pleins d'autres trucs.
        
        [^] # Re: Pas de "bonne" réponse
        
        Posté par fearan le 24 juillet 2014 à 14:18. Évalué à 1.
        
        la question n'est pas d'apprendre spécifiquement une recette par langage, mais un réflexe de que faire avec la ressource une fois qu'elle est consommée, en Java (donc jvm) InputStream, tu es sensé faire un close après avoir lu le flux.
        Pareil en VB (donc Excel) : http://msdn.microsoft.com/en-us/library/system.io.filestream.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1.
        
        Et si algorithmiquement, c'est un point sans intérêt, lorsque l'on passe à la programmation cela fait parti de l'apprentissage du langage, que ce soit C, C++, Python, perl, Java, VB…
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Pas de "bonne" réponse
    
    Posté par Anon le 23 juillet 2014 à 11:46. Évalué à 6.
    
    Pour ajouter ma pierre à l'édifice, en tant que Technicien Supérieur fraichement diplômé, je peux apporté mon ressenti quant au choix fait par mes profs.
    
    Je sors d'une filière info pensée pour l'industrie, autant vous dire que l'on a pas privilégié le Javascript. Au début nous avions des cours d'algo en parallèle de cours de C++. Le coté fun de la chose, c'était créer des IHM dans notre IDE "tout pourri d'y il a 10 ans", mais surtout pas de se pencher sur le typage et autre joyeusetés qui nous étaient enseignées. Peu à peu on a commencé à faire des projets sympas, toujours avec pour fil rouge apprendre les bases comme les boucles, ou les structures/classes (rien que ces trois points ont fait ramer 75% de la classe pendant deux ans). J'en profite pour souligner que seuls ceux qui ont pris le temps de coder chez eux s'en sont sorti, la pratique permettant de ne pas rouiller et de trouver les limites de ce que l'on nous enseigne. En effet, je vois la démarche de nos profs comme une façon de nous inculquer quelque chose, tout en nous poussant à trouver ses limites, réfléchir à ce qui pourrait nous aider, puis à nous l'enseigner. Le parallèle avec le travail personnel est évident, coder comme un âne pendant 4 heures le soir pour finir bloqué, autant dire que le lendemain on chope le prof dans un coin et on lui fait cracher le morceau nous permettant d'avancer un peu plus.
    
    L'avantage du C++ (et du C que l'on a survolé) c'est que l'on aborde des points qui sont omis dans d'autres langages. Je pense surtout au typage dynamique et au ramasse-miettes qui simplifient la vie, mais qui font l'impasse sur ce qui peut s'avérer important. Déjà que mes camarades étaient les pros du "ça marche alors je vois pas pourquoi je devrais faire autrement vous les profs vous êtes bornés" ou "je sais pas pourquoi ça marche pas le compilateur me dit que je ne peux pas comparé un entier avec une chaîne maman je fais quoaaaaaa ??", alors si on avait tapé direct dans du python, j'imagine pas la merde s'ils avaient du tâter un langage typé ensuite.
    
    Alors on a fait un peu de langage web aussi, Javascript et PHP, HTML et CSS (ouais bon c'est pas de la programmation), et j'ai bien vu qu'ils ne cherchent pas à comprendre ce qui se cache derrière les différences entre les langages. Triste histoire. Alors que pendant ce temps la je découvrais les joies de Ruby, après avoir eu le déclic de la POO sur le C++. Et c'est la que j'ai compris l'intérêt d'aborder un langage comme le C++ au début, même si c'est chiant parfois, j'ai pu savourer la magie du Ruby, le tout-objet, le typage dynamique, la syntaxe bien plus épurée, toussa. Tout en gardant à l'esprit que c'est un langage prévu pour contrer quelques désagréments du C++, entre autres, mais que je ne pourrais pas l'utiliser pour les mêmes projets que ce dernier. Et puis je me suis lancé dans le python, parce que ruby python c'est du "même genre". J'ai aussi testé le PHP, à coder 8h par jour pendant mes jours de congé, pour dire que je n'aime pas trop ça, sans même en connaitre vraiment la raison.
    
    Pour ma part, me lancer dans des challenges/tp/exos/projets dans des langages différents permet de comprendre bien des choses que l'on ne pourrait pas concevoir en restant bloqué dans un seul, du moins en tant qu'étudiant, puisque que c'est le sujet ici. La démarche de pousser l'étudiant à avoir besoin de plus, de mieux, sans jamais lui offrir l'opportunité de zapper les bases est la démarche la plus saine. Un étudiant curieux est un étudiant qui va de l'avant, quoi qu'il arrive.
    
    Le seul truc qui me chagrine un peu, c'est qu'avoir appris le C++ dans un IDE tout pourri nous a filé quelques mauvaises habitudes, ce qui nous pousse à les corriger quand on veut un code portable, ou quand on change d'IDE. Sinon ce ne fût que du bonheur, à découvrir les joies de la bidouille informatique. Je pense notamment à ce TP ou l'on devait récup' des infos d'une station météo pour ensuite contrôler le chauffage d'une serre via une carte contrôleur, le tout en traitant les trames brutes de la station. Ce soupçon de rétro-engineering était très excitant, surtout quand, au final, tout marche au poil.
    
    Et je regrette également de ne pas avoir eu la joie de développer pour mobiles et tablettes, car effectivement, on codait comme si l'on avait de la ram infinie, sans tenir compte des différences entre les machines susceptibles d'exécuter notre soft, mais ce n'est clairement pas le point de vue de toute ma promo.
    
    Alors le python, je trouve ça putain de génial, seulement, c'est comparé au C++, qui fût ma première patrie. Je pense que j'aurais fait la grimace si, en débutant par python, on m'avait soudainement imposé du C++, voire du C… Peut-être que c'est à voir selon l'usage que l'on veut en faire, et si l'on veut enseigner l'algorithmie ou la programmation en tant que telle. Toujours est-il que je pense que tatouiller plusieurs langages est bénéfique pendant l'apprentissage, et donc qu'il serait peut-être sympa de pousser les étudiants à le faire, voire à leur imposer en proposant des cours sur plusieurs langages.
    
    Ah oui tiens, ça ne fait pas vraiment avancer le débat =)
    - [^] # Re: Pas de "bonne" réponse
      
      Posté par lolop (site web personnel) le 23 juillet 2014 à 17:05. Évalué à 4.
      
      "je sais pas pourquoi ça marche pas le compilateur me dit que je ne peux pas comparé un entier avec une chaîne maman je fais quoaaaaaa ??", alors si on avait tapé direct dans du python, j'imagine pas la merde s'ils avaient du tâter un langage typé ensuite.
      
      Sur ce point particulier les étudiants ont les même problèmes, sauf qu'au lieu de les avoir à la compilation, ils les ont à l'exécution. On passe un temps certain à expliquer les combinaisons des différents types suivant les opérateurs, ce qui est valide et ce qui ne l'est pas…
      
      Et je te rejoins… seuls les étudiants qui pratiquent un peu chez eux avancent, chez certains autres c'est catastrophique.
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Pas de "bonne" réponse
    
    Posté par keyser.dyson le 25 juillet 2014 à 21:04. Évalué à -2.
```
Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur,
```
    Est ce qu'on peut en déduire que les programmeurs C font plus de sport et assimilent mieux les graisses ?
- [^] # Re: Pas de "bonne" réponse
  
  Posté par barmic le 23 juillet 2014 à 12:14. Évalué à 9.
  
  Je déconseillerais le C à quiconque ne souhaite pas devenir un "gros" programmeur,
  
  Parce qu'en python/perl/ruby/haskel/ocaml/Ada/D/go/bash/etc, tu as le temps de faire du sport, c'est ça ?
  Je te trouve assez irrévérencieux avec Linus…
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Pas de "bonne" réponse
  
  Posté par rewind (Mastodon) le 23 juillet 2014 à 14:18. Évalué à 6.
  
  L'idéal ce serait d'en voir plusieurs, et laisser les élèves choisir celui ou ceux qu'ils préfèrent.
  
  La concurrence libre et non-faussée entre les langages de programmation, et la main invisible choisira le meilleur langage… Sauf qu'en réalité, ça ne se passe pas comme ça. Parce que le temps d'apprentissage d'un langage (et pas juste les trucs de base) est trop important par rapport au temps dédié à cet apprentissage. Et le choix, il revient aux enseignants, qui construisent un parcours pédagogique complet pour montrer tous les aspects de l'informatique.
  
  Si le(s) prof(s) en connaissent plusieurs, pourquoi ne pas leur faire des séances découvertes de chaque avant de les laisser en choisir un individuellement pour les travaux pratiques?
  
  Ha ben oui, c'est vrai qu'on a tellement de temps à consacrer à ce genre de lubie. Sans compter que corriger des TP écrits dans des langages différents doit être un plaisir sans bornes.
- [^] # Re: Pas de "bonne" réponse
  
  Posté par Michaël (site web personnel) le 24 juillet 2014 à 00:08. Évalué à 2.
  
  Un jour j'ai découvert l'OCaml […] j'ai laissé tomber aussi (snif!).
  
  Tu as fait l'erreur de ta vie! Tout simplement. ☺
  
  L'idéal ce serait d'en voir plusieurs, et laisser les élèves choisir celui ou ceux qu'ils préfèrent.
  
  L'idéal c'est d'apprendre à programmer indépendamment de tout langage (un peu comme ce que tu as fait, algorithmique puis Pascal) parceque tu apprends à distinguer entre les deux champs de connaissance: le conceptuel et l'implémentation. Il suffit de lire quelques CR d'entretien d'embauche menés par Joel Spolsky (cf. son blog) pour se rendre compte que c'est une qualité.
  
  Si on t'apprend à programmer indépendemment de Pascal ou C++ ou bidule, tu es à même d'apprendre rapidement de nouveaux langages, et donc tu as beaucoup plus d'opportunités professionnelles et donc tu es plus libre d'organiser ta carrière.
# Latex et html...

Posté par etbim le 23 juillet 2014 à 11:44. Évalué à 0.

Comme beaucoup de gens ici au vu des commentaires, j'ai eu des cours de C++ et Python au cours de ma licence. Cours auxquels je pigeais pas grand chose et laissais faire les potes déjà initiés (autodidactes lycéens) en TD.
Ma véritable initiation à été mon passage par Latex pour la rédaction des rapports et autres rendus scolaires, en autodidacte avec les conseils avisés de profs et d'amis.
Pour moi, c'est déjà de la programmation, on a des balises, on compile et on regarde où ça merde dans les messages du compilateur. Le gros avantage est que l'on obtient mieux au final que les tables de multiplication et autres 100 premiers entiers (ah les td, c'était le bon temps…), on obtient un vrai beau rapport qui en jette et qui motive pour parfaire son latex.
Plus tard, ayant découvert GNU/Linux du temps de Debian Lenny, je me suis intéressé au html puis très vite au php. Ici on se met à coder pour de vrai, surtout avec php, mais le pli pris avec Latex rend l'apprentissage plus facile.
Enfin, ces derniers temps, j'essaye d'apprendre le C++ et bientôt le fortran, et je ne me sens pas trop perdu, en fait j'éprouve plutôt un fort sentiment de continuité.

Donc si j'avais un conseil, ce serait d'apprendre Latex et Html/php aux lycéens, ou au moins aux étudiants de L1. Les autres langages sembleront moins austères aux étudiants après ça.
- [^] # Re: Latex et html...
  
  Posté par Toto le 23 juillet 2014 à 16:18. Évalué à 8.
  
  [latex] c'est déjà de la programmation, on a des balises, on compile et on regarde où ça merde dans les messages du compilateur.
  
  Les balises, oui, on compile oui, on regarde où ça merde dans les messages du compilateur, euh… j'ai jamais réussi à comprendre ces …. de message d'erreur de Latex. A chaque fois que j'ai une erreur en latex, je fais un diff entre ce qui marchait et ce qui marche plus et je recommence à 0. Même les messages d'erreurs abscons de C++ je les trouve plus clair :)
# Mon avis à moi et rien qu'à moi

Posté par El Titi le 23 juillet 2014 à 23:52. Évalué à 10.

J'ai lu attentivement les 190 commentaires de ce journal dont le sujet ne pouvait pas ambitionner moins.

Si je prends la peine de poster, c'est simplement car beaucoup d'idées ont été échangées ici mais peu qui analysent le succès de Python en tant que langage d'apprentissage par excellence.

Pour ne pas faire dans l'originalité j'évoquerai ma propre expérience.
Je fais partie de cette génération qui a découvert la programmation sur les ZX81 et autre Commodore 64.
J'ai commencé avec le BASIC old fashion (pas celui du VB) et j'en retiens que ce niveau de raisonnement reste proche de l'ordinateur et assez imbitable. C'est d'une logique implacable mais vraiment pas destiné à un raisonnement de haut niveau. Basic out !
Mais ceci m'a permis de m'intéresser à la programmation au point que j'ai suivi une option au collège.
Le truc intéressant que mon prof nous répétait est qu'il faut d'abord raisonner en terme d'algorithme avant de concevoir le programme. Aujourd'hui ça peut paraître con, mais lorsqu'on parle de modélisation, de recherche opérationnelle, … l'abstraction prend tout son sens.
Apprendre les structures de données, de contrôle, la différence entre un boucle "tant que" et un "répète jusqu'à" …
Rien de tel pour progresser. Pour passer à la programmation, il ne restait qu'à passer à l'anglais… On appelait ça … le PASCAL.
Ce langage était à mon sens le plus adapté à l'enseignement.

A cette époque, les geeks, les vrais, ceux qui savaient, arboraient des t-shirts "Real programmers use C". Ca le faisait.
C'est vrai qu'utiliser un pointeur de fonction ou une boucle avec 2 variables qui s'incrémentent en même temps, c'est trop fort, mais que c'est illisible. Il fallait en passer par là. Je passe sur le Smalltalk, le langage Eiffel, le PROLOG ou le Lisp pour la découverte des autres paradigmes de langage pour revenir sur les "vrais" cas d'usage (troll inside).
Avez déjà vous essayé de faire de la POO avec du C ? On en tire une certaine fierté lorsqu'on lutte des heures durant pour sortir un peu d'héritage avec des cast de structures, des unions et autres bizarreries (Dire que certains croient encore en GTK: troll++). Et là un certain Stroustrup débarque avec son C++. Quel bonheur … du C objet (non pas celui de la marque à la pomme).
Mais comment peut-on croire qu'un langage qui impose d'assimiler la POO pour eécrire le moindre truc, qui supporte le multi-héritage (et son pendant le diamant), la généricité, la surcharge des opérateurs (qui est d'une complexité sans nom pour anticiper tous les types passés), les méthodes virtuelles vs statiques, la bonne manière de déclarer ses constructeurs et destructeurs, puisse être enseigné comme base pour des débutants. C'est juste une hérésie, même pou appréhender la POO. Ce langage n'a percé que parce qu'il permettait d'apporter la couche objet au C universel.

Java en comparaison (ou je sais quelle honte) a choisi la voie du compromis. L'héritage simple couplé avec des interfaces pour gérer l'héritage multiple, le ramasse miette par défaut avec le finalize pour l'optim, la gestion des exceptions héritée de Eiffel (et C++, OK), les types de base pour la performance enrobée dans des Containers lorrsq'on en a besoin et surtout une JVM qui a permis le portage de tant d'autre langages au point que Krosoft l'a imité avec sa CLR.

Un jour, je suis tombé sur le tutoriel de Guido et là ce fut un peu comme une révélation. Ce langage est juste un condensé de bonnes idées qui m'a ramené au temps du Pascal.

Votre algorithme transparait immédiatement avec l'indentation. Plus besoin de "finsi", plus besoin de déclarer les types …
Ecrire une liste et la manipuler en une ligne. Des structures de haut niveau: hashmaps, sets, listes, strings, …
Le typage dynamique que certains décrient comme prêtant à confusion est juste pratique et intuitif. (Certains ont confondu avec le typage faible de Perl qui lui est vraiment troublant puisqu'il nécessite de connaitre le coeur du langage).
Le fait qu'il soit interprété apporte un retour immédiat.
Par rapport au Javascript, il nécessiterait d'installer des trucs ?
Allez faire un tour ici: http://pythontutor.com/

Mon fils souffre d'autisme et se passionne pour l'informatique. Nous avons entrepris de créer ensemble un jeu de puissance 4 et c'est vraiment un régal d'améliorer progressivement notre petit projet.

Est-il parfait ?
Certes non: Comment ne pas être frustré lorsque la PEP pour la création du while est refusée car le langage se veut dogmatiquement minimaliste. Comment ne pas s'insurger de ce paramètre self redondant dans les méthodes de classes.

Ruby est beaucoup mieux conçu, mais sa syntaxe inspirée du Perl le met définitivement hors de portée du néophyte.
- [^] # Re: Mon avis à moi et rien qu'à moi
  
  Posté par fearan le 24 juillet 2014 à 10:00. Évalué à 4. Dernière modification le 24 juillet 2014 à 10:00.
  Mais comment peut-on croire qu'un langage qui impose d'assimiler la POO pour eécrire le moindre truc, qui supporte le multi-héritage
```
#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "Hello World" <<std::endl;
}
```
  Où vois tu qu'il est nécessaire d'assimiler la POO?
  De même le mutli héritage, n'est absolument pas nécessaire pour coder en C++, c'est simplement disponible le jour où tu en aura besoin. Bref, critiquer le C++ sur des concepts très avancés (qui en plus sont logique une fois qu'on connait un minimum le langage), inutile à l'apprentissage de base. S'il était nécessaire de maitriser tous les aspect d'un langage de programmation pour l'utiliser, ou qu'il était nécessaire de tout apprendre d'un coup, je suis au regret de t'informer qu'a part le go, oOok, et l'assembleur et quelques rares exceptions (dont le python ne fait pas partie) aucun langage ne correspond à la requête.
  
  Ecrire une liste et la manipuler en une ligne.
  
  if ( std::any_of(foo.begin(), foo.end(), {return i<0;}) )
  ou globalement tout ce que tu peux trouver ici :
  http://www.cplusplus.com/reference/algorithm/
  avec notamment :
  http://www.cplusplus.com/reference/algorithm/for_each/
  
  Votre algorithme transparait immédiatement avec l'indentation. Plus besoin de "finsi", plus besoin de déclarer les types …
  
  Mais qu'est ce qui t'empêche d'indenter ton pascal?
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Mon avis à moi et rien qu'à moi
    
    Posté par fearan le 24 juillet 2014 à 11:53. Évalué à 2.
    arggh je me rends compte que la lambda est pas passé, je reprends donc
```
if ( std::any_of(foo.begin(), foo.end(), [](int i){return i<0;}) )
```
    Le crochet a été interprété comme un lien wiki vide…
    
    Il ne faut pas décorner les boeufs avant d'avoir semé le vent
    - [^] # Re: Mon avis à moi et rien qu'à moi
      
      Posté par keyser.dyson le 25 juillet 2014 à 21:11. Évalué à 1.
      
      Je ne comprends pas pouquoi ils ont choisi les crochets pour faire ça. C'est pour les tableaux normalement.
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par fearan le 25 juillet 2014 à 22:15. Évalué à 2.
        
        c'est court
        
        ça évite de rajouter un mot clé (lambda)
        
        sur un clavier qwerty c'est un geste :)
        
        aucune chance de mal interpréter le truc dans le contexte en question (point de vu parser)
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par keyser.dyson le 25 juillet 2014 à 23:00. Évalué à 1.
        
        Je suis tombé sur cette article récemment:
        
        http://theweeklypush.com/how-to-pass-recursive-lambdas-c
        
        C'est ardu. Ca me rappelle mes expériences avec les templates, il y a quelques années.
        
        J'aime bien cette approche. Un préprocesseur pour faire des lambdas en C:
        
        https://github.com/graphitemaster/lambdapp
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par fearan le 25 juillet 2014 à 23:55. Évalué à 2.
        
        Je dois dire que je me suis bien marré en lisant l'article, ça m'a rappelé le temps où je jouait avec les boost::bind*. Il faut bien avouer que le gars à un certain niveau en C++, mais je m'en veux d'avoir tout lu, maintenant je suis incapable de savoir si je pourrai trouver la solution moi même; bon ce qui est certain c'est que j'aurai aussi pas mal testé différents trucs.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par keyser.dyson le 26 juillet 2014 à 17:49. Évalué à 0.
        
        Je n'aime plus le côté brainfuck du C++.
        
        Depuis que j'ai gouté aux langages de script, j'écris différemment en C++. J'ai adopté un style plus sobre.
        
        Ce qui m'intéresse surtout maintenant, c'est la vitesse. C'est toujours ce qu'il y a de mieux de ce côté la.
        
        Dans les benchmarks de langages, les écarts sont énormes. Ca peut aller jusqu'à 400 fois entre le Python et le C++.
  - [^] # Re: Mon avis à moi et rien qu'à moi
    
    Posté par El Titi le 24 juillet 2014 à 15:42. Évalué à 6. Dernière modification le 24 juillet 2014 à 15:47.
    Mais qu'est ce qui t'empêche d'indenter ton pascal?
    
    Absolument rien. Mais le fait que l'indentation définisse la structure de bloc en python rend le code plus concis et facilite la lecture. L'algorithme transparaît. On peut évidemment pinailler sur ce sujet mais c'est un fait. Un code plus concis est plus simple à comprendre.
```
#include <iostream>

int main(int argc, char *argv[])
{
  std::cout << "Hello World" <<std::endl;
}
```
    Où vois tu qu'il est nécessaire d'assimiler la POO?
    
    vs
    print "Hello World"
    Merci de confirmer ce que je tentais d'expliquer.
    C++ est conçu pour apporter la POO à C avec de nombreuses adjonctions (surcharges des operateurs, >>,<<, …)qui donne du potentiel mais qui complexifie. Certes on peut s'affranchir du coté POO. Mais dans ton exemple, il faut expliquer:
    Qu'il faut inclure une librairie ou plutôt son entête car l'implemvient à l'edition de lien, que la fonction main est appleé par défaut.
    - Expliquer qu'il s'agit d'une fonction … qui accepte des paramètres
    - Les paramètres ? N'y faites pas attention. C'est juste quelque chose qui pollue au cas où on passerait des options à la ligne de commande.
    - std:: ? comment vous dire… la modularité on verra ça plus tard
    Avec Python, il te suffit d'exécuter ça via l'interpréteur et le moment venu tu expliqueras l'utilité de stocker son programme et de la ft main.
    
    Dans tous les débats qui font rage ici, on ressent une certaine mauvaise foi pourtant il m'apparaît (c'est certes subjectif):
    - Qu'un langage interprété est une évidence pour l'apprentissage.
      Entre ceux qui débattent de la nécessité ou non d'un IDE et à celui qui martyrise le plus ses élèves avec Maven ou le Makefile, le temps de compilation pour 2 millions de lignes de code … et ceux qui prônen le JS pour avoir tout sous la main. JE renvoie encore à ce projet sous licence libre : http://pythontutor.com
      L'édition de lien, la gestion des dépendance, la modularisation sont loin des préoccupations de base du néophyte.
    - Qu'un langage dynamique (ou à défaut à inférence de type) est tout autant incontournable:
      On a beau évoquer le fait qu'on ne comprendrait pas ce qu'est un type, qu'on prendrait des mauvaises habitudes…
      Le typage dynamique n'apporte aucune confusion sur ce qu'est un type. Le typage statique n'est qu'une assurance qu'on ne fasse pas n'importe quoi avec une variable lorsqu'on la réutilise. Faut-il en passer par une phase de compilation juste pour ça alors qu'un interpréteur permet de tester en direct, d'expérimenter à la volée…
      Bref, tu apprends ce qu'est un type de donnée (contrairement à l’ambiguïté entretenue pas les langages à typage faible) et le moment venu tu verrouilles ton code avec un outil dédié ou tu t'intéresses enfin au langages à typage statique.
    - Qu'il se doit de supporter les structures de haut niveau dans sa syntaxe:
      if ( std::any_of(foo.begin(), foo.end(), [](int i){return i<0;}) )vs
      
      ma_liste=range(50)
      print ma_liste
    Comment dire … Merci de m'expliquer ce que fait ta ligne:
    C'est quoi une lambda au fait ?
    Pourquoi un if ?
    Et foo ? pas besoin de le déclarer ?
    …
    Alors oui tu aurais pu utiliser std::Vector à moins que Qlist ne soit préférable …
    
    Des structures de haut niveau directement dans le langage et bien conçues ca fait la différence … et ca aide à mieux cerner la notion de type (Un outil pour chaque usage).
    
    Après, ca ne signifie absolument pas qu'il faille mettre au rencart les langages qui apportent d'autres éclairages sur différent paradigmes. Apprendre le C/C++ garde tout son intérêt lorsqu'on souhaite approfondir la programmation système que l'on s'intéresse à l'architecture des ordis. Oui la différence entre le tas et la pile est importante … si l'on souhaite l'approfondir. J'ai un peu l'impression qu'une arrière-garde de l'informatique ne souhaite pas mettre ses bases à la portée de tous avec sa conception élitistes au point qu'il faille éliminer absolument les moins vaillants plutôt que de la démocratiser. Une conception de certains profs que j'ai pu croiser en fac et qui ne voulaient pas changer un iota de leur cours depuis des années pour en fournir le minimum pour leurs élèves. (Il faillait bien en terminer par un troll)
    - [^] # Re: Mon avis à moi et rien qu'à moi
      
      Posté par zul (site web personnel) le 24 juillet 2014 à 16:18. Évalué à 3.
      print "Hello World"
      
      SyntaxError: invalid syntax
      
      ah mince, mon python, c'est un python3 :D
      
      if ( std::any_of(foo.begin(), foo.end(), [](int i){return i<0;}) )
      vs
      
      ma_liste=range(50) print ma_liste
      
      Comme y'a aucun rapport entre les deux codes, bah euh, c'est vachement cool comme comparaison sérieusement
      L'équivalent serait probablement
      
      if [i for i in foo if i < 0]:
      
      en utilisant donc la syntaxe de comprehension liste et le fait qu'une liste vide est interprété comme faux
      
      ou en utilisant any
      
      if any(foo, lambda i: i < 0):
      
      avec une lambda fonction. Bref, dans les deux cas, ce n'est pas plus simple.
      
      Alors oui tu aurais pu utiliser std::Vector à moins que Qlist ne soit préférable …
      
      std::vector, tu veux dire surement. Et Qlist ce n'est pas du C++ (i.e. ce n'est dans la spec).
      
      Des structures de haut niveau directement dans le langage et bien conçues ca fait la différence … et ca aide à mieux cerner la notion de type (Un outil pour chaque usage).
      
      Je suis d'accord. En l'occurence, les structures de C++ sont bien pensées, les complexités garanties par la norme, et l'interface est prévue pour faire des choses raisonnables même en cas d'exception. On se demande toujours ce qu'est une "liste" en python (à par un truc pratique) et quelle peut être la complexité des opérations dessus.
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par fearan le 24 juillet 2014 à 16:46. Évalué à 2. Dernière modification le 24 juillet 2014 à 16:50.
        
        pour le liste=range(50)
        il faudra utiliser std::generate (http://www.cplusplus.com/reference/algorithm/generate/) qui permet de faire plus compliqué ou iota
        
        #include <vector> #include <numeric> std::vector<int> v(50) ; std::iota (v.begin(), v.end(), 0);
        
        A noter que ça marche avec un int, mais avec tout objet ayant aussi redéfini T &operator++() :D
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Moonz le 24 juillet 2014 à 16:58. Évalué à 3.
        
        L'équivalent serait probablement
        if [i for i in foo if i < 0]:
        
        Plutôt :
        
        if any(i < 0 for i in foo)
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par fearan le 24 juillet 2014 à 17:22. Évalué à 2.
        
        petite question aux habitués du python : itère t'on sur la totalité de la liste, ou s'arrête t'on dès qu'on choppe un True?
        
        même question avec
        
        if any([i < 0 for i in foo])
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Moonz le 24 juillet 2014 à 17:45. Évalué à 2. Dernière modification le 24 juillet 2014 à 17:46.
        
        On s’arrête dès qu’on choppe un True, c’est assez facile à vérifier :
        
        def to_infinity_and_beyond(): i = 0 while True: yield i i += 1 print(any(i == 5 for i in to_infinity_and_beyond())
        
        Dans la seconde forme la totalité de la liste de test ([False, False, ...]) est générée puis elle est testée dans un second temps (mais le test s’arrête bien au premier True rencontré)
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par François (site web personnel) le 25 juillet 2014 à 10:53. Évalué à 2.
        
        any demande un iterable (qui possède la méthode __iter__). Logiquement, any arrête d'itérer sur l'itérable lorsque un True est vérifié quelque soit l'itérable. Par contre il y a une différence entre
        
        if any([i < 0 for i in foo])
        
        et
        
        if any(i < 0 for i in foo)
        
        Dans le premier cas une liste est générée en totalité, réside en mémoire, et any itère sur ses éléments. Dans le second, un générateur est instancié, génère les éléments à la demande d'any. A noté que le second cas est syntaxiquement équivalent à
        
        if any((i < 0 for i in foo))
        
        mais les parenthèses sont inutiles, l'interpréteur identifie directement un générateur. C'est beau, simple, claire et ça se lit littéralement… Par contre on pourrait faire
        
        gen_obj = (i < 0 for i in foo) if any(gen_ob): print "Toto"
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Zarmakuizz (site web personnel) le 24 juillet 2014 à 18:06. Évalué à 4.
        
        print "Hello World"
        
        SyntaxError: invalid syntax
        
        ah mince, mon python, c'est un python3 :D
        
        Rohlàlà c'est la fin du monde !
        
        print("Hello World")
        
        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par zul (site web personnel) le 24 juillet 2014 à 18:47. Évalué à -4.
        
        Notons aussi que la sémantique de range(x) a changé entre Python2 et Python3 (dans Python2, ça renvoie une liste, dans Python3 un générateur. Va expliquer ça aux étudiants.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par lolop (site web personnel) le 24 juillet 2014 à 21:32. Évalué à 9.
        
        T'expliques rien, tu es en phase d'apprentissage avec un premier langage, et tu vas directement sur Python 3.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
    - [^] # Re: Mon avis à moi et rien qu'à moi
      
      Posté par totof2000 le 28 juillet 2014 à 16:22. Évalué à 2.
      
      Absolument rien. Mais le fait que l'indentation définisse la structure de bloc en python rend le code plus concis et facilite la lecture. L'algorithme transparaît. On peut évidemment pinailler sur ce sujet mais c'est un fait. Un code plus concis est plus simple à comprendre.
      
      … jusqu'au jour ou tu dois modifier du que tu as récupéré, en ajoutant une condition quelque part, et que tu n'as qu'un vi sous la main. Tu as 99 chances sur 100 de te vautrer et d'oublier une indentation quelque part, ou d'en avoir une en trop, et de passer des heures à trouver ou elle est (parce que l'interpreteur te met l'erreur à la fin de ton prog ou de ta classe).
      
      Obliger à indenter, c'est bien. Se servir de l'indentation comme identification de bloc, c'est idiot.
      
      Qu'un langage interprété est une évidence pour l'apprentissage.
      
      Faux. L'un ou l'autre ne change rien. Un langage interprété est aussi compilé, mais ça se voit pas . sinon pour le reste je suis assez d'accord avec toi : apprendre la programmation avec un langage comme C++ est une aberration : on risque de perdre la moitié des élèves.
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Thomas Douillard le 29 juillet 2014 à 12:47. Évalué à 2.
        
        Si tu rajoutes une condition et que ça touche l'indentation de plusieurs dixaines de lignes de code, c'est qu'il faut que tu apprennes à mieux séparer ton code en fonction.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 29 juillet 2014 à 13:20. Évalué à 3.
        
        Si tu rajoutes une condition et que ça touche l'indentation de plusieurs dixaines de lignes de code, c'est qu'il faut que tu apprennes à mieux séparer ton code en fonction.
        
        Bien souvent, ce n'est pas ton code que tu dois modifier mais le code d'un pseudo-développeur, qui a fait un peu de python dans sa vie et qui est persuadé de faire du code propre parce qu'il utilise Python et que son code est bien indenté. Et tu retrouves justement ce genre de problématique lorsque tu récupères un ou plusieurs blocs de code pour les déporter dans une fonction parce que le code devient ingérable, parce qu'il n'a pas été bien écrit, bien décomposé en fonction. Dernièrement j'ai eu entre les mains un bout de code ou le développeur faisait plein de choses différentes dans la même fonction. Le plus drole, c'est que le code traitait les problématiques sans ordre logique, avec des threads dans tous les sens (donc interblocages …).
        
        Personnellement, je ne commence rien en Python, j'utilise autre chose : mais je suis obligé de toucher à dees programmes python qui ne sont pas les miens. Et en général, ce n'est pas beau à voir.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Thomas Douillard le 29 juillet 2014 à 13:29. Évalué à 3.
        
        Je vois pas le rapport avec l'indentation du coup.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 29 juillet 2014 à 16:33. Évalué à 5. Dernière modification le 29 juillet 2014 à 16:35.
        
        Hein ? je répète : soit un bout de code du genre :
        
        def truc (param): machin() ... if (.....): ... .. else: if ( ... ) : while (condition) : if (...): .... else: ...
        
        Si je veux reprendre la partie située sous le premier else pour en faire une fonction, je vais devoir décaler l'indentation. Et à un moment donné, je risque de me perdre dans l'indentation. Avec un bloc défini par un marqueur de fin, j'ai un autre repère qui me permet de savoir ou commence et ou s'arrête mon bloc lorsque je retravaille du code. En ruby, j'ai moins de mal. Je répète : obliger à indenter, je trouve ça bien pour la lisibilité, par contre je trouve ça insuffisant. Il manque un marqueur de fin de bloc.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Thomas Douillard le 29 juillet 2014 à 16:45. Évalué à 3.
        
        J'ai pas spécialement de problèmes, suffit de mettre sa souris ou son curseur sur la colonne dont tu veux repérer la fin et de faire défiler le texte vers le bas jusqu'au moment ou tu retrouves la bonne colonne de texte remplie.
        
        Les éditeurs sont aussi capables de replier les blocs de code aussi bien avec des marqueurs de début/fin qu'avec des blocs, du coup c'est pas trop dur de faire des copiers/coller. Les éditeurs se démerdent aussi très bien pour réindenter des blocs complets quand tu appuies sur 'tab' ou shift tab, ou autre :<< de vim, avec un bloc de code sélectionné.
        
        Le seul potentiel avantage que je peux voir avec le délimiteur c'est que l'éditeur peut surbriller le marqueur de fin correspondant, mais c'est pas forcément compliqué non plus de faire un équivalent avec des blocs de code. Sinon faire le parsage du code pour retrouver le bon marqueur de fin c'est assez pénible aussi sans les repères visuels d'indentation, à supposer que ce soit indenté correctement.
        
        Comme d'hab quoi, faut utiliser les bons outils pour la bonne tâche.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 29 juillet 2014 à 17:11. Évalué à 3. Dernière modification le 29 juillet 2014 à 17:11.
        
        J'ai pas spécialement de problèmes, suffit de mettre sa souris ou son curseur sur la colonne dont tu veux repérer la fin et de faire défiler le texte vers le bas jusqu'au moment ou tu retrouves la bonne colonne de texte remplie.
        
        Encore faut-il être dans un environnement graphique ce qui n'est pas toujours le cas : il ne faut pas oublier qu'il existe des tas d'environnements "hostiles".
        
        Sinon faire le parsage du code pour retrouver le bon marqueur de fin c'est assez pénible aussi sans les repères visuels d'indentation, à supposer que ce soit indenté correctement.
        
        C'est pour ça que je veux les deux : indentation forcée + marqueur de fin.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Thomas Douillard le 29 juillet 2014 à 18:03. Évalué à 5.
        
        T'as l'air d'avoir des conditions de travail de fou : reprendre du code de merde avec notepad.exe :) C'est pas facile effectivement.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 29 juillet 2014 à 18:18. Évalué à 3.
        
        C'est à peine exagéré :). Sinon, je considère que ce n'est pas à l'IDE de pallier ce genre de problème. Idéalement, notepad.exe devrait suffire. S'il faut un IDE sophistiqué ou spécifique au langage, c'est que le langage a un problème.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Thomas Douillard le 29 juillet 2014 à 18:49. Évalué à 2.
        
        Passé un certain niveau de complexité du programme, c'est un principe vain parce qu'un humain ne peut en maîtriser tous les aspects même en y passant tout son temps.
        
        Ce qui est un problème c'est de ne pas penser le développement comme une activité comme une autre ou le programmeur doit utiliser les outils adaptés pour être efficace. Et si un type bien outillé avec un IDE puissant est plus efficace qu'un type mal outillé qui refuse d'utiliser l'outil adapté, le second a un problème, même si il rejette la faute sur le langage. Franchement indenter des blocs c'est pas une fonctionnalité avancée pour un éditeur de code, c'est un truc basique. Sélection de texte, ils le font tous, indenter l'ensemble des lignes sélectionnées, il doit pas y en avoir beaucoup qui savent pas faire.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 30 juillet 2014 à 11:24. Évalué à 3.
        
        Ce qui est un problème c'est de ne pas penser le développement comme une activité comme une autre ou le programmeur doit utiliser les outils adaptés pour être efficace.
        
        Et si un type bien outillé avec un IDE puissant est plus efficace qu'un type mal outillé qui refuse d'utiliser l'outil adapté, le second a un problème, même si il rejette la faute sur le langage.
        
        Attaque à peine dissimulé : personnellement je ne refuse pas d'utiliser un IDE : cependant il y a parfois des cas ou l'utilisation de l'IDE est impossible : typiquement, maintenir des scripts d'admin sur un environnement de prod, avec un vi "historique" (même pas vim) (ou notepad pour des machines Windows), sans possibilité de développer/tester sur un env de préprod ou de dev. Dans la vraie vie ça arrive (c'est ma vie en ce moment et ça ne doit pas être aussi rare que ça).
        
        Franchement indenter des blocs c'est pas une fonctionnalité avancée pour un éditeur de code, c'est un truc basique. Sélection de texte, ils le font tous, indenter l'ensemble des lignes sélectionnées, il doit pas y en avoir beaucoup qui savent pas faire.
        
        Utiliser un IDE est une aide précieuse, mais il ne faut absolument pas se baser dessus. D'ailleurs, pour en revenir au sujet initial, apprendre une langage avec un IDE est une erreur : un éditeur avec coloration syntaxique fait l'affaire.
        
        De toute façon, se servir de l'indentation comme délimiteur de bloc est une absurdité.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par Anthony Jaguenaud le 30 juillet 2014 à 11:31. Évalué à 3.
        
        De toute façon, se servir de l'indentation comme délimiteur de bloc est une absurdité.
        
        Je trouve ça très bien dans une phase d'apprentissage. Ensuite, pour des vrai projets qui vont avoir une vrai vie, je suis d'accord avec toi, je préfère avoir des marqueurs de blocs puis reindentation automatique pour rendre lisible.
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par barmic le 30 juillet 2014 à 12:05. Évalué à 6.
        
        typiquement, maintenir des scripts d'admin sur un environnement de prod
        
        C'est n'importe quoi. Oui il y a des gens qui le font, mais non c'est n'importe quoi. Tu as 2 milliards de solutions pour ne pas faire ça allant de choses très lourdes (demandant l'installation de serveurs et de deamon sur chaque machine) à très légère ne demandant qu'un accès ssh sur le serveur et un outil en local chez toi. Le libre fourmille d'outils pour faire ce genre de chose (AMHA c'est là que le libre est le mieux représenté).
        
        Ce n'est même pas une question d'éditeur ou d'IDE, mais de savoir un peu ce que tu as fais et pourquoi et de pouvoir reproduire les choses en cas de problème sans pour autant avoir à aller fouiller les backup pour des actions aussi simples.
        
        Dernière chose, tu parle de scripts d'admin on est à des années lumière du cas nominal de programmation. Tu va aller toucher le site de prod en direct comme ça ? Juste à coup d'un petit sed bien senti ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par barmic le 30 juillet 2014 à 12:10. Évalué à 3.
        
        Personnellement plus ça va et plus mes fonctions sont courtes. C'est une habitude si je ne peux pas lire un code dans son ensemble avec mon écran (et moins sur les grands écrans), je trouve ça gênant. Bref tout ça pour dire qu'avec des méthodes qui font 15 à 20 lignes max (ce qui n'a rien de compliqué à faire avec un langage comme python), ça ne pose pas vraiment de problème.
        
        Cela dis j'aime pas bien python et son indentation forcée (une histoire de goût).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par gst le 29 juillet 2014 à 15:02. Évalué à 2.
        
        Qu'un langage interprété est une évidence pour l'apprentissage.
        
        Faux. L'un ou l'autre ne change rien. Un langage interprété est aussi compilé, mais ça se voit pas.
        
        ça ne change rien et çà ne se voit pas, pardon ?
        
        Heuh certes, "behind the scenes" c'est sûr qu'à un moment donné ou à un autre, et que ce soit compilé ou interprété, le truc est exécuté d'une manière ou d'une autre dans ton CPU en utilisant ces instructions machine à lui, oui sûr.
        Mais quand même, ~~avec Python~~ en langage interprété, quand tu te prends une exception avec un beau traceback et la ligne incriminée ben tu la vois là, la différence, vis-à-vis d'un crash/erreur de segmentation reporté par un programme venant d'un langage "directement" compilé ou pour en savoir plus il te faudrait sortir le debugger pour analyser le coredump, s'il y en a un !
        C'est bien, AMHA, un des gros avantages des langages "interprétés" vs "compilés"..
        
        Ou tu crashes jamais tes progs ~~C/C++~~ compilés :-?
        
        [^] # Re: Mon avis à moi et rien qu'à moi
        
        Posté par totof2000 le 29 juillet 2014 à 16:28. Évalué à 4.
        
        Ou tu crashes jamais tes progs C/C++ compilés :-?
        
        Jamais !!!!
# L'assembleur ou le Scheme

Posté par Michaël (site web personnel) le 24 juillet 2014 à 00:14. Évalué à 1. Dernière modification le 24 juillet 2014 à 00:14.

Les deux langages les plus simples sont l'assembleur et le Scheme, ils mettents l'accent sur des choses très différentes.

L'assembleur (mon premier langage!) n'est absolument pas conceptuel mais il permet d'apprendre des tas de choses sur le fonctionnement des ordinateurs et permet de manipuler la mémoire de façon explicite. Et écrire un projet vaguement ambitieux en assembleur est l'occasion de se forger une discipline d'organisation qui survivra à tout!

Scheme au contraire est purement conceptuel et c'est très franchement le plus simple de tous les langages fonctionnels, un million de fois plus simple que Common Lisp, Perl, Python, OCaml ou Haskell.

(Et si quelqu'un dit que C est plus facile que l'assembleur c'est qu'il ne sait programmer ni l'un ni l'autre!)
- [^] # Re: L'assembleur ou le Scheme
  
  Posté par gnx le 24 juillet 2014 à 01:23. Évalué à 1.
  
  Ta proposition permet d'allier l'approche allant du bas vers le haut (ASM -> C -> …) et l'approche du haut vers le bas (fonctionnel -> …). Ça me paraît très bien et doit permettre d'aboutir plus tard à un « juste » milieu entre ces 2 extrêmes (le mot « milieu » n'est pas forcément approprié ; suivant le domaine d'application et les bonshommes, le langage favori final pourra être près d'un bord ou l'autre).
  - [^] # Re: L'assembleur ou le Scheme
    
    Posté par Michaël (site web personnel) le 24 juillet 2014 à 18:08. Évalué à 1.
    
    Ta proposition …
    
    En fait c'est surtout les propositions de Knuth dans The art of computer programming et de Abelson, Sussman et Sussman dans Structure and interpretation of computer programs.
    
    Des livres pas importants du tout dans la bibliothèque d'un programmeur.
    - [^] # Re: L'assembleur ou le Scheme
      
      Posté par gnx le 24 juillet 2014 à 18:38. Évalué à 3.
      
      Ou alors on peut arriver à émettre une idée aussi difficile(!) et originale(!!) par soi-même, sans béquille d'autorité. Mais faut croire qu'un programmeur important doit se reconnaître à sa capacité à faire des citations et à écrire un commentaire comme une bibliographie de thèse.
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 18:42. Évalué à 2.
        
        Ou alors on peut arriver à émettre une idée aussi difficile(!) et originale(!!) par soi-même, sans béquille d'autorité.
        
        C'est le cas!
        
        J'ai réalisé après coup que c'était le point de vue des auteurs cités et je me suis dit que ça pourrait donner des idées de lecture aux glandus qui moinssent sans se donner la peine de formuler une contradiction. :)
- [^] # Re: L'assembleur ou le Scheme
  
  Posté par xcomcmdr le 24 juillet 2014 à 18:14. Évalué à 5. Dernière modification le 24 juillet 2014 à 18:15.
  
  (Et si quelqu'un dit que C est plus facile que l'assembleur c'est qu'il ne sait programmer ni l'un ni l'autre!)
  
  Ah bon, pourquoi avoir inventé le C alors ?
  
  Le C est plus facile dans le sens où il te fait gagner du temps (et le temps, c'est du code).
  
  Si l'assembleur était si facile que ça, on y serait resté.
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: L'assembleur ou le Scheme
    
    Posté par Michaël (site web personnel) le 24 juillet 2014 à 18:37. Évalué à -1.
    Le C est plus facile dans le sens où il te fait gagner du temps (et le temps, c'est du code).
    
    Le C est aussi plus difficile que l'assembleur parceque:
    - Il propose une mauvaise abstraction de la mémoire (les pointeurs): on ne comprend cette abstraction qui si on sait comment marche la mémoire, donc du coup on doit apprendre deux choses (la manipulation de la mémoire et l'abstraction de cette manipulation).
    - Il est plein d'incantations mystiques comme include dont le rapport avec l'utilisation des fonctions n'est pas facile à éclaircir pour un néophyte.
    - Il a un type à la con void qui n'a pas de valeurs.
    - La notion de tableau est très voisine de celle de pointeur, avec des différences subtiles sizeof.
    - Il y a des raffinements des déclarations de structures (padding), des unions…
    Si l'assembleur était si facile que ça, on y serait resté.
    
    Je te rappelle qu'on parle des langages pour apprendre à programmer.
    - [^] # Re: L'assembleur ou le Scheme
      
      Posté par xcomcmdr le 24 juillet 2014 à 18:59. Évalué à 1.
      
      Pour apprendre l’algorithmie, l'assembleur ne me semble pas vraiment indiqué, de même pour le C.
      
      Parce que apprendre à programmer avant de savoir ce qu'est un algorithme ça donne de la merde que d'autres auront le malheur de devoir nettoyer.
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par Michaël (site web personnel) le 24 juillet 2014 à 22:21. Évalué à 1.
        
        Pour apprendre à programmer.
        
        [^] # Re: L'assembleur ou le Scheme
        
        Posté par xcomcmdr le 25 juillet 2014 à 01:05. Évalué à 1.
        
        Et ?
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: L'assembleur ou le Scheme
        
        Posté par Michaël (site web personnel) le 25 juillet 2014 à 10:55. Évalué à 2.
        
        On parle de langages pour apprendre à programmer, et toi tu parles de l'ordre dans lequel il faut apprendre l'algorithmique et la programmation. C'est une ouverture actuelle du débat qui mérite à elle seule un journal mais qui en soi est ici un peu hors sujet.
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par lasher le 25 juillet 2014 à 21:35. Évalué à 4.
        
        Encore une fois : le langage importe peu, tant que l'équipe enseignante fait correctement son boulot. De toute manière pour les premiers cours d'algo/prog, les profs vont utiliser des sous-ensembles du langage choisi, quel qu'il soit.
        
        Le C n'est pas un problème si le cursus de l'étudiant est de faire de l'informatique. Par contre, il est important d'y aller progressivement. De plus, l'algorithmique, ce n'est pas simplement faire des tris avec données déjà allouées pour toi en mémoire. Au contraire, c'est admettre qu'il y a un besoin de pouvoir créer (et potentiellement détruire) de nouvelles données dynamiquement. L'exemple le plus parlant est la liste chaînée non-bornée. Les bases de l'algo s'apprennent en recréant les structures de données fondamentales et les méthodes pour les traverser et les modifier. Apprendre l'algo (pour un élève en informatique) sans parler des problèmes d'allocation dynamique à un moment donné, c'est quand même gênant (mais ça existe, je connais des élèves qui ont dû apprendre à coder en C++ seulement une fois arrivés au niveau master/doctorat).
  - [^] # Re: L'assembleur ou le Scheme
    
    Posté par totof2000 le 28 juillet 2014 à 16:25. Évalué à 2.
    
    Ah bon, pourquoi avoir inventé le C alors ?
    
    Pour la portabilité : porter Unix sur d'autres archis que le PDP11 me semble-t-il. A vérifier.
    
    Sinon le C n'est qu'un "assembleur évolué".Et j'ai eu plus de al à appréhendre le C que l'assembleur.
    - [^] # Re: L'assembleur ou le Scheme
      
      Posté par Zylabon le 28 juillet 2014 à 17:01. Évalué à 5.
      Ah bon, pourquoi avoir inventé le C alors ?
      
      Sinon le C n'est qu'un "assembleur évolué".Et j'ai eu plus de al à appréhendre le C que l'assembleur.
      
      Pourquoi on a inventé le C ? La portabilité, certes, mais si c'était la seule raison on se serait contenté d'un « assembleur évolué », une sorte d'abstraction d'assembleur imbitable car il devrait gérer toutes les particularités de chaque processeurs, ou alors il ne serait qu'un sous ensemble extrêmement restreint de chacun d'eux.
      
      Le C offre, contrairement à n'importe quel assembleur :
      
      La portabilité
      
      Un système de type
      
      La déclaration de types complexes, récursifs
      
      La définition de fonctions
      
      Une pile (peut être qu'il y a des assembleur qui en proposent, mais rien de courant)
      
      Des structures de contrôle
      
      Un système de module (rudimentaire, il est vrai)
      
      Une lib standard (ok… ya les cisc).
      
      Bref, toutes ces choses permettent de gagner un temps fou dans de développement et la maintenance, et il est possible d'aborder des programmes autrement plus complexes.
      
      Bref, le C est un langage de haut niveau. Aussi proche de l'assembleur que du lambda calcul.
      
      Please do not feed the trolls
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par Michaël (site web personnel) le 29 juillet 2014 à 06:52. Évalué à 2.
        
        Bref, toutes ces choses permettent de gagner un temps fou dans de développement et la maintenance, et il est possible d'aborder des programmes autrement plus complexes.
        
        Certainement, mais on aimerait plutôt savoir si toutes ces choses sont nécessaires à apprendre, si elles sont faciles à apprendre ou constituent des difficultés pédagogiques, parcequ'on parle des langages pour s'initier à la programmation!
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par totof2000 le 29 juillet 2014 à 13:28. Évalué à 4.
        
        Un système de type
        
        Tu veux dire qu'il n'y a pas de type en assembleur ? C'est faux.
        
        La déclaration de types complexes, récursifs
        
        La définition de fonctions
        Tu peux déclarer des sous-programmes en assembleur : ce ne sont pas des fonctions à proprement parler, mais ça fait parfaitement l'affaire.
        
        Une pile (peut être qu'il y a des assembleur qui en proposent, mais rien de courant)
        
        C'est justement une des caractéristiques intéressantes de l'assembleur : la pile n'est pas "magique" : tu dois te soucier de sa taille. C'est la même chose en C, sauf que c'est moins évident parce qu'il y a une gestion automatique. Celà dit, la gestion de la pile n'est pas du ressort du langage mais de l'OS, a moins de programmer à bas niveau sans OS.
        
        Tu peux déclarer des types complexes avec les assembleurs récents. Récursifs, par contre je ne sais pas.
        
        Sinon tout ce que tu cites sont des abstractions, qui ne sont pas forcément plus simple que les concepts sous-jacents en assembleur.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 29 juillet 2014 à 00:56. Évalué à 5.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: L'assembleur ou le Scheme
        
        Posté par totof2000 le 29 juillet 2014 à 13:34. Évalué à 1.
        
        Alors là, je vous arrête tout de suite : C n'a rien à voir avec un quelconque langage d'assemblage.
        
        J'exagère un peu en parlant d'assembleur évolué (car il y a pas mal d'abstractions en C, justement pour permettre la portabilité), mais le C reste un langage très bas niveau. En théorie, dans les normes, il n'y a effectivement pas d'accès aux registres : en pratique c'est possible, voire indispensable d'y accéder pour les programmes bas niveau. Personnellement je ne vois pas le C comme un langage de haut niveau (d'ou ma qualification d' "assembleur amélioré").
- [^] # Re: L'assembleur ou le Scheme
  
  Posté par keyser.dyson le 25 juillet 2014 à 21:13. Évalué à -2.
  
  Le Forth aussi. Encore mieux que l'assembleur.
# Lua

Posté par steph1978 le 25 juillet 2014 à 16:28. Évalué à 2.

J'avais lu, sans le pratiquer, que Lua permettait de se familiariser facilement avec la programmation : affectation, test, boucles, etc.
# APL et Julia

Posté par keyser.dyson le 25 juillet 2014 à 21:20. Évalué à -1.

Il y a aussi l'APL, le J, le Lush et Julia.

Julia est une sorte de Python mais en mieux. Je pense que Julia remplacera le Python dans l'enseignement à terme.

Le J est une sorte d'APL. Ca ressemble a un brainfuck hyper-puissant.

Personne n'a cité Haskell.

Il y a aussi Clojure qui est très intelligent.
- [^] # Re: APL et Julia
  
  Posté par anaseto le 26 juillet 2014 à 13:13. Évalué à 4.
  
  Je te trouve quand même très optimiste : il s'agit de parler du premier langage de programmation qu'on apprend. J'ai beau trouver J et Haskell très intéressants, j'ai l'impression que commencer par ces deux langages est un bon moyen de réduire drastiquement le nombre de vocations de développeur ;)
  
  Ceci dit, ton message me fait penser que ce dont on ne parle pas beaucoup ici, c'est de ce que chacun attend de la programmation. Pour un cours donné à des futurs informaticiens, le mieux c'est de le confronter aux différents paradigmes en lui apprenant plusieurs langages complets pour qu'il maîtrise les différents concepts, sans commencer non plus par haskell. Mais il y a aussi les gens qui ne sont pas informaticiens, mais qui ont besoin de programmer à un moment pour résoudre un problème concret, et là, suivant le besoin, le premier langage devrait être celui qui convient le mieux à résoudre ce problème, car il n'y a rien de plus motivant qu'avoir un vrai problème à résoudre. S'il s'agit de faire un petit script pour extraire des infos à coup de regexps d'un fichier (par exemple dans un projet de traduction vérifier qu'il y a autant de paragraphes dans la version traduite que dans la version originelle), on pourra choisir perl (voire carrément le shell si ce n'est pas trop compliqué). Si c'est un statisticien qui veut faire des calculs matriciels, il choisira julia, R, octave ou autre langage du style, voire même J.
  - [^] # Re: APL et Julia
    
    Posté par keyser.dyson le 26 juillet 2014 à 17:41. Évalué à 0.
    
    J'ai beau trouver J et Haskell très intéressants, j'ai l'impression que commencer par ces deux langages est un bon moyen de réduire drastiquement le nombre de vocations de développeur ;)
    
    C'est vrai. C'est mieux de commencer avec un langage un peu ludique et concret comme Racket. J'ai vu que tu en parlais sur ton site.
    
    Personnellement, j'ai tout de suite accroché à la programmation dès qu'on m'a montré un ordinateur. Mes premiers programmes en Basic, je les ai écrit sur papier. Je n'avais pas d'ordinateur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.