Showing posts with label Paul Graham. Show all posts
Showing posts with label Paul Graham. Show all posts

Friday, November 29, 2013

Book Recommendation: Hackers & Painters by Paul Graham


Last Tuesday, the Geeky Book Club didn't meet. The night was "off," owing to the Holidays. So, in lieu of Cucumber, I thought I would take today's space to recommend one of the best "techie" reads to be had.

I speak of "Hackers & Painters," by Paul Graham.

Notice that I didn't say I would review it. I'm just recommending it. It's the best technology read around, and if you haven't, you need to get a copy and start reading it ex post haste.

If you want to get a taste, you can read most of the contents online here.





Wednesday, October 16, 2013

Geeky Book Club Had Neither Me nor a Book Last Night


TheHackerCIO is in crunch mode to meet deadlines for client delivery, so I had to miss my GeekBookClub (LAJUG study group) last night. So, the poor club remained wanting in two essential ways:
  • an incredibly brilliant, scintillating commentator, such as TheHackerCIO.
  • a book to discuss.
A book club without a book!

A geeky club without a geek! At least, without one normally in attendance.

What a situation.

The club has finished Java Performance and typically reads articles in-between books for a week or two. Next book up is The Pragmatic Programmer on Cucumber.

I'm very sorry I missed the discussion of the Paul Graham article, Hackers & Painters. If you haven't read Paul Graham's essay, you need to stop reading my blog now, go there, and read it. Then read it again. Then poke around reading his other essays.

I'll explain why in another post, or possibly, an essay of my own!

I remain, Hacking in Crunch Mode,

TheHackerCIO





Wednesday, October 9, 2013

Bookishness & Geekiness

Internally I think of it as "My Geeky Book Club." And so I refer to it with my wife. But, the official name is LAJUG Study Group,  and last night the remaining faithful few finished up the Performance Book:


Now, our group will take a little break, and read a few articles, specifically: 
Paul Graham is a Technologist everyone should know about. Read his essays, if you haven't already. The link above will give you a start. He's a successful entrepreneur and now runs Y-Combinator , which is the best incubator for tech startups to get into. Not so much for the money -- you won't get that much -- but for the in-house expertise on starting tech companies, which is incomparable, and invaluable. 

Invaluable, in that it can't be valued, because it's value is too high. That's one of those problem words that always bothers me, because there are other reasons I can think of why something might be invaluable. For instance, working at a multi-billion dollar enterprise is experience that is invaluable: it can't be valued, because it is worthless. They lied about their desire to transform their technology, or at any rate they have no serious desire to step outside of their comfort zone and really accomplish much of anything. So the time spent working there and the experience overall is invaluable. This is another word to put on my list of peculiar english expressions along with inflammable, which means flammable! But we don't want to get confused here and we need to get back to geekiness and books and articles!

After next weeks session on the two articles linked above, we'll move into BDD and Cucumber. My copy has arrived from Amazon, but I haven't imbibed yet. So comments will have to come later.

As to last nights discussion, none of us are too enamored with the Performance Book, so we ventured fairly wide in our chatting.

One early topic was a comparison of several books from the past, and what was learned from them.  I noted that the Azul presentation, in my view, was far superior to this book. I felt that the Azul presentation answered questions and raised my understanding about Java Performance and Garbage Collection. In contrast, while this book answered some questions and improved my understanding somewhat, for everything I learned, I became aware of ten more questions, issues, and conditioning factors, which were NOT explained. Thus I was left with the feeling that in some sense I knew less than what I started with. Yes, I had gained knowledge, but I had gained more awareness of how lacking that new knowledge was than I had gained in new knowledge. This is kind of a difficult point to explain succinctly, but the pattern is: to understand A, you must understand Q, R, S, T, U and V to enter into a proper comprehension of A and it's implications. And here is are a few more details about A. But in the meantime, if you want to know about Q, R, S, T, U, and V, please consult the references at the chapter end. That is the pattern of what I felt from reading through this Performance Book.

By contrast, with the Azul presentation, I learned basic principles, and then saw an analysis of existent JVMs in the context of those basic principles. That's an extraordinarily good structure for any presentation. And it didn't leave me with tons of unanswered nagging problems and issues.

Another member noted that with the Generics book, it had been confusing, and he concluded that the Java community should have "just said no" to Generics.  I've always found them confusing as well. And I prefer keeping a language simple. 

He also noted that with the Concurrency book, while many of the corner cases were disturbing, there were lots of tips and "don't go there" advice that was well worthwhile.

Then there was some discussion about NRU: Not Recently Used. That's kind of interesting, this this is distinguished from the LRU (Least Recently Used) algorithm with which we are all familiar. Apparently, NRU is less precise, but has less bookkeeping overhead. 

Everyone was kind of surprised to learn that with a Java start command (-XX LargePageSizeInBytes) you can alter the page size all the way up to a Gigabyte! Not sure when I'd want to do this, but it's quite interesting. Perhaps an application might be able to tune to page size. Have to think about that one.

On p. 549, we got hit with a countervailing opinion that "pessimistic locking may provide better performance." But the conventional Whiz-dumb has it that optimistic locking will provide better performance. We discussed this for some time and came to see that really it depends on what the statistical likelihood is of lock failure, in your particular environment. If you're likely to fail on a particular lock, then it actually improves performance if you pessimistically lock! But I don't think anyone ever notes this nearly obvious fact, or stops to consider what their particular environment likelihood of failure is. 

So, that wraps up a difficult, demanding, and marginally rewarding read. I'm still a better person for having worked through it. But I would really love to take the Azul presentation and compare it to the Book chapters on the JVM. Perhaps, if Azul provides us with their slides, I'll do that.

I Remain, Ever Reading, and Ever ...

TheHackerCIO