This gets into the area of patterns and anti-patterns a little bit. Some people think that when patterns emerge in the use of a programming language, that they are a sign of said language's or its libraries' shortcomings. I tend to disagree with that hard and fast rule.
In any event, I think most would agree that no programming language so far has been able to succeed in covering every low-level eventuality in its standard libraries. This is understandable, because so far, even if a language is released with nothing but state-of-the-art standard API, technology marches on, and new design patterns emerge that could not have been foreseen. That's where a lot of debates start with regard to how languages and libraries should be developed, maintained, and retired, how extensible syntax should be, how important principle of least surprise should be, and so on. >From my own practical experience, every developer exhibiting at least a >modicum of care about their trade is bound to develop some preferences in >style, some bags of tricks, some tools in their toolbox. These don't always >have to come in the form of prepackaged libraries they carry with them from >project to project and from employer to employer (though it's possible). >What's important is that they retain that intimate knowledge of their style >and tricks in their mind and therefore are likely to use them in the future. >And so team leads have their own such styles and bags of tricks, hopefully >bigger, better, and more battle tested than those of the developers taking >cues from them. Occasionally their ways are challenged and are revised or >amended, which is all part of the nature of the game. Practical software >development is both art and science, which is why I dig it so. Alexey ________________________________ From: Brian Leathem <[email protected]> To: The Java Posse <[email protected]> Sent: Fri, November 13, 2009 12:50:34 PM Subject: [The Java Posse] Re: A "max" function for comparables On Nov 13, 8:38 am, Kevin Wright <[email protected]> wrote: > On Fri, Nov 13, 2009 at 4:34 PM, Alexey <[email protected]> wrote: > > Otherwise, doesn't seem too difficult to write your own such method, > > no? It is indeed trivial to write my own method. I could then package that method along with other such methods in a "toolbox" jar that I include with all my projects. It just strikes me that in the general case it's not good if everyone does this, as one will have to learn a new toolbox API every time one joins a new project. I don't have the experience of working in many organizations, or on a diverse set of projects, but are such toolboxes common? Is there much overlap amongst these toolboxes that people have seen? Granted I'm blowing things somewhat out of proportion with just this one method. I was just curious if anyone else had a "standardized" way of dealing with this one. Brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
