Oo Environment For Palm

[See also: PalmPython, PalmOs, JavaOnThePalm, ProgrammingOnHandHelds]

I posted to news:comp.sys.palmtops.pilot [old] about an OO environment for the 3Com Palm. I would really like to sketch out and test solutions on my palm. Something like smalltalk would be ideal, but it has to fit on 2 Mb space, with a maximum 64 Kb guaranteed contiguous memory, and a processor which runs at around 20 Mhz (I think).

Assuming that it is possible to create a rapid prototyping OO environment on such a small footprint, what would it look like? How would it work?

For a small HandHeld device like a palm, I'd think any text base programming environment would be less than ideal. That got me thinking about GraphicalProgrammingLanguages might be ideal for pen input on small screens.

Some suggestions keep appearing. Listed here, and then deleted from below.

See comments in ProgrammingOnHandHelds on the above list. -- AndyDent June 2004

One language that hasn't been mentioned so far is LUA. It seems to be a lot like Python in some respects (late-binding, scripting), except that it has much less extensive libraries and is not quite as object-oriented. It seems to be popular as an embedded scripting language in the game programming community largely because its libraries and engine have a much smaller footprint than python.

The reason I bring it up is that, while no one was looking, it seems like they have already achieved the holy grail - a Palm runtime and a basic Palm IDE. have a look at the PLUA project here: http://netpage.em.com.br/mmand/plua.htm

I have no experience of smalltalk, but I've had a rummage around the source code for SqueakSmalltalk, and got the BlueBook from the library. In short, smalltalk is _way_ too big. But I think the environment would have to be smalltalk-like. Actually, there is a small talk for the Palm. Development happens on the PC, but still, it executes as interpreted smalltalk on the Palm.

Forth is very small and fast. Would OO work with a stack-based system? I guess messages would have to be objects then, are they objects in smalltalk?

But I digress. I don't intend for this to be a QnA session for my benefit. Is anybody else interested in discussing how small we could push an OO environment that is still effective, accessible?

I have included the post below for just now. Feel free to remove it if it becomes irrelevant. -- DavidMcNicol

I assume you're aware of the list of existing programming languages for the Pilot at http://www.roadcoders.com/pilot/tools.html. -- KatyMulvey

That page has disappeared. Try this instead: http://goanna.cs.rmit.edu.au/~winikoff/palm/dev.html. -- MichaelDillon

You should look at PocketSmalltalk

http://www.pocketsmalltalk.com/

This is a working Smalltalk VirtualMachine for the Pilot. I wrote a little program that did a fair amount of stuff, it worked fine first time in an executable of around 30k (image and VM!). Warning: as the author warns, this is a work in progress, so no graphics yet and it did nuke my Pilot when I created around 1000 objects...

There's also an interesting white paper, which talks about some of the benefits of Smalltalk as a palm top language, and full source code.

Right now, his environment for creating images is PC-side only, but I think it's written in Dolphin Smalltalk, so presumably could be ported to run on his VM. -- DaveCleal

Original Posting

I have read several posts referring to the possibility of having Java, or at least a JavaVirtualMachine, on the Palm. While I'm sure this would be really useful (I'm a programmer myself), I do wonder whether this is going slightly against the ethos of the Palm. I'll try to explain what I mean by that - I'm a bit of a palm newbie so feel free to correct me.

I see the Palm as an entirely different creature from palm-sized PCs, and I want to see continual improvements in the technology and the applications that are available, I don't see desktop PC emulation as a holy grail.

Applying this to my particular area of interest, I wonder whether we should think about a development environment which would suit the Palm, rather than try to twist the Palm's spec to run an existing environment which was designed for a much larger machine.

I use my palm to take down small notes quickly, to sketch out ideas while I'm on the hoof, and so on. Following that train of thought, I guess I would like a development environment that would allow me to sketch out solutions, data models, and even at a lower level, specific algorithms.

