I was recently at a java conference. The conference was excellent. I sincerely support the idea of getting together with other technology people to discuss best practices in our field and share knowledge. It's a great way to learn and even just understand that there are other people out there who understand what your job is like.
However, there is a risk in going to these conferences and it jumped out at me in a session on immutability.
The presenter was making the case for immutable programming which is the idea that almost none of your variables should ever be allowed to change state. The talk was good, but I find it easy to become almost frantic at sessions like this. Here's a brief look inside of my head:
"Oh gosh...I program with so much mutability! I need to change. I need to change now! MUTABILITY MIGHT END THE WORLD!"
While it is true that programming immutably is better than programming mutably, mutable programs are not the worst thing ever. We've been using them for years and a lot of people will probably continue to use them for years. Immutability may be better, but it isn't the holy grail of programming.
I imagine the same thing happened when the infamous "Go to statement considered harmful" paper came out. Yes, go to is bad. Yes, it is easy to shoot yourself in the foot. But you can also create programs with it that work. And that's really what we need in an enterprise environment, isn't it? Programs that work.
It's easy to set your goal as the perfect programming style and to not be satisfied until you write everything perfectly. Sometimes you need to accept that your design isn't the best and might require work to update later. Sometimes you need to accept that even though you'll strive for perfection, not all of your programs will be that. And that's ok. Make the best program you can in the time you have, learn from your mistakes (and conferences) and improve your programming style over time.
No comments:
Post a Comment