Les bases de la programmation

Ou comprendre ce qu’est un programme, un langage de programmation, l’algorithmique.

Le problème exposé dans ce sujet a été résolu.

Tu peux paralléliser les opérations qui demandent des IOPS (surtout sur le réseau) avec des coroutines.

J'ai bien parlé de "programmation parallèle" pas de "calcul parallèle" qui ici demandera plutôt du multiprocess ou des algorithmes de distribution du calcul que ça soit au niveau matériel (NUMA) ou bien à plus grande échelle (calcul sur plusieurs ordinateurs).

+0 -0

Concernant le schéma récapitulatif, j'avais pensé à un truc du genre :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
                  Langage
                     |
                Code source
                     |
          Compilateur/Interpréteur
                     |                
                 Programme
                /        \
               /          \
              /            \
             /              \
            /                \ 
           /                  \
     Bibliothèques ------> Logiciels
      logicielles
+0 -0

Vers l’exécutable, et au-delà !

ce qui signifie qu’il sera plus rapide que s’il était interprété

Certes, tu as déjà parlé rapidement d'interpéteur dans l'extrait précédent, mais j'ai peur que le débutant bute sur le terme "interprété".

Cela peut s’avérer un inconvénient

Il me semble que le "Cela" fait référence au fait que "le fichier exécutable généré sera optimisé pour [n]otre machine", mais on pourrait l'associer à "ce qui signifie qu’il sera plus rapide que s’il était interprété, et qu’il prend généralement moins de place sur le disque dur que son code source".

La différence dans la vitesse d’exécution est loin d’être négligeable

Cette phrase fait un peu rupture avec le paragraphe précédent. Afin de remédier à cela, et au problème mentionné juste au-dessus, peut-être pourrait-on reformuler le tout de la manière suivante ?

La compilation présente l’avantage que le fichier exécutable généré sera optimisé pour votre machine. Cela peut par contre s’avérer un inconvénient si votre programme est destiné à être diffusé auprès d’autres gens : il faudra soit leur fournir le code source et les laisser le compiler par leurs propres moyens2, soit fournir un exécutable différent pour chaque système d’exploitation et pour chaque type de processeur, et donc répéter autant de fois la compilation à chaque mise à jour du programme, ce qui devient très vite fastidieux.

Du fait de l'optimisation effectuée par la compilation, le fichier exécutable sera plus rapide que s’il était interprété, et qu’il prend généralement moins de place sur le disque dur que son code source. Or la différence dans la vitesse d’exécution est loin d’être négligeable

Ce n'est pas excellent, mais ça donne une idée que ce qui peut se faire. :)

(toutes autres choses égales)

Peut-être préciser cela, en disant que, par exemple, on est sur la même machine ?

(par exemple, il faut impérativement que chaque image d’un film soit décodée et affichée à l’écran en moins d’un 24e de seconde)

Je ne comprends pas trop ça. Tu parles juste avant d'effectuer plein de petites tâches, alors qu'ici, tu mentionnes le fait d'en réaliser une en un temps limité. J'ai du mal à voir en quoi ça illustre ce qui précède.

vous diffusez directement le code source, qui est prévu pour !

J'ai un peu buté sur la fin de la phrase. Peut-être pourrait-on la reformuler en "qui est prévu pour l'être" ?

par exemple, l’interpréteur Perl

Peut-être mentionner que Perl est un langage : l'interpréteur du langage Perl ?

Le Python est un langage interprété.

Sacrebleu ! Un code qui ne respecte pas la PEP-08 ! :P

on trouve les langages à machine virtuelle, souvent raccourcis en « langages à VM » d’après l’anglais virtual machine, qui ont un pied dans chaque monde

Le "qui ont" fait un peu bizarre, vu qu'il n'apparait pas directement à la suite de "les langages à machine virtuelle".

Le principe en est de compiler le code source non pas en code machine compréhensible par un processeur donné, mais en un code machine « fictif » (généralement appelé bytecode) qui sera lui-même interprété par la machine virtuelle associée au langage.

Si je ne dis pas de bêtise, il existe cette notion de bytecode en Python, qui, pourtant, est un langage interprété.

le programme compilé en bytecode peut-être exécuté

peut être

Les langages interprétés utilisent la plupart du temps une compilation « à la volée ». Cela signifie que les langages compilés peuvent faire de même, et certains ne s’en privent pas.

Sans l'exemple avec Haskell, je n'aurais pas compris la seconde phrase. En effet, tu parles des langages interprétés, puis des compilés, et je ne comprends pas trop à quoi fait référence le "faire de même".

Enfin, pour des raisons de portabilité de l’interpréteur, il n’est pas rare que les langages interprétés ne soient pas transformés directement en code machine de l’ordinateur sur lequel ils sont exécutés, mais passent par un bytecode intermédiaire, qui est exécuté par une machine virtuelle intégrée à l’interpréteur.

