Survey: Best programming language for next-gen HP?



#34

What do you think would be the "best" programming language for a next-gen top-of-the-line HP calc?

If it's different, what would you think would be the most sensible choice for HP to offer?

What attributes make your choice (or choices) the best?

Please consider casting aside emotional attachment to what you presently *like* best.

Thank you!


#35

If I had to answer this question with one sentence it would be: Python with proprietary, strong math lib.

Other thoughts:

RPN/RPL: (Yes, I'm bundling them together here!) Time has spoken: no-one (I'm rounding here) is using these languages. It's easy to prove they're out-dated. As such, these would be poor choices. On the other hand, they do offer backwards compatibility. Is this desirable? I don't know. It wouldn't hurt to also offer them, if it's easy to do.

C: Nope. Choice should be a scripting language. Having to deal with compilers and possibly requiring development on a desktop is not cool. There're enough C-like scripting languages that leverage the widely-known syntax. May not be a terrible choice as an optional language for low-level development, but still strikes me as too inflexible/static, and too much of a hassle.

Lua: Do what TI does? (Is Lua actually used by a sizable number of people on N-Spires?) Has a reputation of being fast and concise. Could be a good choice.

Python: In wide-spread use, easy-to-learn, pretty elegant and quite powerful. Best choice on balance, maybe, but still not perfect: lacks focus on array processing that can come in very handy for the small to mid-sized program one may write on a calculator. Also doesn't offer operator overloading and isn't as concise as could be. Could be a superior underlying "system-level" language.

R: has strong focus on array processing. Not in wide-spread enough use to qualify as a strong candidate. Not sure if it's easily extended with the required extra math lib.

J: powerful, maybe even amazing, but too cryptic. Could be a "fun" 3rd language.

J‌avaScript: classified.

System language: RPN and RPL had "assembly" language "system languages". Any scripting language above used "naked" (w/o proprietary math lib) would provide such a lower-level language. Depending on choice, C++ could also be a swell choice as low-level, secondary language, but still burdened with all the compiled-language overhead.


That is, I find none of these choices actually and truly all-satisfactory. This points to a proprietary language (again!) and while this seems to counter what one should do in this day and age, it would mirror what has been done in math systems: Mathematica, Matlab, Maple, etc. all use their proprietary languages.

Given that a calculator is bound to be a mobile device with limited screen real-estate, keyboard, etc., and that, realistically, programs written on the device will be short(-ish), I think the following attributes for a "best" language are desirable:

- concise

- easy to learn and readable

- powerful

"Concise" isn't easy at all. Avoiding fluff syntax, even minimizing the need to indent are attributes almost devoid from any language meant to be used on a desktop. J is an exception but truly unreadable to most mortals. You also want to avoid the need for control structures (for's and if's) but still get what they do.

In my mind, "concise" implies operator overloading (a feature present in C++ and RPL to some extend) and strong array processing.

"Easy to learn" implies the language is free of obscurities. This often counters the "concise" goal.

---

The hallmark of (most) HPs has been the stack and RPN operation.

A stack is devoid in virtually all modern languages. Keystroke RPN and RPL are a direct consequence of a stack. Any language choice is likely to be informed by the question whether a stack and RPN operation would be kept in a new product. (Does the 39gII clear up that question by saying "no"?)

The stack lends itself to "invisible transport" in a program which can aid conciseness but can also severely reduce readability.

---

I'm omitting many things here.

A language choice may also be informed by what other features/functions it should support, such as

- how custom UI is built. In my mind, UI should be built with HTML5 (at least under the hood), as this is *the* cross-platform language for UI.

- how I/O is to be supported. Surely, that new thing must be very "network-aware".

- how development on a desktop is tied into this. Desktop-programmability should be a given, IMO.

- what "incarnations" this calculator may take on. Confined to proprietary HW? Additionally available in SW form for tablet and phones (better!), or even live e-book and future textbooks (better still!)?

---

There's one more choice: no language. That is, no programmability at all. Too sad to ponder for me at length, does it may make "sense" from a business perspective? Graphing is probably a hundred times more important than programmability...

