Of course all of this was labelled as research and wasn't taken too serious by the business units until it was too late. A pity, because a lot of the stuff that NRC produced wasn't bad. There was a thing called friendview that existed before foursquare was a thing where you could share your location on a map with friends. The team that did that also did another app that allowed people to share photos. Instagram was not a thing yet back then. Another team was doing a thing called sports tracker. These were tiny teams doing amazing things. Sports tracker basically was allowed to take their software outside of Nokia and create a company around it. Nokia shipped a lot of stuff like this via Nokia Betalabs. A lot of that stuff came from teams in Nokia Research Center.
Unfortunely, the project did not have a real business use case. People believed that peer-to-peer is a thing (XMPP, BitTorrent, IRC) and this would drive mobile-to-mobile interactions. Unfortunately, it turned out not to be true.
Later me and my friend ported Python to Series 60 with our own rewrite, as Nokia’s official port had many issues. Unfortunately by this time Series 60 was already losing market share for iPhone and Android. Furthermore we found that because of module import delay, Python will never be a good run-time for mobile applications, unless you do some sort of a binary dump/prewarmed up interpreter.
If you really care about the startup time, you could pre-compile it. Nuitka and Cython could do this with different limitations.
The problem you mention can be significant because some design patterns in Python encourages this. Eg function arg with a default that’s expensive. Unfortunately this whole speeds up repeatedly calling the func, the cost is paid at first import.
About a decade ago I worked on a project for a South Korean cellphone vendor whose name I'll not cite for somewhat obvious reasons. The build system was similar to what you describe: a poor port of unix tools for windows that required windows xp which was already obsolete in 2011. I asked why don't we use linux since the build was probably more adequate for that environment. The answer was something like "because they spent a lot of money and time to make this port so we can use windows." Korea was mostly a windows-only country at the time. They had to change because of android, but for them it seemed already too little too late.
LineageOS said it was out of date, but it worked for me on Ubuntu 22.04.
I vaguely remember in the very late days there might have been some simplifications, but the train had gone already at that time.
You could always tell who was using it in the office because their laptop fans would be at full blast.
My understanding, as someone who was peripherally in contact with Symbian in 2007-2011, is that the multitasking concepts were based on the Actor model [1]. This is indeed a kind of callback-based cooperative multi-tasking, but it fits very well in Symbian's tasks-as-C++-objects concept.
C/C++ strings are a nightmare from a memory-management and reliability perspective, so I can't blame them for doing it differently. However their tooling was indeed not up to the challenge.
I remember that concatenating a string to print a log message required several lines of code. (And I mean something simple like: `print("Request took", length, "seconds")`.)
It may have been OK or maybe an absolute necessity for EPOC, when it was running on PSION PDAs with 64-128k of RAM. It was also probably even manageable, because the apps must have been of a smaller code base.
The 3650 was the first S60 phone, IIRC. It came with 4MB of RAM. A decade or so earlier one could run Linux with a GUI on a similar machine and without the insane memory management tricks. And I'd say that the 3650 was still OK, nobody knew whether it would be problematic to develop software for this OS or whether even if people would really use apps. But it was apparent after a few years that Symbian was very constraining and that it would cause serious issues in the future and Nokia did (would) have the time to act and maintain a healthy market share. It would have been risky, of course, but inaction proved fatal.
I’ve continued being a server-side programmer though :)
There was a "gmake" and "cmake", one of them written in Perl and one written in shell, which wrapped make on a Windows port of the GNU toolchain, and the makefiles were generated (as far as I can tell) using Make as a scripting language. Hard-coded drive letters, company-internal packaging systems, Cygwin mount points, multiple terminal windows, etc. The build system dated back a couple decades and was ported from Unix.
If you tracked down the actual rules that Make executed, you'd find something like this:
$(TARGET_1): $(DEPS_1)
$(RECIPE_1)
I have no idea of the actual history for this software. Few teams used it. I can only imagine that it was slowly modified, over decades, by people who did not understand the system that they were modifying. By this point in history computers were plenty fast and had plenty of memory, so I can only imagine how much of a pain it must have been to work with back in the 1990s. During the short time I was there, I managed to reduce the build time by a factor of about 100x, there were so many easy opportunities for improvement. I heard from someone who still works there that my improvements were removed, which doesn't surprise me at all--after all, I wasn't there to support those improvements.
At some point I realized that I was cleaning up bugs introduced by other members of the team, and I was on the losing side. My direct manager had almost zero knowledge of software engineering, as far as I could tell (only seniority & some domain expertise). Some other people on the team were figuring out how to provide proper support, and a couple others were doing stuff with Node.js.
I painfully remember all the hoops that Symbian went through during those years until the last days of Carbide.
Yet, sometimes I still miss it when comparing with NDK development experience on Android.
I remember my first few years of Android/iOS, There would occasion where the 'old Nokia(Symbian) could do it better'; On Android it was largely limited to battery management(similar screen size), Multitasking and on iOS it was everything from SMS forwarding to bluetooth sharing.
Except for two critically important features: user experience and developer experience. (Actually, the first version iOS/iphones didn't even allow 3rd party apps.)
It was a classic case of market disruption: a product (well, two products) inferior to the dominant, incumbent product in almost every respect gets a few things right while missing the mark on just about everything else. And the funny thing is that we'd bean hearing the term "disruption" for years from managers when they talked about strategy. In just about every meeting. They kept quoting Christensen, saying "we have to be disruptive" and even that didn't prevent the company from being disrupted big time. Now don't ask me how we would have been supposed to "disrupt" as the largest incumbents, the market leaders, but it was obvious that the management was not willing to take the required chances. (Hence they stuck with Symbian, despite what should have been obvious to anyone with a decent knowledge of software development.)
And for that he needed quite a few people to agree and he had to sign an NDA (again, as an employee, not a subcontractor!). Then, of course the whole thing was pretty hard to make work on his machine.
Later on I did some work with the (public) SDK as well. The build system was based on the GNU toolchain. More precisely, a windows port of the GNU toolchain, so it would only work on windows. But even on windows it had a lot of warts (because these tools were build for unix in the first place, so e.g. drive letters and back slashes were problematic). As far as I can remember, a lot of the build tools were written in perl. There was some script to generate makefiles for your project and even that, as far as I can remember had a front end script. (I remember something called MAKMAKE.BAT, but I may be wrong.)
The whole thing was a pretty frustrating experience. And we haven't talked about the libraries, the OS (cooperative multi tasking, everything is a callback) or memory management ('descriptors' that made trivial string operations a pain). No wonder it couldn't keep up with android and ios. Now, to be fair, the OS was based on a core and concepts created in the mid 1990s to allow software development on devices with 64k of memory or something. But even with several megabytes of RAM (so the early 2000s), that programming model was obviously way too constraining.