Smalltalk would seem to be ideal for this, but from what little I have read, it would be difficult to implement. In fact, looking back at my argument above, implementing smalltalk, or at least Smalltalk-80, would be just as invalid as implementing Java, VisualBasic or whatever.

Why am I saying all this? Well, I would like to have a go at developing an OO environment for the palm. I don't know how feasible this is, but I think it's worth looking into, and throwing a few ideas around. If anybody else is interested I can set up a mailing list and/or a website, and we can start talking.

I would personally be very interested in doing something like this, especially if it were possible to get a Smalltalk subset up on the machine. I am more interested in having the environment than in building it: it sounds like the same is true for you. In any case, I'm interested if we can get a virtual team together. -- RonJeffries

Not at all, I'm very much interested in building it! But I am aware that I'm not an expert in: compilers, smalltalk, porting, low-level coding and probably other areas too. I don't plan to let that distract me - I have the most fun when I'm learning new stuff.

But regardless of who codes the environment, I think it is really important to investigate it at a conceptual level.

Every Saturday morning, I get up early because I know I will be able to work (something to do with MentalStateCalledFlow). With the Palm I can walk around the house, make coffee and still take notes - sometimes perching in the kitchen, sometimes leaning on the window ledge. With that in mind, my personal preference would be for the environment to support the coding equivalent of hand-waving arguments. -- DavidMcNicol

Here's how to find the interface you want. First learn Smalltalk. Then find a friend that also knows Smalltalk. The two of you take a long road trip ... say, across North America and back. You drive, and while you do, dictate an interesting program to your friend who runs it on a laptop. On the way back home, you program some more. But this time, pay careful attention to what you say. That is your programming environment. -- WardCunningham

One of my complaints about some 'modern' programming environments is that they violate flow, forcing me out of the meta-level ("Put some guards around this") and into the syntax ("Why didn't that line turn green when I typed it?") prematurely. For me, a great programming environment for the Palm would allow sketches and PseudoCode. I want to be able to save something like: 

if (index is out of bounds)
[  throw appropriate subscript exception]
else [ do actual processing]
without officious warnings that "This code won't compile!". I know it won't compile. It's an idea, not a source file. I'll turn it into working code after I've debugged the idea.

BetsyHanesPerry, now working in C++ (oh, the humanity!)

or something like: 

    aCollection 
      do:[:element | element processNormally]
      shitHappens:[:excep| excep translateTosubscriptException]
actually in most Smalltalk implementations, it's just 

   aCollection 
      do:[:element | element processNormally]
You can't get a subscript error, 'cause the collection knows how to iterate over itself. If you were clumsily accessing by index, the collection knows how to raise a subscript exception.

-- PeterGoodall 

  Yes, I refuse to work
  in Java or C++


  If it smells, don't stand in it!

Something like, say, 

self indexOutOfBounds
ifTrue: [self throwSubscriptExpression]
ifFalse: [self doProcessing]
for example?

My heart goes out to you and to all the C++ victims in the world. What a tragedy! Know that I have been there and know what you are feeling. -- RonJeffries

Or something like, 

if (indexOutOfBounds())
throwSubscriptExpression();
else doProcessing();
Which seems virtually equivalent to the ST version, except you'll get compile-time errors with the IDE stopping you on each of the undeclared methods (indexOutOfBounds...), which seems like what I'd want. For greater flexibility in either case, use your favorite comment delimiter... -- JimPerry

Some thoughts on a Palm development environment

anyone can feel free to edit this or move it to different PalmDevelopment? pages -- KatyMulvey

I've written Perl scripts on my Palm while waiting at the doctor's office. Once you master the punctuation strokes, it's not half bad.. -- DaveSmith

Yes, PalmGraffiti takes longer, but I'm hoping that it will become more intuitive for me over time. Still, it will greatly influence the syntax of any input. If the underlying OO model is simple enough, there is no reason why the system should not support different styles of input (other than memory limitations).

