spylls VS contracts.ruby

In my experience of working on complicated algorithmic project (spylls spellchecker) in Python after 15+ years of Ruby, I really liked the gradual typing experience: you write dynamic code to get a grip of the logic, and then start to add typing here and there - and it does help to clarify design, catch accidental null possibility, and in general make inter-module API more visible.

Currently, Spylls has ≈1.5k lines of library code in 14 files. It conforms (with some reservations) to all Hunspell's integrational tests. Those tests look like a set of files each, consisting of "test dictionary + what words should be considered good, what words should be considered bad, what should be suggested instead of the bad words", and there are 127 of such sets to pass. There are 2 thousand comment lines in the code, explaining thoroughly every detail of the algorithm and rendered at the Spylls documentation site; note that besides docstrings at the beginning of each class and method, there are also inline comments in code—that's why the documentation site uses custom theme with inline "Show code" feature.

I had written a code contracts library for Ruby about 10 years ago [1]. I stopped working on it, mainly because it only provided runtime type checking, and I wanted static type checking. Nowadays my main language is typescript. I miss ruby, but can't give up the static typing that typescript provides. I really wish Ruby had a type system with the same level of support. VSCode has phenomenal TS support, and there's a community adding types to projects [2]. This is something I'd like for Ruby also.

> An integral part of this informality is relying on Matz’s taste and intuition for everything that affects the language’s core.

I think a more defined process would mean a better future for Ruby and Ruby developers.

- [1] https://github.com/egonschiele/contracts.ruby

- [2] https://github.com/DefinitelyTyped/DefinitelyTyped

Contracts gem can be a nice middle-ground. It has a fairly readably syntax and only checks method inputs and outputs at runtime. We use it to annotate important core methods, while leaving the rest type-free.

For example contracts gem needs to have a separate version/branch for ruby 3.x due to the breaking change above

This gives me access to input values as long as I defined them via attr_reader. Oh what's the Contract XXX above attr_reader? They are from contracts.ruby and completely optional and won't be explained in this post. You can safely ignore those and maybe study that gem later.