Re: Survey: Best programming language for next-gen HP? Message #2 Posted by Oliver Unter Ecker on 3 June 2012, 5:39 p.m., in response to message #1 by Oliver Unter Ecker
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.
JavaScript: 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.
|