Re: "Little languages" and type-checking

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: "Little languages" and type-checking

RLak
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.





Reply | Threaded
Open this post in threaded view
|

Re: "Little languages" and type-checking

paulmatthews
> > 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 suspect a language can be both lightweight and strongly typed. The 
stong type checking can occur entirly at compile to byte-code time, 
while the byte-code interpreter can just assume that everything is 
correct....

Maybe lua could be broken into two, (1) the bytecode interpreter and 
the (2) the compiler to byte-code. This would allow for different 
front end languages, for example a pure functional front end.





Reply | Threaded
Open this post in threaded view
|

Re: "Little languages" and type-checking

Enrico Colombini
In reply to this post by RLak
>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.

Good old Dylan... I played with it for a while (a couple of programs of
mine are on the Apple Dylan CD) and saw it evolve from a lean, simple
language through a series of ever larger, slower implementations. Just what
I wouldn't like to see happen to Lua.
(nice language, though; and the Apple implementation had some bright ideas
- too bad it was killed by Apple's financial crisis).

  Enrico


Reply | Threaded
Open this post in threaded view
|

Re: "Little languages" and type-checking

Roberto Ierusalimschy-5
In reply to this post by RLak
On Wed, 6 Feb 2002 [hidden email] wrote:

> 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.

Not quite. Several "libraries" in Java need explicit support from the
JVM (e.g. the reflexive API, weak references, class loaders). The
distinction between the "core" and the "libraries" is not very clear,
and a complete JVM implementation is quite a beast by itself.

-- Roberto