On 09/05/10 09:21, Wildam Martin wrote:
[...]
I shudder at the
thought of mutability in some of this, the API effectively states that you
can change May 5th to become September 22nd;
Who cares? - Really: This is something, a professor at university may mutable
have a philosophic problem with - in the real world nobody had a
problem with that before the functional and immutable hype.
Oh yes. I have seen bugs based on using mutable (and mutating) objects
were clients made assumptions about immutability, or even worse: not
making the assumptions themselves but using data structures that do. The
classic example: put a mutable object into a hash structure and change
properties that affect the hash code.
Any object that mutates its identity is a bug waiting to happen. Lack of
immutability is real problem in the real world. It makes reasoning about
code much, much harder and allows for bugs that are hard to see.
And BTW: Yes, it can make sense: Let's have a deadline on May 5th that
is moving to September 22nd. Why shouldn't it be valid to change that
date? - Not every date is a birthday.
There is a difference between a date as a property and a date as an
instance. You might again claim that is "philosophical" or "academic"
(in the negative senses of those words), but I will again claim that it
is of relevance for writing easy to understand and safe code. If you
change the date of a milestone, you assign a new date to the milestone,
you do not change the nature of the old date. The latter would affect
everything else that uses the same date.
[...]
- They continue to be willing to add proven new techniques and patterns to
the platform and C# language. Such as dynamic lang support, FP constructs
via LINQ, sensible property handlers, delegates (method handles), closures,
etc. Java prevaricates over all of these.
Guess what: I didn't miss any of that stuff in the last 15 years of
development - so a) it can't be something real essential. And apart
from that I currently don't see a particular situation currently where
I would use any of that.
Nothing beyond Turing completeness is essential. Yet we still do it.
I have plenty of use cases for using FP in Java, up to the point where I
sometimes do, despite the fact that it creates a lot of syntactic noise
and some confusion in co-workers. But once you get the idea it becomes
easy to understand a huge class of straightforward solutions to problems
that are otherwise hard to solve. Particularly in test code I find
having predicates and a map function for collections much to useful to
avoid the friction FP style creates in the Java world.
If you want FP-free Java you have to take "Strategy" out of your pattern
box, and also remove ActionListener and any similar interfaces. The
people who ask for closures mostly want a nicer solution to exactly this
class of problems.
Peter
--
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.
