Introduction: Why SmallEiffel on PalmOS?

Introduction: Why SmallEiffel on PalmOS?

PDAs, now, are ubiquitous--it seems that everyone has one, wants one, or has one built in to their cell phone. To those who use them, PDAs are reliable, efficient, useful, and above all, ever-present.

To those who program them, however, PDAs can be a different story. To those who grew up in an era of protected memory, seemingly-infinite resources, and astronomical processor speeds, PDA software development can seem very limited indeed... particularly software development on PalmOS, which often feels like a return to old-style to-the-metal programming.

So why would anyone want to program in PalmOS?

Why PalmOS

PDAs are fragmented into two major camps, Windows CE and friends and PalmOS. While a third category (Linux-based PDAs) is gaining some ground, the market share for the two big players is huge--and the installed base of PalmOS-powered devices is burgeoning (according to NPD Intelect's 2000 survey, PalmOS devices from multiple manufacturers commanded 85 percent of the market share of PDAs). Windows CE is making a strong showing, but there is no denying that thousands or millions of PalmOS-powered PDA users are out there--and they need software.

Furthermore, precisely because of the low resources available to a PDA, small developers are put on a more even footing with the monolithic giants who seem to dominate software development these days. No hobbyist team can write a word processor to fully use a 1 GHz machine with 512 megs of memory and a full display. But there's only so much you can do on a 160x160 greyscale display with only a few paltry K of memory to play with--and of the thousands and thousands of programs out there for the PalmOS, many are designed, written, tested, and marketed by hobbyists.

But why Eiffel?

Eiffel is an object-oriented language with a rich and long history... of very large projects. In fact, it's been said of Eiffel that it really only shows its strength in really, really large projects--clusters of hundreds of classes with interlocking contracts. Eiffel has excellent facilities for easing the rigors of large-scale software development, and is well-suited for such projects, where important details of complex problem domains can be abstracted and operated on at a very high level.

This very fact makes it a strange bedfellow for the PalmOS, where every byte of memory is a precious resource and processor time is a commodity not to be squandered.

Still, the primary language for PalmOS development is, and will be for some time, C. PalmOS programming is fairly close-to-the-metal; the developer is operating on a fairly low level, calling routines in the computer's ROM and operating on a byte level with structures and OS-to-program callbacks. Memory management in this development model can be excruciating, and development moves very slowly. A reliance on C code manually designed and compiled keeps software development on a very low level.

Yet the history of software development shows a steady progression to programming on a higher and higher level--more abstract is better. The more you can do with the fewer lines of code, the better off you are.

Ideally, then, we would want a language which worked fundamentally at a high level but was able to dip down into low-level programming at the drop of a hat. Eiffel fits the bill.

Object-Oriented Software Development and PalmOS

Although it works with C functions and pointers to a panoply of structures, the PalmOS design is heavily object-oriented. For example, a function which operates on a database will take a pointer to a database structure as its first argument, and it's easy to see a one-to-one correspondence between PalmOS structures and an object inheritance structure. This can be misleading--because the PalmOS calls exhibit none of the polymorphism that a true OO inheritance structure would show--but it does map well onto basic OO practices.

Big brush strokes at high level Eiffel; delicate details with C

Because of the low-level nature of PalmOS programming, some mucking about with C code is necessary. But writing the whole program with the delicacy of C is like mowing a lawn with a set of hedge shears--sure, it's possible, but why go to that much trouble?

A better approach would be to write the bones of the code in a high-level language and write fiddly bits in a low-level language like C.

Eiffel has a well-developed Eiffel-to-C interface, allowing exactly this sort of two-level development system. It's relatively easy to wrap PalmOS structures in Eiffel code and operate on them at a high level without worrying as much about the details. Still, when precision is necessary (such as the complex callback interfaces with databases or tables) the developer can drop down to C and get exactly the right code for the job.

Tight code in a tight space

Many high-level development languages are, frankly, resource hogs. Not so the SmallEiffel compiler. In fact, it can aggressively optimize code, cutting out entire sections that aren't necessary in order to produce quite lean, compact code--for a high-level language. This means smaller compile times, smaller executables, and a better installation in a low-resource environment.

Garbage Collection

Anyone who has had to manually allocate and free dynamic memory knows a moment of epiphany when moving to a garbage-collected language; the reduction in allocation/deallocation errors, the reduction in code required to support manual allocation, and the reduction in headaches caused by improperly freed memory, dangling pointers, and aliasing make garbage collection a clear win in almost any environment that will support it.

Why not Eiffel on PalmOS?

With all these reasons to use Eiffel on PalmOS, are there any reasons we shouldn't use it? What are the drawbacks of this particular combination?

The code isn't that tight

Unfortunately, while the SmartEiffel compiler does a fantastic job of producing small, tight executables from a high-level language, it still produces larger executables than C. Because of the way SmartEiffel creates specialized garbage-collection code for each live class, executables can be fairly large in comparison to equivalent C counterparts. If resources truly are precious, Eiffel may not be the best choice.

Garbage collection does require more

While in general the benefits of a garbage collection approach to memory management far outweigh the problems associated, there is no denying that SmartEiffel's approach demands more memory than a carefully-managed hand-coded C program. Again, if resources push the limits of acceptibility, Eiffel may not be the best choice.

Things can run a touch slower

In general, C code generated by the SmartEiffel compiler competes well with hand-generated code produced by a software developer. However, because of some issues with the PalmOS platform and SmartEiffel-generated code (which requires function calls across some code boundaries and frequent garbage collection cycles, for example), executable speed can be lower than an equivalent C program.

There's no file system

Most applications use a file system model which dates back to decades of UNIX storage. It's well-understood and has interfaces for almost all popular languages, Eiffel included. A lack of a file system means that many things which are taken for granted on a traditional computer (such as storage and retrieval of data) are more difficult under PalmOS, and that can be difficult to work around.

No, seriously, there's really no file system... or stdin/stdout

A lack of a file system results in a development environment without a standard input/output mechanism. The PalmOS screen is a tiny 160x160 greyscale screen (some devices have color and modern devices may have better resolution). But there is no analog to the standard console in/out. That means no printf or fprintf in C.

And that means no assertions, a major feature of Eiffel

SmartEiffel generates a great deal of code which uses the standard input/output system for some very important tasks, such as printing out a standard stack trace when an assertion is violated. By stubbing out the calls to that I/O subsystem, that important information becomes unavailable--which means that assertion violation information is impossible to retrieve, and thus all code must be compiled in -boost mode, making one of Eiffel's most powerful and remarkable features--assertions--unavailable to the ePalm programmer. Some efforts have been made to replace the stack trace print routine with one which will display a scrolling dialogue box to the developer, but including assertions also inflates the generated code size such that it becomes difficult to compile under the rigorous memory limitations of the PalmOS platform. For now, it seems to be impossible to use assertions with ePalm. Hopefully this will be rectified in a future release.

Some things aren't as easy

As with many high-level development tools, things are easy going if you are working in the tool's domain... but can get complex once you wander from that path. With that in mind, programs which will use completed functionality of the ePalm library will work well--and those which need functionality that's not there will require a fair amount of extra effort.

With all those things in mind, let's turn our attention now to how this all works; how is it possible to compile Eiffel code for the PalmOS?

Powered by Zope