Je comprends ce paragraphe uniquement parce que j'ai un semblant de bases en compilation et que je sais qu'on compile toujours vers un langage intermédiaire (comme le fait pandoc). Peut-être qu'il pourrait être intéressant d'expliciter rapidement le "pour des raisons de portabilité de l’interpréteur", voire d'illustrer ça avec un schéma (comment ça je suis relou avec mes schémas ?) ?

Et puis, la question qui vient fatalement : mais si on utilise une VM, ce n'est plus un langage interprété, si ? Je crois que c'est la même que celle que j'ai posée à propos de Python et des fichiers .pyc.

La différence entre langage interprété et langage à VM n'est pas très claire, notamment à cause du fait qu'on a dans les deux cas une étape intermédiaire (interpréteur ou VM). Peut-être que faire des schémas permettrait de bien différencier les deux, du moins plus facilement qu'en relisant le texte plusieurs fois ?

+0 -0

La différence entre langage interprété et langage à VM n'est pas très claire, notamment à cause du fait qu'on a dans les deux cas une étape intermédiaire (interpréteur ou VM).

Et aussi parce que cette distinction est une énorme simplification de la réalité. Sur l'exemple de Python, on a CPython qui possède un mode avec compilation vers bytecode (.pyc) et un mode interpréteur (où le bytecode n'est pas sauvé sur le disque), JPython où on a compilation vers le bytecode de la JVM, IronPython avec compilation vers le bytecode .NET, PyPy où on a compilation vers le code machine à la volée, nuitka où on a compilation vers le code machine en différé, …

Globalement, il faudrait parler d'implémentation des langages et pas des langages eux-même (on a des interpréteurs C++, cf cling), et bien se rendre compte que la limite n'est pas claire. Mais toutes ces données sont complexe et hors de propos pour un cours débutant. Toutefois, pourquoi ne pas mettre une phrase du type "Toutefois la réalité est plus complexe, et cette distinction entre langages interprétés et compilés est n'est pas si marquée."

+0 -0

Je remonte ce sujet pour venir aux nouvelles : pour moi, ce contenu était très proche d'une validation au moins pour une v1, du coup je m'étonne un peu de ne pas le voir revenir. Et franchement vue la qualité et l'utilité du contenu déjà existant, ce serait dommage qu'il reste coincé en bêta si proche du but.

Je reste à votre disposition si vous avez besoin d'aide ou des questions, que ce soit ici ou en MP.

Edit : typo

+2 -0

La dernière partie ne me semble pas très pertinente : si cette partie doit permettre au lecteur de « choisir un premier langage de programmation à apprendre », je ne comprends pas ce que font le COBOL ou l'Assembleur parmi les premiers de la liste.

PS: « OCaml est également un langage fonctionnel, plus classique que le Erlang, et doté de moins de fonctionnalités que le Haskell. » et « Haskell est sans contexte le langage par excellence du paradigme fonctionnel. » m'ont fait tousser.

+2 -1

Il faut que je prenne le temps de la relire en entier.

La première remarque faisait écho à la pertinence de présenter autant le matériel en début de tuto. Je trouve l'explication donnée ici très pertinente, mais pas forcément très claire en lisant le tuto, d'où ma réflexion.

+1 -0

Dans la partie où il est question des IDE, je pense qu'un débutant serait totalement perdu dans le choix innombrable des IDE/éditeurs/compilateurs. Il serait bon à mon avis d'ajouer une phrase disant que le plus simple pour un débutant est sans doute d'utiliser les outils conseillés par le tutoriel qu'il va utiliser, et qu'au pire il sera toujours temps d'en essayer d'autres plus tard.

Pour la partie sur les frameworks, après la petite blague du randonneur, peut-être préciser : ça dépend de ce que vous souhaitez réaliser, une balade en forêt ou la visite complète du Mont Saint-Michel ?

La partie sur les langages est, je trouve, très bien écrite. Il est écrit ce qu'il faut, et pas plus ! Mais personnellement, j'apprécierais qu'il soit précisé quels langages sont interprétés ^^ Et j'ajouterais que l'utilisation de Java pour le Web est plutôt très spécifique et peu utile à quelqu'un ne souhaitant pas être dev de métier (mais ça, sûrement mon côté dev Java qui ressort).

Vraiment un excellent tuto je trouve ! Un style très agréable, de bonnes informations bien expliquées. Mais le seul reproche que j'aurais, c'est qu'il ne correspond pas (pour moi) au titre du tuto. Je m'attendais plus à quelque chose de ce genre. Peut-être le nommer Introduction aux langages de programmation ?

Bon boulot, continuez comme ça ^^

+0 -0
Ce sujet est verrouillé.