La syntaxe est-elle vraiment importante dans un langage de programmation? [fermé]

Un de mes professeurs a déclaré que "la syntaxe est l'interface utilisateur d'un langage de programmation". Des langages comme Ruby sont très lisibles et en croissance, mais nous voyons beaucoup de programmeurs productifs avec C \ C ++. devrait être acceptable?

J'aimerais connaître votre opinion à ce sujet.

Déni de responsabilité: je n'essaye pas de commencer un argument. Je pensais que c'était un bon sujet de discussion.

Mise à jour: Cela s'avère être un bon sujet. Je suis heureux que vous y participiez tous.

Oui. Si vous avez des doutes, prenez APL , J , Brainfuck ou même Lisp ou Forth, et tentez de comprendre tout programme qui ne soit pas tout à fait trivial. Comparez ensuite à, par exemple, Python.

Comparez ensuite le même Python (ou Ruby, ou même C #) à des éléments comme Cobol ou VB6.

Je n'essaie pas de dire que la syntaxe poilue est mauvaise et que la syntaxe semblable au langage naturel est bonne dans toutes les circonstances. Mais la syntaxe des objections fait une énorme différence. En résumé, tout ce que vous pouvez écrire dans le plus beau langage de programmation que vous pouvez aussi écrire en tant que programme pour machine de Turing - mais vous ne voulez généralement pas, n'est-ce pas?

En pratique, je pense que c'est important. La lisibilité a déjà été discutée ci-dessus. Une autre question pourrait être combien de frappes sont nécessaires pour exprimer une idée / un algorithme? Un autre problème réside dans la facilité avec laquelle il est difficile pour un œil humain de saisir des fautes de frappe simples et dans les dégâts qu’ils peuvent causer.

J'ai également trouvé utile dans certains contextes d'analyser et / ou de générer des fragments de code via un autre programme informatique. La difficulté d’analyser le langage et / ou de générer le code correct a alors un impact direct sur l’effort requis pour créer / maintenir de tels outils.

Je crois que votre professeur fait référence au sucre syntaxique .

Le terme sucre de syntaxe est un terme informatique qui désigne la syntaxe dans un langage de programmation conçu pour faciliter la lecture ou l’expression des choses, alors que d’ autres manières de les exprimer existent .

Donc, ce que votre professeur suggère, c’est que tout code / syntaxe écrit dans un langage de programmation puisse être exprimé dans d’autres langages de la même manière - ou même dans le même langage.

Tirant du théorème de la programmation structurée , Robert Martin a résumé ce que les programmeurs font fondamentalement avec les langages de programmation lors de son discours au RailsConf 2010: Robert Martin (vidéo YouTube, voir au bout de 14 minutes, bien que je le recommande dans son ensemble):

• Séquence (affectation)
• Sélection (si déclarations)
• Itération (boucles)

C’est ce que font tous les programmeurs, d’un langage à l’autre, avec une syntaxe ou une interface utilisateur différente. C’est ce que je suppose que votre professeur voulait savoir s’il parle de façon abstraite des langages de programmation.

Donc, par essence , la syntaxe n'a pas d'importance . Mais si vous voulez être spécifique, il est évident que certaines langues et syntaxes sont mieux adaptées à certaines tâches que d’autres, ce qui vous permet de dire que la syntaxe est importante.

Oui et non.

La syntaxe comporte deux aspects différents.

• lisibilité
• expressivité
• analysabilité

La lisibilité a déjà été mentionnée.

L'expressivité est un cas intéressant. Je vais utiliser le passage de fonction à titre d'exemple, parce que c'est en quelque sorte un point d'inflexion de douleur sémantique / syntaxique.

Prenons C ++ par exemple. Je peux créer une fonction de premier ordre de cette façon:

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

Cet idiome particulier est couramment utilisé dans les éléments de programmation de Stepanov .

D'autre part, je peux l'imiter dans Common Lisp avec quelque chose comme ceci :

(defun myfunc() )

(defun run_func(fun)
  (fun))

Ou, en Perl -

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

Ou, en Python -

def myfunc():
    pass

def run_func(f):
    f()

Celles-ci ont toutes - essentiellement - le même contenu sémantique, bien que l'exemple C ++ comporte des métadonnées de type. Quelle langue exprime l'idée de passer au mieux une fonction d'ordre supérieur? Common Lisp fait à peine une variation syntaxique. C ++ nécessite la création d'une classe simplement pour "porter" la fonction. Perl est assez simple en ce qui concerne la différenciation. Python aussi.

Quelle approche convient le mieux au domaine problématique? Quelle approche peut le mieux exprimer les pensées dans votre tête avec le moins de "décalage d'impédance"?

La paralysie est - dans mon esprit - un gros problème. En particulier, je fais référence à la capacité de l'EDI à analyser et à découper le langage sans commettre d'erreur. Le reformatage est utile. Les langues délimitées par des jetons ont tendance à bien analyser - ruby ​​/ c / pascal, etc.

Cependant, considérez que de grands systèmes de toutes sortes ont été créés avec tous les langages sérieux pour résoudre les problèmes du monde réel. Bien que la syntaxe soit un obstacle à l’expression de certaines choses, c’est un obstacle qui peut être contourné. L'équivalence de Turing et tout ça.

La syntaxe compte vraiment, bien que vous ayez tendance à la remarquer davantage quand elle est peu intuitive et encourage les bogues. Par exemple, la fameuse blague du "dernier bogue du monde":

if (AlertCode = RED)
   {LaunchNukes();}

La syntaxe est importante, et je peux vous donner deux exemples à l'appui: Dylan, qui est un Lisp avec une syntaxe plus conventionnelle, et Liskell, qui est Haskell avec une syntaxe de type Lisp. Dans chaque cas, une variante du langage a été proposée qui avait exactement la même sémantique, mais une syntaxe radicalement différente.

Dans le cas de Dylan, on pensait que laisser tomber les expressions s en faveur de quelque chose de plus conventionnel aiderait à attirer un plus grand nombre de programmeurs. Il s'est avéré que la syntaxe n'était pas la seule chose qui empêchait les programmeurs d'utiliser Lisp.

Dans le cas de Liskell, on pensait que l’utilisation d’expressions s faciliterait l’utilisation des macros. Il s'est avéré que les macros ne sont pas vraiment nécessaires dans Haskell, de sorte que l'expérience n'a pas fonctionné non plus.

Voici la chose: si la syntaxe n'avait pas d'importance pour personne, aucune expérience n'aurait été tentée.

La réponse pourrait être de séparer ce qui "compte" en facteurs informatiques et facteurs humains . Il y a beaucoup de facteurs humains dans la syntaxe:

• Lisibilité
• Concision
• Maintenabilité
• La pédagogie
• Prévention des erreurs
• Adéquation au but recherché - s'agit-il d'un langage REPL, d'un langage de script ou d'un langage système de grande taille?

En ce qui concerne l'ordinateur, le seul problème de syntaxe est de savoir s'il y a des ambiguïtés à résoudre, et combien de temps cela prend pour scinder / analyser le code lors de la compilation / interprétation - et ce n'est que dans le cas de ce dernier où les frais généraux d’analyse constituent un problème important.

C'est peut-être pour cette raison que vous obtiendrez toujours une réponse «oui et non» à cette question, car elle comporte deux aspects.

Sans syntaxe, nous n'aurions pas de "modèle" commun à partir duquel communiquer, à un niveau humain, l'intention d'un bloc de code. Syntax fournit un cadre commun à partir duquel les compilateurs peuvent être normalisés. les méthodes peuvent être partagées; la maintenance peut être simplifiée.

Je pense que ce qui compte vraiment , c'est l' accès aux API et la disponibilité de fonctionnalités de bas niveau (telles que le contrôle de la mémoire et le verrouillage) en cas de besoin. La plupart des autres langues sont livrées avec ces fonctionnalités. Le problème est, lorsque vous avez besoin de fonctionnalités supplémentaires vous devez souvent utiliser un langage comme C pour l’implémenter. Et il est fastidieux d’interfacer C avec le langage que vous utilisez.

Pour tout sauf le développement Web (et les mathématiques), j'ai constaté que C / C ++ est toujours LE langage d'un système d'exploitation et d'une application. C’est ce qui est pris en charge la plupart du temps pour un véritable développement d’applications multiplateformes, préformées et multiplates-formes. Et la syntaxe de C est correcte. Tout simplement très simple et relativement verbeux. La syntaxe incroyable n'a pas vraiment d'importance. La disponibilité de l'alimentation et des API est une nécessité Nous avons tous besoin de nous connecter au code d'autres personnes (qui est la plupart du temps écrit en C ou ses dérivés).

La syntaxe compte vraiment. Il est terriblement précieux si la syntaxe du langage est suffisamment souple pour vous permettre de créer un langage spécifique au domaine, pratique et lisible pour votre application. Si vous en doutez, imaginez-vous faire des problèmes d’algèbre en latin prosaïque, comme avant le XVIIIe siècle, ou imaginez-vous faire des calculs sans la notation de Leibniz, désormais bien connue. Bien sûr, un texte de calcul est illisible pour un novice, mais avec la pratique, nous pouvons utiliser le calcul et la notation de Leibniz pour résoudre rapidement une classe de problèmes nécessitant des pages de mathématiques avec des méthodes classiques. La programmation n'est qu'un autre élément des mathématiques. Une notation commode, proche du domaine du problème, peut faire une énorme différence de productivité.

Voici un programme qui calcule la faculté de 6:

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

La syntaxe est minimale:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

Il semble y avoir une croyance commune que la syntaxe est ce qui rend une langue difficile. Comme souvent avec la croyance populaire, c'est exactement le contraire qui se produit.

Notez que la syntaxe LISP est uniquement lisible (voire pas du tout) car elle a beaucoup plus de syntaxe que la précédente. Donc, si les fans de LISP vous disent que "la syntaxe n'a pas d'importance", demandez-leur d'être cohérent et essayez le calcul SKI. Ils devront admettre qu'un peu de syntaxe n'est pas si grave après tout.

Je ne pense pas que cela compte au-delà des préférences personnelles. Toutes choses étant égales par ailleurs (performances, capacités, etc.), je vois donc pourquoi on donnerait plus de poids à une syntaxe de langage, mais en choisissant de passer outre les performances de langages tels que c / c ++ ou tout autre langage mieux adapté au poste simplement en raison de: la syntaxe semblerait être une mauvaise idée tout autour.

Oui, la syntaxe est importante, bien que ce soit uniquement pour la lisibilité. Comparer:

for i in range(10):
   print(i)

(Ouais c'est Python) avec

FOR(i<-RNG-<10){PRN<-i}

(Oui, c'est un langage que je viens de créer) Les deux font exactement la même chose, de la même manière, mais la syntaxe est différente et Python est plus facile à lire. Donc, oui, la syntaxe compte vraiment. Même le "sucre syntaxique" compte.

 @property
 def year(self):
     return self._date.year

Est plus facile à lire que

 def year(self):
     return self._date.year
 year = property(year)

Oui, bien sûr.

Si vous voulez initier une grande flamme, demandez aux gens où ils placent le bras d’ouverture en langage C-like. je veux dire

void foo() {
  // blah
}

CONTRE

void foo()
{
  // blah
}

ou même VS

void foo() 
{ // blah
}

Et c'est juste la même langue! Demandez-leur également à propos des espaces, où ils les placent (nom de la fonction et bracet, opérateurs, etc.).

1000 réponses sont garanties!

La syntaxe est importante. Cependant, de nos jours, je dirais que cela est presque entièrement important pour la lisibilité et pas vraiment pour la quantité de frappe nécessaire. Pourquoi?

• À moins que vous n'écriviez vraiment quelque chose d'aussi simple, si le nombre de touches que vous appuyez sur est le facteur limitant dans l'écriture d'un programme, alors vous êtes vraiment, vraiment en train de chier à taper ou de penser beaucoup, beaucoup trop vite.
• Tous les IDE décents de nos jours comportent un grand nombre de raccourcis qui vous évitent de saisir tous les caractères que vous utilisez la plupart du temps.

Cela dit, si elle est trop verbeuse, elle peut en arriver au point où elle affecte la lisibilité. Je préférerais voir quelque chose comme:

foreach (String dans stringList)

À:

pour chaque chaîne qui est dans la liste comme référencé par la variable stringlist

...n'importe quel jour!

Pour ceux qui l’apprennent, la syntaxe est importante: plus la barrière à l’entrée est basse, plus la langue pourrait être populaire au départ. Mais si la langue est difficile ou impossible à exprimer de manière riche et succincte, elle commencera à dépérir.

Très laconique et opaque (Perl) est aussi grave que trop verbeux et verbeux (AppleScript).

Il doit y avoir un équilibre, une barrière d'entrée réduite, une productivité élevée et un entretien facile.

Une autre chose à considérer est que les langages de programmation avec une syntaxe plus agréable sont plus faciles à analyser, ce qui rend le compilateur plus facile à écrire, plus rapide et moins sujet aux bogues.

Pour le dire simplement: la syntaxe en tant que telle n'a pas d'importance. La sémantique que vous pouvez exprimer à travers elle est importante.