Pourquoi Arc n'est pas particulièrement orienté objet

Il y a une sorte de manie pour la programmation orientée objet en ce moment, mais certains des programmeurs les plus intelligents que je connais sont les moins enthousiastes à ce sujet.

Mon propre sentiment est que la programmation orientée objet est une technique utile dans certains cas, mais ce n'est pas quelque chose qui doit imprégner chaque programme que vous écrivez. Vous devriez pouvoir définir de nouveaux types, mais vous ne devriez pas avoir à exprimer chaque programme comme la définition de nouveaux types.

Je pense qu'il y a cinq raisons pour lesquelles les gens aiment la programmation orientée objet, et trois et demi d'entre elles sont mauvaises :

1. La programmation orientée objet est excitante si vous avez un langage statiquement typé sans fermetures lexicales ou macros. Dans une certaine mesure, elle offre un moyen de contourner ces limitations. (Voir la dixième règle de Greenspun.)

2. La programmation orientée objet est populaire dans les grandes entreprises, car elle convient à la façon dont elles écrivent des logiciels. Dans les grandes entreprises, les logiciels ont tendance à être écrits par de grandes équipes (et fréquemment changeantes) de programmeurs médiocres. La programmation orientée objet impose une discipline à ces programmeurs qui empêche chacun d'eux de faire trop de dégâts. Le prix est que le code résultant est gonflé de protocoles et plein de duplication. Ce n'est pas un prix trop élevé pour les grandes entreprises, car leur logiciel va probablement être gonflé et plein de duplication de toute façon.

3. La programmation orientée objet génère beaucoup de ce qui ressemble à du travail. À l'époque du papier à fanfolds, il y avait un type de programmeur qui ne mettait que cinq ou dix lignes de code sur une page, précédées de vingt lignes de commentaires élaborément formatés. La programmation orientée objet est comme de la crack pour ces gens : elle vous permet d'incorporer tout cet échafaudage directement dans votre code source. Quelque chose qu'un hacker Lisp pourrait gérer en poussant un symbole sur une liste devient un fichier entier de classes et de méthodes. C'est donc un bon outil si vous voulez vous convaincre, ou convaincre quelqu'un d'autre, que vous faites beaucoup de travail.

4. Si un langage est lui-même un programme orienté objet, il peut être étendu par les utilisateurs. Eh bien, peut-être. Ou peut-être pouvez-vous faire encore mieux en offrant les sous-concepts de la programmation orientée objet à la carte. Le surchargement, par exemple, n'est pas intrinsèquement lié aux classes. Nous verrons.

5. Les abstractions orientées objet se mappent parfaitement sur les domaines de certains types spécifiques de programmes, comme les simulations et les systèmes CAO.

Personnellement, je n'ai jamais eu besoin d'abstractions orientées objet. Common Lisp a un système objet extrêmement puissant et je ne l'ai jamais utilisé une seule fois. J'ai fait beaucoup de choses (par exemple, créer des tables de hachage pleines de fermetures) qui auraient nécessité des techniques orientées objet pour être faites dans des langages plus faibles, mais je n'ai jamais eu à utiliser CLOS.

Peut-être que je suis juste stupide, ou que j'ai travaillé sur un sous-ensemble limité d'applications. Il y a un danger à concevoir un langage basé sur sa propre expérience de programmation. Mais il semble plus dangereux d'y mettre des choses dont vous n'avez jamais eu besoin parce qu'on pense que c'est une bonne idée.