James Golick

Having little experience with Rails, it's the tone of that "Crazy, Heretical" article [1] that really strikes me. That tone where you're laboring to describe something that really truly does make sense when you're in the company of a bunch of people that just don't want to hear it.

There's too much purism in those kinds of arguments, arguments that really are more about spectrums. It sounds like Rails is really great for learning the shallowest 40% of a wide variety of programming concerns, and a lot of web solutions for small clients aren't ever going to dip below that 40%. And as soon as you get beyond that 40%, asking questions like "but what if it doesn't make sense to do it that way?" and "what is that weird runtime bug that doesn't happen in my development environment?" and "why can't I refactor without being scared I'll introduce a weird regression bug?" then it's totally fine to be attracted to the idea of static typing, compilation, and libraries/frameworks that are more explicit.

[1] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html

Rails used as intended can be a real pain to upgrade, I agree.

Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required.

[1] https://github.com/garybernhardt/sucks-rocks
[2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html
[3] http://objectsonrails.com/
[4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.html
[5] https://www.youtube.com/watch?v=CGN4RFkhH2M

You posted something similar at http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-segal.html#comment-217524976 and I've checked a few other posts of yours surrounding the context. I'm not sure why you're giving Loren grief.

> If Loren can be part of that solution, I'd love to see him working for RubyGems rather than against it, for sure.

I know you're trying to be a diplomatic bridge for the RubyGems team, however saying things like that just makes me shake my head.

I appreciate James' appeal. As an outsider to the situation, I wonder why not just let Loren do his thing without comments like that? I'm also saying this with respect to Eric and Ryan's work.

Defining instance-specific behavior of any kind is catastrophic to method caching. JRuby has a hierarchical method cache so it can clear only what's needed, but MRI does not:

http://jamesgolick.com/2013/4/14/mris-method-caches.html

The late, great James Golick had a patch to add one once, but it never got merged upstream.

If you care about performance even the tiniest bit at all whatsoever, please don't use the techniques discussed in the OP in production code or in your gems. It may make your memos 30% faster on a microbenchmark... while causing the rest of your program to run considerably slower.

If you're a Rails developer, you probably have a config/initializers/backtrace_silencers.rb file in your app. Think of James the next time you see that file. He wrote the initial implementation:

http://jamesgolick.com/2007/12/1/noisy-backtraces-got-you-down.html

DHH later ported the work to Rails:

https://github.com/rails/rails/commit/f42c77f927eb49b00e84d355e07de48723d03fcb.patch

I knew James mostly online and a little in person from various programming conferences. He was smart, funny, and kind. He made a difference. He will be missed.