For example, I would like to be able to sketch out a skeleton of a class using a simplified OMT/UML tool, and fill the implementation of the methods in later. That would give the system enough information to see which methods were being selected, and so on.

I've developed a simple version of Wiki for the Palm, and I plan to add support for annotated diagrams, outline lists, OMT diagrams. Actually, the plan is to have a simple API to allow anybody to add new functionality. I see no reason why a system like this could not be hooked into the OO environment. Ward's HyperPerl springs to mind, though I am perhaps becoming a tad too adventurous. -- DavidMcNicol

<< The ForthLanguage is very small and fast. Would OO work with a stack-based system? >> Getting back to an early question - I love the concept of Forth and think it is a good candidate for the Palm. I'd be interested in a discussion of Forth implementing the virtual machine for Smalltalk, or a similar OO environment. I think of Forth as a one-address machine (there was an article about this in a SIGPLAN some years ago, called, The Ultimate Risc Machine) rather than so much as a stack machine. The only bad bit is Smalltalk's use of returns out of a blocks, which causes things to stay around and exit not in stack sequence. Perhaps someone else has an idea for an alternative with better stack behavior. -- AlistairCockburn

I've never seen any good come from one of those blocks anyway ... I'd be inclined to figure a way to make the compiler/VM not allow them. -- RonJeffries

