pat_shaughnessy

That's the magic of YJIT, and what I'll describe in the rest of Chapter 4. YJIT uses a "wait-and-see" approach, and often defers compilation of the block/function until the actual types are provided by your program. And YJIT then keeps track of separate block versions based on the operand types, and can call the appropriate block version as needed.

This basic algorithm is called "Basic Block Versioning." Maxime Chevalier-Boisvert from Shopify has some great presentations online about this; for example [1].

I believe ZJIT, the newer JIT engine, uses a different approach. I'm exploring that now.

[1] https://www.youtube.com/watch?v=zO9_uTaELCw — RubyConf 2021 - YJIT - Building a new JIT Compiler inside CRuby by Maxime Chevalier Boisvert.

> Idiomatic Ruby uses blocks for loop bodies

Yes that's something I want to dig into and explore in this chapter... when exactly does Ruby's JIT compiler activate and optimize our code? And you're right: since Ruby will JIT blocks as if they were separate function many loops will be optimized using this simple heuristic.

What a lovely comment - thank you!

I tried that while researching the article, but found the call to "puts" doesn't link without the standard library code. And without a "puts" or similar call to produce output LLVM optimized the entire program away :)

I suppose this could work if, as you suggest, I manually called out to a lib_c function like printf instead.

(author here) ...FYI I actually learned assembly language for the first time back in the 1970s and 80s using a 6809 inside a Radio Shack "Color Computer." I was super-fun at the time. I don't remember much of it now but I'm sure x86 isn't as clean or fun as 6809 assembly was.

Thanks a lot. I'm looking forward to writing it, I think it will be interesting.

Thanks! Glad to hear you made it to the bottom :) I always worry that I tend to write on and on for too long.

Thank you! Knowing that people enjoy reading this sort of thing makes it worthwhile.

Thanks everyone for the kind comments, and for taking the time to read this stuff :)

Yes, good point. Rails has a lot of conventions like this - that "first" implies ordering by primary key (by default). I just imagine that most Rails developers don't think about sorting and its implications when they ask for the first record.

Oh absolutely. I thought about saying that, and just ran out of energy before posting the article this morning.

The reason I used this particular SQL statement as an example is that ActiveRecord (a Ruby ORM) generates it from a fairly simple, common Ruby expression. I suppose ActiveRecord could be improved to drop the sort when you know there's one one possible match.

By the way, I used a simple query on purpose to keep things simple for readers (and for me, the author!). By using such a simple SQL statement I was able to avoid complex optimizations and algorithms I would haven't been able to follow - and that wouldn't have helped readers much anyway. I wanted to get the basic idea across to people who have no prior knowledge of DB internals.

Plus I wasn't interested in comparing one DB vs. another, as much as I was interested in understanding how any DB works.

This sounds fascinating - I read Codd's original paper on relational algebra for my last post (http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf).

... and this notation almost seems more similar to the underlying math than SQL does.

Thanks :) Yea indexes are where some of the real "magic" of database servers happens. It will be fun to write that up...

I discuss circular references and how CPython handles them a bit in my followup post: http://patshaughnessy.net/2013/10/30/generational-gc-in-pyth...

Another great post, Daniel... keep 'em coming!

I agree with the other commenters - RailsApps is a fantastic resource for the community. It's a great way to have a peer reviewed and curated set of high quality examples to learn from.

At the same time, I do agree with many of the points in Tammer's article. I think the danger with Rails templates, scaffolding and even Daniel's work is that it's very easy to take it and use it part and parcel without understanding what's really going on inside, and why certain decisions were made (this gem vs. that gem, or this code technique vs. that). I think there's a lot of value in starting from scratch (Daniel's option #1) and adding things step by step. As Tammer pointed out, this can lead to a positive team discussion and learning dynamic. And I don't mind the extra typing and time required.

The next time I start a new Rails app, I'll probably: - Look for a good example to learn from in RailsApps or elsewhere. - But then step back to "rails new" and add in the recommended gems bit by bit, with testing along the way. - Hopefully contribute back to RailsApp if I learn anything new :)

Yup, (re)reading SICP is definitely on my list!

Awesome links - thank you!

Thanks! Yea for some reason learning how things work is often more satisfying to me than building stuff... I guess I'm more of a scientist than an engineer?

Interesting idea - thanks for the suggestion!

Absolutely - it is a pleasure to read. Someday I'd like to learn how another language is implemented, maybe JavaScript or something like Haskell, but I'm afraid the language source code will be much more difficult to understand than Ruby's is.

I agree - it's an amazing narrative of an interesting time. I wonder if contacting Xerox directly would lead to some more historical archives?

Thanks Gary... yea and all of these things more or less mean the same thing.

At a more technical, detailed level, however, the Ruby core team uses both the term "metaclass" (in the same sense Smalltalk uses it - the class of a class), and the term "singleton" (the hidden class of a single object instance). You can see what I mean by looking through the MRI class.c source file.

Yea it's been a source of discussion (and confusion) for years. Thanks for the link!

Great read - thanks! I love the river metaphors. The metaphysics discussion also brought back memories of college philosophy classes on Plato's theories around ideas vs. forms. Probably my memory is failing me here and someone more versed in philosophy could help me out here :) But to me it's interesting how classical philosophy could even remotely be related to computer programming.

FYI I used a Ruby library called Coderay to handle code highlighting. This wasn't integrated with Pages, but instead with the Bookshop Ruby gem after I moved the text into HTML files.

The code was inline in the HTML, but set apart using pre tags.

XSL! Oh no! I'll have to steer clear of that :)

The only complaint I've heard about Leanpub is that they don't give the author access to end user email addresses. I don't use email as a marketing tool much (almost never) but I would guess this could be a show-stopper for many eBook authors who are considering their solution.

Thanks for the links - I had heard of Scrivener but didn't try using it. The approach I took with Bookshop is more geared towards programmers and web developers who are comfortable with HTML/CSS coding.

I love your "in 30 minutes" idea! Easier to read, and I'm guessing easier to write for you. My eBook definitely will take more than 30 minutes to read :)