Open Sourcing a watch face - Almost nobody does it

longtrousers said:

I have read some comments lately about OOP versus conventional functional programming, and I was surprised that OOP is not considered by everyone as the holy grail.

I mean, functional programming is definitely much trendier these days. (Of course functional programming and OOP are not mutually exclusive, but there's a lot more interest in the former). Even when Monkey C first came out, I saw a few comments lamenting the lack of modern features like functional programming and string interpolation.

I've worked with C, C++, Java, C#, Python, Javascript, and Typescript (among others, including bespoke domain-specific functional programming languages), and I have to say that I really enjoy functional programming and other modern features (especially string interpolation), when they're available. For example, it sucks working with Typescript for long stretches, then switching back to Java where:

- string interpolation is not available

- functional programming is available but there's a ton of "ceremony" associated with it

One anti-OOP argument I've seen is that it doesn't actually model the real world. Others will retort that it's not supposed to.

It could also be argued that OOP in unnecessary in many cases: if you look at modern web app development with React, for example, code reuse is accomplished via composition, not inheritance. It's definitely simpler, which is part of the current trend. (And that's a good thing, imo.)

longtrousers said:

Although it is suggested here in this forum multiple times that you can't avoid global variables in certain situations. And you should avoid declaring too many classes because of the overhead that causes. All conflicting with the principles of OOP.

Yeah, well the problem from my POV is that Monkey C gives you a bunch of features like classes and dictionaries which can't even be used without incurring a huge memory cost relative to the available memory on devices. Similarly, application settings consume of a lot memory at run time. On top of that, every string you define for application settings wastes memory at run-time (assuming you load at least one resource), even if those strings are never used in the app itself.

So Monkey C is designed around OOP, but if you actually write proper OOP code, you waste a lot of memory. Similarly, if you use dictionaries for everything, you waste a lot of memory. CIQ provides app settings, but again, if you actually use them, they could take up 25-50% of the memory available for a data field.

So one example is that I have an app which largely revolves around "features" - it's an app which provides the user with a data field whose value is calculated based on a formula they enter. Kinda like Excel for your watch. An example of a "feature" would a metric that's exposed to the user (e.g. Speed) or a function which manipulates data in the formula (e.g. Average() or LapAverage()).

Some of these "features" require data structures which lend themselves very naturally to OOP, like queues. But if I implement a queue using OOP constructs, it consumes a huge amount of memory since objects are expensive in Monkey C. This means that the user gets fewer features, or the maximum complexity of their formula is lower than it could be. When I developed that app, I started out writing "nice" OOP code for everything. Eventually I got rid of almost all the OOP code (except where absolutely necessary, of course) and saved a ton of memory in the process. For example, instead of writing an OOP queue, I just had global functions which passed around simple data structures like arrays. The end result was the same, but the code wasn't nice to look at, use or maintain -- it wouldn't be suitable to be published as a shared library, for example. Def something I wouldn't be interested in sharing, except as an example of how to write memory-efficient code in Monkey C.

So when I say my code is "terrible" or I "cut corners", I don't mean it's because I don't know how to write better code. I mean that it's largely due to the constraints of the CIQ ecosystem and Monkey C. I could write better code but then I'd have to cut features. My apps are niche but one of the reasons some of them are unique is that they have more features on older / low-memory devices then similar apps. (Vivoactive 4 is still being sold and it has the same amount of memory for data fields as the 7 year old Vivoactive HR, so we can't just say "no problem, just drop support for old devices").

In contrast, modern development on the majority of platforms is very wasteful in many ways, but we also have the luxury of writing code that's simpler and easier to maintain.

Also, to be clear, I don't want to invest additional time and effort to make my code suitable for sharing, especially for stuff that I am not actively maintaining.

jim_m_58 said:

I don't open source my apps for a different reason.  I've seen cases when someone grabs an open source app, tweaks a few things and then publishes it as their own.  I don't want to compete against what's mainly my code for users!

The OP and the majority of replies said the same thing in different words. In my case, it's especially true for some of my niche apps which really don't have any competitors in the store.