Task Scheduling

I don't think Java is a bad language, overall. It's got a lot of
industry support and a lot of programmers who know it. Sometimes
it's the best tool, sometimes not. But it ain't the be-all of
programming languages, and I have some arguments against some of your
points.
On Jan 25, 2006, at 3:23 PM, Bryan Sant wrote:
>> This is only true if you're restricted to use vim or emacs. If all
> you have is a text editor, then a verbose, typesafe language like Java
> is a hindrance. If you use an IDE such as Eclipse or NetBeans, your
> productivity with Java and these tools far outstrips that of dynamic
> languages. I hardly type at all, the IDE does all the work for me.
>
There's more to dynamic typing than simply not having to type out
type annotations. Consider the Gang of Four's book on Design
Patterns. Quite a few of them are completely unnecessary in a
dynamically-typed language. They're ways to produce dynamic,
flexible systems in a static language. An IDE won't be able to work
Design Patterns into your programs like it can automatically enter
type annotations.
I submit that productivity is not so based so much on the amount of
typing that must be done as it is on the amount of conceptual work
that must be done. When building dynamic, flexible software systems,
dynamically-typed languages can require a lot less conceptual work,
as evidenced by the lack of need for several common design patterns
that are necessary in statically-typed languages.
> Additionally, dynamic languages have always hit a major wall when
> dealing with larger projects. As long as your project is trivially
> small, or very well suited to the original problem domain of that
> language, you're better off with a stricter, type-safe language.
>
This is often trotted out by proponents of static typing, but I don't
know if there's any hard evidence. Certainly static typing brings
some benefits, but it has some costs as well. I believe dynamic
languages suit large projects quite well, and as evidence I can point
to a number of large systems built in Lisp and Smalltalk, which were
developed and marketed as systems languages long before the term
'scripting language' was coined.
>> - Runtime performance goes up
>> Completely incorrect. Java is significantly faster than any dynamic
> language. It is nearly as fast as C/C++. Get your facts straight.
> Run some of your own benchmark tests if you must.
>
Java has a very mature implementation with lots of cool technology in
its virtual machine. The fact is, though, that dynamic behavior has
run-time cost due to extra layers of indirection. Although types are
established at compile time, so they don't need to be checked at run-
time, method dispatch is still performed at run-time. This
dynamicity is what slows Java down relative to C, for example, when
coding object-oriented programs. Java's advanced implementation
technology is what speeds this up and makes it competitive, not its
static typing.
If you're going to benchmark language implementations (one language
is not faster than another, but one language implementation may be
faster than another one) then you have to decide what you're going to
benchmark. A 'dynamic' language has a lot of features that make it
easier to program dynamic, flexible software. You can also program
dynamic, flexible software in statically-typed languages (witness
Design Patterns), but there's a conceptual overhead that the
programmer must pay, namely how to work dynamicity into a static
language. The extra levels of indirection required to implement
dynamicity in 'static' languages produce a similar run time cost to
the dynamic features in the 'dynamic' languages. So, benchmarks must
be carefully chosen to reflect what /you/ intend to do with the
language implementations you're considering.
By the way, a lot of the technology behind Java's virtual machine
comes from an extremely dynamic language called Self that was
developed by some Sun researchers. It's based on Smalltalk, and
requires the advanced virtual machine to have reasonable performance
at all. But the technology does exist, so it is a surprisingly fast
language implementation.
--Levi