4.2. Basic Java Limitations
I've painted a picture of the average project. The average team builds or ports
applications that will deliver a web-based frontend on a relational database,
potentially with other less meaningful services. The team probably uses
increasingly agile princip
les, and likely wants to do unit testing. The team typically
works under short schedules and great pressures. And given more dynamic
alternatives, Java is not at all the language that I'd usually choose for such a
project, in such an environment:
 The many frameworks designed to simplify the Java development
experience do make experienced Java developers more productive, but make
the learning curve too steep for those new to Java.
 Compile-time checking of exception and types adds safety, but comes at a
cost of additional time and syntax.
 Java's inability to express structured data leads to an over-reliance on XML,
with the corresponding additional complexity and bloat.
 Java's many compromises, like primitives, make Java harder to learn and
more complex to write.
 Java is more dynamic than C++, but is nowhere near as dynamic as
languages like Smalltalk and Ruby. Java developers are finding
metaprogramming, but they're not able to execute on those ideas fast
enough.
 Java's long compile/deploy cycle is much longer than interpreted, dynamic
alternatives.
Taken alone, none of these issues hurts enough to matter. Taken together, Java
becomes much less productive for most developers.

Java. AOP helped a little (albeit at a high entry
cost), but nowhere near enough. Nothing else
helped at all. What I needed was a new
language.
How does
Java hold you
back?
SY: First, Java offers an impoverished set of
abstractions. No first-class functions, no
reference parameters, no keyword or default
params, no destructuring bind or even parallel
assignment, no way to return multiple values
efficiently, no continuations, no user-defined
operators, no generators, no closures, no
tuples the list just goes on. Java's about 25
teeth shy of a full mouth.
Second, Java is entirely nonextensible. It can't
grow. There's no metaprogramming, no macros,
no templates, nothing that gives you syntactic
abstraction. So, Java's incompressible. Java
code is always filled with stuff that looks like
copy and paste, but you can't factor it out. Java
code and APIs always wind up bloated (and yet
oddly impressive looking).
Third, Java can express code, but not data.
You're stuck using property files, XML, and
other means of defining data. But the line
between code and data is blurrythink about
configuration, for example. So, the Java folks
are piling on framework after framework,

Strong versus weak typing decides how a type is enforced, or interpreted. In a
weakly typed language (like C), variables can be coerced easily, or interpreted as
something else. A strongly typed language strictly enforces compatible types
across operations. It probably doesn't surprise you that Java is a strongly typed
language.
Ruby, Smalltalk, and Python also enforce strong typing, which might surprise you.
Many developers believe Smalltalk, Python, and Ruby are so productive because
they are weakly typed. They are misinformed. Consider this brief Ruby example:
irb(main):003:0> i=1
=> 1
irb(main):004:0> puts "Value of i:" + i
TypeError: cannot convert Fixnum into String
from (irb):4:in '+'
from (irb):4
In the first line, the undeclared variable i takes on the value of 1. At this time,
Ruby decides that i is a Fixnum. When Ruby interprets the third line, it sees the
+ operator after the string, and tries to concatenate i. Of course, Ruby doesn't
know how to concatenate an integer to a string, so it throws an error. That's clearly
an example of strong typing. (Actually, I've oversimplified things a little. You can
dynamically change the definition of Ruby classes and objects at runtime, and this
weakens the typing somewhat. Still, on a continuum from strong to weak typing,
Ruby would lean slightly to the strong side.)
In a similar situation, a language with weaker typing may instead coerce types to a
compatible form, as in C. Consider this example:
int a = 5;
float b = a;
In the second line, C coerces the value of the integer to float. Other examples
are even worse. In C++, the ( ) cast operator does not yield type safety, so you
could say, for example:
Cat *cat;