Les langages de programmation doivent-ils être stricts ou lâches? [fermé]

En Python et JavaScript, les points-virgules sont facultatifs.

En PHP, les guillemets autour des clés de tableau sont facultatifs ( $_GET[key]vs $_GET['key']), bien que si vous les omettez, il recherchera d'abord une constante de ce nom. Il permet également 2 styles différents pour les blocs (deux-points ou accolade délimitée).

Je suis en train de créer un langage de programmation et j'essaie de décider à quel point je devrais le rendre strict. Il y a beaucoup de cas où les caractères supplémentaires ne sont pas vraiment nécessaires et peuvent être interprétés sans ambiguïté en raison des priorités, mais je me demande si je devrais toujours les appliquer ou non pour encourager la cohérence.

Qu'est-ce que tu penses?

D'accord, mon langage n'est pas tant un langage de programmation qu'un langage de modèle sophistiqué. Une sorte de croisement entre les modèles Haml et Django . Destiné à être utilisé avec mon framework web C #, et censé être très extensible.

Différents types de langues ont des utilisations différentes, donc la réponse à cette question dépend vraiment de l'utilisation que vous en ferez.

Par exemple, Perl est un langage très lâche, et je le trouve très utile pour écrire des scripts de correction rapide ou de calcul de nombres. Pour les projets solides et robustes, j'utilise C #.

Vous devez trouver le bon équilibre pour l'utilisation cible. Plus elle est stricte, plus vous devez passer de temps à écrire le code, mais vous obtenez plus de robustesse, de réutilisabilité et de maintenance.

Ce que je recherche dans un langage de programmation (par opposition à un langage de script), c'est la cohérence et le typage fort.

Dans les langages de programmation actuels, il est possible d'omettre le point-virgule par exemple à certains endroits sans devenir ambigu (la dernière expression d'un {}bloc en est une). Si un langage de programmation vous permet d'omettre des caractères dans ces cas, un programmeur a maintenant un problème supplémentaire; en plus de la syntaxe générale du langage, elle doit maintenant savoir dans quels cas il est également possible d'omettre des parties de la syntaxe.

Cette connaissance supplémentaire n'est pas un problème pour le programmeur qui écrit le code, mais elle devient un fardeau pour quiconque doit interpréter le code existant à un moment ultérieur (y compris l'auteur d'origine après un certain temps).

Votre exemple PHP ouvre la possibilité de bugs subtils dans un programme lorsque la constante keyserait ajoutée dans le même contexte. Le compilateur n'a aucun moyen de savoir que ce n'est pas ce que l'on voulait dire, donc le problème n'apparaît qu'au moment de l'exécution au lieu de la compilation.

Chaque fois qu'il y a une ambiguïté, le compilateur doit avoir un moyen de deviner ce que le programmeur voulait vraiment dire. Chaque fois que cela se produit, il y a une chance que le programmeur ait vraiment voulu dire quelque chose de différent, mais n'a pas aboli la règle de résolution d'ambiguïté.

Il est déjà assez difficile d'écrire du code logiquement correct. L'ajout d'ambiguïtés syntaxiques peut sembler "convivial" à première vue, mais c'est une invitation ouverte à introduire de nouveaux bogues inattendus et difficiles à déboguer dans la base de code. En bout de ligne, soyez aussi strict que possible.

Dans votre exemple, vous avez mentionné que les points-virgules sont facultatifs en Python et JavaScript. Pour Javascript, au moins, ce n'est pas entièrement vrai. Les points-virgules sont tout aussi requis dans JS que dans tout autre langage de la famille C. Mais l'analyseur JavaScript est requis par la spécification du langage pour insérer des points-virgules manquants dans certaines circonstances. Ceci est largement considéré comme une très mauvaise chose car il a tendance à se tromper et à bousiller votre code.

La réponse à la façon dont vous devriez rendre votre langue lâche est égale à la réponse à la question posée avec un accent texan "Quelle chance vous sentez-vous, punk?".

Tout le monde n'aurait pas à travailler aussi dur pour coder la cohérence si les langues n'avaient pas autant de variations. Nous n'aimons pas cela lorsque les utilisateurs font des demandes qui augmentent inutilement la complexité, alors pourquoi devrait-on le demander à nos langages de développement?

Ma préférence personnelle est la capacité d'avoir juste assez de rigueur pour attraper mes fautes de frappe, mais avec le moins de passe-partout possible. Je parle de ce problème sur http://www.perlmonks.org/?node_id=755790 .

Cela dit, vous concevez votre langue pour vous-même. Vous devez en faire ce que vous voulez.

J'aime mes langues pour faire ce que je veux dire. Généralement, cela penche assez fort vers le lâche. Je voudrais également pouvoir marquer "strict" sur un élément ou un bloc pour pouvoir déboguer / analyser cette zone limitée.

J'ai généralement tendance à tomber du côté de "Qu'est-ce qui me faciliterait la tâche en tant que programmeur". Bien sûr, cela peut signifier plus d'une chose. En Javascript, il n'y a presque pas de vérification de type, ce qui fonctionne très bien jusqu'à ce que vous rencontriez un bug bizarre. D'un autre côté, à Haskell, il y a beaucoup de vérifications de type qui mettent plus de travail à l'avant, mais encombrent certaines classes de bogues.

Pour être honnête, je vérifierais un tas de langues pour voir ce qu'elles font et essayer de trouver un créneau qu'aucun d'entre eux n'a atteint!

Je ne pense pas qu'il y ait une bonne façon évidente de le faire, ou du moins s'il n'y a pas quelque chose sur lequel les gens ont encore trouvé un consensus. Donc, en créant des langues avec différents types de systèmes, nous apprenons.

