Re: [Haskell-cafe] Yi project proposal for GSOC 2014

On 10/03/14 16:13, Roman Cheplyaka wrote:

* Mateusz Kowalczyk [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.