[Tfug] Language choices

[Bexley Hall]

Hi, T,

--- t takahashi <gambarimasu at gmail.com> wrote:

> can you tell us more about the domain and platform?

I have several different applications domains to
address -- and the platform is likely to vary in
each.  Things like rotating media are not viable
options (e.g, take the finished product, *throw*
it on the ground.  Does it still work?  :> )

Solid state media are limited in size (cost per bit)
as well as power consumption (some applications
are battery powered, some are battery backed -- in
either case, power consumption becomes an issue
for any bulk memory scheme).  Using something
like FLASH for a swap partition would be
dreadfully slow -- and also limits the choices
of vendors (some flash has lower durability
than other$).

My ideal choice of processor would have been the
StrongARM.  (quite fast, very low power, etc.
Imagine having a machine running on 1W or less  :>)
I suspect I will ultimately end up with some
ARM-derivative as ARM seems to have the right
business model nowadays...

> what's going to be using up memory?  code?  data? 
> initialization? how much can be shared?

Everything has to start in FLASH -- since there is
no "disk" to boot off of, etc.  The OS is reasonably
small (< 1MB).  But, many of the core services
can be resource pigs (figure ~50MB of TEXT that's
live all the time).

Since resources are *so* scarce, I play games
to minimize duplication wherever possible.
E.g., I am keenly aware of 'const' and use
it wherever I can in my code.  And, design my
algorithms to accept const data wherever possible.
Then, access that data via pointers to eliminate
the overhead of the extra copy in function 
invocations, etc.

Tasks (processes?  whatever you wish to call them)
execute in protected address spaces.  But, share
TEXT wherever possible.  I use CoW semantics
so chiold processes can inherit their parent
TEXT without the extra copy overhead.  Etc.

I *could* use XIP to further economize on resources
(eliminate the copy of the TEXT into RAM).  But, that
imposes constraints on the FLASH that I would like
to keep "free" at this time (e.g., so I could use
a FLASH with an ATAPI-style interface) -- though
the lower levels of the OS execute directly out of
the boot FLASH.

My interface to the "filesystem" relies on mmap-ing
the FLASH into the targeted process's address space.
So, *some* task(s) can eliminate the copy entirely
and just read the FLASH as if it was fread() into
their memory space explicitly (I reserve this for
some key services that use *big* files that I
would not want to copy into a process's address
space).

The OS aggressively tries to recover *every*
page of unused memory -- at the expense of execution
time.  E.g., at each context switch, the stack of
the suspended task/thread/process is examined and
any complete, unused pages are unmapped -- instead
of waiting for the task to eventually terminate
and free its resources.

Tasks *rarely* terminate.  Most services run
continuously.  So, things like aggressively
managing the stack can actually recover *real*
resources (not just theoretical ones!).
Languages that beat on the heap cause this
mechanism to work harder trying to keep up...

I tend to favor recursive algorithms (insteadof
iterative).  But, design those algorithms to
ensure that the depth of recursion is known
a priori and is "reasonable" -- else I favor
an iterative approach to get bounded resource
use.

I haven't (yet) added support for "shared libraries"
as much of my implementation moves things that would
be passive *libraries* into active *services*...

I.e. I am very aggressive in keeping my thumb on
my resource usage... :>

> did you need something that is already ready for
> embedding?  if so, into what other language?  c?
> itself?

I'm not sure I understand the question.  I want to
be able to write applications (applets?) in this
language that I can bind to threads in my system
and cause to execute.  The application need not
be aware of the environment that invokes it.
 
> do you want to write all of the applications in the
> lang?  are you ok with a single runtime or do you
> need to run each application from the command line?
> do you want to take advantage of shared libraries?

I see two classes of applications.  Those that are
computation/resource intensive will be written in
something closer to the metal -- e.g., all of the
core services that I have implemented are written
on C for performance and determinism.  For example,
if you wanted to write an MP3 decoder or a printer
driver...

OTOH, many applications are not very demanding.
Hence the idea of a *scripting* language.  Something
that lets you quickly and easily hack together an
application without dealing with the minutiae of
type declarations, bounds checking, extra function
invocations (e.g., using '+' instead of strcat),
etc.

