Que signifie cette déclaration sur C # et Java étant la moitié d'un langage?
Dans l'article: Pourquoi POCO , il y a cette phrase:
Maciej Sobczak le dit bien: "Je n'aime tout simplement pas que quelqu'un me donne la moitié de la langue et me dise que c'est pour ma propre protection".
Je ne comprends pas ce qu'il veut dire, même si C # appartient à Microsoft & Java appartient à Oracle , cela ne signifie pas qu'ils détiennent la moitié du langage, il? Je n'ai trouvé aucune preuve pour prouver cette phrase, et je suis vraiment curieux à ce sujet. Et encore plus curieux de la partie "pour ma propre protection".
Sobczak ne parle pas de propriété d'entreprise. La "moitié" de la langue qui lui manque est toutes ces choses que vous ne pouvez pas faire dans de nombreuses langues modernes, même si en tant qu'informaticien instruit, il sait qu'elles pourrait être rendues possibles: hériter de autant de cours que vous le souhaitez. Attribuez un objet à un autre sans contrainte de type. Contrôlez l'allocation et la libération des ressources manuellement au lieu de faire confiance au compilateur et à l'exécution pour le faire pour lui.
Le fait est que toutes ces restrictions ont été mises dans les langages de programmation pour une raison. Nous avions des langues qui permettaient tout cela. Au fil du temps, nous avons constaté que le programmeur moyen s'en sort mieux avec un certain nombre de restrictions et de prise en main, car le potentiel de faire de très mauvaises erreurs est tout simplement trop grand pour valoir la puissance et l'expressivité supplémentaires.
(Évidemment, cela dérange parfois les programmeurs qui n'auraient pas vraiment besoin de beaucoup de tenue de main. Leurs plaintes sont parfois légitimes. Mais les gens sont notoirement mauvais à évaluer leurs propres compétences, et beaucoup de ceux qui pensent qu'ils n'en ont pas '' En fait, ils en ont vraiment besoin. Il n'est pas toujours facile de distinguer les intellectuels supérieurs réels qui se sentent freinés par les restrictions dans les langages de haut niveau des codeurs moyens qui pensent simplement que se plaindre les rendra supérieurs , ou qui ne connaissent pas mieux.)
Ceci est expliqué très bien dans la source originale de la citation :
J'ai décidé d'en savoir plus sur le C++ et je suis devenu son fidèle passionné - cela inclut mon intérêt pour la façon dont ce langage est susceptible d'évoluer. De plus, j'ai remarqué que les techniques les plus avancées et les plus avancées sont nécessaires pour développer des bibliothèques utiles , pas les applications réelles . Dans cet esprit, j'ai essayé d'écrire quelques-unes de mes propres bibliothèques à des fins différentes (voir ma page de téléchargement) et j'essaie également de regarder par-dessus les épaules des développeurs C++ Boost (voir ma page de liens) pour savoir ce que ces les techniques haut de gamme le sont. Passer du temps sur le développement de bibliothèques censées être génériques et utiles à la fois est très exigeant. C'est pourquoi les programmeurs n'arrêtent jamais d'apprendre.
[…]
Je continue à jouer avec C++ et les techniques d'écriture de logiciels robustes. Pour acquérir une perspective plus large dans le domaine des logiciels fiables, j'ai décidé d'investir un peu de temps dans l'apprentissage d'Ada (et des choses connexes), qui est une langue qui semble être complètement abandonnée par les entreprises, même si c'est Ada qui a été vraiment conçu pour être complexe et fiable. systèmes. Je dois admettre que l'apprentissage d'Ada a été vraiment bénéfique pour moi dans le sens où il m'a permis de jeter un regard nouveau sur mon travail et mes approches de développement. Plus important encore, certaines des idées du monde Ada peuvent être plus ou moins directement appliquées au C++ avec de bons résultats dans le domaine de la robustesse et de l'exactitude.
[…]
OK, j'ai oublié. J'ai juré un jour de ne pas apprendre Java. Mais je l'ai fait. Eh bien, dans la mesure où cela me permet de lire et d'écrire du code de travail. J'ai lu 'Thinking in Java' (disponible en ligne, gratuit) et 'Core Java' (pas en ligne, pas gratuit), j'ai également été indirectement impliqué dans certains Java, et. .. Eh bien, je ne l'achète pas. Je n'aime juste pas quand quelqu'un me donne la moitié de la langue et me dit que c'est pour ma C'est comme un marteau en papier, allégé pour que personne ne se blesse en se frappant le doigt ... Il en va de même pour C #. Je choisis le marteau en acier, pour être sûr que quand je veux jouer macho, il résistera.
La question est - pourquoi tant de gens l'utilisent-ils (Java, C #, etc.)? Hmmm ... Peut-être parce que c'est très bon à certains endroits. Mais il y a des situations où la langue et la bibliothèque montrent qu'elles ont été conçues plutôt pour les applets (au départ) que pour devenir des utilitaires tout-faire. Elle promet juste trop et donne trop peu comme pour la technologie fourre-tout. Ou comme une solution qui pourrait labourer toute concurrence ..J'aime C++ quand une puissance maximale et une perspective plus large sont nécessaires. Dans des endroits où l'expressivité du C++ n'est pas un must-have, des langages comme Tcl ou Python semblent convenir. Non seulement ils sont ouverts quant à leur évolution, mais on peut étendre et les intégrer, en fonction des besoins particuliers. Je vois beaucoup de possibilités rêver dans ces technologies. J'ai également tendance à abandonner C comme langage pour la programmation régulière - cela semble être un choix raisonnable uniquement comme cible pour la génération de code, sinon c'est trop Aujourd'hui, Ada est mon deuxième choix probable pour les projets plus sérieux, à condition que j'aie le libre choix (ce qui n'est malheureusement pas le cas la plupart du temps).
Donc, en d'autres termes, l'auteur de cette citation aime C++, et il n'aime pas Java, et il pense que Java manque la moitié de C++. Et c'est tout ce qu'il y a à cette citation .
L'article lié au blog que vous avez publié a été supprimé, il est donc difficile d'en être sûr, mais comme le dit Kilian, il est probable que lorsqu'il dit "la moitié du langage", cela signifie que C # et Java se sentent comme C++ mais avec de nombreuses fonctionnalités et constructions supprimées pour les rendre plus faciles à utiliser ou plus sûres.
En 2006, lorsque cela a été écrit, lorsque C # était relativement jeune et Java était à bien des égards immature, et lorsque la puissance contre la sécurité semblait être un compromis où vous ne pouviez en choisir qu'un, ce n'était pas une position totalement déraisonnable à prendre.
De nos jours, cette position n'est plus du tout raisonnable. En pensant simplement aux langages traditionnels, C # et Java ont énormément mûri, empruntant des fonctionnalités à d'autres langages (particulièrement fonctionnels) pour promouvoir l'écriture de code sûr. Nous avons également des langues comme Rust et Swift qui sont construites à partir de zéro pour ce faire.
Si quelqu'un méprise une langue parce qu'elle tient votre main, ou dit qu'une langue difficile à utiliser est en quelque sorte une bonne chose, je prendrais tout ce qu'ils ont dit avec un grain de sel. Il suffit de regarder le nombre embarrassant de bogues trouvés dans le code dont nous dépendons chaque jour, écrits par les esprits les plus brillants de l'industrie, qui auraient été trivialement évités en utilisant des langages `` sûrs '', pour voir pourquoi.
En regardant les archives , il semble que cette citation date de 2003 (malgré l'article citant qu'elle date de 2006). A cette époque, C # était dans la version 1. x , et il lui manquait beaucoup de ses fonctionnalités modernes :
Nouvelles fonctionnalités
C # 2.0
- Génériques
- Types partiels
- Méthodes anonymes
- Itérateurs
- Types nullables
- Accessibilité séparée des accesseurs/poseurs
- Conversions de groupes de méthodes (délégués)
- Co-et contre-variance pour les délégués
- Classes statiques
- Inférence de délégué
C # 3.0
- Variables locales typées implicitement
- Initialiseurs d'objets et de collections
- Propriétés implémentées automatiquement
- Types anonymes
- Méthodes d'extension
- Expressions de requête
- Expression lambda
- Arbres d'expression
- Méthodes partielles
C # 4.0
- Reliure dynamique
- Arguments nommés et facultatifs
- Co- et contravariance génériques
- Types d'interopérabilité intégrés ("NoPIA")
C # 5.0
- Méthodes asynchrones
- Attributs d'informations sur l'appelant
C # 6.0
- Compilateur en tant que service (Roslyn)
- Importation de membres de type statique dans l'espace de noms
- Filtres d'exception
- Attendre dans les blocs catch/finally
- Initialiseurs de propriétés automatiques
- Valeurs par défaut pour les propriétés getter uniquement
- Membres valides pour l'expression
- Propagateur nul (opérateur conditionnel nul, vérification succincte des valeurs nulles)
- Interpolation de chaînes
- nom de l'opérateur
- Initialiseur de dictionnaire
C # 7.0
- Variables de sortie
- Correspondance de motifs
- Tuples
- Déconstruction
- Fonctions locales
- Séparateurs de chiffres
- Littéraux binaires
- Retours et locaux
- Types de retour asynchrones généralisés
- Constructeurs et finaliseurs à corps d'expression
- Getters et setters à corps d'expression
C # 7.1
- Async main
- Expressions littérales par défaut
- Noms d'élément de tuple déduits
- "C Sharp" , Wikipedia (références et liens supprimés)
Il est probablement plus compréhensible que C # semblait être un demi-langage dans ce contexte, car il manquait beaucoup de ce que C # est aujourd'hui. C'est bizarre de penser qu'il n'avait même pas de classes static!
Il manquait également plus de choses, car C # était lié à .NET. Par exemple, WPF n'était pas là à l'époque; c'était tout WinForms.
Il se plaignait du manque de fonctionnalités linguistiques permettant un contrôle fin. Il s'agit notamment d'outils pour
- Application de l'immuabilité (comme le mot clé C++
const) - Contrôle de la durée de vie et de la propriété des objets
- Contrôle de l'utilisation de la mémoire, du style de copie et d'allocation
Cela me rappelle une de mes critiques de Java:
tout est un pointeur, mais les pointeurs n'existent pas.
Dans les objets C++, les pointeurs et les références sont trois concepts distincts avec une sémantique claire. Dans Java vous avez juste le pseudo-objet-pointeur. En les combinant et en évitant la vraie sémantique du pointeur, le modèle d'objet est moins clair.
Dans un programme C++ bien défini, le programmeur peut s'attendre à ce que les références soient valides et non nulles. En raison de son modèle simplifié, Java ne peut pas offrir les mêmes garanties.
Les symptômes de ce modèle moins clair incluent les conditions modèle d'objet nul et yoda telles que 5.equals(potentiallyNullIntegerReference).
Je suis d'accord avec la réponse de @Kilian mais j'ajouterai quelques éléments.
1- Exécution sur une machine virtuelle et non sur le système d'exploitation
Étant donné que Java et C # s'exécutent sur une machine virtuelle, il est logique que vous ne puissiez pas faire exactement ce que vous voulez en étant directement sur le système d'exploitation, car vous risquez de corrompre quelque chose dans le De plus, avec Java étant orienté comme étant indépendant de la plateforme, c'est encore plus logique.
2- Des tonnes d'applications ne nécessitent pas que vous ayez besoin de ce genre de choses.
Il y a des tonnes d'applications qui n'ont vraiment pas besoin de vous pour fouiller autant de détails, mais si vous le faites avec une langue qui vous oblige à le faire, vous obtenez:
- Plus de risques d'avoir des bugs à cause de ces choses inutiles.
- Plus de coûts de développement, la gestion de la mémoire et les tests prennent du temps et donc de l'argent!
3- Le langage est fait sur un choix de pondération coût/utilisation/risques, comme ... tout.
Avec C++, vous pouvez faire à peu près ce que vous voulez, c'est le choix des personnes C++. Cependant, plus il y en a, plus vous devez gérer.
Donc, des choses comme l'héritage multiple ne sont pas abandonnées simplement parce qu'elles sont dangereuses, elles sont abandonnées parce que leur mise en œuvre a un coût (développement, maintenance), tout cela pour une fonctionnalité qui est rarement utilisée correctement et peut être généralement réécrit différemment.