Langages dynamiques vs langages statiques pour sites Web [fermé]


13

Cette déclaration suggère que les langues typées statiquement ne sont pas idéales pour les sites Web:

Je comparerai cela à la construction d'un site Web. Lors du rendu de pages Web, vous avez souvent de très nombreux composants interagissant sur une page Web. Vous avez des boutons ici et des petits widgets là-bas et il y en a des dizaines sur une page Web, ainsi que des dizaines ou des centaines de pages Web sur votre site Web qui sont toutes dynamiques. Avec un système avec une très grande surface comme celle-ci, l'utilisation d'un langage typé statique est en fait assez rigide. Je trouverais probablement douloureux de programmer dans Scala et de rendre une page Web avec, quand je veux pousser interactivement les boutons et quoi. Si tout le système doit être cohérent, comme tout le système doit taper check juste pour pouvoir déplacer un bouton, je pense que cela peut être vraiment inflexible.

Source: http://www.infoq.com/interviews/kallen-scala-twitter

Est-ce correct? Pourquoi ou pourquoi pas?


6
On dirait qu'ils ne considéraient pas un langage / package avec une hiérarchie d'objets appropriée. Pas besoin de vérifier si le contrôle que vous déplacez est un Buttonmoment où WebControlcontient toutes les informations dont vous avez besoin et tous les contrôles en sont dérivés.
Matthew Read

5
Yup @Matthew - sonne comme quelqu'un qui ne connaît pas vraiment le polymorphisme
Nicole

8
Aussi - Twitter peut être populaire, mais ce n'est pas parce que leur site est un chef-d'œuvre d'ingénierie.
Nicole

Réponses:


39

Je suis totalement en désaccord. À mesure que les systèmes grandissent, les langages typés statiquement garantissent la robustesse au niveau des composants et donc la flexibilité au niveau du système.

De plus, l'exemple donné par l'auteur n'a pas vraiment de sens. Il semble plutôt que ce type ne sait pas que le polymorphisme peut être obtenu par d'autres moyens que le typage de canard.

Il y a un certain nombre de personnes qui prétendent que les langages dynamiques sont supérieurs, mais cela est généralement basé sur leur manque d'expérience avec les systèmes de types expressifs qui prennent par exemple en charge le sous-typage structurel, les types de données algébriques et les fonctions de premier ordre.


1
Comment les fonctions de premier ordre entrent-elles dans la même catégorie que les sous-types structurels et les types de données algébriques? Vous donnez l'impression que les langages dynamiques n'ont pas de fonctions de premier ordre, ce qui n'est clairement pas vrai (Scheme, Common Lisp, Erlang, Smalltalk, ...).
Frank Shearar

21
+1 pour "Il semble plutôt que ce type ne sait pas que le polymorphisme peut être obtenu par d'autres moyens que la frappe de canard."
Nicole

1
@Frank Shearer: Ce que je veux dire, c'est qu'ils sont pris en charge avec le même type de sécurité que toute autre valeur. Il existe un certain nombre de langages strictement typés qui prennent en charge les valeurs de fonction, mais ne font pas de distinction entre les signatures.
back2dos

1
Je ne suis pas d'accord non plus, c'est pourquoi je sélectionne ceci comme réponse.
Bradford


8

Tout d'abord, gardez à l'esprit que l'auteur de la déclaration ci-dessus parle de développement de sites Web. Il est donc inquiet présentation développement de la , et c'est là qu'il pense que Scala ne serait pas un bon choix ...

Cela dit, j'ai une bonne expérience du développement Web. Je travaille depuis au moins 8 ans exclusivement avec elle, dont 5 dans des agences digitales.

Et, oui, d'après mon expérience, un langage compilé de façon statique au niveau de la couche de présentation peut être un gros obstacle. Le contenu doit être modifié en permanence, beaucoup plus souvent que les exigences de l'entreprise. Et généralement, cela doit être fait par une équipe distincte (les développeurs "front-end"). Ils connaissent normalement beaucoup de choses sur HTML, JavaScript, les normes Web, CSS, mais pas beaucoup sur les langages côté serveur comme Java et C #. Ils supposent également que tout type de changement dans un modèle est immédiatement disponible; ils ne sont pas utilisés pour compiler et taper des erreurs. Et ils ont raison: les langages typés statiquement sont très bons pour les exigences dures et complexes, comme l'accès aux données et les règles métier, mais pas aussi bien pour le développement d'interfaces.

C'est, en fait, l'un des principaux avantages de l'utilisation d'un langage de modèle spécialisé et interprété comme Velocity . Sa facilité d'utilisation, sa puissance et sa flexibilité conviennent aux développeurs de couches de présentation. Et puis les gars côté serveur sont libres d'utiliser un langage sérieux et typé partout ailleurs ...

