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".
Réponses:
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.)
la source
dynamic
?Ceci est expliqué assez bien dans la source originale de la citation :
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.
la source
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.
la source
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 :
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
static
cours!Il manquait encore des éléments, car C # était lié à .NET. Par exemple, WPF n'était pas là à l'époque. c'était tout WinForms.
la source
static
les classes semblent être une telle caractéristique primitive; J'ai un peu imaginé qu'ils prédataient les cours instanciés.static
cours dans la plupart des cas de toute façon. Honnêtement, je l'ai choisie comme fonction à appeler car cela semblait très simple, une partie primitive de C #; Je n'ai pas considéré qu'ils n'étaient pas en Java.Il se plaignait du manque de fonctionnalités linguistiques permettant un contrôle fin. Ceux-ci incluent des outils pour
const
mot clé C ++ )Cela me rappelle une de mes critiques de Java:
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)
.la source
Map.merge
quand vous souhaitez simplement mettre à jour une valeur dans une carte).const
. Il fait mention « programmation fonctionnelle », cependant, la langue qu'il utilise comme exemple le schéma, ce qui est pas un langage fonctionnel pur (en fait, les concepteurs du schéma prennent soin d'éviter l'utilisation du mot « fonction » et parler de " procédures "), il semble donc qu'il utilise l'interprétation" de première classe "de FP et non celle de" transparence référentielle ".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:
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.
la source
B
est remplacé par une classe moyenneM
, saB
version ne sera accessible que parM
' s dérogation; (2) étant donné toute référence de typeT
, le convertir en n'importe quel super-type et inversementT
donnera une référence équivalente à l'original. Ces deux garanties sont utiles et, pour soutenir les successions multiples, il faudrait en abandonner au moins une.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!
la source
They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!
ou est-ce pour protéger les autres programmeurs du programmeur?