tonic

diff --git a/shorts2/tonic.tex b/shorts2/tonic.tex
index 532b248..e03093f 100644 (file)
--- a/shorts2/tonic.tex
+++ b/shorts2/tonic.tex
@@ -13,30 +13,60 @@
 
 \author{Mart Lubbers (s4109503)}
 \title{Static and Dynamic Visualisations of Monadic Programs}
 
 \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)
 
 \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?)
 
 %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?)
 
 \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
 
 %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?)
 
 \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
 
 %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}
 
 \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}
 \end{itemize}
 
 \end{document}