Re: interpreted languages

Russ Nelson wrote:

> Question: Should most applications for the iPAQ be written in an
> interpreted language?

I think that you should use the best tool for the job. In some cases,
it interpreted and in some cases it isn't. I think that for most of the
core applications for the iPaq ( whatever that means ) shouldn't be
written in an interpreted language since they will be used the most and
must preserve battery life and take up as little memory as possible.

>
> I think yes. Here's my rationale: 1) the ARM and MIPS are
> unconventional architectures. 2) if you're going to write in a
> compiled language, you need a toolchain. That means: 2a) a skiff or
> shark, but so far the skiffs haven't been of stellar usability. 2b)
> cross-compilation, but that doesn't work with anything that tries to
> make a Makefile, or system-dependent Makefiles. 2c) native
> development, but that means you need more mass storage; either over a
> network or a microdrive. 3) An interpreter can interpret the same
> language regardless of architecture. 4) An interpreter can be
> assisted with some assembly-language in critical sections, e.g. the
> ARM memory pre-fetch instruction.

These are all developer issues. We have to think about end user issues
which are:

o How long will my battery last?
o How easy is it to use and learn?
o How well does it interoperate with my existing applications?

>
> Perl is a reasonable choice, if only because of Tom Christiansen's
> Perl Power Tools project: http://www.perl.com/pub/language/ppt/index.html
>
> I think Python is a better language for larger projects, though.

Instead of choosing a language choose a component architecture that lets
you write components in any language you want.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
mozilla.org - We're on a mission from God.  Still.
------------