Re: "Little languages" and type-checking

[RLake@...]

This is a complete digression, but it's an interesting topic.

Steve Dekorte escribió:

> It's interesting that are no languages that are both lightweight and
> strongly typed. (At least none that I know of) Could this be more than
> coincidence?

I think the question is what "lightweight" means. (I won't even go into
question of what "strongly typed" means; that's definitely flamebait.)
Java, for example, was intended to be a lightweight language.

(From http://java.sun.com/java2/whatis/1996/whatjavameans.html; an
announcement from the past. I remember this announcement. But then I
remember when Unix was young. Sigh.)

> The Java platform's ease of development and widespread industry support
mean lower development
> costs and quicker time to market. Built-in security protects company's
information and assets.
> The lightweight, distributed model eliminates software installation
headaches and lowers administrative
> and maintenance costs of managing a computing network (that is, "total
cost of ownership," or TCO).
> Platform independence frees you to pick the hardware and operating system
best suited to their needs.

It's certainly true that the JVM can be implemented in a fairly tight
environment and that Java can be parsed quite easily. I think that what
makes Java "heavy-weight" is the enormous weight of the standard libraries.
So there's a warning there somewhere.

One thing Java does demonstrate is the power of byte-compiled VMs *exactly*
in embedded environments.
But Lua demonstrates that better and with a lot less faffing-about. Even
without much effort, a byte-compiled
VM can reduce program size enormously, and it is exactly for this reason
that languages like Forth, Postscript,
and Lua are used in embedded environments (and why Java was designed the
way it was, for that matter).


David Jeske añadó:

> It's pretty to easy to see why having great static type-checking is
> going to make the language implementation bigger, because writing
> software smart enough to save you from yourself and others -- without
> getting in your way too much of the time -- dosn't come for free.

> It seems to me that most staticly typechecked languages have opted to
> make the problem easier by getting in your way more often.

I think that's mostly true. It's easy to have draconian type-checking. The
problem is to have type-checking which doesn't make you dot every i and
cross
every t. I personally find C++ extremely frustrating to use for exactly
this
reason. I end up doing a massive amount of bookkeeping which a compiler
*ought*
to be able to do; furthermore, there is no alternative but to do this work
because the compiler requires it. Java is not much of an improvement there.
ML, despite it's various short-comings, at least demonstrates that it is
possible for a compiler to figure stuff out on its own.

Instead I settle for the inefficiency (and flexibility) of dynamic
type-checking.
That doesn't necessarily mean using "little" languages. If you want to see
a
"not-so-little" language with both static and dynamic type-checking, which
hardly
ever gets in the way, which provides an easy way to extend control
structures
as well as object structures, and which comes with a lovely UI framework,
take
a look at Dylan. <http://www.functionalobjects.com/> I probably would use
it for
everything if it were not for two little problems: the only adequate
implementation is Windows-only, and there is not a lot of certainty about
it's
future. (It also costs money but I think the price is reasonable for what
you get.)
Still, it's a great language design and well worth looking at IMHO.