human
Comment les ( nouveaux ) langages de programmation / codage sont créés . Comment quelqu'un peut-il produire un nouveau langage de programmation à l'usage des programmeurs ? Comment les systèmes d'exploitation des différentes plates-formes reconnaissent-ils le nouveau langage ? Explique comme si j'avais cinq ans.
gpt
Vous posez ici deux questions différentes. Je vais essayer de traiter les deux : > Comment quelqu'un peut-il produire un nouveau langage de programmation pour les programmeurs ? Quelqu'un produit un nouveau langage de programmation simplement en l'imaginant. Si un programmeur se réveille un jour et dit « Les outils dont je dispose sont nuls. Je veux quelque chose de mieux », il peut concevoir son propre langage s'il le souhaite. C'est beaucoup de travail, car il y a * * beaucoup * * de choses que la plupart des langages de programmation modernes peuvent faire et vous devez toutes les couvrir si vous voulez que votre langage aille n'importe où. Vous devez aussi vous poser quelques questions : * Interprété ou Compilé ? Les langages interprétés examinent le code écrit et exécutent chaque instruction au fur et à mesure qu'ils l'analysent. Les langages compilés prennent tout le code et le convertissent en [Assembly] (URL_0), qui est un autre langage, quoique de très très bas niveau. Comme cela a déjà été souligné sur ce fil, Java est à mi-chemin entre les deux. Les langages compilés sont généralement plus rapides , mais aussi moins * portables * -- c'est - à - dire qu'un programme compilé pour Windows ne fonctionnera pas sous UNIX . La langue interprétée fonctionne généralement partout où ils vont. * Dans quel environnement fonctionnera-t-il ? Si vous écrivez un langage pour Windows, c'est une chose. Si vous l' écrivez pour UNIX , c'en est une autre . Il peut également s'exécuter à l'intérieur d'un navigateur, ce qui entraîne d'autres complications, comme la sécurité, qui doit être beaucoup plus stricte que dans une application exécutée localement. Il ya cependant des avantages , car cela signifie que votre langue n'aurait pas besoin de * * faire * * autant de choses différentes . Après avoir décidé cela, vous devrez construire soit un interpréteur, soit un compilateur. Un interpréteur est un programme qui lit le langage écrit et exécute les instructions du code ligne par ligne. Un compilateur est un programme qui lit le code écrit et le convertit en assemblage qui est écrit dans un fichier compilé. Pour Windows, l'exemple évident est un fichier .EXE. Pour UNIX, il n'y a pas d'extension de fichier magique. Au lieu de cela, il y a un drapeau défini dans les propriétés du fichier qui le marque comme exécutable. > Comment les systèmes d'exploitation des différentes plateformes reconnaissent-ils le nouveau langage ? Pour les fichiers compilés, c'est facile. Les systèmes d'exploitation ont leurs propres règles concernant les fichiers exécutables. Vous compilez votre code dans le fichier exécutable qui suit les règles établies par le système d'exploitation. Le * langage * utilisé pour produire ce fichier n'a aucune importance. Windows ne se soucie pas de savoir si le fichier .EXE a été écrit à l'origine en C , C++ , C # , Java , J++ , Delphi , VB ou une demi-douzaine d'autres langages auxquels je n'ai pas pensé du haut de ma tête . Pour les langages interprétés, ce n'est que légèrement plus compliqué. Le système d'exploitation désigne un programme "gestionnaire" qui traite certains types de fichiers. Ainsi, si vous trouvez un fichier .py, Windows sait qu'il doit l'ouvrir avec l'interpréteur Python, car lorsque l'environnement Python a été installé, il s'est *enregistré* comme le programme à appeler lorsqu'il rencontre des fichiers .py. De même pour les fichiers Perl , etc ... Pour UNIX , je ne sais pas s'il existe cette fonction , mais vous pouvez toujours appeler explicitement dans le shell l' interpréteur , vous dites donc au système d' exploitation d' exécuter l' interpréteur , en utilisant le nom de fichier de votre programme perl ou python comme argument du programme. Il pourrait y avoir cette fonction de « gestionnaire officiel » intégrée à UNIX, je n'en suis pas sûr. Ou peut-être n'est-il fourni que par XWindows ou d'autres interfaces graphiques. Il est également important de garder à l'esprit que vous ne voyez jamais vraiment le système d'exploitation. Vous pensez que vous avez affaire au système d'exploitation lorsque vous êtes dans une invite de commande (ou, sous UNIX, le shell ?) Enfer non. Vous avez affaire à une abstraction qui vous donne une interface en ligne de commande. Il y a encore une demi-douzaine de couches entre vous et le système d'exploitation. La merde qui se passe au niveau du système d'exploitation est ridiculement ésotérique - Prendre des valeurs situées au registre 6655321 et les déplacer vers le registre 6655322, basculer un peu ici ou un peu là, regarder la valeur d'un bit et se brancher sur un autre segment d'instructions basé sur qu'il s'agisse d'un un ou d'un zéro, etc... Ce que vous appelez la ligne de commande ou le shell n'est qu'un interpréteur en direct d'un langage de programmation limité. Pour Windows, c'est le langage des fichiers batch. Pour UNIX, il existe plusieurs options, comme le shell Bourne, le shell C, le shell Korn et des centaines d'autres, toutes avec différents niveaux de compatibilité entre elles. Si votre script est compatible avec l'un de ces shells, vous pouvez simplement l'exécuter * depuis ce shell *, et boum, il est reconnu. Il existe une vieille règle , qui n'est vraiment plus pertinente aujourd'hui à l' époque de Perl et Python , et d' autres langages spécialisés comme Javascript ( navigateur uniquement ) ou Ruby ( serveur Web uniquement ) , mais à l' époque , si vous vouliez savoir si vous aviez un langage * orthogonal et complet * vous deviez pouvoir utiliser ce langage pour écrire un compilateur * pour le langage * ! Donc si vous avez inventé un langage , appelez - le D , ( vient après C ) , et que votre compilateur était complet , vous écririez votre compilateur * * next * * D entièrement en D.