Cependant, je conviens également que Scala est quelque peu différent. Étant à la fois beaucoup moins verbeux et beaucoup plus expressif que Java, je pense qu'il pourrait être utilisé pour le développement de présentations - donc peut-être qu'il pourrait être utilisé avec succès comme langage de modèle. Et s'il pouvait également être combiné à un cadre comme Play (qui compile automatiquement le site Web après chaque changement), il pourrait être un gagnant à mon humble avis. Pourtant, même Play a opté pour un langage de modèle (dynamique) de type Groovy, ce qui n'est pas bon signe.

Pour résumer: le problème avec Scala est beaucoup plus lié au fait qu'il est compilé. En fait, son mécanisme d'inférence de type vous fait presque oublier qu'il est également typé statiquement.

(Et désolé pour mon anglais. Faites-moi savoir si quelque chose n'est pas clair, je vais essayer de le réparer.)


1
J'appuierais ceci - il suffit de regarder le désordre JSP / STRUTS quand ils ont essayé de faire de Java un langage web!
James Anderson

8

Je pense que le texte (et la plupart des réponses) mélange des langues typées statiquement et des langues excessivement verbeuses . Bien sûr, l'intersection est très grande (surtout si l'on considère uniquement les langues les plus courantes); mais il y a quelques exemples intéressants de langages non verbeux, typés statiquement: Go, Haskell, Scala, Rust…


2
Définissez «excessivement». À mesure que les programmes deviennent de plus en plus complexes et que leur durée de vie et leurs cycles de maintenance augmentent, la probabilité qu'une personne autre que l'auteur d'origine ait besoin de déboguer ou de modifier un morceau de code donné continue de croître. Lorsque vous êtes dans cette situation, vous êtes généralement sous le feu des armes, et plus vous disposez immédiatement d'informations sur les données que vous traitez et sur ce qu'elles peuvent faire de mieux. J'ai débogué le Delphi d'autres personnes et le JavaScript d'autres personnes, et le Delphi est des ordres de grandeur plus faciles, en raison de la verbosité et des informations de type.
Mason Wheeler

1
Juste une remarque: quelque chose comme TypeScript (JavaScript, avec des informations de type statiques) pourrait être un moyen simple de tester la théorie de l'OP. Ma courte exposition a été assez agréable - une fois lors de la conversion de JavaScript en TypeScript, cela m'a en fait aidé à trouver qu'il n'y avait aucun moyen d'appeler une certaine méthode et à ne pas produire d'erreur .
Katana314

5

Je vous encourage à lire Strong Typing vs. Strong Testing de Bruce Eckel . Son argument principal est que la qualité du logiciel se résume à des tests. Vous pouvez tester de différentes manières. Les compilateurs testent certaines choses au moment de la compilation: essayez de stocker une chaîne dans une variable int et elle vous aboiera probablement. Dans les langages dynamiques, une grande partie des tests ont lieu lors de l'exécution. En fin de compte, peu importe quand le test a lieu. Cela doit juste arriver. Le temps que vous gagnez à ne pas compiler dans les langages dynamiques est perdu lors des tests lors de l'exécution. Vous testez tout robuste, non?

Étant donné que, une préférence pour les langues compilées avec des systèmes de types rigides par rapport aux langues dynamiques n'est que cela - une préférence. Un peu comme les boxeurs contre les slips ou les tongs contre les slips français. Il n'y a pas de bonne ou de mauvaise réponse. Portez-les avec la bonne attitude et il n'y a que génial.


1
"Les compilateurs testent certaines choses au moment de la compilation: essayez de stocker une chaîne dans une variable int et elle vous aboiera probablement. Dans les langages dynamiques, une grande partie des tests ont lieu au moment de l'exécution.": Vrai, lorsque j'utilise un langage dynamique, il m'arrive pour écrire de nombreux tests qui remplacent la vérification de type. En utilisant un langage statique, mes tests peuvent se concentrer davantage sur la logique métier.
Giorgio

@Giorgio Intéressant, j'ai rarement une logique de vérification de type dans mes tests.
suppliez le

@pllee: Parfois, ce n'est pas directement une logique de vérification de type, mais les tests vérifient un comportement qu'un système de type statique aurait de toute façon appliqué.
Giorgio

Bruce Eckel semble être juste une autre personne ayant passé des années à gérer des langages trop verbeux (Java, C ++, ...) puis à sauter le premier train différent (Python) qu'il rencontre. Il consacre la moitié de l'article à louer l'excellente syntaxe Python. Il n'a rien à apporter à ce débat faute de connaissances.
ziggystar

