Question

Dans ma lecture sur le typage dynamique et statique, je continue à venir contre l'hypothèse que sont compilées langues statiquement typé, alors que sont interprétées Les langages typés dynamiquement. Je sais qu'en général, cela est vrai, mais je suis intéressé par les exceptions.

Je voudrais vraiment que quelqu'un donne non seulement quelques exemples de ces exceptions, mais essayez d'expliquer pourquoi il a été décidé que ces langues devraient travailler de cette façon.

Était-ce utile?

La solution

Voici une liste de quelques systèmes intéressants. Il est pas exhaustive!

et compilé typé dynamiquement

  1. Le compilateur Scheme Gambit, Chez Scheme , le compilateur Scheme Larceny Will Clinger, Bigloo du compilateur Scheme, et probablement beaucoup d'autres.

      

    Pourquoi?

    Beaucoup de gens aiment vraiment le schéma. Programmes en tant que données, bon système macro, 35 années de développement, grande communauté. Mais ils veulent la performance. Par conséquent, un certain nombre de bons compilateurs-Chez-code natif Scheme est encore un produit commercial réussi. (Bytecode interprétées sont gratuits, les codes natifs que vous payez)

  2. Le luajit juste à temps pour le compilateur Lua .

      

    Pourquoi?

    Pour montrer cela pourrait se faire. Et puis, les gens ont commencé à comme se speedup 3x sur leurs programmes de Lua. Lua est dans beaucoup de jeux, où les questions de performance, plus il est rampant dans d'autres produits aussi. 70% du code dans Adobe Lightroom est Lua.

  3. Le iconc href="http://www.cs.arizona.edu/icon/" rel="noreferrer"> Icône compilateur -À-C.

      

    Pourquoi?

    Les cinquante personnes qui l'ont utilisé aimé Icône. modèle d'évaluation tout à fait inhabituelle, les plus innovants (et à mon avis, le meilleur) système de traitement de chaîne jamais conçu. Mais ce modèle d'évaluation était vraiment cher, surtout sur les ordinateurs fin des années 1980. En compilant Icône à C, le projet Icône a permis pour les grands programmes d'icône pour exécuter en moins d'heures.

Conclusion : les gens développent d'abord une pièce jointe à un langage typé dynamiquement, et probablement une base de code significatif. Finalement, la communauté recrache un compilateur de code natif afin que vous puissiez obtenir de meilleures performances et de résoudre des problèmes plus importants.

dactylographiée et Interprété statiquement

Cette catégorie est moins fréquente, mais ...

  1. Objectif Caml. Dialecte de ML, véhicule beaucoup d'expériences innovantes dans la conception du langage.

      

    Pourquoi?

    Système très portable et les temps de compilation très rapide. Des gens comme les deux propriétés, de sorte que les nouvelles idées de conception des langues sont largement desseminated.

  2. Moscou ML. Standard ML avec quelques fonctionnalités supplémentaires du système de modules.

      

    Pourquoi?

    temps de compilation portable, rapide, facile à faire une lecture / Eval / boucle d'impression interactive. Est devenu un compilateur d'enseignement populaire.

  3. C-Terp. Un vieux produit, je pense que peut-être de Gimpel Software. Sabre C-un produit que je ne pense pas que vous pouvez acheter plus.

      

    Pourquoi?

    Debugging. Surtout, le débogage sur le matériel sous MS 1980-DOS. Pour très peu de ressources, vous pourriez obtenir vraiment bonne aide le débogage du code C sur du matériel très limité (pensez: processeur 4.77MHz avec un bus 8 bits, 640K de mémoire vive entièrement chargée). Presque impossible d'obtenir un bon débogueur visuel pour le code natif compilé, mais avec l'interprète, assez facile.

  4. UCSD Pascal-système qui a fait "P-code" un mot de ménage.

      

    Pourquoi?

    Les enseignants aiment la conception du langage de Niklaus Wirth, et le compilateur pourrait fonctionner sur très petites machines. la conception propre de Wirth et le système P UCSD fait une combinaison imbattable, et Pascal la langue d'enseignement classique des années 1970. Les jeunes peuvent trouver difficile de comprendre que dans les années 1970 il y avait pas de débat sur la langue à enseigner dans le premier cours. Aujourd'hui, je sais que des programmes utilisant C, C ++, Haskell, Java, ML et Scheme. Dans les années 1970, il était toujours Pascal, et le système P UCSD était une grande entrée de la raison.

    Dans le cas où vous vous demandez, P était portable .

Résumé : L'interprétation d'un langage typé statiquement est un excellent moyen d'obtenir une mise en œuvre entre les mains de tout le monde rapidement. (Il avait également des avantages pour le débogage sur le matériel Age du Bronze.)

Autres conseils

Objective-C est compilé et prend en charge le typage dynamique (certainement lorsque l'appel de méthodes via la syntaxe de [target doSomething]). Autrement dit, vous pouvez envoyer tout message à une cible (en utilisant la syntaxe du langage ordinaire, sans programmation contre une API de réflexion), ne reçoivent qu'une mise en garde au moment de la compilation qu'il pourrait ne pas être manipulé, et recevoir une seule exception à l'exécution si la cible doesn « t répondre à ce sélecteur (qui est comme une signature de la méthode); et vous pouvez demander à tout objet (qui peut tous être de id de type statique si votre code ne sait pas mieux ou ne se soucie pas) si elle respondsToSelector: pour sonder ses capacités.

Java utilise (un langage typé statiquement) est compilé en bytecode JVM, qui a été interprété sur les anciennes versions de la machine virtuelle Java, alors que maintenant la compilation Just In Time (JIT), ce qui signifie code machine est générée lors de l'exécution. Je crois aussi ML et ses dialectes peut être interprété, et ML est certainement statiquement typé.

Actionscript a typage dynamique et compile en bytecode.

Et il compile même jusqu'au code machine natif si vous voulez libérer une application Flash sur l'iPhone.

Python est un langage dynamique qui a compilateurs.

Voir cette question SO -. Python - why compile?, par exemple

En général, la compilation rend le programme fonctionne beaucoup plus rapidement.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top