Que signifie cette affirmation selon laquelle C # et Java représentent la moitié d'un langage? [fermé]

Dans l'article: Pourquoi POCO , il y a cette phrase:

Maciej Sobczak le dit bien: «Je n'aime pas quand quelqu'un me donne la moitié de la langue et me dit que c'est pour ma propre protection».

Je ne comprends pas ce qu'il veut dire, même si C # appartient à Microsoft et que Java appartient à Oracle , cela ne signifie pas qu'ils possèdent la moitié du langage, n'est-ce pas? Je n'ai trouvé aucune preuve pour prouver cette phrase et je suis vraiment curieux à ce sujet. Et encore plus curieux à propos 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 l’ensemble des choses que vous ne pouvez pas faire dans beaucoup de langues modernes, même si, expert en informatique bien éduqué, il sait qu’elles pourraient être rendues possibles: hériter d’autant de classes que vous le souhaitez. Attribuez n'importe quel objet à un autre sans contrainte de type. Contrôlez l'allocation et la libération manuelle des ressources 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 n'avons langues qui ont permis à tout cela. Au fil du temps, nous avons constaté que le programmeur moyen s'en sortait mieux avec un certain nombre de restrictions et de capacités de prise en main, car le potentiel de commettre de très mauvaises erreurs est tout simplement trop important pour valoir la puissance et l'expressivité supplémentaires.

(Évidemment, cela agace parfois les programmeurs qui n’auraient pas vraiment besoin de cette main-d’œuvre. Leurs plaintes sont parfois légitimes. Cependant, il est notoire que les gens évaluent mal leurs propres compétences, et nombreux sont ceux qui pensent ne pas avoir besoin des garanties, Il n'est pas toujours facile de distinguer les intellectuels supérieurs qui se sentent freinés par les restrictions imposées dans les langages de haut niveau par les codeurs moyens qui pensent simplement que se plaindre leur donneront une apparence supérieure, ou qui ne le savent pas. rien de mieux.)

Ceci est expliqué assez bien dans la source originale de la citation :

J'ai décidé d'en apprendre plus sur le C ++ et j'en suis devenu un passionné passionné - cela inclut mon intérêt pour la façon dont ce langage est susceptible d'évoluer. De plus, j'ai remarqué que pour développer des bibliothèques utiles , il fallait les techniques les plus sophistiquées et les plus avancées , et non les applications réelles. Gardant cela à l’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 c’est le cas. techniques haut de gamme sont. Consacrer du temps au développement de bibliothèques supposées être à la fois génériques et utiles est très exigeant. C'est pourquoi les programmeurs n'arrêtent jamais d'apprendre.

[…]

Je continue de jouer avec C ++ et les techniques pour écrire un logiciel robuste. 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 outils associés), langage qui semble complètement abandonné par les entreprises, même si c’est bien Ada qui a été conçu pour les logiciels complexes et fiables. systèmes. Je dois admettre que l'apprentissage d'Ada m'a été très bénéfique en ce sens que cela m'a permis de jeter un regard neuf sur mon travail et mes approches de développement. Plus important encore, certaines idées du monde Ada peuvent être plus ou moins directement appliquées au C ++ avec de bons résultats en termes de robustesse et de correction.

[…]

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 développements Java, et ... Eh bien, je n'achète pas il. 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. C'est comme un marteau à papier, allégé pour que personne ne se blesse au doigt ... Il en va de même pour C #. Je choisis le marteau en acier afin de pouvoir être sûr que lorsque je veux jouer au macho, il résistera.
La question qui se pose est la suivante: pourquoi tant de gens l'utilisent-ils (Java, C #, etc.)? Hmmm ... Peut-être parce que c'est très bien à certains endroits. Mais il existe des situations dans lesquelles le langage et la bibliothèque montrent qu'ils ont été conçus plutôt pour des applets (initialement) que pour devenir des utilitaires à tout faire. Cela promet trop et donne trop peu en matière de technologie fourre-tout. Ou comme une solution qui pourrait sonder toute concurrence.

J'aime le C ++ lorsque la puissance maximale et la perspective la plus large sont nécessaires. Dans les pays où l'expressivité du C ++ n'est pas indispensable, des langages comme Tcl ou Python semblent convenir. Non seulement ils sont ouverts en ce qui concerne leur évolution, mais on peut les étendre et les intégrer, en fonction de besoins particuliers. Je vois beaucoup de possibilités rêver dans ces technologies. J'ai aussi tendance à abandonner le langage C en tant que langage pour la programmation régulière - cela semble être un choix raisonnable uniquement en tant que cible pour la génération de code, sinon il est trop sujet aux erreurs. Aujourd'hui, Ada est probablement mon deuxième choix pour les projets plus sérieux, à condition que je puisse choisir librement (ce qui n'est malheureusement pas le cas la plupart du temps).

Donc, en d'autres termes, l'auteur de cette citation aime le C ++, il n'aime pas Java, et il a le sentiment que Java manque de la moitié de C ++. Et c'est tout ce qu'il y a dans cette citation.

L'article lié au blog que vous avez posté 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", il signifie que C # et Java se sentent comme du C ++, mais avec beaucoup de 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 que Java était immature à bien des égards, et lorsque pouvoir et sécurité semblaient être un compromis qui ne permettait de choisir qu’un seul, cette position n’était pas totalement déraisonnable. .

