Slashdot Mirror
Mobile Game Applications Need Scripting Too
An anonymous reader writes "Mobile game developer Tom Park believes that scripting for wireless devices is important for proficiency sake. And with the need to scale mobile applications across so many different platforms, proficiency is everything.
Read his thoughts on scripting, as well as his ideas on wireless application development's future."
I wish that wireless applications would get at least a little bit faster, first. The J2ME software for my cell phone runs like molasses in Fargo in February. I've tried three different phone models, and they all simply cannot run things well enough to be usable.
I don't know if it's strictly a hardware issue or what, but I know that I certainly have written off mobile apps for at least the near future until I can get a phone in my hands that can actually run things well.
It is interesting that this article appears this morning, because I have just now posted the first beta of BeanShell version 2.0.
For those of you who don't know: BeanShell is a light weight, LGPL, pure Java Java source interpreter with a minimal footprint of less than 150K (and getting smaller). In addition to interpreting standard Java code, BeanShell extends Java into the scripting domain in a natural way by allowing loose types, method closures, commands, and other obvious scripting language features. And because BeanShell runs in the same VM with your app, you can freely pass "live" objects into scripts and back.
BeanShell is already widely distributed with Emacs, Weblogic app server, Sun's NetBeans/Forte, and many other commercial apps and non-commercial apps.
With version 2.0 BeanShell adds (bugs withstanding) full Java compatibility and the ability to script true Java classes. Scripted classes appear to outside Java code and by introspection as ordinary classes but are fully dynamic and may include arbitrary scripts in their bodies, methods and constructors.
Please check out www.beanshell.org for more and check back for updates on 2.0 in the near future.
Thanks,
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language.
What's true for the Sims and mobile apps is just as true for business applications.
The first trick is to define a language that expresses the highest level of abstraction you can, thus giving your developers the most powerful modeling tool they can get. The second trick is to do this economically. Hehe.
My team does just about everything with scripting, using XML languages as the scripting language and a code generator (GSL) as the metaengine. It's a good combination that lets us hit any level of abstraction we need to. Using XML is a bit clunky, but it gives us a single syntax (and single parser) for all our scripting languages. GSL... well, that's another story. Let's just say it does this kind of thing wonderfully.
Ceci n'est pas une signature
All applications need scripting, scripting needs to be cross-application (one script controlling more than one app) and that scripting needs to be available to the common user if they wish to use it.
This is one of the areas where I feel Windows fell down on the job - while COM allows all applications to make their functionality available to scripting languages, Windows does not provide a default scripting language that is universally available. Yes, Visual Basic will script things, but it is not a default part of a standard Windows install.
DOS had scripting of a sort (batch files), and people used that feature. However, DOS could not script every application, and batch files were missing key elements needed to make them anything more than linear sequences of commands. (Yes, batch files did have IF, GOTO, and so on, but try looping over a set of files, or taking the output of one file and using it on the command line of another file).
Unix has many scripting languages available to it (Perl, Python, TCL, in addition to bash, tch, et. al.), and at least one of them will usually be installed by default on a modern system. They can script command line apps like nobody's business, but unfortunately the more modern GUI apps provide much less scriptablity. CORBA and Kparts might help this if they were more commonly available. This is an area Unix-like environments (including MacOS) need to really improve in.
Granted, J. Random User may not want to get his hands dirty writing scripts, but think about it - if you, the person JRU turns to for help, could KNOW that scripts were available, how much better you could help the poor guy out.
www.eFax.com are spammers
I'm not going to argue about specific cell phone implementations, but let me just point out that Java was *designed* to run on cell phones.
People used to complain that Java was too slow for all sorts of applications... Have you noticed that they have been very quiet for the past few years? It's all about getting a good VM wedged into the device.
BeanShell is not the fastest implementation possible, but it does internally compile and perform many optimizations. It should be fast enough for a lot of applications to use it effectively.
Thanks,
Pat Niemeyer
BeanShell is a general Java scripting and extension language. It just happens to be small enough to be useful in some embedded applications.
If it's too slow for a particular application then just compile that code. That's the beauty of a Java *compatible* scripting language... see?
Pat Niemeyer
i wish my phone had scripted menus and interface. you could change anything in the menu, add your own custom functions, etcetera.
like taking a picture and uploading it to your web page and then bringing up a form for you to enter a caption.. or to run an executable to turn your voice mail into a text summary.. the possibilities are endless.
i'm sick of hard-coded phone interfaces built for a particular type of user who is most often Not Me.
Having written a fair number of applications for cell phone J2ME and Symbian let me just say that all of the folks out there trying to blame Java for the woes of their cell phone being slow are barking up the wrong tree. The problem with speed is a function of the trivial amount of CPU that's available in the phone at this point. That is something that's getting better over time - as is the issue with RAM in the phone. Wireless applications need better CPUs, better input devices, and a better data network infrastructure (in the case of cellular networks) before they need scripting. That's not to belittle the position or to say that it isn't something that's important to someone out there - but the current condition of the phone from a technology standpoint is not well suited to to imposing a scripting engine that requires scarce resources. One has to look at the reality of the market as it exists and the devices within it before trying to add more stuff to it. Today as the devices stand - the vast majority of them just don't have the resources necessary to handle scripting. The situation is improving and one day we'll be at that point (12-18 months from now) - but today adding scripting to the resource starved devices is just not a good move... especially given that someone would in many instances have to download 150k of scripting framework onto the phone - a size larger than many wireless applications. When you consider that wireless users pay for this by the meg (or in some cases by the K), it becomes pretty clear that the market isn't yet ready for that.
I don't have too much experience with current mobile devices, but I'd say that they need a bit more processing power/memory/etc under the hood before any really good, serious scripting can be done for them. The cell networks also need to become a good bit more reliable(at least in the US). My parents still can't get proper coverage for their cell phone at their home due to geography.
So, while you(and the main article) make some interesting points, I think that it's a bit too early to talk about scripting.
The article also strikes me as being a bit of a propaganda piece.
In my life I've downowded and installed hundreds (if not thousands) of Emacs distributions for at least a dozen of platforms. And I had never had a chance to find BeanShell there. Where do hide it? Or is it possible that you have just mistaken Emacs with vi? How dare you! Oh, by the way, what is the model of the wireless phone that has Emacs in it - I want that phone now!
On a serious note, Java is specially designed to be not scripted - statically typed, eager evaluation, run-time only after a compiler. Every attempt to bring scriptability to Java is making it even slower and even requiring more memory. I've tried BeanShell, Jacl, Jython, Kawa - none of them are good for mobile aplications. All by exactly the same reason: Java itself is the worst case of scenario for embedded applications. Of cource due to its resource requirements.
What's wrong to use scripting language directly, without Java? If you are addicted to imperative semantic (let's say you worked too long with C/C++, and Java and "program" for you is a sequence of commands) then use Python: compact, fast (enough for scripting, at least much faster than any scripting exte4nsion for Java), OOP, widely distributed (not with Emacs, but with many operating systems... just kidding). If you don't have such "imperative" addiction then try Erlang: that langauge has been specially designed for being used in mobile (at first in wireless, but now it's not limited to) applications, it's compact (more compact than JVME), fast (faster than JVME, often as fast as C++), high-level scripting (aka functional-logical) language for disctributed and mobile applications. IMHO ideal choice.
Less is more !
Actually I think VBA comes with windows. After all, those .vbs viruses didn't seem to have much trouble finding hosts :P
autopr0n is like, down and stuff.