Slashdot Mirror
Nokia to Port Perl to Mobiles
jonknee writes "MobileTracker notes that Nokia has made it clear that the Perl scripting language is coming to its popular Series 60 devices. This will be a huge boon to mobile software. Just look what happened to the web when CGI got popular. A time frame was not announced."
This will be a huge boon to mobile software.
What? Please elaborate how perl can help in front-end applications for mobile phones.
In that case, how long until shitstorm.pl gets launched from a cellphone?
I was thinking of getting a Sony Ericcson phone, but if the Nokia will have a Perl port available, I might wait a bit longer before getting a replacement for my existing one :-)
Oolite: Elite-like game. For Mac, Linux and Windows
This is so great - instead of using the built-in PDA contact manager functions of our phones, us geeks will be able to craft perl scripts with regexes to look up people's phone numbers...
the current choices (C++, Java) are overkill for a lot of applications
They are right, for ripping info off of web pages and stuff you just can't compare C++ and Java to Perl because of the overhead, kudos. Now you can make perl scripts to provide real time quotes off of various websites very quickly, this is great news.
Just think...turn your ringing option to vibrate and then run the pleasure program. Insert phone in front pocket and enjoy!
There is no spoon or sig.
The web exploded - suddenly hundreds of thousands of dynamic sites, and sites with at least some dynamic content, sprang up in an amazingly short amount of time. The web was transformed from a purely flat, static medium to a dynamic one.
But mobile phones aren't static. The more modern ones can already run applications written in C/C++ or Java. Simply adding support for perl merely increases the number of people who could write code for them. The difference is nowhere near as great as CGI vs custom web server was.
Don't get me wrong, I'm not saying that this is a bad thing, by any means. I just don't see it having quite the same degree of impact as the poster.
It's official. Most of you are morons.
It already takes me forever to enter names and phone numbers on a cell keypad. I am going to love finding how to do a % or a @.
...is a phone to make calls.
What does this have to do with Perl? I don't get it... This handy-piss-contests will never end...
"Handy" (germanized anglism) == "Mobile Phone"
Anyone who has done any development on Nokias phones knows that Nokia is very 'bullet point' when it comes to supporting them. Their Java support for MIDP2.0 for example is a complete joke. Its horribly broken and Nokia knows it - basic applications from tutorials sometimes don't work properly or don't work in certain firmware batches of phones. What they NEED to do is get some quality control in place instead of adding a 'language of the year' to their platforms.
How would I get the shebang line up using predictive text input?
John, I'm Only Dancing!
There is some more information here if anyone is interested.
... or how paying $2 per kilobyte (thank you, local carrier) makes those four words the most expensive data message ever sent, at an average of 50 lines of code to produce the later ones people came up with!
take it easy 1337 dudes, its a joke
Now if only Siemens ported Python, that would be cool.
before MS dominates the market with that Windows Mobile.
I mean, I's rather use Perl than Java for many tasks, but if Nokia wanted a good, clean interpreted language, why not Ruby, which has the power of Perl but a far cleaner design.
Java is the blue pill
Choose the red pill
Forget the tutorials, yes the documentation is often not up to date, however, there are better places to learn midp programming than Nokia tutorials. There is *nothing* Nokia specific to midp programming!
Point some midp2.0 that works on any phone but a Nokia please? I haven't seen any!
Bugs in Nokia software? Certainly! Midp2.0 completely broken? No way!
...now I can host my own slash based site using my cell phone :)
The IT section color scheme sucks.
"We are unable to complete your call. Please hang up and try the -w option."
How about a link to the better, more informative article where the actual information lies?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
I was at Borland when the C++ effort started scaling up, and there was a lot of enthusiasm among people who thought that there was going to be a huge demand for personal device apps. Obviously there's the same feeling at Nokia, only more so. I suspect that this market is not living up to expectation -- the only apps that generate any buzz are phonecams and games, and there's only so much market for those. Nokia seems to think that there'd be more cool apps if there were more and better development tools. I really doubt that this is the problem.
Slashdot server will be moved to run on Nokia mobile phone. A slight lag might appear after the change.
agreed. My nokia 3650 that runs the Symbian Series 60 OS is the only cell phone I know that actually crashes, and you have to restart it. There have been several times that I actually had to format the phone's flash memory. I haven't had to reformat anything due to a crash since windows 98.
"You had this look that of an angel, it was such a bad disguise" --Dishwalla
CGI was the first easy way to program interactive web pages, as far as I know (it was a bit before my time), and perl was one of the languages you could use (along with C++, and pretty much anything else). But how does being able to write programs in perl on a device you can already code in C/C++ or java give you any huge advantage, unless you only know perl? I'm sure there are people who like to do all their coding in Perl, but unless you're one of them, this doesn't seem like much of a deal. Certanly nothing compared to CGI on the web. (And lets not forget that CGI was a pretty early tech, that came about when the web wasn't much. While CGI probably helped a lot, the web itself was pretty compelling, and growing quickly on it's own).
... simple code ...}}).
Also, how exactly is java "overkill" for these devices? People talk about how a hello world app is 5 lines of code, but those few lines are constants that are going to be in any small app (i.e. public class Classname{ public static void main(String args[]){
If they're talking about running time, they're probably wrong too. Perl is interpreted, while java runs in a VM. I don't know if they use JIT on moble devices, but java will still be faster then Perl.
So how is java 'overkill'? This is certainly good news for perl buffs, but I don't know why the rest of us should care.
autopr0n is like, down and stuff.
A C++ proponent accusing something else of bloat? Next, I imagine you'll be accusing something of being obtuse and unnecessarily complex. Thanks for the funniest (or is it most ironic) post of the week.
I mean, you're talking a 39,970 (wait, with a UK URL you want 39.970, don't you?) line difference in your estimate of the codebase here. Recommend calibration.
Ah, you meant between 30 and 40,000 lines.
Just tweaking your beard, boss.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Is this poster crazy?! To suggest that the sudden surge in web usage was down to CGI is frankly ludicrous! There is no way you can say, "right, that technology lead to the boom in the web". Its not possible! And even if you could pin it down to one thing, it would be something Many, many, many technologies have helped it along the way.
Further, perl is not the only scripting language on the internet; furthermore i doubt it is the most popular. PHP, ASP, Java; all popular and equally efficient languages.
Sure, here's an entire PDF of them
Known issues with 6600
If you KNOW you have issues - DON'T SHIP THE PRODUCT! Its painfully clear that we can't upgrade these phones once they're in the space.
CGI was the first easy way to program interactive web pages, as far as I know (it was a bit before my time), and perl was one of the languages you could use...
While you can use Perl to write CGI, Perl doesn't really have anything to do with CGI coding. You talk alot about CGI, not Perl, I don't see your point? CGI is totally irrelevant to mobile phones...?
Saying that Perl is used to write CGI scripts is like saying Java is used for writing web applets. Yes, you can write applets in Java, but most of the people I know don't.
Al.The Daily ACK - Eclectic posts by yet another hacker
cool site you have BTW
C|N>K
Wonder why it's easier to put a camel through a mobile phone than a snake.
It's just a BloJJ
Sure, it'd be nice if we all could move to the 6600, but I'd like to see if they could fit it in with *existing* hardware - via rom update(sure, some of you might argue that the Series 60 firmware is customized by each vendor, but if you can supposedly fit Perl into the 6600, it shouldnt be a stretch to to put it into existing devices such as the 3650). Yes, I *also* know that the Series 60 firmware is highly customized by some vendors, but if this is going to go into those newer customized models, there's few things that would prevent it from getting into existing hardware.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
How many bytes of mem does it use at runtime? How is it linked?
Sometimes the correct thing to do is to trade off memory and CPU usage for less upfront developer time. Sometimes you need something that'll run small and tight and it doens't matter how much effort (within limits) it takes to get it to run faster and smaller. It depends very heavily on what you're doing and why...
Al.The Daily ACK - Eclectic posts by yet another hacker
since Perl is way too large to even consider running it on anything with less than 64 megs of memory when you factor in the external modules.
How much non-volatile RAM do these phones have anyway?
I disagree, how many of those issues affect real midp2 apps? I never experienced any of those problems, 'cause I never needed those functionalities. The average midp2 developer goes seldom there... Actually my midp are generic. I just tried to install them on Nokias and they just work. This is my experience anyway, I suppose some midp2 apps out there use those functionalities...
Perl is probably fine for half arsed system scripts that don't exceed 50 lines or so, but it is a hindrance and an abomination to a professional development environment
Perl can be used by people who are not professional developers--people like "half arsed system" administrators who like to actually do useful things. Non-technical people can do things with Perl, too. Granted, sometimes they make awful mistakes, and on a networked device, that's scary. But tools for the n0n-l33t are a Good Thing, except maybe for some 3(g0)l33t15t5.
Call me old-fashioned, but I like simple things to be simple. I've written about this before, but it seems like java wonks can't write a hello world with out also generating a "HelloWorld" class, and about 500 classes (not lines of code, but classes to go along with it. I'm getting pretty pissed off about it.
Not all problems require an OO solution. The majority of all problems don't require an OO solution. When you're doing something simple, the code should be simple as well. Why invent zillions of java classes and interfaces when 5 or 10 lines of perl code will do? IMO, this is the overkill that people speak of.
And, as we all know, complicated things are just layered simple things, so perl does well for complicated things, too. Very well, in fact.
Perl is interpreted,...
This is a common mispercption about perl. Perl is what mainframers used to call a "compile and go" language (I used to do all my MNF programming as compile and go, but then I had unlimited machine time). Perl is compiled down to an optree, and the the optree is run by the perl runtime (which is essentailly a VM, but the perl folks don't like to call it that). This all happens transparently. An interpeted language is quite a different thing.
I have my doubts. All the language performance comparisions I've read never take into account that perl programs are compiled just before they are run. I'd wager that if this was taken into account, then their performace would be fairly similar. (Of course, anyone can write inefficient programs in any language).
In the course of every project, it will become necessary to shoot the scientists and begin production.
I'm going to stick my neck out and say I like Perl -- so I think this is good news. However, I've always thought of Perl as a text-processing language, and In My Limited Experience, mobile phones can only fit about ten words on the screen. {on the other hand, this could simply lead to phones with bigger screens.}
There's no denying that you can write really ugly code in Perl, but you can also write beautiul code in Perl. I think some of the people who knock Perl are confusing "undisciplined" with "not anal retentive". Perl was always based around the idea of serving the end rather than the means -- it's about where you're at, rather than how you got there. It does not impose a particular style on the programmer. Thus, for any given task, there could be many, many ways to accomplish it in Perl.
They're all right.
Some will be faster than others, some will use fewer resources than others, some will look prettier then others when viewed as source. But if you don't care enough about those things to mention them in the design spec, then they don't matter.
Now, you can have your fancy object-oriented stuff, but in many ways it's overkill. For instance, if you needed to write a programme involving geometry, you could create an Angle object which would have a value assumed to be in radians and properties for its sine, cosine, tangent and representation in degrees; a Distance object which would have properties for its representation in different measuring units; and assigning a value to any property would affect the object and therefore its other properties. It might be beautiful if you like the OO concept, but it's a bit overkill if you just want to find the missing side of a triangle.
And does a "disposable" programme -- one that you will run only a few times before forgetting it forever -- really need to look pretty anyway?
As for PHP, well, it really isn't much different from Perl -- apart from always needing to put brackets around function parameters, the fact that all variables start with a $ sign whether scalar, array or hash and there is no $_. {I happen to love $_. It goes nicely with the concept of an accumulator. If you never did any assembly language, you probably won't know what I'm talking about, though}. That is hardly surprising, because the original PHP was actually written in Perl to be like a kind of subset of Perl.
Also, one of my little niggles -- and I freely admit that this is just my own opinion -- is the inability to get on with any language that uses the plus sign as the string concatenation operator while letting you freely mix string and numberic variables. {*cough* ruby *cough*} I expect "2" + 2 to equal 4, not 22. Hell, if I have to do something to my variables before I can add them, that just nullified the advantage of having freely-mixable scalar types! It might as well be a strict-typed language and barf on an expression such as "2" + 2!
As for Python - well, it's not my cup of tea {I guess you like either Perl or Python} but other people seem to have written some pretty good stuff in it, so I shan't knock it.
Je fume. Tu fumes. Nous fûmes!
All I want my cell todo is make calls. How will perl help me accomplish this goal?
Tom
Someday, I'll have a real sig.
They're currently in the process of porting Quickbasic to MS enabled Phones.
Ruby would probably take a lot less memory space than Perl which would make it a goot fit for these sorts of small devices.
Python will be ported when the phones become more commonplace, common enough that the porting will be done by the open source community itself, not necessarily Nokia.
I guess choosing Perl for porting is a form of popularity whoring - Perl is more popular that Python, let's port that, even when porting Python would be a more sensible move in technical sense (why would any sane person port such a monolithic awk-sed-workalike to a phone is beyond me). And also in the "open source community" sense; Perl seems pretty much to be a fad that is losing the significance it once has. A has-been, if you will.
Equally possible is that they are doing the port because some perl fans inside Nokia are willing to do it. I guess I'll have to bring this up the next time I deal with Nokians...
Save your wrists today - switch to Dvorak
I believe they are doing this the wrong way. Instead of focus on the "top end", they should try to make it easier for "hardcore" developers to start developing on their phone in the first place. The first step would be a good emulator/simulator which run the same binary code as the phone itself (not some specially compiled "java" stuff). At the same time making sure that the most popular development environments are supported would be a good idea. This would mean supporting the *ixes with development tools. Supporting gcc and the similar set of tools would also make it easier to get started developing for Symbian, as it would be possible for developers to get access to complete development environments for the platform. If they do this, perl, python and most other useful stuff will come virtually "by itself". It would also mean that the most popular toolsets would be available even when Nokia decides their "perl porting team" does not serve its core business.
can you imagine lining up the syntactically-significant indentation as your're typing in Python code on your cell phone?
While you can use Perl to write CGI, Perl doesn't really have anything to do with CGI coding. You talk alot about CGI, not Perl, I don't see your point? CGI is totally irrelevant to mobile phones...?
Yes, it is totally irrelevant. This makes the statement referencing CGI in the body of the Slashdot article (to which the grandparent was obviously replying) all the more mistifying.
concrete5: a cms made for marketing, but strong enough for geeks.
Call me old-fashioned, but I like simple things to be simple. I've written about this before, but it seems like java wonks can't write a hello world with out also generating a "HelloWorld" class, and about 500 classes (not lines of code, but classes to go along with it. I'm getting pretty pissed off about it.
"public class HWorld{public static void main(String args[]){System.out.println("Hello world");}}"
Happy? There's a little more text, but no more programming is required then the C version. You obviously need at least one class in a java program, just like you have at least one "anonymous" class in any C or C++ class (the set of global variables and functions). If people are making hundreds of classes for a hello world program, then they are shitty programmers. Switching to Perl will just make their code less readable.
autopr0n is like, down and stuff.
You should know better than to repy to an AC.
However let me chime in also, were I work we just released a web based control system that monitors and controls a large remote vessel for the Navy. The system continuously monitors vessel roll, pitch, ballast levels, mooring tensions, intrusion detection, etc.
This vessel is research platform is unattended for long periods of time. If an alarm condition is encountered the system starts a generator fires up a long haul net connection and sends data and images and dispatches alarm e-mails and phone messages.
I think we can use the term "mission critical" for this application. It is written with Perl and uses Apache sitting on top of Linux.
Oh and by the way we got to do this job because of a similar successful system that monitors and provide critical control for a research submersible.
We have about 15k lines of code libraries that are well written, modular and easy to maintain. Perl's facilities promote packaging your design into small self-contained objects and features like built in (and fast) reg exp, symbolic references, tie, fast (near C like) I/O, etc are fantastic tools that speed development.
Perl modules suck, everyone is so damn lazy and won't write their own code anymore and depend on whacky modules located who knows where!
It sucks!
Makes sense to me. I would've thought that something as embedded as a phone would need the smallest possible, but maybe they've advanced a bit while I wasn't looking.
C|N>K
Perl6 will parse and execute code written in a number of other languages and is itself more thoroughly object-oriented (if you want) than anything.
Java is a mess. It runs reliably on 2 platforms and uses bytecode. Perl does real compilation which is more efficient.
"public class HWorld{public static void main(String args[]){System.out.println("Hello world");}}"
.027 seconds
Happy? There's a little more text, but no more programming is required then the C version.
Happy??? What is there to be happy about that? Let's see what you really have there. You have a file that MUST be named HWorld.java. You have an HWorld class. You have the mandatory main function. Then a function call. At the end of the day, it's a whole lot of typing for a "Hello world" program.
In this simple example Perl rocks the socks off of Java.
Let's get a comparison on slow hardware to magnify latencies: celeron 500mhz, 128 megs RAM.
Recent Java (1.4.1_02)
javac compilation of HWorld: 10 seconds
java execution of HWorld: 1 second
size of Hworld.class: 417 bytes
Recent Perl (5.8.2)
perl compilation:
perl compilation & execution: 0.027
size of hworld.pl: 39 bytes
Come again as to what exactly java is better at? It takes more Java to do the same thing in Perl, and no offense, the code you mentioned isn't exactly a joy to read (90% of it is required filler/overhead). Some might call that OVERKILL.
No.
" Erk. Learning Perl is less fun than gouging your eyes out with a spoon. ;)"
-cfmdobbie Java Gaming forums
They've been around for a while now:
The Purring Kitty
DialAnOrgasm Cellphone vibrator
Do a cost benifit analysis. Ruby would need to be so much better than C++, Java and now Perl that it would be worth training people to use it. It's not.
Yes, Java programmers wouldn't want to be inefficient with all that overhead that an IDE imposes.
And to be exact, you usually run Perl under mod_perl, not via CGI. (When using Apache, anyway.)
-- wolverian
Now there'll be 15 different ways to answer my phone?
Relax...
it's Funny...Ha..Ha..
WTF? Over?
I still see only 1 class, not the 500 mentioned by the original poster. I'll grant you the speed differences, but the equivalent in C or C++ still has a mandatory main function, and a function call to output the text (but I guess those languages suck too). The filename requirement strikes me as a good thing, as does the fact that the compiled code is considered a class (an actual data type in Java that can be manipulated dynamically) instead of just an executable file, (which you can only do one thing with: execute it).
Besides which, I'm sure this has a major impact on day to day use of the language. I mean, all those Hello Worlds that you write on a daily basis.
At the end of the day, it's a whole lot of typing for a "Hello world" program.
Yeah, but it's typing you can do with your fucking eyes closed.
I was previously a Perl developer, and I've since switched to doing Java for work (market forces), but I still prefer Perl by far.
But this whole "extra typing" argument is bullshit. Who fucking cares? If you don't want to type it, copy and paste it. Also, I usually put a "sub main {" at the top of my perl programs anyway, because otherwise all the main code has to be at the bottom, under any other functions. Does this extra "sub main {" bother me? I type it every time! But it's mindless typing. Who really fucking cares?
Also, since most people write Java in an IDE, that stock code isn't even typed usually, it's put there automatically.
So, fuck, find some new reasons to hate Java already. That one is a total red herring.
These statistics might mean something if you spent your career writing "Hello World" programs.
If you want to write a complex multi-user, multi-tier application with database interaction, you wouldn't want to do that in Perl.
Just what cell phones need, more slow-moving wicker programming languages...
But it would seem like JAVA would be more ideal for cell phones for basic programs, however I am sure we'll see a 1001 nokia address orgainizing scripts here soon.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Not all problems require an OO solution.
Blasphemer! Burn him! Burn him! Send him to hell!
Hurry, before he says that a database might not be the solution to everything either!
No matter how many of my rights are taken away, somehow I still don't feel safe. -Frigid Monkey
Lessee ...
"public class HWorld{public static void main(String args[]){System.out.println("Hello world");}}"
versus
print "Hello world\n";
Which one is simpler, more easily understood, less likely to break?
"A Class to Bind Them All" does not a good programming language make. Simple tasks become hard, and hard tasks require massive time/investment for moderate return. Then entire premise of this needs to be seriously examined.
IMHO Java is a solution in search of a problem, not well suited to anything in particular. Introducing complexity and verbosity for complexity and verbosities sake is not an advantage.
I know the idea has been tossed around before, and people have said that the platform is just too small... but now PalmOS has better devices, tons more memory, and the ability to work with files, and it pretty much always _has_ had the abiliy to load libraries. Even the internet-connection stuff is downright unified these days. I would think that it would be possible to port a considerable subset of Perl, by this point, that would be able to do most of the things one would want to do on a handheld anyway.
Perl is compiled down to an optree, and the the optree is run by the perl runtime (which is essentailly a VM, but the perl folks don't like to call it that). This all happens transparently. An interpeted language is quite a different thing.
So just like Java, except for the compiling to bytecodes is done at runtime. I don't know how you concieve of interpreted languages, but even some of the old-style BASICs did something similar. Translating each line from text every time it's run isn't done in modern non-toy interpreters, with the exception of very high level languages.
All the language performance comparisions I've read never take into account that perl programs are compiled just before they are run.
What? Knowing how Perl works doesn't change its speed at all. `time' really doesn't care.
I have tried to confirm this posting at the news section of NOKIA. As far as I could see there is no official news about Perl on NOKIAs phones. Perhaps we have to wait for the recently announced mobile Linux cell phones.
Extra typing is just the start of it. I also listed a few other reasons. I'll take the Pepsi taste test challenge any day of the week when given Perl.
Java zealots who sit there and say that Java code is "pertier" than Perl are discussing something that is a matter of opinion and I'm just stating the Java Emporer has no clothes.
Java easily allows bad/ugly code as well. You can inherit classes ad nauseum to the point of who knows what the fuck a method might be doing when it's called.
Perl doesn't need an IDE to put "that stock code" their automatically. With a minimal amount of code one can do the required work correctly. Don't know what the fuck $, @, %, m///, s///, tr///, ~, ->, [], {}, or _ mean. Too bad is what I say. Learn the language. It's the equivalent of saying Java is ugly because of all the static, public, private, protected, void, int, string, class nonsense.
Now if you have to ask my wrists which one they want to type all day without an IDE? It's Perl, hands down (no pun intended).
No.
Not true with regards to the multi-user, database app. But it's definitely true you don't want those startup times for a cell phone. Maybe you could "hide it", waiting for the phone to get a signal when it started. Perl compile time runs circles around Java compile time. Perl and Java probably tie for second (behind C) at runtime.
No.
The symbian mafia are delighted.
Aww, c'mon. Don't you reconize hyperbole when you see it? The main point is that an OO solution isn't always the correct solution to a problem. In fact, I'd maintain that an OO solution usually isn't the solution to most problems. Don't use OO when it's not called for. Ooops, Java won't let you do that.
OK, here's a more real-world example: Say you use CVS and the (:pserver:) repository has been moved to another machine, and the old CVS server is no more. You already have a lot of CVS stuff checked out into your local directory. You don't want to have to pull all your source again. An easy solution is to simply re-write all the CVS/Root files in your source trees with the CVSROOT of the new server.
Write a program that will descend into a specified directory and re-write any CVS/Root files that it finds with the current value of the CVSROOT environment variable. There may be hundreds of these files.
I can do (and have done) this with 10 lines of perl code. How many would it take in Java?
In the course of every project, it will become necessary to shoot the scientists and begin production.
Given that I already have, why wouldn't I?
In the course of every project, it will become necessary to shoot the scientists and begin production.
Interpreted languages are intepreted one line at a time, just before the line is run.
In the course of every project, it will become necessary to shoot the scientists and begin production.
So your argument is basically that since Java isn't the right tool for every possible job it must be useless?
It's true that there are many situations where full OOP is too much. Eg small scripts. So you don't use Java for small scripts.
There are also situations were a language which has a lot of built in checks and helps you structure your code is helpful. Then use such a language.
The best implementation I've ever seen of QuickSort is in Haskell. (And I bet you can do the same in any functional language.) It's two lines and extremely easy to understand. It's in fact easier than any textual explaination I've read. That doesn't mean imperative languages are complete crap and useless.
The key distinguishing factor for an interpreter is that you can feed it unprocessed source code, and have it executed, as opposed to generating an executable in advance. How that source code is treated in order to execute the program is secondary.
I am a Java programmer by trade and you are pissing me off. Do you hear!. BTW you are also tweaking my interest because I have this growing uncertainty that there must be a better way. Thanks.
TIBET(tm) 2.0 is being released with the moral equivalent of CPAN compressed into around 200k of gzipped ECMAScript. It's pure ECMAScript -- and includs client-side tag expansion to active client pages, as well as support for web services, Jabber, etc.
Seastead this.
Now if you're going to implement this on a cellular handset, then either it's going to have stacks of RAM, or you;re going to have to drop large chunks out of Perl to fit it in.
Also, as a Perl programmer of +3 years now, the main attraction I have to the language is the heap of modules available on CPAN. Will I be able to install these modules on my Nokia ? If not, then there's little attraction for me here.
Don't get me wrong - I love Perl, and I'd like to be able to easily code up stuff for my cellular handset, but I'd sooner work in a clean standard inplementation of Java or
So your argument is basically that since Java isn't the right tool for every possible job it must be useless?
No, if you look back at the thread, it is all a response to some moron that more or less argues that Java is better than Perl in pretty much all circumstances (including an assertion that Java is faster). His argument is thus rather the fact that Perl is not slower, and may be a better language at least for small apps.
Trust the Computer. The Computer is your friend.
import java.io.*; //first command line arg is initial folder //second command line arg is the new root
public class Cvsr{
public static void main(String args[]){
File f = new File(args[0]);
recurse(f,args[1]);}
static void recurse(File f, String root){
if(f == null){return;}
for(int i = 0; i < f.listFiles().length; i++){
if(f.getName().equals("CVS")){
OutputStreamWriter os = new OutputStreamWriter(new FileOutputStream(f.getAbsolutePath() + "/Root"));
try{
os.write(root);
os.close(); }
catch(Exception e){
System.out.println("error writing file " + f.getName() + "/Root"); } }
else{recurse(f,root);}}}}
//wow. 16 whole lines. 3 from error checking, and 3 from the original import and class defs. Yes, java requires you to deal with errors. The horror. And I don't really see how putting everything inside one class is any different from having a bunch of variables at global scope. It's hardly 'forced object orientation'
autopr0n is like, down and stuff.
Which one is simpler, more easily understood, less likely to break?
You need to port your code to a system that doesn't have a console, so you have to rewrite the entire I/O system. In Java, Ada, C or C++, you can search for class/package/header name for every case that uses I/O. How do you do that with "print "Hello, world\n";"?
Furthermore, in any non-trivial program, you're going to have to add some sort of function around your code that accepts args. That reduces the relative simplicity of your program immensely.
Having Perl on a mobile phone would be great, because I already know Perl and would like to be able to write scripts. It would also be handy to have a Wiki that runs on the phone (which is really a PDA) and can be used to take notes, syncing to a real web-based Wiki when needed. Perl makes many things easier than Java, at least for me, but it's surely better to have more options rather than fewer... J2ME is clearly a big success on mobile phones, spawning a market for Java app downloads, but scripting is useful too and J2ME is not a scripting tool.
Agreed. All languages are interpreted, especially compiled languages. A CPU is nothing but a machine code intepreter. I think too many people have forgotten that.
In the course of every project, it will become necessary to shoot the scientists and begin production.
It's a no brainer - under 500K footprint for the Mozilla Spidermonkey (Javascript) code.
Perl is way too large to be considered for a phone.
Lua is another alternative ~ 200K in size.
guess it answers this question (Does Perl Have a Future?) posed by Brian d foy.
perl has some neat text processing capabilities (munging), regex, unicode and CPAN. I wonder if you can gain access to CPAN from your phone?
peterrenshaw ~ Another Scrappy Startup
You have a file that MUST be named HWorld.java.
And that's a bad thing? Why would you want to name the file a name unrelated to its contents? In a package/unit/class based programming language, it's entirely reasonable to require that you name file based on the package name, and makes it portable to systems without long filenames, since you can rename the files (compilers for such systems invariably include a name hash or a name mapping table) without editing the files.
At the end of the day, it's a whole lot of typing for a "Hello world" program.
Perl is a several megabyte binary. Echo is a few kilobytes. That's a whole lot of binary for a "Hello world" program. If you write "Hello world" programs all day, both echo and awk are superior to Perl.
(90% of it is required filler/overhead).
Yes, in a "Hello world" program. That's why useful language comparisons don't use "Hello world" programs.
And that's a bad thing? Why would you want to name the file a name unrelated to its contents?
Sometimes it is a bad thing. Let the programmer decide how the executable should look, without requiring that they make a class just like it. Better yet, let the SysAdmin decide how the program should look. Ever try to execute a symlink of a java.class? Oops! Doesn't work, does it? Java is looking for the wrong class for some reason, even though it's right there.
And please, Perl requires "module/object/class" files to be the same as the "module/object/class" name. It's not a strange concept to perl coders, just an unnecessary enforcement for small programs or executables. It's yet something else Perl gets right for both cases.
Perl is a several megabyte binary. Echo is a few kilobytes.
You're embarassing yourself. echo is not a programming language. Perl is under a megabyte, even less stripped. Java is in the low 20k. Neither of which is an indication of "your" program's final executable file size. However, if we were to code a shell script using either, perl is right on the razor edge of executable size with the echo/awk shell script. Java is still not even close. Let's add something program'ish to the example like a for loop of a hello world. Java add's no less that 60 bytes to the size of the executable object. Perl adds 33 bytes (and that's raw source code).
Java lives up to none of it's early promise (low object/execute size, seemless portability, robust downloadable applications, java network computers, the end of Microsoft and world hunger). Java has been a further burden for everything else, and festering pool of pundits who believe their code is prettier, faster, smaller, more robust, easier to understand, and just plain more correct because it's OO. People who know, aren't swayed by the marketing and head nodding of Java, and are already using real solutions. You found one of them.
No.
Don't get me wrong, it's a nice phone. But, really the only item that needs to be un-deletable would be "reset".
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
This thread is rapidly leaving the world of reason. :-)
Of course Java is bad at Hello World - it's not designed for such duties. Then again, if your objective is to print "Hello World" on stdout at max speed and convenience, perl is overkill also
% echo "Hello World"
As I can see it the original post claimed that the possible benefits of Perl would not be very useful on a mobile phone. Developing for mobile phones is still a rather cumbersome process compared to writing small scripts on a PC. The main reason being that you don't code and execute the program on the same platform. (It's not fun coding with a keyboard which has 9 keys and a 2" screen. Although Symbian phones are usually high end.)
Furthermore the programs you tend to make on a mobile phone are not like small scripts at which eg Perl excel. And you don't have a large amount of text to process in normal mobile phone.
I just fail to see where Perl's good areas would actually give you a benefit on a mobile phone.
Both Scheme and Forth are powerful languages in small packages. Forth maps well onto embedded hardware, and runs quite efficiently. Both languages are usually, but not always, implemented with an interpreter. Compilation to machine code is sometimes done with both. Both languages are quite expressive, so an application's source can be kept small.
I'm not against Perl by any means. It's one of my favorite languages, and I use it for projects of many sizes. It's definitely not dead. I'd like to have it on my phone. I'm just not sure how many people will use it.
Ok, so Perl is now another language in which you can use to program a cell phone. I'm not knocking Perl but... now what?
- My calls still get cut off.
- "Can you here me now?" is still the most widely spoken phrase among all cell phone conversations.
It seems people's standards of what is considered an acceptable, workable device is slowly deteriorating since musical ring tones, solitaire and programming languages seem to excite consumers of the 21st century more than getting something to function properly.
What was wrong with OPL? It was dropped in SymbianOS 6 if I remember correctly, but it seemed like an easy language to do simple applications. All Psion applications were developed in OPL if I am not mistaken, so I would prefer support for that again rather than perl.
I'm about to change phones & It makes sense to go for one that I can develop Java applets on. If Nokia is so useless, what is the best phone to get for development? (preferably one that works as a phone as well).
There may have been an Ask Slashdot about this recently but I can't find it.
Just noticed on the Register.co.uk that Nokia is apparently evaluating both Perl and PHP for use in Nokia mobile phones, link: http://www.theregister.co.uk/content/64/35040.html