commit f182746635bab11653718ce482d07b8abf1df1e9
parent f3bc534db906a9a3bffe32234d47e1ee770907bd
Author: gduperon <gduperon@5d9ba3ac-444b-4713-9fb3-0b58e79229a2>
Date: Mon, 17 May 2010 15:16:51 +0000
Section EDI du rapport : OK
git-svn-id: https://projetud.info-ufr.univ-montp2.fr/svn/flin607-2009-gduperon@55 5d9ba3ac-444b-4713-9fb3-0b58e79229a2
Diffstat:
3 files changed, 163 insertions(+), 24 deletions(-)
diff --git a/rapport/biblio.bib b/rapport/biblio.bib
@@ -36,7 +36,7 @@
year = 1998,
pages = {22-29},
bibsource = {DBLP, http://dblp.uni-trier.de},
- abstract = {The Java programming language eases the creation of programs, as compared to textual languages such as C++, through use of features such as definite assignment, type safety, pointer restrictions and exception handling. However, errors resulting from the incorrect use of these features are hidden from the programmer when using a standard text based editor until they are detected at compile-time. The programmer is forced to edit, compile, and re-edit the program to correct the errors detected during compilation, resulting in inefficiencies in the development process. In this paper a Java compatible visual syntax is briefly introduced. We then focus on environment features made possible by the visual presentation of the language which provide for the visualization of errors resulting from incorrect use of the following features: definite assignment, static type checking and exception handling.},
+ abstract = {The Java programming language eases the creation of programs, as compared to textual languages such as C++, through use of features such as definite assignment, type safety, pointer restrictions and exception handling. However, errors resulting from the incorrect use of these features are hidden from the programmer when using a standard text based editor until they are detected at compile-time. The programmer is forced to edit, compile, and re-edit the program to correct the errors detected during compilation, resulting in inefficiencies in the development process. In this paper a Java compatible visual syntax is briefly introduced. We then focus on environment features made possible by the visual presentation of the language which provide for the visualization of errors resulting from incorrect use of the following features: definite assignment, static type checking and exception handling.},
url = {http://doi.ieeecomputersociety.org/10.1109/VL.1998.706130},
note = {\footnote{Ce papier n'est pas en accès libre. Par conséquent, je ne peux pas vérifier sont contenu. Protestons contre les papiers payants.}}
}
@@ -44,13 +44,15 @@
@misc{modular-synth,
author = {Jacques Bon},
url = {http://cafcom.free.fr/ams/ams1.html},
- note = {Article décrivant les premiers synthétiseurs virtuels et leur relation avec les synthétiseurs matériels, \myurl{\url{http://cafcom.free.fr/ams/ams1.html}}, section intitulée «Débuts de l'informatique musicale»}}
+ title = {Petite histoire du synthétiseur},
+ note = {\myurl{\url{http://cafcom.free.fr/ams/ams1.html}}, section intitulée «Débuts de l'informatique musicale»}}
% http://cafcom.free.fr/ams/ams1.png
@misc{alsa-modular-synth,
author = {Jacques Bon},
url = {http://cafcom.free.fr/ams/ams2.html},
- note = {Article décrivant Alsa Modular Synth, \myurl{\url{http://cafcom.free.fr/ams/ams2.html}}}}
+ title = {Alsa Modular Synth},
+ note = {\myurl{\url{http://cafcom.free.fr/ams/ams2.html}}}}
% http://www.world-machine.com/images/ui1.jpg
@misc{world-machine,
@@ -66,9 +68,68 @@
%
@misc{the-right-tool,
url = {http://therighttool.hammerprinciple.com/},
- note = {Sondage cherchant à déterminer quelles affirmations correspondent le mieux à quels langages de programmation, \myurl{\url{http://therighttool.hammerprinciple.com/}}}}
+ title = {The right tool},
+ note = {\myurl{\url{http://therighttool.hammerprinciple.com/}} est un sondage cherchant à déterminer quelles affirmations correspondent le mieux à quels langages de programmation}}
% http://zone.ni.com/devzone/cda/tut/p/id/9387
@misc{labview,
url = {http://zone.ni.com/devzone/cda/tut/p/id/9387},
- note = {Logiciel de mesure LabView, \myurl{\url{http://zone.ni.com/devzone/cda/tut/p/id/9387}}}},
-\ No newline at end of file
+ title = {Creating Recursive \textsc{VI}s},
+ note = {(Logiciel de mesure LabView) \myurl{\url{http://zone.ni.com/devzone/cda/tut/p/id/9387}}}},
+
+@misc{config-grub,
+ url = {http://grub.enbug.org/grub.cfg.fr},
+ title = {grub.cfg: le fichier de menu de Grub 2},
+ note = {\myurl{\url{http://grub.enbug.org/grub.cfg.fr}}}}
+
+@misc{config-awesome,
+ url = {http://awesome.naquadah.org},
+ title = {Awesome},
+ note = {\myurl{\url{http://awesome.naquadah.org}}}}
+
+@misc{biblio-vpl-a-screen-real-estate,
+ url = {http://web.engr.oregonstate.edu/~burnett/vpl.html#V6C2},
+ title = {Effective use of screen real estate},
+ note = {(bibliographie, partie de \cite{biblio-vpl-burnett}) \myurl{http://web.engr.oregonstate.edu/~burnett/vpl.html\#V6C2}}}}
+
+@misc{biblio-vpl-burnett,
+ url = {http://web.engr.oregonstate.edu/~burnett/vpl.html},
+ title = {Visual Programming Languages research papers},
+ note = {(bibliographie) \myurl{\url{http://web.engr.oregonstate.edu/~burnett/vpl.html}}}}
+
+@misc{biblio-vpl-paul-lyon,
+ url = {http://www-ist.massey.ac.nz/plyons/776/vpl%20papers.html},
+ title = {Visual Programming Languages Bibliography: A Branch of the Visual Language Research Bibliography},
+ note = {(bibliographie) \myurl{\url{http://www-ist.massey.ac.nz/plyons/776/vpl%20papers.html}}}}
+
+@misc{deutsch-limit,
+ url = {http://en.wikipedia.org/wiki/Deutsch_Limit},
+ title = {Deutsch Limit},
+ note = {\myurl{\url{http://en.wikipedia.org/wiki/Deutsch_Limite}}}}
+
+@misc{code-bubbles,
+ url = {http://www.cs.brown.edu/people/acb/codebubbles_site.htm},
+ title = {Code Bubbles - Rethinking the User Interface Paradigm of Integrated Development Environments},
+ note = {\myurl{\url{http://www.cs.brown.edu/people/acb/codebubbles_site.htm}}}}
+
+@misc{mutant-storm,
+ url = {http://pompomgames.com/mutantstormreloaded.htm},
+ title = {Mutant Storm Reloaded},
+ note = {Utilise une interface «zoom» \myurl{\url{http://pompomgames.com/mutantstormreloaded.htm}}}}
+
+@misc{project-cecily,
+ url = {http://www.osmosoft.com/cecily/},
+ title = {Project Cecily},
+ note = {issu de \cite{tiddlywiki} \myurl{\url{http://www.osmosoft.com/cecily/}}}}
+
+@misc{tiddlywiki,
+ url = {http://tiddlywiki.com/},
+ title = {TiddlyWiki},
+ note = {\myurl{\url{http://tiddlywiki.com/}}}}
+
+misc{,
+ url = {},
+ title = {},
+ note = {\myurl{\url{}}}}
+
+
diff --git a/rapport/rapport.pdf b/rapport/rapport.pdf
Binary files differ.
diff --git a/rapport/rapport.tex b/rapport/rapport.tex
@@ -18,6 +18,8 @@
\usepackage{subfig}
\usepackage{calc}
+\usepackage{epigraph}
+
\usepackage{pgffor}
\usepackage{ifthen}
\usepackage{tikz}
@@ -182,33 +184,109 @@ Force est de constater que tous les exemples cités ci-dessus sont des cas parti
provenant d'appareils de mesure). Le paradigme du dataflow devrait être tout aussi efficace pour construire des programmes conventionnels~:
les signaux d'entrée sont les évènements provoqués par l'utilisateur (clic de souris, appui sur le clavier), ceux de sortie sont les retours
(écran, haut-parleurs, \dots). Cependant, les langages graphiques n'ont eu que peu de succès auprès de la communauté des programmeurs, et
-les raisons de ce rejet méritent d'être étudiées.
+les raisons de ce rejet méritent d'être étudiées\footnote{Peut-être que c'est simplement que les langages textuels, c'est pour les
+ programmeurs avec du poil sur le torse, et les langages graphiques sont pour les mauviettes…}.
Récemment, un chercheur a mis en place un sondage auprès des programmeurs qui devrait à terme permettre de savoir quels langages
-correspondent le mieux à quelles affirmations, selon les programmeurs\cite{the-right-tool}. Ces affirmations sont du type «Ce langage est facile à utiliser» ou
-«Ce langage à une bonne communauté». Les affirmations qui obtiennent les moins bons scores pour un langage donné indiquent en général les
-défauts de ce langage. J'ai donc contacté l'auteur de ce sondage pour lui demander d'ajouter des langages de programmation visuels pendant
-que le sondage est encore ouvert.
+correspondent le mieux à quelles affirmations, selon les programmeurs\cite{the-right-tool}. Ces affirmations sont du type «Ce langage est
+facile à utiliser» ou «Ce langage à une bonne communauté». Les affirmations qui obtiennent les moins bons scores pour un langage donné
+indiquent en général les défauts de ce langage. J'ai donc contacté l'auteur de ce sondage pour lui demander d'ajouter des langages de
+programmation visuels pendant que le sondage est encore ouvert, afin de pouvoir étudier par la suite ces résultats.
\subsection{Langages spécifiques à un domaine}
-DSL = bien mais pas bien. Langages existants : ajout au vocabulaire (fonctions, variables), mais pas à la grammaire (structure) (sauf
-macros, mais pas complètement). Nous on propose de permettre d'écrire de n'importe quelle manière (grammaire libre), tout en gardant la
-possibilité d'ajout au vocabulaire. Nous ne gardons que les barrières nécessaires à une certaine cohérence (des éléments graphiques
-connectés à d'autres). Les blocs peuvent être ronds, les traits annotés d'étiquettes, ou encore d'autres choses.
+Il est fréquent que des programmeurs créent des «langages spécifiques à un domaine» (DSL, Domain Specific Language) pour répondre au besoin
+d'exprimer facilement des instructions et notions très fortement liées à un certain domaine, sans être encombrés par la syntaxe rigide, le
+vocabulaire limité et le manque d'expressivité de leur langage habituel. Les fichiers de configuration sont en général écrits dans un DSL
+par exemple. Mais les DSL ont de grosses limitations : bien qu'ils soient adaptés à l'expression d'idées dans ce domaine, ces langages ne
+possèdent pas l'expressivité nécessaire à des opérations plus complexes~: souvent, ces DSL ne sont complets au sens de turing et n'ont pas
+accès aux bibliothèques de fonctions des autres langages.
+
+C'est pour ces raisons que les DSL sont de plus en plus laissés un peu de côté~: La configuration de GRUB 2 est toujours dans un DSL, mais
+elle est générée dynamiquement par des scripts shell\cite{config-grub}, la configuration du gestionnaire de fenêtres awesome est écrite en
+Lua\cite{config-awesome}, beaucoup de logiciels utilisent python comme langage de script, plutôt que de créer un langage de script
+spécifique à l'application.
+
+D'un autre côté, le problème des langages de programmation généralistes est qu'ils permettent d'augmenter le vocabulaire disponible, par
+l'ajout de fonctions et la création de variables, mais ils ne permettent pas de modifier la grammaire utilisé (la structure du code). En
+réalité, de nombreux langages permettent cela par le biais de macros, mais cette approche est assez limitée~: l'écriture de macros est en
+général fastidieuse -- beaucoup plus difficile que l'écriture de fonctions -- et l'utilisation de macros est néanmoins soumise à un grand
+nombre de contraintes syntaxiques du langage hôte (parenthèses, accolades, \dots). De plus le système de macros de certains langages, comme
+le C, n'a pas la puissance d'un vrai langage : pas de récursivité des macros, pas de structures conditionnelles à l'intérieur d'une macro.
+
+Il y a donc des avantages dans les deux approches, mais aucune ne permet de satisfaire complètement les besoins de facilité d'expression et
+de puissance du langage. Nous proposons une solution alternative~: permettre l'écriture d'un programme sous n'importe quelle forme visuelle
+(grammaire libre), dans un langage graphique orienté dataflow. Nous imposons quelques contraintes, afin de garder une certaine cohérence~:
+\begin{itemize}
+\item Les sous-programmes sont représentés par des éléments graphiques (blocs) ;
+\item Les paramètres d'entrées de ces sous-programmes sont des entités visuelles qu'on peut connecter entre elles (ports) ;
+\item Les valeurs de ces paramètres sont fournies à travers des liens qui relient les ports ;
+\end{itemize}
+Ces règles laissent toutefois une très grande liberté, les blocs peuvent être rectangulaires, ronds ou de n'importe quelle forme. Ils
+pourraient par exemple afficher les calculs mathémathiques qu'ils contiennent non pas sous l'apparence d'instructions mais d'une formule
+mathémathique. LabView utilise cette technique.
+% TODO screenshot en pgf pour la formule mathémathique.
+% TODO ref Intérêt des langages visuels, liste, item 4.
+
+Il est même possible que certains blocs aient une apparence invisible. Par exemple les opérations de conversion de types (cast) pourraient
+être masquées, et ne s'afficher que sur le lien entre la source du transtypage et sa destination.
+
+Avec ces règles, les ports n'ont pas besoin d'être affichés en permanence. Ils peuvent par exemple être dans une boîte de dialogue de
+configuration dui apparaît lorsqu'on double-clique sur le bloc correspondant (World Machine utilise cette approche, et laisse aussi les
+ports visibles en mode «réduit»).
+
+Les liens peuvent être annotés, regrouppés en bus, etc. Comme on peut l'imaginer, avec un minimum d'effort de cohérence, ces libertés sont
+suceptibles de rendre les programmes plus lisibles (non-affichage des éléments qui ne sont pas importants à la comprhéension du programme)
+et plus faciles à écrire (les instructions (blocs) spécialisées ont une interface d'utilisation adaptée).
\subsection{Environnement de développement intégré}
-Espace à l'écran
-\begin{itemize}
-\item code bubbles
-\end{itemize}
+{
+ \setlength{\epigraphwidth}{0.85\linewidth}
+ \renewcommand{\textflush}{justify}
+ \renewcommand{\epigraphflush}{center}
+ \epigraph{
+ Clearly good design is as important for visual languages as for textual ones. Furthermore, the effectiveness of a visual language indeed
+ any precise language for specifying structures, depends to a large extent on the quality of the editor, browser, interpreter, debugger and
+ other tools supplied by the language implementation
+ }{Christopher C. Risley and Trevor J. Smedley \cite{the-editor-is-as-important-as-the-language}}
+}
+
+Les environnements de développement intégré jouent un rôle crucial pour les langages de programmation visuels. En effet, sans la possibilité
+de construire un programme par une séquence (obscure) de caractères, la convivialité du langage est directement liée aux outils que propose
+l'EDI. Ces EDI n'ont en général que peu en commun avec les ceux destinés aux langages textuels, et se présentent plus comme des logiciels de
+dessin vectoriel que comme des éditeurs de texte.
+
+Certaines questions sont récurrentes dans la conception d'EDI pour des langages visuels. Une des plus importante est la gestion de l'espace
+à l'écran~: les primitives graphiques sont décorées de bordures, et d'autres éléments visuels, qui occupent beaucoup d'espace à l'écran,
+réduisant ainsi la quantité d'informations affichées. Ce problème est plus communément connu sous le nom de «Deutsch
+Limit»\cite{deutsch-limit}~:
\begin{quotation}
- Clearly good design is as important for visual languages as for textual ones. Furthermore, the effectiveness of a visual language indeed
- any precise language for specifying structures, depends to a large extent on the quality of the editor, browser, interpreter, debugger and
- other tools supplied by the language implementation\cite{the-editor-is-as-important-as-the-language}
+ Well, this is all fine and well, but the problem with visual programming languages is that you can’t have more than 50 visual primitives
+ on the screen at the same time. How are you going to write an operating system?
\end{quotation}
+Cependant, dans le cas d'un affichage textuel, le cerveau humain n'est pas capable d'ingurgiter en temps réel toute l'information à
+l'écran\footnote{Sur mon écran, on peut loger plus de 60 lignes de texte verticalement, et ce sur 2 colonnes. Allez donc analyser 120 lignes
+ de C d'un seul coup.}. L'affichage sous forme graphique permet au contraire de clarifier et de nettoyer les informations à l'écran, on
+peut donc supposer que le cerveau est capable d'analyser plus rapidement du «code» graphique que son équivalent textuel (un dessin vaut
+mille mots, dit-on).
+
+De plus les programmeurs passent beaucoup de temps à chercher tel ou tel morceau de code ou fonction. L'EDI Code Bubbles\cite{code-bubbles}
+apporte une solution à ce problème pour les langages textuels, en fournissant une interface dans laquelle le programmeur manipule un gand
+nombre de fragments de code assez court, et a la possibilité d'en ouvrir facilement de nouveaux de manière contextuelle (ouvrir la
+définition de cette fonction, ouvrir la documentation de celle-là). Nous avons repris ce principe pour les langages visuels~: Dans la
+définition d'un bloc, il est possible d'ouvrir sur place ou à côté les définitions des sous-blocs.
+
+Une autre solution consiste à utiliser une interface «fish-eye»~: les objets au centre de l'écran ont une taille normale, et sont de plus en
+plus petitsà mesure qu'ils approchent du bord. Une variante est l'interface «zoom», utilisée notamment dans certains jeux
+vidéos\cite{mutant-storm} pour permettre au joueur de focaliser son attention sur les ennemis les plus proches, ou bien avoir une vue
+d'ensemble, et dans le logiciel de prises de notes Project Cecily\cite{project-cecily}.
+
+Plusieurs recherches ont été menées concernant l'utilisation de l'espace à l'écran par les langages visuels, une bibliographie référencant
+plusieurs papiers sur ce sujet est disponible à \cite{biblio-vpl-a-screen-real-estate}.
+
+
\subsection[Manque d'expressivité]{Manque d'expressivité des langages de programmation existants}
\begin{itemize}
\item Design patterns
@@ -239,8 +317,9 @@ Espace à l'écran
\begin{itemize}
\item Control flow graphs.
\item Taxonomie: étudier l'utilité des différentes catégories.
-\item pas de conflits de nommage.
-\item Une infinité de DSL à disposition. Par ex. on peut faire en sorte que dans un outil de conception d'interfaces utilisateur, les composants graphiques (fenêtre, bouton, etc.) ne soient pas de simples images, mais \emph{soient} les fonctions ou objets correspondants.
+\item pas de conflits de nommage (SCID Source Code In Database).
+\item Une infinité de DSL à disposition. Par ex. on peut faire en sorte que dans un outil de conception d'interfaces utilisateur, les
+ composants graphiques (fenêtre, bouton, etc.) ne soient pas de simples images, mais \emph{soient} les fonctions ou objets correspondants.
\end{itemize}
\begin{figure}[h!]
