discussion.tex

\section{Discussion}
\label{sec:discussion}

% Discussion of actual solution \emph{vs.} initial constraints from \ref{sec:problem}. Explain the space of the solution, why we made it this way.
There are number of discussions that arised while evaluating the experiences
with our previous tools in courses, and that were taked into account in Wollok's
design.

One of them is whether the learning experience should provide a way to reuse
code while still in the form of stand-alone objects without classes.
We detected that while working only with objects, on the first part of the
course, it's common to end-up with excersices where there will be at least some
sort of duplicated code between objects.
Therefore, later versions of Ozono introduced a mechanism based on prototypes, 
similar to that found in Self language\cite{Ungar87self:the, Ungar91organizingprograms}. 
That allowed full reuse of code (both behavior and state definition).

However, practice has shown that introducing prototyping did not smooth the transition between objects and classes. Actually it made it harder.
% In addition, prototyping is an excellent abstract model for pure object languages, keeping it simple and incredible powerful.
% But there are almost no popular or industrial languages implementing it (besides Javascript which is not exactly as standard Self prototyping). 
Therefore, we decided that Wollok should not provide a way of code-reuse between stand-alone objects.
Examples have to be carefully selected to avoid confronting students to problems they will not be able to solve gracefully.
% When duplicated code appears as part of the course, it's important to highlight that to students, and delay solving code duplication later with classes. 
% This subject will be analysed later when we can have results of the application of this approach instead of the one of Ozono.

\medskip 
Another interesting point of discussion is the way to integrate a visual tools
to improve the understanding of the program. There are many different solutions
to this problem. One approach used by several tools, like BlueJ
\cite{bennedsen_bluej_2010} involves strict UML as a diagram format for showing
the information.
We think that this decistion is not the best option, because UML  
includes a lot of information that is not relevant for the inexperienced programmer. 
We are exploring the idea to have custom diagram formats only showing information that 
is relevant to the teaching process. Furthermore, we are analysing the possibility of 
adding more attractive diagrams, like board games, or adding custom images and
animations to objects.
Allowing the creation of basic board games, and presenting the information in a more attractive way. 
This idea is explored in Gobstones \cite{lopez_nombre_2012} but with a fixed board.

\medskip
Regarding the language grammar and syntax we have at least two points that need
to be discussed. One is whether Wollok should introduce alternative
advanced syntax for several constructions like property access, or message
sending. The objective of this alternative syntax would be to reduce the amount
of code and syntax elements (\eg parenthesis, dot for sending messages, or calling getters and
setters). Modern languages such as Scala\cite{Oder04a} and
XTend \footnote{http://www.eclipse.org/xtend/} provide such syntax sugar.
Although we need to be careful because this shouldn't confuse novice programmers.

The second point regarding syntax (and actually the whole language) is whether
the language should support some kind of type-level programming. Starting from
type annotations (to fix types for example for parameters, or variables), but
also type aliases, which could come handy given the fact that Wollok has
structural-types. This of course would be an advance topic for the course.
Probably the last topic. Again this concern shouldn't confuse the student all
over the course until reached the point where types are introduced.

\np{Si hacemos una versión larga tenemos que extender esto.}
Finally, an important design issue addressed by Wollok is the use of text files instead of image
 based as a way of storing the programs. This decision was taken with the objective of ease the 
process of switching to an industrial language, as most of them use this way. 
This also allows the use of industrial tools like Version Control Systems, collaborative tools 
and code revisions.

% Evaluation of the solution. How does the solution meet the criteria? Where does it succeed or fails...