He jumps right to features and benefits, and so is more succinct than I would have been. Its a good read. Plus, it saves me the trouble :)
A few comments:
- The EE (as the underlying engine of the OCP) is about supporting a more scalable, abstracted runtime environment. For example, a lot of design time went into versioning and deployment considerations, and a lot of thought went in to figuring out how to minimize service APIs.
There's a big difference between object-oriented or component development and the services model we're advocating in the OCP (which isn't necessarily fully reflected in all of our first generation services).
A rationale platform is more than just a collection of services.
- One of the core guiding priniciples of the OCP is data driven design: factoring policy OUT of code - turning technology limitations into business and product choices, as they should be.
Who's your Daddy?
Completely unrelated to the EE, but if you read further down on JR's blog, you'll see that he discusses a coding contest some of us former hard-core coders had here at AOL a few weeks ago - as John notes, it wasn't anything official, just an informal challenge a small group of us conducted for one week (after hours, of course :)).
The challenge was to write a fast, efficient memory allocator for small blocks (1024 bytes or less), as compared to the Microsoft C common runtime (MSVCRT) and SmartHeap. We used both a custom test and the smart heap benchmark for comparison.
John goes into some more details in his post - I just wanted to point out that I was the winner :)
I'll post the code and benchmark harness at some point in the near future, but the scores (per the system JR mentions on his blog) were as follows:
Lower is better (names changed to protect the innocent):
- Sree Kotay 13584.3
- Bave Desbris 15652.2
- Rohn Jobinson 16378.4
- Mat Peenan 16709.2
- Microsoft CRT 52516.8
- Park Moesch [no show]
- Cave Dorboy [no show]
Justin Uberti kindly judged for us.
We couldn't benchmark smartheap entirely accurately (because it doesn't call our base allocator for memory efficiency measurement), but using the amount reported by the OS as a proxy, well, suffice it to say that it came out in middle of the pack, in both speed and efficiency.
So, in summation: NYAH NYAH NYAH hahah!!!! :P