FREE SHIPPING. 24/7 CUSTOMER SERVICE. ALL THRONES SHIP WITHIN 7 DAYS.

Programming Environment Research

L'histoire
La programmation est une tâche difficile. L'objectif d'un environnement de programmation est de fournir des outils qui aident le programmeur et simplifient la tâche. Nous sommes un ardent défenseur des outils de programmation et développons de tels outils depuis longtemps. Pendant mes études de premier cycle, j'ai travaillé sur le système d'exécution Dartmouth Basic. L’une des innovations clés ici a été d’ajouter un débogueur en langage source à l’environnement.

Nos recherches réelles dans les environnements de programmation ont commencé avec l'avènement des stations de travail (Apollos, Suns, Percs, ...). Nous (avec plusieurs autres groupes) avons estimé qu’il faudrait pouvoir utiliser la puissance de calcul supplémentaire et l’affichage graphique pour simplifier et améliorer la programmation. Notre tentative initiale est reflétée dans le système PECAN. PECAN a utilisé la technologie du compilateur pour générer une suite d'outils pour un langage. La suite d'outils comprenait des éditeurs textuels (partiellement dictés par la syntaxe) et graphiques (diagrammes de Nassi-Schneiderman, diagrammes de Rothon), des vues sémantiques de la table des symboles, du flux de contrôle et des expressions, ainsi que des vues d'exécution de la pile et du code. Il comportait également une compilation incrémentielle au fur et à mesure que l'utilisateur tapait. C’était un système amusant qui nous enseignait beaucoup, mais ce n’était vraiment pas pratique (la mémoire manquait après environ 1000 lignes de code) et n’exploitait pas pleinement les capacités graphiques des postes de travail.

Sur la base de ces travaux, nous avons ensuite essayé de mieux utiliser les capacités graphiques des postes de travail en utilisant des langages visuels. Nous nous sommes rendus compte que les langages visuels ne couvraient généralement qu'une partie limitée de la programmation (par exemple, seulement un flux de contrôle ou qu'un flux de données), et que pour faire de la programmation réelle, il faudrait laisser le programmeur travailler avec plusieurs langages de ce type. Pour ce faire, nous avons développé ce que nous avons appelé un environnement conceptuel de programmation, GARDEN, qui permet au programmeur de développer de nouveaux langages visuels ou textuels (avec une syntaxe visuelle appropriée et une sémantique appropriée), et d'imbriquer ou de mélanger ces langages dans un système complet. Le système fournissait des éditeurs graphiques et textuels appropriés, un langage de base similaire à Lisp, un magasin d'objets partagés complet (pour permettre à plusieurs programmeurs de travailler simultanément sur le même programme et de prendre en charge des applications distribuées), des navigateurs de type Smalltalk, plusieurs threads et même un compilateur. Le système a été utilisé pour développer une grande variété de langages visuels.

Lors du développement de GARDEN, plusieurs personnes ont contesté la recherche globale dans les environnements de programmation, affirmant que, même si les outils que nous développions et ceux que nous développions étaient utiles et utiles, rien n’était réellement pratique et aucun des projets ne pouvait réellement s’utiliser pour le développement; Le développement quotidien des programmes sous UNIX (ou n’importe quel autre système d’exploitation de l’époque) reposait sur des éditeurs de texte séparés, des débogueurs, etc., qui n’avaient pas changé de manière significative depuis dix ans. Nous avons donc commencé à développer un environnement pratique pour une programmation réelle. Nous nous sommes rendus compte que vous n'aviez pas besoin d'un magasin commun ou d'une représentation centrale pour avoir un environnement intégré, ni de développer de nouveaux outils pour avoir des interfaces graphiques. Au lieu de cela, nous avons développé un mécanisme d'intégration simple, basé sur des messages, permettant aux outils de communiquer entre eux, ainsi qu'une série de wrappers fournissant des interfaces graphiques aux outils existants (dbx, gdb, make, rcs, ...). Le résultat a été l'environnement FIELD. Au fur et à mesure de son développement, l'environnement a été étendu à diverses vues graphiques, notamment des vues structurelles (organigramme, hiérarchie des classes) et dynamiques (affichages de la structure des données, visualisation des segments de mémoire, visualisations d'E / S). FIELD a eu beaucoup de succès. Nous l'avons utilisé pendant plusieurs années dans nos cours de programmation d'introduction. Il a été commercialisé par DEC (sous le nom de FUSE) et copié par HP (Softbench), Sun (Tooltalk), SGI et autres.

Notre prochain environnement, DESERT, a essayé d’étendre FIELD de plusieurs manières. Premièrement, elle souhaitait fournir au programmeur un affichage de haute qualité du code. Cela a été fait en élargissant Adobe Framemaker en tant qu'éditeur de programme. L'extension comprenait le formatage du code de style Baeker-Marcus qui était fait par l'utilisateur, ce qui incluait la recherche sémantique des symboles sur l'ensemble du système (et pas seulement le fichier actuel). Deuxièmement, nous voulions laisser le programmeur voir le système de différentes manières, en pouvant isoler le code correspondant à un changement ou à une caractéristique particulière. Cela a été fait en scindant le programme en fragments et en demandant à l'éditeur de travailler sur des fichiers virtuels constitués de différents fragments rassemblés à partir de fichiers sources réels. Le programmeur pourrait spécifier un ensemble de fragments à l'aide des requêtes appropriées. Les fragments étaient en cours de gestion de la configuration et les modifications apportées aux fichiers virtuels ont été intégrées aux fichiers source originaux lors de la sauvegarde des fichiers virtuels. Enfin, nous voulions fournir des visualisations de code et d’exécution de meilleure qualité et avons donc développé un système de visualisation 3D intégré à l’environnement.

Nos efforts les plus récents se sont concentrés sur la prise en charge de l'évolution et de la cohérence logicielle plutôt