[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
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.
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
This is a working
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
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
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.
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.
, now working in C++ (oh, the humanity!)
or something like:
do:[:element | element processNormally]
shitHappens:[:excep| excep translateTosubscriptException]
actually in most Smalltalk implementations, it's just
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.
Yes, I refuse to work
in Java or C++
If it smells, don't stand in it!
Something like, say,
ifTrue: [self throwSubscriptExpression]
ifFalse: [self doProcessing]
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,
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
- It should have as little syntax as possible. Writing Lisp code would be awful on a Palm, because the added time to write the parentheses (two strokes) would get in the way of the idea.
- Is PalmGraffiti really fast enough to think in? When I type, I don't need to think about individual keystrokes - I touch type, and how to do it is down in my fingertips. Graffiti still takes longer - I have to think about letter shapes which distracts from thinking about the larger ideas. Perhaps I just need more practice?
- What is the coding equivalent of a hand-waving argument, anyway? Ward may be close - I can envision saying something pretty generic and having another experienced programmer turn it into real code and giving me real feedback. I'm less sure about how to write a program that would make it easy to organize my thoughts so I could turn them into code later. Perhaps one of the outliner programs (none of which I've used) as long as I could attach pictures right into the outline, since I can often think about a problem better as long as I have a picture of it.
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'm less sure about how to write a program that would make it easy to organize my thoughts so I could turn them into code later..
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.
<< 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.
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.
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?
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
shows an implementation of SmalltalkOnThePalm?
I have so far been able to locate TinyLogo
, 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
folks have an interesting paper on how and why to KeepItSimple
s at :http://www.palmos.com/dev/support/docs/zenofpalm/
: 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:
- Shared functionality and access to common abstractions from different palm applications
- Form-based "controls" for entering new data types, shared between different applications
- Installation of palm-based "components" via the conduit
- Perhaps it might be possible to keep proxies of palm objects in a desk-bound environment and to do queuing and forwarding of messages to the ultimate targets on the device.
- Connectivity between palm-based components and the usual suspects (CORBA, JavaBeans, COM...)
-- 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
, but they won't let you write applications on
Still, we need these tools to bootstrap the inital OoEnvironmentForPalm
... or do we?
has a high quality C++ environment for the PalmOs
has included the PalmObjectLibrary
. 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
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.
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.
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.
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
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:
- Programs are of limited functionality and so...
- Programs are often of limited complexity
- Space is limited, but programs are small (because of the above), so fixed overhead is more important than "code bloat" (whether the memo pad program is 8 or 14K is probably irrelevant, adding 100K to every program isn't)
- The probable use of cross-development tools, rather than native environments, if for no other reason than the difficulty of typing on a Palm.
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
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/
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.