The answer to this will obviously depend on the overall scope of the speculated "high-end" calculator: If the old market for the 50g is abandoned and instead middle- and high-schooler's (mainly graphing) needs are to be addressed, then, well, programmability may really be of little to no interest. If the old market isn't abandoned and maybe the sight is even set higher and toward new opportunities (live textbooks, math-based tools/instruments), programmability becomes anywhere from relevant to crucial.

Apple didn't think much of giving people an SDK for the iPhone, resisting calls for that for quite some time and stating that people should stick to writing web apps. 500,000 apps later, look how wrong this initial assessment was, and what happens when people are let loose on a mobile platform with adequate tools!

I think a calculator could be a very suitable base for specialized math tools development, which, yes, will require a spanking dev environment.


#36

My 2 cents of Euro and perhaps some stupid ideas (?):

First of all, i want a really _interactive_ langage, and the RPL is perfect in this point of view. LUA, JAVA etc ? no. C would be awfull ... Interesting for create programs on a PC with special library to develop and then use the program on the calc; But i want an interactive language embedded in the calc.

1/ I think a bicephalous calculator like the 50G ( RPL _or_ Algebraic mode) is very confusing for most users.

2/ I am pretty sure that Algebraic and RPN could be mixed in a very interesting way. The stacks is just a kind of list isnt it (LIFO) ? I have not had any detailed thinking but I have a hunch that it is possible. And why only one stack in this case ? And why not some FIFO structure to manage messages ?

3/ imagine if you could use both SIN which take the data on the stack and SIN(A) ... 45 SIN will be correct but SIN(45) also
45 SIN

or

SIN(45) same than 45 SIN

or

'SIN(45)' (no immediate evaluation here) and why not '45 SIN'

4/ Imagine that you can access to the stack with for example $1 (first level) $2 $3 etc... SWAP or SWAP($1,$4) etc...

5/ the idea could be :

- A procedure (function) with no parenthesis will take arguments on the stack. If there are parenthesis, like in C or Pascal then take them between paranthesis

- the return data could be on the stack or not... A:=SIN(45) or 45 SIN 'A' STO ( the :equal symbol exist or not). If an := symbol exists put the result in the variable. If not, on the stack ! Put on the stack all you dont know what to do with. Take on the stack datas that are not detailled

6/ Go beyond with lists processing. Look at Haskell for example

7/ Some improvement like { 1..10 } for { 1 2 3 4 5 6 7 8 9 10 }... why not { 1..+inf}

8/ Introduce BREAK or EXIT to exit all loops and structures

9/ keep the organisation in repertory like the 50

10/ Extendable and polymorph langage. Keep the idea of 'word' (small program combinded) like in forth

11/ Must be homogenous and coherent like the 50

12/ CAS inside like the 50 and very easy to use in program

13/ Better screen resolution needed. Grayscale needed

14/ List processing and 'stack processing' functions could be quite similars no ?

15/ hum .... That's all for today ;)

In my opinion, the idea for a new calculator is somthing like "objects manipulation" . Easy acces to numbers, formula, list, matrix , combine all of this, store recall in the most possible easy way.


Edited: 3 June 2012, 7:20 p.m.


#37

Quote:
6/ Go beyond with lists processing. Look at Haskell for example

Reverse Polish Haskell would be cool! I've often thought that Haskell would be good on a calculator.


#38

So you might like cat or joy.

Cheers

Thomas


#39

Thanks Thomas, those both look very interesting.

#40

Quote:

Lua: Do what TI does? (Is Lua actually used by a sizable number of people on N-Spires?) Has a reputation of being fast and concise. Could be a good choice.


If Lua is
good enough for the spooks, it's good enough for me.

#41

I'll second that vote. RPN has been (and should always be HP's main toolkit. RPL is the next natural progression of RPN in its purest and unlimited form. Besides, RPL picks up where RPN leaves off. Plus, to add a high-level programming language/structure to the RPN framework makes for the perfect marriage.

I for one am glad for the development of RPL. if I can't have the dream of Pascal as a calculator language, RPL fits the niche and adds postifix/RPN syntax. What more could I ask for?

#42

Quote:
for a next-gen top-of-the-line HP calc

