Improving Motoko's programmability

I’ve felt like in the past that I wish I had some reflection available. Probably mostly when trying to write some generic helper functions that might operate over some limited set of types that I want to do specific things for.

This is all likely based on my bad practices from javascript and some old .net habits. I know they are bad habits, but it is still frustrating to have a language that claims to be general-purpose but doesn’t let me do some things.

I wrote the candy library(which really bastardized the language - candy_library/lib.mo at main · aramakme/candy_library · GitHub ) because I needed a way to store JSON style dynamic data structures. I know that I shouldn’t use them in general, but I also need them in specific circumstances, especially when trying to plan for future extensibility without accidentally blowing away my data store on an upgrade because I added a variant in the wrong order. With the library I’m able to reflect on the data coming in and out of my functions. Maybe a refactoring of the library by a better programmer could make it useful for addressing the situations where you need reflection without needing to change the language.

This is mostly a collection of thoughts while I’m in a place where I’m having a bit of trouble concentrating, but I thought I’d throw the thoughts out there for discussion.

2 Likes