Mais si vous essayez de stocker une chaîne dans une variable int dans un langage dynamique - bien sûr, vous ne le remarquerez que lorsque vous exécuterez / testerez l'application et la verrez en action. Mais dans la pratique du monde réel (plus de 17 ans de développement), je considère très rarement cela comme la principale cause d'un bug! Déjà! Mais même si c'est le cas - vous le remarquez et vous le corrigez? Quel est le problème? C'est comme si tout l'argument était basé sur un cas de bord rare très technique. Ce n'est pas un gros problème! D'un autre côté, l'avantage du typage dynamique est que le développement est considérablement plus rapide.
Manachi

2

Je suis d'accord avec cela dans la plupart des cas, car avouons-le, lorsque vous traitez avec des clients sur une plate-forme Web, la flexibilité est un must.

Les langages à typage statique sont plus robustes et sécurisés que les langages à typage dinamique, mais lorsque vous commencez à adapter le code pour qu'il ne soit pas censé l'être et que vous en ayez besoin rapidement, les solutions semblent plutôt complexes et rigides.

Donc, si vous avez le changement de fusionner les technologies, je recommanderais de créer un noyau dans un langage typé (le noyau ne change pas beaucoup) et d'utiliser de manière dinamique pour l'interaction avec l'utilisateur.


Le couplage lâche est bon. Mais les langages dynamiques ne sont pas nécessaires pour y parvenir. Voir, le Web est tout sur le couplage lâche fait via HTTP, et la plupart des serveurs Web et des navigateurs sont écrits dans des langages statiques. Les langages dynamiques brillent dans les applications de script lorsque vous avez besoin d'un morceau de code facilement modifiable à l'exécution, sans invoquer une grande chaîne d'outils.
9000

2

Je pense que l'auteur de ce post n'a pas examiné Scala lui-même. Bien que je convienne que Java et C # ont des limites et sont un peu inflexibles pour le développement Web, Scala est un langage typé statiquement qui est assez différent de ce à quoi vous pensez normalement lorsque vous entendez cela. Scala permet de taper du canard ainsi qu'une version sécurisée du patch de singe (via des conversions implicites). Cela rend les bibliothèques de programmation un peu plus complexes car vous devrez penser aux types, mais si vous utilisez simplement une bibliothèque comme Lift, cela ressemble beaucoup à un langage dynamique, sauf que le compilateur vous informera sur les bogues évidents où vous ne l'utilisez pas. droite. Personnellement, je pense que le cadre Web de l'ascenseur n'a pas à se cacher du rubis sur les rails ou similaire. Jetez un œil aux exemples de code ici ou iciet décidez par vous-même. Je me développe en ascenseur depuis un bon moment maintenant et je n'ai jamais eu de situation où j'ai eu une erreur de type et bien que "Ah mec, si c'était dynamique ça marcherait" ... parce que si c'était dynamique ça ne m'aurait tout simplement pas dit que il y avait un bogue jusqu'à ce qu'il se bloque pendant l'exécution.


1

Personnellement, je pense que ce qu'ils disent est vrai pour n'importe quel système, pas seulement pour les sites Web. Vous aurez besoin de la frappe statique lorsque vous parlez au matériel, car tout le reste la frappe dynamique a les mêmes inconvénients et avantages, peu importe ce que vous faites, et ce qui dépend le mieux du goût et des problèmes spécifiques à chaque projet.


Je pense que cela vaut la peine de noter que Scala est un peu spécial car il utilise l'inférence de type et n'appartient donc pas à la même catégorie de typage statique que Java.
Winston Ewert

1

Réponse rapide et pratique: cela dépend de la taille et de la complexité de la taille du Web. Petit site Web, progr. Dynamique. lang., Complex Large Website, progr. statique lang.

Réponse ennuyeuse étendue: De nombreux développeurs insistent sur le fait qu'un site Web doit être fait avec un programme dynamique. langr. mais la vérité est que, finalement, les outils de développement Web ont tendance à utiliser ou à émuler des langages de type statique.

J'ai dû travailler avec PHP plusieurs fois, et tôt ou tard, nous avons dû ajouter beaucoup de code qui vérifie les types de données données, ce qui est implicite dans un programme typé statique. lang.

Tapé Lagn. aide également à l'utilisation des IDE, ce qui nécessite beaucoup de vérification de type.

(apporté par votre voisin progr. & concepteur du compilateur ;-))


0

Je suis d'accord. Quand je regarde la plupart du code C # Web frontal, il y a beaucoup de transtypage des chaînes et de la sérialisation des données en chaînes. Fondamentalement, HTTP en tant que protocole convient parfaitement aux langages dynamiques.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.