What makes you think there will even be one of these? Look what happened with the 35s, when was it, 5 years ago?

In my opinion, the "next-gen top-of-the-line calc" will be an app running on either iphone or Android.


#43

Quote:
What makes you think there will even be one of these?
Since:


A. the market for this kind of calc is apparently diminishing, and

B. making such a calc more and more advanced probably requires a greater and greater investment in man-years to develop,


the next-gen HP, just to make it happen at all, will probably need to be a modification of what's already there in the 50g, even if my own (and many others') approach to designing the 50g would have been different. If the system is plenty well documented, users will extend its usefulness far beyond what HP can afford to do, even beyond what I observed and experienced with the 71 which got loads of great LEX files from the users' groups, and large third-party memory modules.

The ability to add languages is definitely welcome. No development should be totally dependent however on a host PC and its operating system, or on interfaces that are also here today and gone tomorrow. Remember how long PCMCIA lasted? or Zip discs? I'm not likely to make the time investment to really learn a new system if I sense that it's a consumer item like iPhones or Androids whose life expectancies are just a couple of years instead of decades.

For myself, it definitely needs to be programmable though, and it needs to be strong in the I/O department, able to be a controller to many devices at once, like HPIL allowed. I know graphics are important to some, but it's almost irrelevant to me.

#44

An interesting question.

The lowest level core will be C or maybe C++. There really isn't much other choice here. Once the core routines are done, the rest can be written in pretty much whatever language one wants.

If the calculator is programmable, it makes sense for the rest to be written in this language -- no point having two separate interpreters on the device. Thus, if you are aiming for a keystroke programmable, implement most functions as such. RPL, likewise. Thinking about what language you want your users to program / might already be familiar with is very important. RPN or RPL might be old and crusty to some but they are what this group knows and uses.


As for the criteria for choosing, I'd start with:

  • Flexible/easy. The language must be easy to use and must make solving numeric (& other) problems easy. No bizarre syntax. No weird limitations. Some scripting languages are okay here, some less so.

  • Powerful. The language must be capable of doing what ever is required of it. What exactly is required won't be known at the outset. Most modern scripting languages are fine on this point.

  • Safe. Calculators can't crash. The implementation language must be completely robust and uncrashable. Most modern scripting languages are pretty good here.

  • Compacting garbage collection. Garbage collection is a given I think, user's don't have to have to worry about this. Compacting is also essential -- this is a limited memory device and fragmentation will kill it eventually. Most current scripting languages fail this one. Only some LISPs seem to meet this requirement fully (but I'm probably wrong).

  • Libraries. There is going to be a lot of mathematics code in such a device. Having to write everything from scratch is very painful. Leverage existing libraries. This applies to the non-mathematics code too. This less you have to write the more likely the project is to produce something. Python is very strong here as is R.

  • Footprint. Both ROM and RAM use are critical. Some so called scripting languages are way too large to fit onto a small memory hand held device.

  • Speed. Using a scripting language pretty much mandates a performance penalty over using C. A small handheld device isn't CPU rich and from the 34S experience, many optimisations will be trading speed for space.


- Pauli


#45

Having seen some recent articles about "bendable e-Ink displays" makes me think about another clamshell design with a BIG display. This might open the door for some form of visual programming language or at least a simplified but powerful core language with visual extensions.

I do dispare that the tablet/pad world does reduce the viability of handheld calculators. The number of folks who want such a limited use product are probably (and sadly) dwindling. Nothing wrong with daydreaming about it though, and hoping.

#46

Quote:
RPN or RPL might be old and crusty to some but they are what this group knows and uses.

Is this group as it stands really large enough to justify continuing with RPN or RPL for a next generation machine? If the answer is no, then there needs to be a plan for expanding the user group for RPN or RPL before proceeding with a development. Any ideas on just how to do that?

#47

I have the printed books for RPL and they must be 6 inches thick and weigh 8 pounds. I think many 50G's are at auction as the learning curve is way too steep and the amount of program calls are too large. Since RPN is ingrained in older HP calculators programming in RPN requires no new knnowledge aside from tests andd flags. If a more complex computer is needed there is always the desktop. I think with more number storage and steps RPN is preferable for the average user. Improvements could be made in keyboard keys using a choice menu. The storage of data pairs should be made simple for regression analysis. We have heard from programmers, now could everyone else have their say? Sam


#48

On second thought I realized that H-P already has a good idea of the potential market for a next generation RPN machine based on the HP-15 LE sales. So the only real question is do they think that market is large enough to support a new development.

#49

Quote:
... the rest can be written in pretty much whatever language one wants.

Perhaps that's the answer. A calculator onto which one can load any interpreter/compiler you fancy. E.g. I have Pascal 5 on my 200LX. As has been mentioned elsewhere in this thread, no single language will satisfy everyone.

But to be able to load any interpreter/compiler you basically need a computer? That brings me to the next subject:

I read of wishes for large colour screens, USB, internet, camera .... a picture of a small tablet computer comes to mind. There has always been the fuzzying of borders between calculator and computer. I think the 100LX/200LX designers were on the right course. "The office on my mobile device" is where it's at - that's not the future, it's the now (e.g. office apps on the Lumia). So have some calculators for it that are well intergrated (e.g. the 200LX calculator solver was available in the spreadsheet app too).

However, it is also good to have a small handheld calculator too, to quote the "bring back the 15C" website:
"In conclusion, outside of college a large powerful graphing calculator is not needed or wanted. When relativity simple calculations are needed most people reach for a pocket calculator. I do real world calculations everyday, the 15C more than meets those needs."
And I couldn't agree more, except about the size: reduce it to credit card size. There is one calculator i truly have had in my pocket since the day I got it: the DM-15CC (the little hard case I bought a year before on ebay because "it looked nice and could be useful" - not knowing how right I was :-).

So, my programming language choice?
1) Any that I want to use at the time, on a well integrated calculator on my "office-in-my-pocket".
2) Keystroke programming on a quick to use credit card sized scientific calculator.

