11

Note that this question is about the programming language RPL for the Commodore PET, not the HP language with the same name. RPL was developed by Tim Stryker and sold through his company Samurai Software at least as early as 1981, together with some other development and debugging tools. RPL is a stack oriented language, like Forth, and compiles to byte code. The manual can be found here.

I only recently learned about this language and like its clever balance between simplicity, speed, and compact code. However, it does not seem to have been very popular. The only materials that I can find online (e.g. on archive.org) are either generic reviews of RPL, or articles written by Tim Stryker himself.

So my question: Was RPL for the Commodore PET ever seriously used, other than in projects involving Tim Stryker himself? I’d be very interested in any references.

Improve this question
13
  • 3
    What would be considered a 'serious' usage? He seems to have sold the language and it's safe to assume people bought and used it. Everything thereafter would be quite up to opinion, wouldn't it? (Beside that, nice find!)
    – Raffzahn
    Nov 27, 2021 at 14:16
  • @Raffzahn Hard to define. :-) Any commercial use for example. But to be honest, I’d love to hear any story about it, also the home tinkering applications.
    – WimC
    Nov 27, 2021 at 14:20
  • 1
    @WayneConrad Thanks for pointing that out. It was mainly about the stack oriented part. I rephrased it a bit. Technically the difference in execution seems even not that big. Plus, using byte code instead of address code saves about 50% of space. :-) Judging by some reviews, RPL ran just a bit faster than Forth, but no doubt there would have been various implementations of Forth around with varying speeds.
    – WimC
    Nov 29, 2021 at 18:53
  • 1
    @TimLocke Yes, it's a quite interesting case. Not so much as RPN language or it's functions, but the very fine tuned way it was made to fit the PET ecosystem Editor as well as BASIC cruncher is used without any modification. Such pretty integration is a very rare feature and worthwhile to be remembered.
    – Raffzahn
    Nov 29, 2021 at 19:06
  • 1
    @WimC The slow speed of threaded FORTH is in part due the PET using a 6502 which lacks 16 bit operations and a versatile indirect jump. The additional effort needed for transferring to the next instruction levels the advantage threading has over a byte code interpreter loop
    – Raffzahn
    Nov 29, 2021 at 20:21

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.