RE: interpreted languages

In the end the user of the device wants to see something, not just run sed, awk, ps, ls, etc. (I'm thinking real-world users, not developers/geeks). These users want to run 'productivity' applications, syncronize their calendars, email, to-dos, etc. This means we would need a toolkit with a good widget set binding, or a widget set of it's own. As far as I can tell the best language/widget set combo I can think of is python (TK, gtk, Qt, wxWindows). But then again I'm biased....and love python. I even write windows apps in it (Mark Hammond is my savior!)....

Anyway...All of the reasons you've stated below are pretty valid (as far as I'm concerned), but there are also some problems with interprited languages:
1) They are probably slower than C/C++ (Python/Perl at least use native C toolkits)
2) They take up more room on the device, their widget wrappers take up more room, etc. On the flip side I bet a whole bunch of unix commands (like the Perl toolkit you mention) can be written in a few K (less than 10) each of Perl/Python code. Which I think is a lot smaller than the compiled C code. Plus with Python you can put just the pre-compiled .pyc files on the device (they should be smaller, but they may not be). Plus text should compress on a cramfs image much better than an executable.
3) I'm sure there's more, but I can't think of anymore.

> -----Original Message-----
> From: Russ Nelson [mailto:rn-handhelds_at_crynwr.com]
> Sent: Tuesday, September 26, 2000 7:38 PM
> To: handhelds_at_handhelds.org
> Subject: [Handhelds] interpreted languages
>
>
> Question: Should most applications for the iPAQ be written in an
> interpreted language?
>
> 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.
>
> 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.
>
> --
> -russ nelson <sig@russnelson.com> http://russnelson.com | A
> hate crime makes
> Crynwr sells support for free software | PGPok | it illegal
> to think certain
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice | thoughts.
> The crime is
> Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | itself
> already a crime.
> _______________________________________________
> Handhelds mailing list
> Handhelds_at_handhelds.org
> http://handhelds.org/mailman/listinfo/handhelds
>
Received on Tue Sep 26 2000 - 17:42:14 EDT