For example, the units conversion program I mentioned
would be *harder* to write in C than in such a
language!  You'd be calling strcat() to assemble
menu items, counting bytes to make sure you don't
have buffer overflows, worrying about whether each
numeric operation resulted in lost precision, etc.

> who uses the language more, you or people who are
> less technical?

Not necessarily "less technical" but, rather, people
who want to hack together an applet in a *weekend*
instead of wading through lots of little detail
thst doesn't make the application any *better*...

E.g., do you write all your web CGI's in C?
Why not *assembler*??  :>  ANS:  because both of
these approaches gie you far more control than you
need -- at the expense of lower levels of abstraction.
Much easier to write a few lines of perl...
 
> did you need to be able to tweak the running
> application using the language while the application
> is running?  do you want to use eval?
> do you need secure execution of eval?

No.  I am assuming applets are simple enough that
you can do most debugging with judicious stubbing.

> did you need to have an interpreter or are you
> flexible on that?  does byte code appeal to you?

No preference.  *But*, if the code is not compiled,
the interpreter needs to be able to be
"multi-session";
no desire to have N instances of an interpreter
running concurrently (i.e. the interpreter's
TEXT should be shared/sharable and, ideally, just
maintain an instance-specific set of data for each
applet that it is running -- though this also has
to fit within the protection model I've adopted
so tht complicates things... )

> you're ok with obsolete languages, but would a
> language that will be around in 10 years be better?
> 25 years?

Nope.  I suspect this will be something I maintain
regardless of what's going on around me, etc.
 
> you're ok with changing syntax of the language. 
> would a language that supports easy syntax changes
> be important or is that unimportant?

Nope.  I suspect I will end up having to implement
some hybrid language so it would probably be easier
to plan on writing from scratch.  There are just too
many features from different languages that have
merit -- expecting to find them in one place would
be wishful thinking.

> how strict are your needs?  you like weak typing and
> dislike strongly functional languages, but seem to
> be fascinated by ml.

*I* enjoy ML.  But, I suspect it wouldn't be a viable
option.  I'm debating what ideas I can take away from
ML, though.

Weak typing is a win because it takes a level of
detail away from the developer.  E.g., why have to
call atoi() to handle "12345"?

> is optional strong typing appealing?

No.  If the developer wants to work in that
environment, he can write his code in C, C++,
LISP, "whatever" and just bind directly to my
API's.
 
> gc: gc is already out there in the solar system; are
> you sure your platform can't handle it?  if it
can't,
> have you looked at severe and special-purpose
> implementations of gc languages like scheme that at
> the very least mitigate gc?  is memory more
> important than speed?

Memory has an immutable limit.  Speed just translates
into *time* (which is infinitely variable  :> )
These are *appliances*.  There's no console where
you can say "out of memory" and expect the user
to kill off some process to recover some memory, etc.
Determinism is important.

> is a multi-paradigm language more appealing than a
> single paradigm language, or do you just want the
> right kind of non-functional language?

I see this as something *simple*.  Elegance through
simplicity.  The idea of having an application fit
on a single sheet of paper (!) is the driving force.
(note, the applets here aren't that "complex" that
they can't be *expressed* on a single sheet of paper)

> syntax: in addition to counting non-bracketing
> syntax, have you
> written hello-world in each of the languages and
> counted the
> bracketing expressions () {} []?  consider trying
> that as an exercise
> to see if your existing opinions about bracketing
> expressions are correct.

I have pulled my hair trying to come up with ways
to do away with parens, brackets, braces.  But, so
far, I haven't been able to find a realistic way of
doing this.

I can prevent them from being used in expressions
by arbitrarily enforcing that -- and causing the
expression to be rewritten as a set of smaller
expressions glued together, etc.  But, that makes
things VERY clumsy.

> what happens if the compiler you choose goes out of
> business?  will you maintain it yourself or can you
> switch to another compiler?

I don't expect to find a COTS solution so I've
implicitly assumed the role of maintaining it.

--don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com