2006/5/27, Ryan Leavengood <leavengood / gmail.com>:
> On 5/26/06, Robert Klemme <shortcutter / googlemail.com> wrote:
> >
> My declaration that Java's design is negative was made as compared to
> Ruby. After 10 years of Java development and 5 years of Ruby
> development here is what I feel in regards to data structures: in a
> situation where one might choose to code something in Ruby or Java
> (because their uses don't always overlap), the simpler choices Ruby
> provides in data structures will speed up development. There will not
> be a need to think about exactly what data structure you need in Ruby
> (beyond choosing Hash or Array) because most of the time it does not
> matter. Maybe this only applies to small scripts where just getting it
> working is the most important thing. In large scale development it may
> be moot, and that is probably where Ruby's simpler choice in data
> structures might lack (but I'd argue that is not guaranteed to happen
> all the time.)

Point taken.  Maybe it's also a topic where individual experience and
approach make a difference; I personally did not experience that the
amount of classes to choose from in Java caused me a headache or
serious slowdown.  In fact I'd rather have even more collection
classes. Maybe it's also that thinking about data structures is one of
the first things I do when thinking about a problem to solve; I even
create some specific classes even for small scripts as it's so easy in
Ruby.  It helps me personally to think about the problem and also to
document what I did.

> For the sake of bringing this discussion to a close, I will retract my
> statement about Java's static typing causing so many data structures.
> It seems it was really a design choice and the typing didn't affect it
> too much. Though I think the plethora of classes is a result of a
> certain design philosophy that comes from static typing (this may seem
> contradictory to the previous sentence but I think I'm just having a
> hard time articulating my point.)

I think I understand your point now. Maybe it's not a direct causal
relationship but rather the "spirit" of following an engineering
approach to software engineering. I can imagine that both, Java's type
system as well as the rich set of collection classes, were inspired
from a more formalized approach to software engineering (stress on
"engineering").

> As a counterexample I would be
> curious to see a dynamically typed language which has such a huge
> variety of collection classes built into the language or standard
> library.

I'd have guessed that Smalltalk does this. Thanks, Jeremy for the
confirmation.  Btw, just out of curiosity: what about common lisp?
Does CLOS also contain a rich set of abstract data types?

> In Ruby, of course it doesn't take long. And don't expect me to argue
> that you never need to choose between a Hash or Array or Set, that is
> just silly. You have to at least choose that, of course.

:-))

> But then in Java you need to decide if you are going to use a HashSet
> or a TreeSet or a LinkedHashSet or maybe an ArrayList but then there
> is LinkedList but of course also HashMap or TreeMap or LinkedHashMap,
> plus PriorityQueue. Having a lot of choices will always slow a human
> down. Maybe where you work speed of development does not matter, but
> for me it is important.

Most of these classes solve different problems so once the problem is
understood the choice is usually fairly easy.  I cannot remember
having a problem with this selection process but YMMV.

> > I don't think agile methodologies make the distinction between sets
> > and maps or sets and arrays superfluous...
>
> I never said it did. I'm mostly speaking about the second level you
> get in Java: ArrayList versus LinkedList, HashMap versus TreeMap, etc.
> But when you are coding Java I guess you are just used to that. I'd
> rather code Ruby.

Both have their strenghts and weaknesses, I fact I like both very
much. I like Java for it's powerful IDE's (namely Eclipse), rich
standard class library, native threading support - and I like Ruby for
compact code, low overhead OO and the dynamic nature (inclusive easy
meta programming).

Thanks for taking the time and sharing your thoughts!

Kind regards

robert

-- 
Have a look: http://www.flickr.com/photos/fussel-foto/