Comments for Empathy Box

Comment on But wait, perhaps we can optimize it further! by Reg Braithwaite

Reg Braithwaite — Mon, 13 Aug 2007 14:46:02 +0000

The good news is that this should have NO effect on performance. Just about every compiler and interpreter implementation out there can optimize the test and the return statement away.

I recall writing a Scheme implementation in 1998 that optimized this sort of thing just so that I could use my own version of #IF statements without incurring runtime costs.

That being said, now we can count the cost of human capital. How long does it take a programmer reviewing this code to recover from the inevitable coughing/laughing fit?

Comment on But wait, perhaps we can optimize it further! by Peter Holm

Peter Holm — Mon, 04 Dec 2006 18:50:11 +0000

Haha I love the title “but wait, perhaps we can optimize it further!”.

Comment on But wait, perhaps we can optimize it further! by Brent Ritchie

Brent Ritchie — Tue, 14 Nov 2006 19:02:59 +0000

I think someone needs a little practice with DeMorgan’s Laws and basic Logic Principles. This is totally not cool, and unacceptable. I could only imagine how much redundent checks like these slow down execution and clutter the control flow of a program.

Comment on The Ideas in the Spring Framework by Sijin

Sijin — Fri, 27 Oct 2006 16:28:18 +0000

Right on regarding the “Program to an interface part”, see my post on a similar topic http://www.indiangeek.net/?p=41

Comment on But wait, perhaps we can optimize it further! by DAR

DAR — Fri, 27 Oct 2006 13:45:08 +0000

Sounds like fodder for thedailywtf!

Comment on The Ideas in the Spring Framework by Wes Maldonado: Data Junkie » Blog Archive » The Number One NIH Syndrome Sympton (or, How I learned to not invent wheels and learned to love 3rd party components.)

Thu, 26 Oct 2006 20:52:47 +0000

[…] I was happily reading The Ideas in the Spring Framework for Java that covered the basics of Dependency Injection using Spring and linked to another article, Dependency Injection without Frameworks… which screamed of NIH and slightly ruined my day. […]

Comment on 5 Principles For Programming by bugfox blog » Blog Archive » 5 Principles For Programming

bugfox blog » Blog Archive » 5 Principles For Programming — Fri, 20 Oct 2006 14:42:43 +0000

[…] Simple but deep: Empathy Box :: 5 Principles For Programming […]

Comment on 5 Principles For Programming by David House

David House — Thu, 19 Oct 2006 15:51:44 +0000

Really interesting post. I’m a Haskeller myself, so I’m in total accord with things like your advocation of static typing. The last section was probably the most interesting — I can claim knowledge of a functional programming language, I’ve read a few papers and am about to start a maths degree, but kernels scare me and my database experience goes about as far as MySQL. I think I’ll be buying some books.

Thanks again.

Comment on 5 Principles For Programming by James Watson

James Watson — Tue, 17 Oct 2006 16:43:00 +0000

“I feel that unless a member needs to be non-final, it should be non-final.”

That should read:

I feel that unless a member needs to be non-final, it should be final.

Comment on 5 Principles For Programming by James Watson

James Watson — Tue, 17 Oct 2006 16:40:01 +0000

The points about state are very good to point out as they are often unknown/ignored in the Java universe. I feel that unless a member needs to be non-final, it should be non-final. I wish the compiler would follow method calls in the constructor to check for initializing finals, though.

Another technique is to use stateful objects that never escape the stack. There is no concurrency issues with this and in fact, future versions of Java will (if all goes well) actually create such Objects on the stack or even extract their members onto the stack.

But again, I completely agree with reducting state to the absolute minimum. If you do so, it will be much easier to refactor code to be threadsafe if needed in the future.