I used to work for Nokia Research during the mid 2000's. I remember how hard it was to get the source code for this back then as internal employees... One of my colleagues was working on a research prototype that needed tighter integration with the system than what you could achieve with a deployed app. So he needed the source code and the build environment for the OS.
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.
One of my colleagues in Nokia Research Center actually created and maintained the python port to symbian. He was dealing with some crazy stuff. NRC actually ported quite a bit of oss to Symbian. You could actually run a webserver on the device which you could share to the internet with a reverse proxy. So, you could host your own photos from your device or use it as a webcam. Php, apache, mysql were part of this effort if I remember correctly. Another team in the same lab was responsible for porting Webkit to Symbian. This actually shipped when the iphone was nothing but a rumor. Ajax websites running on a smart phone. In 2005 when Ajax was still a new thing. Amazing stuff.
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.
I was working on the mobile web server project. The project was heavily subcontracted to a company in Oulu, Finland, where I worked by the time before starting a career in open source and Python consultancy. Mobile web server was a Series 60 web server, based on Apache, some glue and reverse proxy gateway (written in Java). You could deploy your own “apps” that could be accessed by anyone, running on your mobile phone.
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.
youtube-dl/yt-dlp (Python) is a full second slower than youtubedr (Go) or youtube.com (JS) to download YouTube videos, and I think a lot of that is due to interpreter warmup (though I don't know exactly why). Sadly mpv only supports youtube-dl/yt-dlp for watching videos, and youtubedr doesn't have the vast plugin ecosystem of yt-dlp for non-YouTube websites.
The above mentioned Python’s import delay. This is a notorious behavior in high performance situation (including your cli startup time example). Essentially the import process is IO intensive. This comes up in massive parallel applications as at launch each process is importing the same stuffs. It is briefly mentioned for example in https://docs.nersc.gov/development/languages/python/
If you really care about the startup time, you could pre-compile it. Nuitka and Cython could do this with different limitations.
I've run into the import issue as well, it's especially painful if something imported is doing work using a slow library (e.g. a config module loading a HOCON config using pyhocon a.k.a slowasmolasseshocon)
That will be another slow down happening at import stage. But even if ideally everything you import only does import with not much work, the import overhead mentioned above still exists. But frankly I’m not sure how significant it is on a typical personal computer with SSD, especially when the OS may cache recently used files already.
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.
Confirming that I was able to run a webserver on my Nokia 3650 https://en.wikipedia.org/wiki/Nokia_3650 back in 2004. Those were the days when T-Mobile USA actually gave you a public IP address! It was pretty awesome to be able to download photos from the phone via the web - even if only at GPRS speeds.
> 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).
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.
I would claim that something 50% of the application developers writing code for Nokia (internal or contractors) could not handle strings correctly. It was in theory C++ code, but because compilers were not very good at the time when EPOC32 was developed and memory was pretty limited there were special implementations to work around all the limitations. Programming was not easy, productivity was low, and buggy application code was the norm.
I vaguely remember in the very late days there might have been some simplifications, but the train had gone already at that time.
First it was Visual Studio, second CodeWarrior and then obviously Eclipse (I probably never used the latter, jumped ship a couple of years before the infamous burning platform.) So every 3-5 years they changed the development environment. Can probably also seen as a sign that Symbian development was tedious and not much fun.
> 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).
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.
C++ strings might be problematic, but the solution that EPOC came up with and then Symbian inherited was terribly bad. Symbian didn't really just have a single string type (as I'm sure you remember), but a set of different types for different scenarios. And actually this wasn't only strings, but, IIRC all allocated memory. But for strings it had types like e.g. zero terminated string on heap, zero terminated string on stack, non-zero terminated strings, i.e. ones that had a length (for both locations). The main issue being that you ended up having to remember all these different types, sometimes having to convert between them (APIs/library functions, of course would have different versions accepting different types). Conversion would then end up making the apps slow, as manipulation was hard and require a lot of code, people would end up overrallocating memory, etc. (while the whole idea behind these was efficiency).
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 probably know you, or some of your colleagues. Worked in Mountain View during the late 2000s. I really hated Symbian with a passion, and I was on the Java (and then Qt) side of it. It was embarrassing to try to sell that thing to external developers, but that was part of my job. I was a good soldier though, and ended up writing a few chapters in the worst computer programming book of all time, on how to do JavaME development on Symbian. That does NOT go on my resume.
I worked in Budapest and didn't have connection with the Mountain View site, but I remember some of my direct colleagues talking about it. I think one or maybe two of them did visit it too, so I guess they did work with people from over there.
The build system sounds eerily familiar to one I used at a previous job.
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)
Copy/pasted a hundred times.
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.
> No wonder it couldn't keep up with android and ios.
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.
Symbian did everything better than iOS and most things better than android. At least it could do a lot more than any of these. Symbian had 'push' email (i.e. email that would just arrive, like it does now), whereas at least with iOS you had to check for it, it had MMS (I think neither iOS or Android had it), backrgound apps, tethering, data connection over Bluetooth and in general, BT could be accessed from 3rd party apps for whatever purposes you wanted (this took quite a while for iOS), etc.
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.)
Wow making an employee sign an NDA! How did they realize that the employment contract probably already covered all of the legal angles? Seems like pointless internal gatekeeping and infighting. No wonder the project was crushed by Android.
He was not allowed to share the stuff (and the information) he had even with us. But yep, super crazy. That was the time before if was obvious that you do want to give access to all code being written to all of your developers. (And eventually to put extra effort into making it as painless as possible.)
Maybe I'm remembering wrong but didn't the iPhone not have multitasking for apps for a long time as well. I recall that essentially the OS did something like a snapshot of every app when one switched.
The iPhone always had multitasking. What it didn’t allow was background processing. When selected again, your app would be suspended and allowed to run again or be launched fresh based on memory pressure.
As someone else said Symbian also was capable of multitasking, it was the frameworks that did not allow is. Can someone explain the practical difference for someone programming an app between the iphone and symbian limitations?
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.