[peter9477]

they laughed about the playbook failure and how the lead email dev manager convinced everyone to do the application in "python" (?) and it took so much more time to get it done than what was committed. the lead is now promoted to a director (laugh). and they now have huge memory issues due to python taking so much more memory and bb10 might not fit in 1 gb memory.

This sounds totally like sour grapes from non-Python developers who know little about Python except that it was forced on them, and they are experiencing a classic knee- "it sucks!" reaction to something that isn't the thing they personally would have preferred.

I'm sure the PIM took way more time than was committed, but it wasn't because of the choice to do it in Python, though there's really never going to be a way to prove that. Go back in time and use C++ instead and see just how quick the project moves along. I'll laugh with you....

(Note: Python is easily one of the fastest languages for development, in the hands of competent Python programmers. You make a tradeoff with it: slower code for faster development time. They likely choose well there, but still mismanaged the project... I don't doubt that.)

About the memory issue: that's probably exaggerated, since OS 2.1 has way more memory free than 2.0 did, and runs much faster, for all the PIM stuff. There's more to be said on that topic, later.

[peter9477]

C++ and QT aren't runtime environments. Neither is Android (it's more a virtual environment) but I can understand the confusion on that one.

I'd think one would have to define "runtime environment" before making such a claim.

Still, since it hasn't been defined here, I'll simply note that Qt is very much a runtime environment, with substantial overhead compared to vanilla C++ code for all the dynamic capabilities it brings. In fact, in learning Qt over the last two months, I've been repeatedly surprised at all the things it provides, noting how each one is also provided in the Python runtime environment. I see Qt as basically turning C++ into a dynamic language like Python, to the extent possible, though it's still constrained in some ways (and given a performance advantage) by some of the inherently static nature of C++.

Anyone want to try defining that term "runtime environment" now? ;-)

[peter9477]

I don't see why a Python app would be a memory hog. It may be very slow compared to C/C++, but in byte code the app itself should not be that large. Does Python have particularly large libraries? Is its memory management necessarily worse than that of C++?

Python is both slower, and typically a greater user of memory, than C++. Still, throwing around terms like "hog" and "very slow" implies that it's unacceptably worse, which is very rarely the case.

Python is slower than C at doing some of the things you do with C, like parsing text one character at a time, or compressing data. That's why nobody does those things with Python, but instead uses the very extensive collection of Python libraries which do those things in C code, callable from Python. If you tried doing the C work in Python, it runs roughly 10-30 times slower... Wow! That's "very slow" indeed! Fortunately you don't want to do that.

When Python is used in the PIM application, it's being used for all the "backend" work of interfacing with various services over the network (email, LinkedIn, Twitter, Facebook, and many more to come). Those operations are clearly IO-bound, which means limited by the speed of your network data transfer, which is far slower than what Python can handle well.