Bonne chance.

Je dirais qu'un bon langage de programmation devrait avoir des règles strictes, que les implémentations devraient appliquer de manière cohérente, mais les règles devraient être écrites de manière à être utiles. Je suggérerais en outre que l'on devrait envisager de concevoir un langage pour éviter les cas où la "distance de Hamming" entre deux programmes sensiblement différents n'est qu'un. De toute évidence, on ne peut pas réaliser une telle chose avec des littéraux numériques ou de chaîne (si un programmeur qui voulait dire 123 à la place tape 1223 ou 13, le compilateur ne peut pas très bien savoir ce que le programme voulait dire). D'un autre côté, si la langue devait être utilisée :=pour l'affectation et ==pour la comparaison de l'égalité, et ne pas utiliser un seul= à quelque fin juridique que ce soit, cela réduirait considérablement les possibilités de cessions accidentelles qui étaient censées être des comparaisons et de comparaisons accidentelles qui étaient censées être des cessions.

Je dirais que bien qu'il y ait des endroits où il est utile pour les compilateurs de déduire des choses, une telle inférence est souvent plus utile dans les cas les plus simples, et moins valable dans les cas plus compliqués. Par exemple, autoriser le remplacement de:

  Dictionnaire <complicationsType1, complicationsType2> item =
    nouveau dictionnaire <complicationsType1, complicationsType2 ()>;

avec

  var item = new Dictionary <complicationsType1, complicationsType2 ()>;

ne nécessite aucune inférence de type compliquée, mais rend le code beaucoup plus lisible (entre autres, en utilisant la syntaxe plus verbeuse uniquement dans les scénarios où cela est nécessaire, par exemple parce que le type de l'emplacement de stockage ne correspond pas précisément au type de l'expression la création, aidera à attirer une attention supplémentaire sur les endroits qui peuvent en avoir besoin).

Une difficulté majeure pour tenter une inférence de type plus sophistiquée est que des situations ambiguës peuvent survenir; Je suggérerais qu'un bon langage devrait permettre à un programmeur d'inclure des informations que le compilateur pourrait utiliser pour résoudre de telles ambiguïtés (par exemple en considérant certaines typecasts comme préférables à d'autres), déterminer qu'elles n'ont pas d'importance (par exemple parce que même si deux possibles les surcharges peuvent exécuter un code différent, le programmeur a indiqué qu'elles devraient se comporter de manière identique dans les cas où l'une ou l'autre pourrait être utilisée), ou signaler celles (et seulement celles) qui ne peuvent pas être traitées de l'une des manières ci-dessus.

Pour moi, la lisibilité est la plus importante.

Pour une personne expérimentée avec le langage, la signification d'un fragment de code doit être claire sans avoir à analyser le contexte en profondeur.

La langue doit pouvoir signaler les erreurs aussi souvent que possible. Si chaque séquence aléatoire de caractères crée un programme syntaxiquement correct, cela n'est pas utile. Et si les variables sont créées automatiquement la première fois qu'elles sont utilisées, une faute clientd' orthographe cleintne vous donnera pas d'erreur de compilation.

Outre la syntaxe, le langage devrait avoir une sémantique clairement définie, et c'est peut-être encore plus difficile que de décider d'une syntaxe décente ...

De bons exemples:

• En Java, "1"est une chaîne, 1est un int, 1.0est un double et 1Lest un long. Un regard et vous savez ce que c'est.

• En Java, =c'est l'affectation. Il affecte la valeur pour les types primitifs et la référence pour les types de référence. Il ne copie jamais de données complexes ni ne les compare.

• En Java, appeler une méthode a besoin de parenthèses et de cette façon se distingue clairement des variables - donc, s'il n'y a pas de parenthèses, vous n'avez pas besoin de rechercher une définition de méthode, il s'agit simplement de lire des données.

Mauvais exemples:

• En Java, un symbole comme clientpeut être à peu près n'importe quoi: un élément de chemin de package, un nom de classe ou d'interface, un nom de classe interne, un nom de champ, un nom de méthode, une variable locale et bien plus encore. C'est à l'utilisateur d'introduire ou de respecter les conventions de dénomination ou non.

• En Java, le point .est sur-utilisé. Il peut s'agir d'un séparateur dans le nom du package, d'un séparateur entre le package et la classe, d'un séparateur entre la classe externe et interne, d'un connecteur entre l'expression d'instance et la méthode à invoquer sur l'instance, et bien d'autres.

• Dans de nombreuses langues, les accolades des ifblocs sont facultatives, ce qui conduit à des erreurs désagréables si quelqu'un ajoute une instruction de plus au bloc (pas vraiment existant).

• Opérateurs Infix: parfois je dois m'arrêter sur une expression numérique et réfléchir sérieusement à ce que cela signifie, étape par étape. Nous sommes tous habitués à écrire des expressions mathématiques en notation infixe comme a * b / c * d + e. La plupart du temps, nous nous souvenons de la priorité de la multiplication et de la division sur l'addition et la soustraction (mais saviez-vous que nous ne divisons pas par c*d, mais que nous divisons uniquement par cpuis que nous multiplions par d?). Mais il y a tellement d'opérateurs d'infixes supplémentaires avec leurs propres règles de priorité et dans certaines langues, la surcharge est difficile à suivre. Peut-être que l'application de parenthèses avait été une meilleure approche ...

Vous pourriez envisager une analogie avec le langage naturel. Dans le courrier électronique, êtes-vous un nazi de grammaire? Ou êtes-vous d'accord avec certaines erreurs grammaticales, telles que les infinitifs divisés, les conjonctions manquantes ou les modificateurs mal placés. La réponse se résume à une préférence personnelle.