Neon and Actor were stack-based, threaded-code, OO languages for the Mac. Neon came first and even used post-fix notation like Forth. But apparently it looked too alien to sell. So they developed Actor which used a more standard, "Pascal-like" syntax. (That's how it was typically described as Pascal was a biggie on the Mac in those days.)

Apparently, Neon is still around and being maintained but under a different name for legal reasons. Off hand, I don't recall the name, but if there is interest I could dig it up. -- KielHodges

Wasn't the DylanLanguage supposed to be suitable for tiny devices? -- RonJeffries

Doesn't it seem a little silly to talk about "tiny devices" and Forth in the context of the devices at hand? Forth was ecstatic to have an entire 64K to play with, and I'm pretty sure I played with ST80 on a 512K Macintosh... Kids today! -- JimPerry

I played with Forth on a TimexSinclair? 2000. (Different from the Sinclar ZX-81 in that it had 2 K RAM built in instead of 1 K RAM.) Forth required the 16 K RAM-pack, though I'm sure at least 8K of RAM was free. -- KeithRay

I found a note about NeonAndYerkAsStackBasedOo from a search, perhaps someone else can find more about them. I guess Palm counts as small in today's world. -- AlistairCockburn

I'm interested in this for testing variations on mathematical algorithms (combinatoric/operations research stuff).

You may consider defining a language/environment with the palm constraints in mind. For example, any language syntax should be abbreviated (2 characters per keyword?) since handwriting is slower and the screen is small. Also, reduce or eliminate punctuation for language syntax since this is more difficult to enter.

Also, the language should convert easily into traditional languages (so the models you create aren't throwaways). I've done a little Palm programming using gcc in Windows if you want some help.

-- WayneCarson

You may consider defining a language/environment with the palm constraints in mind [ .. ]

Heehee, that would be fun. Though, the copious free time I was planning to spend on seems to have evaporated when I wasn't looking. I was thinking of using something like OMT or UML to build up relationships between objects, and defining a smalltalk-like syntax to fill in the logic. Maybe CrcCard-like operation would be better?

-- DavidMcNicol

I've been thinking about the Palm development environment a lot. I've been looking at pilotFORTH and PocketC, which has been enlightening. Here's a start for a wish list.

First, if a written language is chosen, the syntax should be primarily alphanumeric (since this is the easiest to type). Punctuation, if any, should be limited to simple characters (".",",","/","\"). Since the screen is sooo small, the keywords should have single letter abbreviations. This limits you to 26 keywords, but I'm not sure this is a problem.

For my testing of ideas/algorithms, I would want single inheritance, polymorphism, recursion (both direct and indirect), and dynamic memory allocation. Some package mechanism would be nice for reducing collisions in the namespace.

With the limited speed of the Pilot, I would suggest having the language compiled rather than interpreted, smart recompilation based on time/date to reduce compilation time, and easy embedding of assembly.

The machine isn't that bad at interpreted code. For one thing, it doesn't have to spend as much time minding other things like a complex GraphicalUserInterface, or background tasks.

Eventually, it would be nice to be able to create free-standing executables.

Randolph M. Peters's "Object-Oriented Extensions to Pocket Forth", ported to QuartusForth, is available here: http://www.quartus.net/files/PalmOS/Forth/Contrib/oop.zip

Forth has vocabularies which are essentially namespaces. True dynamic memory allocation was never really a part of Forth, though there have been implementation with non-standard words that accessed OS facilities to allocate memory. -- KielHodges

http://www.tiac.net/users/ajb/pocketst/whitepaper.html shows an implementation of SmalltalkOnThePalm?.

I have so far been able to locate TinyLogo, PalmPython, PocketSmalltalk, and ForthLanguage (for which there seem to be at least 2-3 OO versions) for the PalmPilot. Seems like just choose your poison and have at it. (I somehow didn't look for Palm Java and C++, although I'm sure I passed them along the way) -- AlistairCockburn

IMHO, the principal advantage of the PalmPilot is that the software is designed for its purpose rather than trying to shoehorn a desktop OS into a palm-sized device. Just look at the fact that PalmOs has no apparent "file system". On a device that has no disks it doesn't make sense to save your work to a file. This is the principal reason why the device is so cheap and easy to use.

The odds are against file-oriented languages. (Think about "CLASSPATH", "cout", and "#include...") The Smalltalk "image" concept looks more appropriate.

-- some guy

IMHO, the principal advantage of the PalmPilot is that it doesn't try to be a complete standalone computer, but concentrates on doing well what makes sense in the form factor leaving other stuff to your main computer. This is what makes it better than the Newton or Psion to me.

Having said that I agree that file oriented programs on the PP don't make a lot of sense (although PocketC is probably the most popular on-Palm development language, and that's file based), and despite what I said about C++ above my first significant PP programs will probably be in PocketSmalltalk. -- pth

The PalmOs folks have an interesting paper on how and why to KeepItSimple for PersonalDigitalAssistants at :http://www.palmos.com/dev/support/docs/zenofpalm/ -- ScottElliott

[EditHint: is there a better page for this comment?]

I'm not so bothered about an OO environment for developing on the palm - what I'd like is a component model for the palm. Here are some things that'd be worth investigating:

Any ideas?

-- some guy

Comment about a severely early version of PipPy was deleted as no longer relevant.

There is a free version (unregistered it wont make prc files) of Quartus Forth at http://www.quartus.net. There are some OO extensions for it on the contributions page http://www.quartus.net/files/PalmOS/Forth/Contrib/ and there is a shareware on board resource editor at http://www.individeo.net/ please register it if you can.

There is also a nice tutorial on Forth and the Resource editor on the contributions page.

I'm only learning so far but this is the first development environment I've been able to use while standing on an underground train!

I like Quartus Forth. I don't like not having a keyboard. Guess I'll have to go get one of those Visor keyboards for my green-and-ice. :-)

But now that I've registered my happiness, I must say that I wish there was a version that I could use to make PRCs - even restricting me to making ones that are FreeSoftware - without plunking down the cash. This is a hobby, not a money-making venture, after all. Or maybe I'm just greedy... -- MattBehrens

The registered version of Quartus is only $70. That's dirt-cheap in the realm of development tools. Anyone who wants to see some of the things being done with Quartus Forth should check out the SleeplessNightWiki.

I looked at the book 'Object Oriented Forth'. It requires some extensions to the Forth language itself not available in all Forth implementations, at least not in QuartusForth the best Forth going on the Palm. I still believe that one could get an object language going on top of Forth, someone pointed us to some OO extensions above, but I also believe it is a moot point.

Of special note is LispMe, which others have also pointed out. I looked into it and found it to be a moderately mature environment that runs entirely on the Palm. Some of the environment that makes Lisp and Smalltalk so productive is there. It also has some features which make it very well suited to taping out a quick algorithm on your Palm and running it. I created a simple object environment called LispMeObjects for a project I am working on.

Probably the most likely OO environment in the long run will be Python. Pippy is working in a limited capacity now and should become more robust over time. The Pippy folks seem to be working to give it an on-board development environment like LispMe. You could then add modules by cross compiling from the desktop or you could experiment with code on board, that would be perfect. -- DonWells

I really like the idea of a UML notepad for analysis and design work. It should have an ability to export to the Memo Pad in XML so it can be manipulated later for input into Rose, or whatever. Something simple at first with, say, use-case, class and activity diagrams, and then getting into behavioural modelling with sequence and state diagrams and beyond.

The small screen is a problem but with clever viewports and zooming, it can be made easier. Remember, we used to do graphics on 320x200 pixel screens on PCs not that long ago. -- AndrewJoyner

Yeah, but the Palm is 160x160.

bootstrapping a development environment

I would suggest as a first step that someone comes up with a Pilot simulator. The manufacturer probably already has one that is an environment running on a PC that fully simulates the Pilot's native language, but with single stepping, interactive debugging, etc. A nice little unit test framework for this environment would be good too. A Pilot assembler comes next if one does not already exist. Perhaps a Forth implementation comes after that (Forth needs an assembler to implement some of the Forth language itself). (I recommend Forth because it is designed specifically for stuffing 10 pounds of software into a 5 pound processor.) Now you are ready to implement an OO VM of some sort (the primitives). Hopefully not Java, but something interpreted like Forth itself, logo, lisp or Smalltalk. Next comes the development environment, but it needs to be small so that the source code for the environment is available within the environment or the source code is interpreted directly so it is resident. Logo is a source code resident language as I recall. I believe Forth can be decompiled giving an intermediate solution. I have a book called Object Oriented Forth at home I will try to remember to look it up.-- DonWells

There are already simulators for the Palm. For the Mac and Windows it comes with the device or the development kit. Xcopilot exists for the Linux environment. There is an assembly development kit for the palm as well. (EZasm http://www.palmblvd.com/software/pc/development.html) There is also already an implementation of Forth for the Palm. (QuartusForth http://www.palmblvd.com/software/pc/development.html) I guess all that's left is for someone to make the OO environment! -- ScottElliott

Wow, there's a lot of development tools at http://palmblvd.com/software/pc/development-datesort-1.html.

tangential stuff about tools that cannot run on the palm, but produce applications that run on the palm

These let you write applications for the PalmOs, but they won't let you write applications on the PalmOs. Still, we need these tools to bootstrap the inital OoEnvironmentForPalm ... or do we?

MetroWerks has a high quality C++ environment for the PalmOs. MetroWerks has included the PalmObjectLibrary from AqPoint. The PalmObjectLibrary is a very serviceable framework for Palm Development. A good review of PalmOs tools is the "PalmPilot Software Development - Alternatives to C" page at http://www.winikoff.net/palm/dev.html -- ScottElliott

Some fellow has been posting stuff on alt.sex.smalltalk regarding code written in Smalltalk (on the PC, I think) which he can then port to the Palm. Might be a possible base? -- RonJeffries

I believe there is more than one place where researchers are porting a small implementation of Java to the Palm platform. I haven't heard of an OOP development environment though. But I remember GlyphicTechnology?'s Codeworks environment for GlyphicScript? that was shown at OOPSLA 92, and it seems like it could be a good match - it was developed for the EO after all.

As for OO systems on small devices... I work on the JavaCard project at Sun, and we are defining the spec for (a subset of) Java on smart cards. Our current target system is just 512 bytes of RAM, 24K ROM, and some amount of EEPROM depending on how many applets you want to run.

-- JoshuaSusser

Check out Waba at http://www.wabasoft.com; it's a VM for the Palm that runs pre-processed JavaByteCode. IE, you write Java code that uses their packages, run the class files through a converter, then you have a Waba application their VM can run on your Palm.

-- RobCrawford

http://waba.sourceforge.net/

Nice, but it won't let me write code on the Palm.

I've written some sample code using gcc for my staff. Not bad, but not what I'd want to do all day. I've designed some apps that my staff has written using various tools. Castle is one tool they used. The runtime environment is a little hefty, but now they have released a "castle to C" converter that generates code that the CodeWarrior Palm development environment. One of my guys has used this to successfully convert a fairly large application with no major effort.

The CodeWarrior development kit is one of those "modern" ide type things. (I'm an emacs dinosaur.) The version for the Mac is actually stable. The version for Windows is, well..., Windows doing what it does best: crash. -- DaveBennett

CodeWarrior Mac Note: MetroWerks suspended development of the Mac version of CodeWarrior for the PalmOs as of Version 8.3 (That's only the Mac PalmOs tool. They still support native Mac tools) -- ScottElliott

There's a class library for the GCC Palm cross-compiler. -- pth

I'm sure Palm C++ would be more efficient than those others, and efficiency is very important on those tiny computers. -- RonJeffries

What measure of efficiency? Space-efficient is needed. Speed efficiency often isn't. Most of the programs on a PalmPilot do very little compared to a PC application - it's the convenience of the delivery platform that gives them their value. Given this, it's quite difficult to make them run annoyingly slowly.

For space efficiency, a byte- or threaded- code language might well win, especially if the support library is small and shareable between applications. For standalone applications, C or assembler probably win on space -- pth

Paul, see GentleSarcasm.

Seen it. I don't agree with the premise behind Ron's sarcasm. I'll try again: In my view, the context of development of applications for a PalmPilot is different enough that many of the purported disadvantages of C++ in other contexts either don't apply or are weakened to the point that C++ is a reasonable choice as an OO development environment. That context includes:

If for your needs you want native development, then I would agree that a C++ compiler on the Palm would probably be inefficient. If you're happy with cross development, then C++ is a respectably efficient choice for any meaning of efficiency. -- pth (heretic)

The original context of this page was that we "would really like to sketch out and test solutions on my palm." C++ (or C) is completely appropriate for cross-compiling, but some kind of small OO language would be nice for interactive development. (And I think it's a cute rebuttal of C++ advocacy.) -- MartinPool

I agree with MartinPool's point. and so do I; I should have made it clear I was talking about a slightly divergent situation-- pth

Sun has a beta of a very tiny Java VM for PalmOS, with some tiny subsets of the Java library to go with it: http://web2.java.sun.com/products/kvm/

co-authors:

EricJablow DavidCary ... etc.

One of the benefits of a PolyannaLanguage, if ported to C/C++ and compiled for Palm and/or PocketPc would be to allow you to make your own language for the device. Assuming the grammars were open source (text files) and there was one for each popular language, it would make more languages available for these devices than are now. For instance PocketC is not C++ (not object oriented). Someone posted a OO framework for LispMe but it seems cumbersome. With the Polyanna framework you could potentially get subsets of Perl, Ruby, Eiffel, whatever you prefer on the device it would be slow but that to me would be a worthwhile tradeoff to have a range of languages to play with at the bus stop. You're not doing anything anyway who cares if the program takes a few extra seconds to run. See also ProgrammingOnHandHelds.

Just because you find LispMeObjects cumbersome doesn't mean that is the only OO framework available. Granted with LispMe there are some limitations as to what you can do with Macros, but for the most part if you don't like the available object systems, it's not that difficult to build your own. Also, Closures can provide a lot of what you need/want in an object system by themselves.

CategoryHandheld CategoryPalmOs

EditText of this page (last edited April 10, 2012) or FindPage with title or text search