After the data is transferred, it then stores it in a local database and presumably does things like indexing it for quick searching and such, as well as doing sophisticated analysis of it (the Gist-related stuff) to merge contact information (e.g. LinkedIn and Facebook entries), and other such things. Imagine (if you're a developer, or know anything about programming) writing all that from scratch in C++! The PIM likely wouldn't have been released even now.

As for memory, a bit more on that. Python bytecode is quite compact, and since the Python runtime provides powerful capabilities "for free" (once you've chosen to use it), the code size for your own Python code is pretty much negligible in comparison. It wouldn't be Flash storage space, or RAM usage for the code itself, which is the concern.

Python data memory consumption is generally going to be higher than the "equivalent" C++ code, however, because of various types of overhead. It's a bit of a dangerous comparison to make without knowing more details, however.... The main reason is... where's the memory usage actually coming from? If it's from your email messages, then those are going to be taking roughly the same memory in either language, provided you're storing them internally the same way. This gets us into Unicode, and issues like UTC-16 versus UTF-8 encoding and such. The Python 3.2 runtime which they're using now stores every character in a blob of text in 4 bytes (32 bits). The cost of doing that for ASCII data (i.e. much of the message content, at least from an Anglo-centric point of view) is enormous. Python 3.3, which is in beta testing and due out this fall, does a far better job in that respect, and with the BB10 delay I won't be at all surprised to see them switch to it just for the gains in this area.

Still, relative to the overall system memory usage, I seriously doubt that Python's overhead (aside from the Unicode character size) is their biggest problem. No doubt they faced some issues because of it, spent more time optimizing in that area than they expected or would have liked, and moved on. As I said, OS 2.1 is way lower in RAM usage than 2.0.

[peter9477]

In general Python's an excellent choice for a lot of applications. If it was used it's probably because the PyQT bindings are mature. That said, if they really didn't want to write the UI in QML/Cascades (a very bad sign) they should have used HTML5/JS. You have to dogfood your own APIs!

BTW. I didn't see QNX as a sponsor for Pycon 2012.

A note on the PyQt comment. First of all, they're not using Python for the UI portions of the apps at all, only backend (non-GUI) code. The existing (non-BB10) PIM apps have GUI code written in Flash (Adobe AIR). The BB10 equivalents are a complete rewrite in Cascades using C++ code. The backend is, as far as we know, the Python code in each case. There's no Qt involved in the Python stuff.

Another note on that: PyQt itself has a restrictive (commercially-speaking) GPL license, so a few years back Nokia wrote their own replacement with an LGPL license, called PySide. PySide is what they would have used, had they wanted the UI stuff integrated with the Python code (which they did not). It's what we're using in the BlackBerry-Py project which lets anyone write BB10 and PlayBook apps using Python, with user interfaces done using PySide and, most likely, QML/QtQuick on top of it all.

[peter9477]

In general, python is a POOR choice for a phone application for the same reason Java is a poor choice for the platform layer of your OS. Everything about it happens runtime: late binding, dynamic typing, garbage collection, interpreted code segments.

If you want a core application like email that runs all the time to be lean, fast, and battery sipper, then write in a language that gives you tighter control over memory, performs less dynamic binding and allows for strong compile-time optimizations.

Also, Python is notably less readable by programmers with different coding styles because it is carries a high degree of syntax flexibility -- that is great for rapid development, not team programming.

If performance and memory were your sole concerns, to the exclusion of all other considerations including development time, ease of maintenance, and so forth, then the first two paragraphs would likely be right. This isn't the right place (non-developer forum) for a debate about that.

On the "notably less readable" comment, however, I have to wonder if you've actually used Python much or at all, as if there's one thing that almost everyone agrees on, it's that Python is one of, if not THE, most readable modern programming languages. In fact, it's a constant surprise to most new Python programmers how few variations there are in coding style, to the point where most Python programmers code looks just like the code in the standard library, and like most others' code. And that "high degree of syntax flexibility" part has me completely puzzled, because -- unlike Ruby for example -- Python's syntax is fixed and not subject to the sorts of craziness brought by the C preprocessor macros, or similar constructs in other languages.

Even that jibe about "rapid development" but not "team programming" makes me quite suspicious about your knowledge in this area. Typically rapid development (assuming we're talking at all about "agile" stuff) implies and goes tightly hand in hand with "team" programming. It's all about teamwork, communication, rapid integration and so on.

Python's an exception language for team programming, as has been proven in hundreds of major companies. Just check the list of sponsors for PyCon 2012 (with QNX notably absent this year) and imagine those companies all saddling themselves with an unreadable language which is hard to use in a team environment: https://us.pycon.org/2012/sponsors/

[DenverRalphy]

I'd think one would have to define "runtime environment" before making such a claim.

Still, since it hasn't been defined here, I'll simply note that Qt is very much a runtime environment, with substantial overhead compared to vanilla C++ code for all the dynamic capabilities it brings. In fact, in learning Qt over the last two months, I've been repeatedly surprised at all the things it provides, noting how each one is also provided in the Python runtime environment. I see Qt as basically turning C++ into a dynamic language like Python, to the extent possible, though it's still constrained in some ways (and given a performance advantage) by some of the inherently static nature of C++.

Anyone want to try defining that term "runtime environment" now? ;-)

Would be happy to.

Qt is in no way a runtime environment. Qt is a development framework for building a UI using C++. In a nutshell it provides tools for creating and/or libraries for developers to incorporate into their C++ projects. The code is compiled into machine code to run directly within the OS environment. In this case, the OS itself would more accurately represent the runtime environment (though conventionally it isn't referred to as such).

A runtime environment refers to the virtual environment created to execute code not natively recognizable. ie... Java apps require a JRE (jave runtime environment) or JVM (java virtual machine) to be running. Same applies to Python. A runtime environment consumes additional reasources, and the code is either interpreted, or more recently, compiled at execution time. Resulting in less desirable performance.

While there are uses for a runtime environment, simply choosing to write an app in Python because that's what one developer is familiar with is not one of them.

[VerryBestr]

... A runtime environment refers to the virtual environment created to execute code not natively recognizable. ie... Java apps require a JRE (jave runtime environment) or JVM (java virtual machine) to be running. ...

That is a modern definition, and really seems to have been formalized by the name "Java Runtime Environment." I'm an old computer guy, from back when there was no Java.

I'm sorry I used this term. Please substitute the phrase "runtime system" as defined here:
| Run-time system - Wikipedia, the free encyclopedia

Note that the Wikipedia URL is named "Runtime_environment," while the article itself is entitled "Run-time system." I suppose that indicates that some some name-changing has been going on, and perhaps someone should update Wikipedia's entries to now differentiate the two names.

[peter9477]

While there are uses for a runtime environment, simply choosing to write an app in Python because that's what one developer is familiar with is not one of them.

If development time is very important, then choosing to use a familiar language over an unfamiliar language may be a very reasonable choice in a given situation.

Likewise, if development time is very important, choosing to use a language where there are numerous, free, third-party libraries that solve many interesting problems is also very reasonable.

I think there are lots of reasons for making choices about tools, environments, development methodologies, and so forth. I suspect most of those made by the RIM and QNX people were generally reasonable at the time.

I suspect that the delays actually resulted from an incredibly complex combination of degrees of mismanagement, absorption of acquired companies, infighting, too many bosses, unfamiliar tools and languages, changing requirements, market and media pressures, resource constraints, poor or no architectural designs, arbitrary and changing schedules, bad communications, brain drain, low morale, and a dozen other classic problems related to death march projects.

I'm quite certain that, whatever issues the use of Python may have contributed, it was not the primary cause of any delay. Neither was any other single thing...

[Blackberry_boffin]

I wrote this in reply to another post in analyst blogs.

“This is what shocks me about RIM.For a 20 billion dollar in sales company, did RIM do any kind of technical feasibility study before adopting QNX.Because since the day I have been following this company I assumed that RIM obviously knows what its doing and QNX integration shouldn’t take more than 12-18 months max.Nokia put out windows 7 phone in less than 12 months and those are doing well, considering how far behind windows phone was/ still is. The fact that they are taking 36 months for QNX phone clearly shows no technical feasibility study ever was done.That’s just beyond inexplicable.It’s dumbfounding!!!RIM had a choice to adopt WEBOS, even Windows phone 7.It boggles my mind how they could be so stupid?? I think Prem watsa, one of the savviest investors of our times, would say the same thing since he lost almost half a billion on this company now.”

Mistake RIM has done is infantile, even a child is smarter than this.How can you hinge your entire fate of company on an OS without doing a modicum of feasibility study?? Unfortunately unless u were an insider it would be difficult to know that RIM was acting infantile, a lesson i will keep in mind for my future trades.

PS: All those dimwits calling me a troll please understand that as a trade/analyst my job is to call a spade a spade.Sugarcoating doesn't lead u to trading success.

First, to the OP.
I don't know if you were recording this but this is not a typical report of tidbits gleaned over a beer, and as somebody said you're so generic you're describing all companies. I am not saying its untrue but i have the exact same view of my superiors.

@purijagmohan
As a "trade/analyst" how can you surmise RIM banked on QNX before they had a good look at it? When RIM bought QNX the signs were all there but things were not so bad that they couldn't look at all options will clear heads. Even today QNX still seems a good bet to base a new OS on in today's mobile computing requirements. What you need to accept is RIM is slow (or having issues) in adapting it into a smartphone OS running smooth and feature complete native apps and complete with all SDKs, APIs, NDKs etc. RIM decided to pursue their "Flow" based UI and functionality without popping in and out of apps by way of open/close/open (theirs words not mine) and are you surprised the coding to give this level of fluidity takes time?
"Nokia put out windows 7 phone in less than 12 months and those are doing well" you say. I think there is a lot wrong with this statement and you know it. Nokia put out WP7 HARDWARE in less than 12 months (they decided to go to bed with Microsft) and whether or not they are doing well is another day's bone to gnaw.
I do not know how long Microsoft spent working on WP7 but already its building blocks are absolete as they migrate to Win8 and WP8. That should tell you something about the challenges of building an OS that will also drive third party apps in today's market.
Of course they could have ran with WebOS but HP failed to make that work, bailed and noone has looked in since. You want RIM to follow them? There were good ideas in WebOS (which RIM has picked up) but a failed OS is just that, a failed OS. They could have ran with WP7 but (right now) that is faring worse than BBOS, an OS even RIM has long conceded has done its run and must go. WP8 may yet change all that but that is anybody's guess. Plus running with WP7 would have meant changing the entire RIM business model as they move onto an open source, perhaps less secure pkatform.
Another pointer would be to check how many OEMs are enjoying running with Android? If/when WP8 picks up, its headed the same way.

[bk1022]

If development time is very important, then choosing to use a familiar language over an unfamiliar language may be a very reasonable choice in a given situation.

Likewise, if development time is very important, choosing to use a language where there are numerous, free, third-party libraries that solve many interesting problems is also very reasonable.

I think there are lots of reasons for making choices about tools, environments, development methodologies, and so forth. I suspect most of those made by the RIM and QNX people were generally reasonable at the time.

I suspect that the delays actually resulted from an incredibly complex combination of degrees of mismanagement, absorption of acquired companies, infighting, too many bosses, unfamiliar tools and languages, changing requirements, market and media pressures, resource constraints, poor or no architectural designs, arbitrary and changing schedules, bad communications, brain drain, low morale, and a dozen other classic problems related to death march projects.

I'm quite certain that, whatever issues the use of Python may have contributed, it was not the primary cause of any delay. Neither was any other single thing...

I don't know that Python contributed to delays. I read a prior comment complaining about Python as a choice for an email app. I seconded that complaint on the basis that mobile devices are systems with limited processor, memory and battery resources.

I felt delays were related to porting Java code to C/C++ which should avoided more than poking out your own eyes.

Python certainly makes it easy to code for someone familiar with it. However, it does significant amount of "late" work, which is a fundamentally overriding reason never to use it for critical mobile applications for the foreseeable future because of resource constraints mentioned above. Furthermore, modern CASE tools make Python's championed features redundant. To me Python is just a better PERL (sorry, I know that hurts PyFans.)

Regarding the runtime-environment comments. Yes, you are showing your age We take for granted nowadays that the hardware and OS exist and are not special things that just got assembled by a crew from DEC. QT is very much a framework in any event. It doesn't implement any system libraries, nor does it execute anything.