As always, just my opinion,
Regards
-B
#50

Not exactly an answer to your question but I saw an opportunity to get on my soap box:

I'd like to see the calculator evolve and not just take incremental steps. Calculators used to be the mass-market go-to device for solving difficult numeric problems and they have largely lost their relevance. I like calculators, and these days even I will usually reach for the spreadsheet before I reach for the calculator.

Changing the user programming language may very well be necessary/desirable, but I don't think that it will ultimately do much in terms of how relevant most people see the calculator to their problem solving. Do people really want to be writing increasingly complex programs on devices with tiny screens and limited debugging facilities?

Before the question of language is answered, I'd like to see this question tackled: "what should be the next-gen way of using a calculator to go about solving difficult numeric problems?"

What I would like to see is a calculator that has a built-in camera, much like any cell phone, and has built image processing and text/handwriting recognition software. So, instead of writing programs, I can scribble down equations and flowcharts on a paper, take a snapshot; the calculator should write the program for me. I would like to be able to point the calculator at tables of data, whether hand written, or on my computer screen, or in a magazine, and use those as input to a large library of solvers and analysis tools. I'd like the calculator to take into account the iterative process I use when solving problems and give me intuitive ways of iteratively cycling through multiple variations of approaches without having to manually rework a program every time. Etc, etc, etc.

All those things that I would like to see have to do with the interface. Underneath it all, yes, there is a programming language and I want to be able to look at that programming language. However I don't want to look at it often.

Just like I only rarely look at the assembler generated by the C++ compiler these days. Thirty years ago, I had to know a lot more about the instruction set of the computer I was working on. Now, I don't really need to care much about what the instruction set of a computer looks like - its just not relevant. That's what I want from a calculator - a device that provides a great interface for solving problems, where I don't really care what the underlying language is.


#51

Excellent points, Marcel.

You're right. One has to decide what the machine will be used for, before figuring out in what user language it should be programmable.

I like various of your suggested uses. There's quite nice hand-writing recognition SW available (e.g., Anoto), which one could leverage. Not sure this should come first, but it sure isn't just a pipe-dream.

Also agree that the next step ought to be a big one, and not an incremental one. There's too much that happened since the last true refresh of the high-end machine, which ought to be digested/incorporated if the idea of a dedicated (high-end) calculator is to remain viable.

