[Haskell-cafe] Yi project proposal for GSOC 2014

[Mateusz Kowalczyk]

On 10/03/14 16:13, Roman Cheplyaka wrote:
> * Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> [2014-03-10 15:09:49+0000]
>> Greetings,
>>
>> GSOC 2014 proposal period opens in ~4 hours and I'm hoping to
>> participate this year as well. This time around I'd quite like to work
>> on Yi. As we did last year, I think it's worthwhile to put up the
>> proposals on café for people to comment on before they are submitted on
>> Google's site.
>>
>> I paste it in full below so that it is easier to respond to parts of it
>> (although I do ask that you don't quote the whole thing if it's not
>> necessary). In case any changes happen, the most up-to-date version
>> should be at https://gist.github.com/Fuuzetsu/9462709
>>
>> Please feel free to nitpick on anything, throw in suggestions and ask
>> for clarifications. I will give 5 days of discussion period on this
>> after which point I'll submit it on Google's site. I appreciate all
>> feedback.
> 
> From what I've seen, the less uncertainty there is in a GSoC project, the better
> it works. For example, the situation in your past GSoC project where it was
> decided in the middle that instead of implementing markdown syntax you're going
> to do other things is undesirable, IMO.

That was indeed unfortunate. Well, technically Markdown was only part of
the project and ‘the other things’ were the other part of the project. I
do understand where you're coming from however.

> 3 months is a very short time for a research project. (By research I mean not
> academic research, but finding a way (or the best way) to do something.)
> And here you're basically saying "there are several ways to do that, we'll
> figure out what to do as we go".

We're aware of this. The problem is that if I were to conduct this
research starting today and it takes a week to settle on which approach
we'll take, we end up with close to no discussion period as the proposal
submissions are open for 10 days. I left it open like this because it's
an implementation detail: after playing with it for a few days, it might
turn out that the FRP approach is actually amazing and we should do
that. I'd rather not tie myself to a specific implementation before even
considering other options. If I state today that we'll use STM, I'm
stuck with STM even if it turns out a terrible idea. In the end the goal
is to allow for concurrency in the editor state, and that much should be
clear.

> If, on the other hand, it was already decided what the right architecture for
> concurrency in Yi should be, and it was just a matter of someone doing the work,
> it would be a good project.

In this case, deciding on the right architecture is part of doing the work.

> Roman
> 


-- 
Mateusz K.