Whatever are you on about, Phil?
Point-by-point:
1. blah = ["this", "argh", "d'oh", "world", "hello"]
Two points. (A) Making explicit lists immutable is obviously a good
idea. 99.9% of them were never meant to grow or shrink and if you hand
out reference to these lists this invariant is screwed up for
everybody. So, +1 for immutable lists when explicitly listing its
contents like this. In java:
List<String> blah = ImmutableList.of("this", "argh", "d'oh", "world",
"hello");
Note how "List<String>" is in fact inferred; for example, you can do
this:
ImmutableList.of("this", "argh", "d'oh", "world",
"hello").get(0).toLowerCase();
No mention of "String" anywhere in that entire snippet and yet it'll
compile, because String is inferred.
2. blah << "another"
It's programming, not cartoon swearing. Left shift has zip squat to do
with adding things to lists, so this kind of code is silly. However,
in java:
blah.add("another")
which is just as short, so I'm confused as to why you think this "<<"
malarkey is such an improvement. Note that .add() unfortunately is
allowed by the compiler but would fail at runtime if we had our
ImmutableList created in step 1. This is not a failing of static
typing systems. On the contrary, it's a failure of java and the google
collections API (understandable, they wanted to be compatible with the
java.util. interfaces) to not use the static typing system provided
properly. A proper design here would have:
public interface List {} // contains only get(), size(), contains(),
and other non-mutating methods.
public interface ImmutableList extends List {} // Doesn't add anything
but highlights that immutability is guaranteed
public interface MutableList extends List {} // Adds clear, set,
remove, add, etc.
If this design had been carried through, the compiler would have
stopped you from trying to add to it. One way or another. Way 1:
MutableList<String> list = ImmutableList.of("1", "2", "3"); //FAIL -
the 'of' method doesn't return a MutableList.
Way 2:
List<String> or ImmutableList<String> list = ...;
list.add("foo"); // FAIL - Lists and ImmutableLists do not support the
add method.
So, static typing wins the day.
3. blah.join("").sort()
I'm assuming this is a typo. You're sorting a string, which is
impossible. Perhaps you meant blah.sort().join("")? In that case, in
java:
Joiner.on("").join(Collections.sort(blah))
I fully agree that 'Collections.sort(blah)' instead of blah.sort() is
an ugly wart, but this is mostly a failure of java not supporting
traits nor extension methods. It could have been added and it almost
was, for java 7. Joiner's API shows that there's some advantages in
using a separate hierarchy; it has a few more options than python's
join.
NB: These examples require the google collections API.
On Apr 24, 4:03 pm, "[email protected]" <[email protected]>
wrote:
> First, please don't call a dynamically typed language "weakly typed".
> All the languages we are talking about here: python, ruby, groovy,
> perl are STRONGLY typed. They are just dynamically typed, not
> statically typed. http://en.wikipedia.org/wiki/Dynamic_type
>
> IMO many of the perceived advantages of dynamic typing have nothing to
> do with dynamic typing - it's a result of language design.
>
> There is no reason this code can't be statically typed:
>
> blah = ["this", "argh", "do'h", "world", "hello"]
> blah << "another"
> blah.join(" ").sort()
> println(blah)
>
> >> another argh do'h hello this world
>
> It's obviously an array of string, which can be inferred.
> The java equivalent would suck in comparison.
>
> I am watching Charles Nutter's work on Duby, which is a statically
> typed Ruby on the JVM. Really cool stuff IMO. http://github.com/headius/duby
> &http://blog.headius.com
> It's statically typed, but he is adding in optional dynamic typing.
>
> I think having an option for dynamic typing is hugely powerful. I
> would just prefer that it's not my ONLY option. Most of the time
> static typing is great and makes me more productive. However, there
> are cases in which dynamic typing is very handy:
>
> In Ruby's Active Record -
> user = User.findByName("phil")
> println "user = #{user.name} : #{user.location}"
>
> >> user = phil : denver, co
>
> this does a query "select * from user where name = 'phil'"
> so "findByName" is a dynamic method and the user model creates/methods
> based on the result set (user.id, user.name). Powerful stuff!
>
> --
> 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
> athttp://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].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