"Dedicated" in no way should preclude that it could/should *also* exist in SW form on non-dedicated platforms. IMO, a scalable solution built around one trusty core would be ideal. At the same time, tests and test boards are not going to go away and "dedicated" will be a requirement (and true advantage for a player like HP to have over app makers!) for some time to come.

#52

Whatever the language is, it should be consistent between models. One could port a program on the HP 35S or 15C to the 50g II (my guess for the name of the next model).

I would expand on the RPN language to include string operations, FOR and WHILE loops, and graphic commands.

I also like the idea of being able to literally write in equations (by touch or stylus). I would also like to see a math reference beyond the equation library - this includes definitions, properties, and syntax.

#53

Hi there.

In light of a programming language for the HP's next line, I would like to also suggest a keyboard enhancement.

As with the 71B and since the 28/48/49/50 are driven by an actual language, the keyboard should reflect and support such an interface.

1--in the HP tradition and identical to the HP-71B, the double-shot tactile slanted key design and feedback.

2--a QWERTY-based keyboard in its traditional typewriter layout instead of the calculator row-based layouts akin to the Voyager series in order to accommodate a standard typist feel and environment.

3--Like the 71B, each key should have a token word for each of the language's commands. Yes, yes, the menu-based command structure native to the 28 to 50 has its purpose, calling up command tokens in this fashion has a limited practicality.

4--For program entry and display, rather than a command line string of the program, I'd like to see an actual formatted program--akin to the usual look for C, C++, Pascal, Forth programs. Viewing programs in the standard multi-line form makes them easier to edit and read.

The aforementioned being said and with the release of other such programmable handhelds from the 71B to Casio's 702P and Sharp, I think HP can design a next gen follow-up to the 50G that will meet and exceed my wish list hopefully with a 71B form factor.


Edited: 4 June 2012, 2:20 p.m.


#54

Quote:
2--a QWERTY-based keyboard in its traditional typewriter layout instead of the calculator row-based layouts akin to the Voyager series in order to accommodate a standard typist feel and environment.

Put a QWERTY keyboard on it and I believe that you will have problems with various test boards. I think TI did with their Voyage 200.

Also, I might be in the minority, but for a larger calculator I feel that a vertical layout is easier to handle when hand-held.

Cheers,

-Marwan


#55

Quote:
Put a QWERTY keyboard on it and I believe that you will have problems with various test boards. I think TI did with their Voyage 200.

Good point. Does anyone know what a test board would think of a "pop up"-style virtual QWERTY keyboard (i.e. touchpad-driven) on a machine that's otherwise dedicated (i.e. only a "calculator"; not a smartphone/tablet with apps), dumbed-down (CAS disabled), network-disabled (WiFi off) at the touch of a physical "test mode" button? (The button would send the machine into said semi-conscious state for, say, 2-4 hours.)

#56

Quote:
Put a QWERTY keyboard on it and I believe that you will have problems with various test boards.
How big of a factor is this, ie, how much of the potential market would care? I'm asking because I honestly don't know; but it would seem that anything that submits to those limitations will be too limited to appeal to another major portion of the potential market.

#57

Good question. I don't know the answer. But one could look at the sales of the TI89 vs. the Voyage to come to some conclusion as to sales volume for each format. I believe that the OS of those two devices is very similar.

Also keep in mind that HP has in the past hamstrung devices just so that they would meet test board requirements.

Cheers,

-Marwan

#58

Sage would be a natural choice, provided the calculator has enough power to run it.


#59

Quote:
Sage would be a natural choice, provided the calculator has enough power to run it.

Thanks for reminding me of Sage - I played with it very briefly a long time ago, but it's a very different beast now. I'm currently installing it from source on two of my machines. ;)

A tablet device running Sage would be a Thing of Beauty and a Joy Forever - but it's probably the opposite end of the spectrum from what I actually need most on a day-to-day basis, and that's a basic scientific with an excellent keyboard. Something like the original HP-27, really.

Maybe an integrated pair of the two devices, with a bluetooth connection, would work best all round.

Best,

--- Les

