mpartel

You're right, assuming the module is not too large.

There's another point in favor of instance variables: it gives you the flexibility of multiple values in different parts of your code. As codebases grow, the danger of two unrelated places wanting different values for your global also grows.

Say a physics simulation has a global for gravity. This precludes, or at least unnecessarily complicates, the same process from having two separate simulations with different gravities (perhaps in different threads). This is especially bad in library code.

What if you, one day, want multiple worlds for some reason?

I'm developing a game in Unity, and the programming culture around it encourages globals and singletons to an unhealthy degree. I pushed back against them heavily in our project. As a result, it was very easy to add a previously unplanned split-screen mode one day, thanks to the codebase (e.g. the UI and input modules) not assuming that there's only ever one local player.

Mutable instance variables are much less bad because their scope is much more limited: you can much more easily scan all the code that mutates them and check that invariants are upheld etc.

Global mutable variables are also awful for multithreading. Thread-locals help, but even they breaks horribly as soon as you use something like a thread pool.

The only (relatively minor) downsides I can see are:

(A) it makes the code "singleton" by default: you can't instantiate two objects of the same class with two different values for the global argument

(B) unless the global argument is declared in the same class, it slightly obfuscates the fact that a class depends on the argument (compared to all dependencies being constructor parameters)

(C) it makes testing, especially multithreaded testing, more awkward and error-prone: tests have to set and reset global variables

It's easy enough to refactor (A) where needed, as long as you have control of the code, and (C) can be worked around with good enough test helpers.

I think one can reasonably argue both for and against the convenience outweighing these downsides.

Without an IDE, discoverability is not great even in implicitless code. In `x.y.z()`, you don't need to import the type of `y`, much less the method `z`. And an IDE's "go to definition" works fine on extension methods.

IMO the greater discoverability problem is knowing and remembering what to import in the first place.

Still, even with an IDE, extension methods do add complexity and should only be considered when they'd be called very frequently. In my current (Unity/C#) codebase, the ratio of static helper methods to extension methods is probably around 10:1 or more, and that seems alright.

Although it sounds very controversial, it might actually be good if libraries could by default add their implicits to the prelude. SBT (which is horrible in many other ways) lets its plugins do something similar, and that seems to be ok.

In your example, not really, but in general, assuming the implicit is in scope most of the time, `x.method` is much more discoverable through autocomplete than `method(x)`.

Incidentally, the fact that Haskell's function calls look like `f x` instead of `x.f` probably makes building a pleasant Haskell IDE quite difficult.

For others that didn't notice this new and somewhat less expensive version come out, here's the HN thread from 2 months ago: https://news.ycombinator.com/item?id=17124593

The truth does not care but human opinions tend to be biased towards extremes.

I found "The list of reference capabilities" at https://tutorial.ponylang.org/capabilities/reference-capabil... especially interesting to compare with Rust's borrow checker.

For the remote third party case, the option to unlock should be isolated from the OS so that it needs physical access (boot to bios/recovery mode). AIUI that's how it's typically implemented in Androids and in Secure Boot.

The point about attackers with physical access is fair, though significantly mitigated on Androids (and Chromebooks I think) by a warning (of varying severity) that the OS has been modified. On my Nexus 5, it's a subtle "unlocked" icon, on my Moto G it's an unmissable red triangle on white background with "warranty void" and other scary words.

It's still vulnerable to the user getting a prebooted device and only seeing the warning on next boot, so not perfect, but also not the only imaginable defense. One could e.g. move initial authentication to the locked down "bios" phase so either (a) the warning is visible there and/or (b) the OS isn't replaceable in the first place without authentication.

And we should bear in mind that a malicious repair tech can probably convince a fair portion of the population to give away their password :/

That's fair, and those numbers for rooting are a bit higher than I expected. There's the caveat that rooting and complete OS replacement are somewhat different topics, but those stats are still relevant.

So clearly there's a significant demand (some of which I'm inclined to believe is very legitimate), and clearly there are significant dangers.

I guess in the end it comes down to the eternal debate of freedom vs safety. I find it very hard to side with the stance of protecting people from their own stupidity, beyond giving stern warnings. It feels sort of like giving up on cultural progress in humanity :/

And I think we could still do much more to mitigate this attack vector (Big flashy red lights with "probably a bad idea" in all-caps? Adding more fine-grained permissions so root is needed less?) before ceding yet more control to powerful organizations who are already, somehow, in a position to tax 30% of all software and IAP sales on most devices and reject apps that don't align with their interests.

If a significant number of Android security breaches indeed happen through misleading a user into unlocking their bootloader, that would be a convincing statistic to me.

But I'm under the impression that that is exceedingly rare and that Android has many way more pressing security concerns (e.g. the lack of driver security updates to even slightly old devices).

