During this week I have an exchange with Mario Havel about the possibility, which I mentioned last week, to dedicate the four months of the EPF to work on this idea of a new programming language that I have been thinking about, even before the EPF.

We both came to the conclusion that it might be too long and complex for one person and four months of work. Considering this, I decided that the ideal would be to help the Ipsilon team to gain more experience, possibly with the implementation of EOFv1, if there is no rush for it to be part of the next update (I don't want to slow everyone down).

At the same time, and since I will probably keep reading and developing ideas about this new language in my free time, we agreed that I could add all the ideas I collect to my development updates.

Ipsilon

Regarding my idea of helping the Ipsilon team, this week the progress was a little bit slow, mainly because the communication via Discord doesn't seem to be working (not sure if we share the same timezone or if they are too busy with other projects). I will try to communicate again next week, because my lack of progress is starting to worry me.

Others

Trying to make the best use of time, I've been catching up with C++ again, because probably most of my contributions will be in this language. Also, I've been re-reading the Ethereum yellow paper, to try to refresh as many ideas as possible (and because it's a key document in relation to the work I'm tackling).

I'm also starting to browse through the Fe and Vyper repositories, to better understand the codebase and, in the case of Vyper, looking for "Easy Pickings" issues to try to do small collaborations (they don't seem to have the time to take someone to mentor). I think that if communication with Ipsilon continues to be a bit slow, I could use those downtimes to collaborate with one of these projects.

Regarding my own ideas for a PL, I also have been reading about typestate, a way of associating states to the different types of a language, in order to model the program (or in this case, contract) interractions in a way that is much closer to a state machine, enhancing software reliability and allowing to use a mental model (which I think is) much "closer" to reality. My main take is that programming languages for smart contracts should try to be as explicit as possible (with respect to restrictions at least), to help the developer avoid expensive mistakes.