Ces jours-ci cette position n'est pas raisonnable du tout. Rien qu'en pensant aux langages traditionnels, C # et Java ont énormément évolué, empruntant des fonctionnalités à d’autres langages (particulièrement fonctionnels) pour promouvoir l’écriture de code sécurisé. Nous avons également des langages comme Rust et Swift qui sont construits à partir de la base pour faire cela.

Si quelqu'un méprise une langue parce qu'elle vous tient la main ou dit qu'une langue difficile à utiliser est en quelque sorte une bonne chose, je prendrais ce qu'elle disait avec un grain de sel. Il suffit de regarder le nombre embarrassant de bogues trouvés dans le code sur lequel nous dépendons tous les jours, écrits par les plus brillants esprits du secteur, qui auraient été évités de manière triviale en utilisant des langages "sûrs", pour voir pourquoi.

En regardant en arrière dans les archives , il semble que cette citation date de 2003 (bien que l’article le citant date de 2006). À 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 Getter / setter
• Conversions de groupe de méthodes (délégués)
• Co- et contre-variance pour les délégués
• Classes statiques
• Déduction déléguée

C # 3.0

• Variables locales implicitement typées
• 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 optionnels
• Co- et contravariance générique
• Types d'interopérabilité intégrés ("NoPIA")

C # 5.0

• Méthodes asynchrones
• Attributs d'information de l'appelant

C # 6.0

• Compilateur en tant que service (Roslyn)
• Importation de membres de type statique dans un espace de noms
• Filtres d'exception
• Attendre dans les prises / enfin les blocs
• Initialisation automatique des propriétés
• Valeurs par défaut pour les propriétés de lecture uniquement
• Membres à corps d'expression
• Propagateur null (opérateur null-conditionnel, vérification succincte de null)
• Interpolation de chaîne
• nom de l'opérateur
• Initialiseur de dictionnaire

C # 7.0

• Out variables
• Correspondance de modèle
• Tuples
• Déconstruction
• Fonctions locales
• Séparateurs de chiffres
• Littéraux binaires
• Ref renvoie et les habitants
• Types de retour async généralisés
• Constructeurs et finaliseurs avec corps d'expression
• Getters et setters

C # 7.1

• Async principal
• Expressions littérales par défaut
• Noms d'éléments de tuple inférés

- "C Sharp" , Wikipedia (références et liens supprimés)

Il est probablement plus compréhensible que C # apparaisse comme un demi-langage dans ce contexte, car il lui manquait beaucoup de ce que C # est aujourd'hui. C'est bizarre de penser qu'il n'y avait même pas de staticcours!

Il manquait encore des éléments, 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. Ceux-ci incluent des outils pour

• Mise en application de l'immutabilité (telle que le constmot clé C ++ )
• Contrôle de la durée de vie et de la propriété d'un objet
• 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 à la sémantique claire. En Java, vous n'avez que le pseudo-objet-pointeur. En combinant ces notions et en évitant la véritable sémantique du pointeur, le modèle 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 le modèle d'objet null et les conditions yoda telles que 5.equals(potentiallyNullIntegerReference).

Je suis d'accord avec la réponse de @Kilian mais je vais ajouter 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 quand vous êtes directement sur le système d'exploitation, car vous risqueriez de corrompre quelque chose sur la machine virtuelle. De plus, Java étant orienté comme une plate-forme agnostique, c'est encore plus logique.

2- Des tonnes d'applications ne vous obligent pas à avoir besoin de ce genre de choses.

Il y a des tonnes d'applications qui n'ont pas vraiment besoin que vous approfondissiez autant de détails. Pourtant, si vous le faites avec un langage qui vous oblige à le faire, vous obtenez:

• Plus de risques d'avoir des bugs dus à ces choses inutiles.
• Plus de coûts de développement, gérer la mémoire et la tester prend du temps et donc de l'argent!

3- La langue est faite sur une pondération de choix coût / usage / 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 en gérer.

Donc, des choses comme l'héritage multiple ne sont pas abandonnées au seul fait qu'elles sont dangereuses, elles le sont 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 qui peut être utilisée correctement. généralement être réécrit différemment.

Il suffit de mettre toutes les restrictions dans les langages de haut niveau tels que C # et Java pour protéger le programmeur. Ils existent moins pour protéger le programmeur de lui-même que pour le protéger des autres programmeurs!

Combien de fois avons-nous, en tant que programmeurs, rencontré des bibliothèques qui étaient carrément imparfaites dans leurs pratiques de codage et leur conception mais que nous avons été forcés d’utiliser pour une raison ou une autre?

Ces programmes présentent généralement les caractéristiques de l’ancienne méthode de programmation procédurale: manque d’encapsulation, beaucoup d’écritures en mémoire directe avec peu ou pas d’identification ou de gestion des erreurs. Les Segfaults poursuivent en masse lorsqu'ils tentent de les utiliser dans tout projet de grande envergure.

C'est là que des langages comme Java et C # sont extrêmement utiles. ce n'est pas qu'ils apprécient le fait qu'ils ne nous laissent pas faire tout ce qui est bien fait par les autres langues, c'est que nous apprécions le manque de maux de tête que nous devons endurer car d'autres programmeurs abuseraient des choses soignées que d'autres langages peuvent faire. faire.

Les interfaces valent bien n'importe quel compromis en termes de mémoire ou de vitesse d'exécution dans mon esprit. J'espère que vous pouvez voir que dans n'importe quelle application critique limitée dans le temps, toutes ces protections, une gestion correcte des erreurs et une certitude générale que la mémoire n'est pas utilisée, sont de bonnes choses!