[http://www.lesbell.com.au]

#60

There's never a "best language" until you've got much of the task defined. Locking users into languages is a losing proposition.

RPN, perhaps extended to being a FORTH variation, as the base (yes, there's a machine code, Lower Level Language interpreter, LLL.) Other languages translate, interpret, or compile to either RPN or LLL; typically, user code to RPN, libraries to LLL.

REXX hasn't been mentioned and would be a good step above RPN.

Unicon is improved Icon, which I used to describe as the cross-product of Pascal and SNOBOL. It's wonderful to write in, close to DWIM, but has the APL "write-once" problem (straight forward code to one person's brain is obscure to another's.)


#61

Yes! REXX, pleeease!! :)

Well, it depends what you imagine as 'next-2nd-2-none' calculator. If that is an HP200LX replacement (kind of clamshel iPod touch PIM and more) then REXX would be nice. If it is a key-per-function calculator sufficient for 'normal' use then a programming like the HP41 offered is ok for me.

A good FORTRAN programmer may do FORTRAN in any language.

Ciao.....Mike

#62

A far more pressing problem that the choice of language is the namespace. RPL is not hard per se, it is hard because you need to know the thousand odd other names being used by the ROMs and CAS before you can name a variable or function, to avoid a conflict. RPN / Basic/ Whatever would be exactly the same unless you give up named programs.


Lua handles this reasonably well but that doesn't mean Lua is the right choice.


#63

I don't think it's a problem at all. Just name your variables with lowercase if you want : 'Beep' 'Cross' etc.

or name them in french, it is an advantage ;D

#64

If HP continues to use ARM chips, then the best language (in my humble opinion) is to program in ARM. This gives you total control over all the hardware, and maximum speed.

If the cross-compilers are well optimized, then perhaps you could find the appropriate one in your favorite language and just program in that. For example, the HPGCC project allows you to program in C, and compiles the binaries into ARM code.

Han


#65

The 34S firmware contains almost not ARM assembly at all. Almost all of the code is written in C. Assembly would be a bit faster and smaller but the time required to code anything would be way too large.

Given the resources on these kinds of modern embedded CPUs, assembly really isn't required.


- Pauli

#66

I favor two languages. One would be a high level scripting language for programs developed by the end user on the calculator itself. It would need to be easy to learn and use. BASIC is the old canonical example.

The second language would be for writing complex applications on a desktop development environment that included a cross-compiler for the calculator, sort of like HPGCC today. For this, I think C, C++ and Java are good alternatives.

As for RPN and RPL, I think RPN is great for doing calculations by hand on the calculator, but not for programming. It's just too hard to tell what's going on.

Others have praised the RPN/RPL stack, but consider this: every programming language that I'm aware of has a stack. The difference is just whether you're manipulating it yourself or whether the compiler does it for you.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 41CX Survey Pac Keith Burr 7 369 03-29-2013, 10:09 AM
Last Post: Keith Burr
  HP-41C Custom Survey Module Identificaiton Help Dan Grelinger 0 135 01-27-2013, 01:51 PM
Last Post: Dan Grelinger
  Error Message/Procedure HP-48SX with TDS Survey SX card bporter101 6 317 12-10-2012, 10:18 AM
Last Post: bporter101
  HP 75 Assembly Language Michael Fehlhammer 7 336 10-01-2012, 08:32 AM
Last Post: Michael Fehlhammer
  Survey for Special Math Problem Namir 7 341 06-03-2012, 09:46 PM
Last Post: Namir
  HP-17B Language selection disappeared. Kees van der Sanden 10 410 02-13-2012, 10:51 PM
Last Post: bill platt
  Calculator natural language user interface Donald Williams 12 435 01-07-2012, 09:45 AM
Last Post: Vince (Italy)
  HP15C LE Keyboard Survey Results M. Joury 23 717 10-02-2011, 07:52 PM
Last Post: M. Joury
  HP15C LE Keyboard Survey Take 3 (last round) M. Joury 33 931 09-28-2011, 02:28 PM
Last Post: Michael de Estrada
  HP 15C LE Keyboard Survey Redux M. Joury 57 1,659 09-25-2011, 04:03 PM
Last Post: db (martinez, ca.)

Forum Jump: