Une des propriétés principales à la conception d'un logiciel compréhensible (et, en effet, de concevoir quoi que ce soit) est de développer un bon ensemble d'abstractions forts>. Ces jours-ci, ces abstractions incluent des éléments tels que des fonctions, des classes, des interfaces, des réursions et des fonctions d'ordre supérieur. Mais qu'est-ce qu'il y a d'autre? Comment pouvons-nous davantage abstraits nos conceptions, de sorte que je n'ai pas besoin de penser à rien em> mais mon objectif immédiat et direct? Quelles nouvelles abstractions n'ont pas encore été exploitées par les technologies existantes? P>
Notez également que la plupart des éléments de ma liste (à l'exception, peut-être, de récursivité) sont également des outils utilisés pour la réutilisation du code. La réutilisation du code est pas em> le sujet de cette question et n'est pas ce que je vois comme un aspect nécessaire d'une bonne abstraction. Les fonctions sont utiles comme des abstractions car elles cachent ce qu'ils font derrière un nom descriptif, non pas parce que je peux les appeler de plusieurs endroits différents. P>
Une idée mal formée: est une fonction de pilote qui n'appelle qu'une séquence d'autres fonctions, sans entretenir aucun état propre, vraiment identique à une fonction? Nous l'écrivons comme une fonction et l'appelons comme une fonction, mais peut-être que cela représente un concept différent? Cela se reflète dans certaines langues en faisant des distinctions entre les procédures de retour des valeurs et des procédures ne renvoyant pas les valeurs. Mais peut-être qu'il y a une meilleure façon de voir cette différence, d'une manière différente de résumée de la séquence d'étapes relativement non liées? P>
afin de répéter,
8 Réponses :
En ayant construit une détection d'idées stupides qui, lorsqu'elles sont trébuchées, verrouillent le développeur hors de l'IDE et refusent de les laisser refuser de nouveau. p>
OOP facilite assez bien l'abstraction. Ce sont des développeurs qui proposent des idées mal formées. P>
D'accord, sarcastique mais je me penche de plus en plus vers un compilateur plus restrictif. Aussi, je conviens que si vous comprenez réellement OOP, c'est assez bon, mais il y a beaucoup de gens qui ne le comprennent pas. Une langue qui appliquait la bonne conception OO résoudrait beaucoup de problèmes.
C'est comme dire qu'il n'y a pas de place pour améliorer les langages de programmation actuels. Thats bs, imo.
Un outil d'abscription puissant, macros LISP . Pourquoi ne pas regarder dans le passé et présent? :) p>
Bien alors, de quelle manière les macros Lisp peuvent-elles mieux faciliter l'abstraction? :) L'utilisation de Macros est essentiellement équivalente à la création d'une nouvelle langue, la question est donc toujours pertinente, je pense.
IMO Si vous pouvez écrire des mini langues (non complexes) pour décrire des types de problèmes spécifiques, vous avez une forme d'abstraction puissante. Bien sûr, l'abstraction est bonne, mais d'autre part, il peut être difficile de le garder sous contrôle :-d
Ils peuvent utiliser une sémantique auto-exposant pour mieux permettre
Voir la réponse Nick D ci-dessus :-)
(Oui (mais pouvez-vous) (altérer (tout dans) (l'environnement))?
Exposer plus i> semble antithétique dans le but d'améliorer l'abstraction.
Dépend de la manière dont cette exposition a une incidence sur le processus de développement. Si vous pouviez modifier toute la syntaxe et la sémantique de Java ... Vous pouvez toujours programmer en Java ... ou casser la barrière. Choix I>, pas d'exposition forcée ou une complexité accrue.
Voyons, que directons-nous si nous faisons de l'abstraction obligatoire pour chaque type de données, puis fournissez des moyens de généraliser nos abstractions sur les paramètres de type? Attendre! Je viens de réinventer CLU . Est-ce que je reçois un prix Turing? P>
Toute personne intéressée par le rôle de l'abstraction dans la programmation devrait Étudier CLU STRUT>. P>
Certaines zones que je pense sont potentiellement fructueuses: p>
Programmation intentionnelle ou quelque chose de similaire. La société de Charles Simonyi Software intentionnel est très silencieux pendant un moment, mais commence maintenant à montrer des démonstrations précoces prometteuses . P> li>
Programmation fonctionnelle : Les idées de la programmation fonctionnelle trouvent de plus en plus leur chemin dans plus de Langues traditionnelles comme Python, C # (Linq, Lambdas, etc.) et même C ++ (Lambdas en C ++ 0x). F # devient une langue de première classe .NET avec un support complet dans Visual Studio. La montée du développement multi-fondamental est un autre facteur qui entraîne l'adoption plus large de concepts fonctionnels. P> Li>
Langues spécifiques à domaines (DSLS): étroitement liée aux idées Derrière la programmation intentionnelle, Microsoft semble mettre un effort pour soutenir les DSL dans le cadre de l'écosystème .NET. P> LI>
Idées beaucoup plus sophistiquées. Il existe déjà des développements positifs avec des outils de refactorisation dans les IDes comme Visual Studio et Intellij, mais je pense qu'il y a beaucoup de place aux progrès dans ce domaine. S'éloigner des fichiers de source de texte muet vers quelque chose de plus comme une représentation abstraite de la syntaxe de syntaxe pourrait rendre beaucoup plus facile de travailler à un niveau d'abstraction plus élevé. Encore une fois, cela se connecte à de nombreuses idées de la programmation intentionnelle. P> li> ul>
Programmation fonctionnelle, programmation orientée forme, conception par contrat et généralement tout ce qui nous éloigne de l'âge sombre de la programmation impérative. P>
En outre, j'espère que le développement de logiciels non géré cessera d'exister. C ++ et autres trucs de bas niveau me rend triste. : - ( p>
J'aime ma linq, mon opérateur Lambda, mes méthodes d'extension et mes interfaces courantes. Oh, et j'aime postshaarp.net. Et f #, mais je suppose que c'est très difficile de ne pas aimer f #. : -) p>
"Le développement de logiciels non géré cessera d'exister" - lorsque Microsoft commence à vendre la singularité en tant que projet commercial et que Linux est porté à Python, vous pourriez avoir une Inkling i> d'une chance de cela se produire. Jusque-là, ne tiens pas votre souffle.
La programmation impérative n'est pas l'âge sombre: aujourd'hui, le mal de OO dépasse de loin le méchant du style ancien, qui était fondamentalement la bonne façon mais pas très bien organisé. OO est la mauvaise manière même si les principes qui sous-tendent sont sains.
Je vais donner une réponse indirecte. Avant de pouvoir développer de meilleures constructions dans les langages de programmation, nous devons d'abord comprendre la théorie de l'abstraction em>. P>
Oh oui, il y a une théorie réelle qui prédate l'informatique moderne, elle s'appelle la théorie de catégorie em>. p>.
+1 pour une question très intéressante posée.
+1 Vous avez laissé "Type Systems": un type est une abstraction, et un élément vital, mais + pour la même raison que @Turture complèted dit.