Coltrane VS bootsnap

https://github.com/pedrozath/coltrane Has gotten me thinking about AI for teaching music theory, but I really don't think it is there yet, music theory is far to fuzzy for AI right now. I do think there are niches where it could be quite great, it could absolutely do well in teaching much of counterpoint and classical forms, perhaps even the basics of harmony but it is hard to disentangle harmony from the fuzzy areas and I could see AI doing more damage than good there.

> because none of the commands work

The Readme had some outdated information. Explained better on the issue https://github.com/pedrozath/coltrane/issues/56

> The chords for guitar also are weird. It doesn't seem to be using traditional shapes, but is looking for available notes within a fret range. Which leads to difficult, basically unusable fingerings.

That's a design choice on this library. I tried to rely the least as possible on lookup tables, dictionaries, etc, leaving things to be discovered algorithmically instead. It is a difficult challenge, but for example if someone decides to use an entirely different tuning, the software will provide. The software might also find chords that you have never thought about. What has to be improved here is the sorting mechanism for guitar chords.

> The other functions would be very useful to have, if it worked

Just try running `coltrane` and test it interactively.

There's this https://github.com/pedrozath/coltrane

Coltrane music theory library on the command line

Indeed, I did not mention Bootsnap so as to detract the core point.

> That's one of the things Bootsnap does to speedup boot time. And when you do that, there's no compilation at runtime.

Correct, if one does `bootsnap precompile`.

Bootsnap hooks itself on `Kernel#load` + `Kernel#require` and `RubyVM::InstructionSequence#load_iseq`:

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

https://github.com/Shopify/bootsnap/blob/f627992c52642394311...

Essentially this means that it makes LOAD_PATH lookup faster + intercepts iseq compilation to store to cache on a miss and return a cached version on a hit.

That does not change the load order.

> But that doesn't change anything about OP's suggestion, it's still impossible to know if an interface will ever be implemented.

Again correct, as even with `bootsnap precompile` it would only result in earlier ISeq generation (it is essentially cache priming instead of doing it "lazily" on demand), not the time at which these ISeq get loaded and effective, so even then an `abstract` keyword would be ineffective.

I always had mixed feelings about writing native Ruby extensions. They surely are the way to make critical parts of the code run faster, but the developer experience around that was not great for a Ruby programmer like me. Sure, I know C. This was the second language I learned (after Pascal). I can write C, I can read C, and I even wrote some larger extensions in it, but I never felt comfortable with it.

To alleviate this problem, the engineers at Shopify created bootsnap, a gem which automatically detects and caches exact load paths to make those require calls fast (see Bootsnap: Optimizing Ruby App Boot Time for details).