On 13 January 2011 14:09, Ricky Clarkson <[email protected]> wrote:
> Why, are there some inaccurate judgements you might otherwise make > about Java based on those two classes? > > The standard Java date/time library is a joke, it's: - inconsistent (days start at 1, months at 0) - guilty of using side effects in unexpected places. (try using the same instance of DateFormat in different threads) - mutable - verbose - packed full of duplication The heavy use of side-effects and mutability makes dates a tricky thing to work with in concurrent code. What if I supply someones birthday to some thread as a date, which then subtracts 2 days from it in order to decide when to remind me of it, but I still hold onto that original reference for other purposes? Ooops! JodaTime for the win, but it's not in the standard lib... If i were to judge Java purely on the basis of the basis of date/time handling, then I'd have to conclude that it just can't use threads at all, let alone efficiently. I'd also think it was very badly designed. The collections, by being mutable, are also sensitive to this problem. Unlike the presence of a foldLeft method, you can't simply choose to not use that mutability, as it may well be used by other blocks of code without your knowledge. "Unmodifiable" collections don't help either, they're just a wrapper around some other collection that can, itself, be changed still. Google's immutable collections are the way forward, but they're absolutely not in the standard lib. On Thu, Jan 13, 2011 at 2:06 PM, Kevin Wright <[email protected]> > wrote: > > > > > > On 13 January 2011 13:36, Ricky Clarkson <[email protected]> > wrote: > >> > >> On Thu, Jan 13, 2011 at 12:57 PM, Reinier Zwitserloot > >> <[email protected]> wrote: > >> > I'm a bit confused as to why Scala programmers have the gall to claim > >> > the > >> > moral high ground in regards to multi-core programming. > >> > >> The confusion is in your head. Scala programmers don't claim that high > >> ground. > >> > >> > For example, scala has enshrined foldLeft and foldRight forever more > as > >> > core > >> > language, by importing both of those by default as operators (i.e. > "/:", > >> > as > >> > a token, is a fold operator in scala unless you go out of your way to > >> > unimport it). > >> > >> Let's rewrite that without the emotional crap: "Scala has foldLeft and > >> foldRight (and symbolic versions of those) in the standard library." > >> Yes, it does, but so what? > >> > > > > Java has java.util.Data and java.util.Calendar. So I think that's enough > > said about judging a language based on classes and methods that just so > > happen to be defined some standard library, yes? > > > > -- > > Kevin Wright > > > > gtalk / msn : [email protected] > > mail: [email protected] > > vibe / skype: kev.lee.wright > > twitter: @thecoda > > > > -- > > 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]<javaposse%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright twitter: @thecoda -- 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.
