From: Mart Lubbers Date: Wed, 8 Jun 2016 09:18:17 +0000 (+0200) Subject: tonic X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=HEAD;p=rsss1516.git tonic --- diff --git a/shorts2/tonic.tex b/shorts2/tonic.tex index 532b248..e03093f 100644 --- a/shorts2/tonic.tex +++ b/shorts2/tonic.tex @@ -13,30 +13,60 @@ \author{Mart Lubbers (s4109503)} \title{Static and Dynamic Visualisations of Monadic Programs} -\date{2016{--}06{-}08} +\date{2016{-}06{-}08} \begin{document} \maketitle \subsubsection*{Summary \& Evidence} %Summary (as briefly as you can - two or three sentences) +This paper presents a method of adding static and dynamic blueprints for +information flow to iTasks programs and general programs that use the monadic +design patterns. The extension, Tonic, is meant to bridge the gap between the +programmer and the designer and to offer debugging facilities for iTasks and +monadic programs. %Evidence (what evidence is offered to support the claims?) +Accompanied with the detailed description is some implementation and a lot of +examples in the form of screenprints from the generated static blueprints and +prints showing the dynamic blueprints. For the iTasks programs the code is just +another task that decorates the existing tasks. For the general monad +implementation only a description of the implementation in the compiler is +given. \subsubsection*{Strengths \& Weaknesses} %Strength (what positive basis is there for publishing/reading it?) +The strength of the paper is the readability and clearness of the evidence +proposed. The problem they tackle is a real problem that has been around and +there are a lot of solutions in the Object Oriented world. However there are +not a lot of solutions for the Functional Programming world and this paper +presents one. %Weaknesses +Because there is no in-depth implementation it is not easily possible to +recreate the system from the paper alone. Also the implementation for the +dynamic blueprint system for general monads looks very hacky because of the TCP +communication. While this is a great idea for the future it might not be worth +mentioning the current implementation. \subsubsection*{Evaluation} %Evaluation (if you were running the conference/journal where it was published, %would you recommend acceptance?) +I would advice the board to accept the paper with minor changes. %Comments on quality of writing +There are some buggy references to images. The images that are referred to +appear on the next page and contain colors that is not available when printed in +greyscale. Also there is a slight inconsistency in the abstract with emphasis +of proper names. Besides those two minor issues the paper is very well written +and very understandable for people without particular iTasks knowledge or +knowledge about monadic programming. \subsubsection*{Discussion} %Queries for discussion \begin{itemize} - \item + \item There should be more introduction to the iTasks framework. + \item The dynamic version of the general blueprint system should not have + been mentioned. \end{itemize} \end{document}