java follies [was: PHP vs Perl (Put on flame proof gear)]

Bryan Sant bryan.sant at
Mon Mar 20 13:52:27 MST 2006

On 3/20/06, Levi Pearson <levi at> wrote:
> On Mar 20, 2006, at 12:24 PM, Bryan Sant wrote:
> Although I agree that the amount of time that it takes to enter type
> annotations is not really significant, that's not really the point.
> For some tasks, working around the type system takes a significant
> amount of extra logic.  Witness Design Patterns, a significant number
> of which are methods of doing things in statically-typed languages
> that require no extra thought in dynamically-typed languages.  IDEs
> don't really do anything to alleviate this.

Not that I don't believe you, but please supply and example.  How
would a dynamic language make a singleton, prototype, strategy,
flyweight, facade, or adapter pattern unneeded?  I can see how some of
these patterns would require fewer charaters to be typed (not need to
cast a value frome one type to another or create
super-classes/interfaces in some cases).  But again, we'er back to my
original point that A) with an IDE, I'm just as fast and B)
sacraficing type-safety costs in unit tests.

> And another point:  statically-typed languages in the ML and Haskell
> families are often more compact than dynamically-typed languages.
> Types are (mostly) inferred, so there are very few type annotations
> in the code.  There is also special syntax for pattern matching that
> makes for very succinct code in situations where it's useful.

I learn something new ever day.  I'm switching to Haskell on my next project.

> The verbosity of a language is not inherently tied to its type
> system.  It only seems that way because of the current crop of
> languages in the mainstream.  The choice of dynamic vs. static typing
> ought to be made on its own merits, and both are appropriate in
> different situations.  The ability to create powerful abstractions
> (and thus write succinct code) is almost always a win, though.

Untill you have to write the documentation that explains what your
code does.  Not that you don't have to do this with Java, but the
language is far more self-documententing than most other languages. 
I'm not saying that smaller code isn't better.  I do think so.  But in
the totallity of what a good developer is expected to do (write unit
tests, and document your code) Java (or C#) isn't nearly as bad off as
some try to paint it.


More information about the PLUG mailing list