J'ai tendance à penser en termes de fonctionnalités:
Syntaxe:
Basé sur C ou quoi d'autre. Java a une syntaxe basée sur C. Je recommande fortement d'essayer quelque chose comme Python ou Ruby pour sortir la tête de la syntaxe et penser davantage en termes de principes de fonctionnement d'un langage donné. Je suis d'avis qu'aucune syntaxe n'a besoin d'être plus volumineuse que celle basée sur C et n'a aucun problème à créer des blocs autour de l'espace blanc.
Compilé vs interprété w. Build-Process vs Interpreted / Console:
Je connais très peu les problèmes liés à l'environnement de compilation par rapport à l'environnement d'exécution, mais je comprends qu'il y a tout un tas de problèmes auxquels je pense rarement.
De même, il existe de nombreux langages interprétés qui ont encore quelque chose d'un processus de compilation pour s'exécuter à l'intérieur d'une machine virtuelle comme Java. Vous devez encore reconstruire pour voir les changements aux choses.
Et puis il y a JavaScript et Python que vous pouvez exécuter à la volée, commande par commande dans une console dans un environnement en direct. Les trois peuvent conduire à des manières très différentes d'écrire du code.
Typage dynamique vs strict:
J'ai tendance à voir les deux comme des compromis de conception. Lorsque vous êtes à un niveau beaucoup plus bas et que les performances sont essentielles, la saisie statique a beaucoup de sens. Je n'ai jamais compris cette notion d'un être "plus sûr" qu'un autre, mais je suis venu dans un langage très plastique / dynamique où vous venez d'apprendre comment fonctionne le système de frappe et à quoi s'attendre, en gros. Les manigances de type sont rarement une préoccupation pour moi dans JS. À certains égards, la flexibilité peut rendre les choses plus robustes, bien que, certes, une touche plus mystérieuse pour un développeur de niveau plus junior si vous ne connaissez pas certains des nids-de-poule dans la langue.
Portée au niveau bloc vs Portée fonction vs?:
Le niveau de bloc est le plus courant (n'importe quoi entre {} dans la plupart des langages de syntaxe basés sur c). La portée JavaScript est construite autour de fonctions (qui sont également utilisées pour construire des objets aussi efficacement). Il existe également une grande variation dans le type d'accès dont vous disposez d'une portée interne à une portée externe. Je ne connais pas les autres schémas de délimitation mais je suis sûr qu'ils existent.
POO classique vs POO prototypique vs Presque-POO (structures en C?) Vs Non-POO:
Même dans la POO basée sur les classes, il y a beaucoup de place pour la variation. Que vous puissiez faire un héritage multiple (ew, bien en excès, ew), définir des interfaces, etc ...
En JavaScript, nous avons une sorte de POO prototypique hybride rabougrie où les objets sont considérablement plus simples, hautement mutables, mais nous avons toujours la possibilité de séparer l'interface des préoccupations internes, ce qui, à mon avis, est l'aspect important de l'encapsulation.
La chose à propos de la POO est qu'il y a vraiment beaucoup de choses que vous pouvez retirer qui sont essentiellement orientées OOP sans être techniquement OOP. Il y a des puristes bien sûr, mais à la fin de la journée, les modèles de conception visent à réaliser certaines abstractions qui fonctionnent bien dans certaines situations. Ne soyez pas trop rapide pour supposer que les idées d'un langage basé sur la POO n'ont aucune utilité dans quelque chose qui est plus orienté vers la procédure. Et je ne parle pas de JavaScript. Il n'est pas du tout limité par sa version maladroite d'un paradigme OOP basé sur un prototype.
Fonctions de première classe:
Ne pas les avoir dans une langue est une chose difficile à abandonner. Vous pouvez transmettre des fonctions comme s'il s'agissait de données à utiliser dans d'autres contextes. Cela rend les schémas de gestion des événements en particulier très faciles à implémenter, mais il est également très facile d'adapter le langage pour qu'il fonctionne comme vous le souhaitez. C'est, plus que tout ce que je soupçonne, ce qui a fait de JavaScript le succès qu'il a ultimement été malgré sa conception en deux semaines et la mise en place d'une syntaxe Java approximative en tant que schéma marketing.
Fermetures:
Je ne sais pas où en est le débat pour Java, mais je sais que beaucoup de développeurs Java réclamaient cette fonctionnalité il y a un an ou deux. Dans un langage sans fermeture, lorsqu'une fonction se ferme, tout ce qui est en mesure de référencer quelque chose de l'intérieur de cette fonction ne pourra pas y accéder car il a été récupéré. Dans une fermeture, le contexte d'exécution est lié de telle sorte que si vous êtes en mesure de référencer des éléments à l'intérieur de cette fonction fermée à partir d'une autre étendue comme dans un objet ou une fonction renvoyé, vous obtenez essentiellement ces variables comme elles l'étaient lorsque la fonction s'est fermée. C'est comme un coincement de votre pied dans la porte de la collecte des ordures, bien que je soupçonne qu'il est mis en œuvre plus comme des copies de ces vars transformées en vars locaux de l'entité référente.
Rigide / strict / sûr vs vous donnant toute la corde que vous voulez:
Les développeurs JS et les développeurs Java ont tendance à ne pas se comprendre du tout et je pense que cela a beaucoup à voir avec les deux langages tombant sur des côtés presque opposés de ce spectre de conception particulier. Je ne veux pas que vous me protégiez de moi-même ou des autres développeurs de mon équipe. Je veux en faire beaucoup plus avec beaucoup moins de code et tout faire de manière très différente (mais cohérente pour un domaine donné) en fonction de la situation. Il y a absolument des compromis entre les deux et beaucoup de langues ont tendance à se situer davantage au milieu.