Bootloader lockdown was practically unheard of for the PC/laptop form factor before Microsoft started doing it for ARM laptops. And and it's not even really standard for phones. Plenty of Android phones have unlockable bootloaders (see LineageOS).

I don't think whether one is more evil than Apple/iOS in this regard is a good benchmark.

OK, let me be more accurate: "user-openable" in the sense that the user is free to choose to trust any OS vendor they want. What's the unmitigatable harm?

If I knew that to be the end-game and if I knew it to be an informed choice on the part of consumers, yes, I'd be OK with that.

My two reservations:

1. I think such a lockdown is a kind of hidden anti-competitive "dark pattern" that benefits the seller much more than it benefits the consumer by significantly lowering the the reuse/resale value of the device. One could argue it makes the device cheaper to begin with, but I have serious doubts about that. The anti-competitive effect seems more likely to increase the price instead. Hindering reuse also implies an environmental impact, though I'm not sure how significant that is.

2. If lockdown becomes the norm for >99% of devices/users and even we tech people start to accept it the way of things, some sufficiently bribed lawmakers will no doubt be inclined to make unsurveiled general purpose computing illegal because "security" and "copyright" and "pro-business" etc. Yes, it's a "slipper slope" argument, but when it comes to social norms, I think that's a valid form of argument.

That's why I'm entirely OK with making it scary and a little difficult.

And it's not just IT professionals, but also their friends and family, especially those that can't afford to or don't want to get a new device that often. I think this is a pretty significant set of people.

I admit I may be ignorant, but could you spell out the security benefits of going from "locked down but user-openable" to "not user-openable"?

(edit: specifically benefits that couldn't be effectively addressed by making it a little difficult and scary to open that lockdown?)

I don't see the tradeoff honestly. Sure, make it a little difficult, show a big red scary warning, perhaps even require the use of a screwdriver to discourage "casual" users from being misled into compromising their machine's security.

But ultimately true ownership, recyclability/reusability (Linux on aging hardware..), and hardware-independent OS competition are norms with significant benefits that we shouldn't give up lightly.

Like iOS yes, and some, but not all, Android manufacturers/phones.

"Others do it too" is not a very good justification in my mind.

Another recent example: lockdown of ARM-based Windows machines, preventing the installation of other operating systems.

I realized I glossed over the fact that this would put other AWS/GAE customers's money at risk too. This complicates matters somewhat, and some (I believe a negligible number of) customers might switch to an unblocked competitor.

Personally this weakens my view a little, but is not enough to change it substantially.

Amazon and Google are certainly within their rights to refuse this. Allowing domain fronting is likely to put quite a lot of their money at risk, so this outcome is unsurprising, but it's still the less ethical one.

This might be the only possible outcome given a corporation's legal responsibilities to its shareholders etc, I don't know all that well enough, but I think it's still justified to lower my opinion of Google and Amazon because of this.

Could you elaborate? Setting us back by a decade seems like a pretty bold claim. And I say this as someone that, on balance, despises the Microsoft of the past (for monopolistic behaviour) and present (for spyware and normalizing hardware lockdown).

Stealing from the (relatively speaking) super rich can be, in some circumstances, according to a sufficiently utilitarian moral framework. One could argue that's what progressive taxes are all about.

I admit it's hard for me to quantify the damage Microsoft's business practices have caused (any helpful links/sources?), but it's extremely difficult to imagine it being worse than not saving millions of lives.

And a monopolized OS market has probably cost zero lives.

I'd let corporations get away with way worse if the profits were always used like this.

I didn't believe you would, but I fear it's a likely outcome if all that 99% of people ever use is a locked down system. Then misguided (or bribed) lawmakers will almost certainly start getting ideas about banning unlimited computers because "they're only used by hackers and pirates" or "because security" or something.

Curated stores are fine and can indeed improve quality, but it'll be a tremendously sad day when they'll be mandated by law.

Adding a 30% tax and central control on all software just because we believe users can't be taught to not install random crap is a very bleak outlook indeed. Freedom is sometimes messy, but almost always worth it.

C does not have particularly strict typing

LineageOS runs fine without Play Services. It's actually the default mode. It just limits your app choices. My needs are simple so I don't really mind, and I appreciate the improved battery life and speed.

It turns out many apps from the Play Store don't actually have a hard dependency on Play Services. Example: Slack works, except for notifications and (IIRC) receiving calls, which is good enough if you don't need to be reachable all the time.

I don't think so. They've released their internal guidelines here: https://opensource.google.com/docs/iarc/

In this case, the person seems to have opted for the easier "go/releasing" route where Google retains the copyright. But that doesn't seem to strictly mandate using GitHub either.