GP might be incorrect in stating that the author is parroting Anthropic's marketing, but the author certainly does not go out of his way to specify that these are only Anthropic's claims. It is actually a bit ironic as the article linked[0] from the quoted part (by another author) uses the correct phrasing when dealing with such claims:

> Anthropic, the artificial intelligence company that recently fought the Pentagon over the use of its technology, has built a new A.I. model that it claims is too powerful to be released to the public.

[0] https://archive.ph/GC6WP#selection-4713.0-4713.200

Apple's "It just works." sometimes gets in the way by obscuring details. Simple example, Airdrop. You share a file, select the person, and it gets stuck displaying sending on the bubble. What is happening? No one knows, because it should "just work". But when it doesn't, you usually have literally no recourse and you are told to wipe your device and try again. From GP's example, the synchronisation. I don't know about iMessage, but synchronising Photos is a nightmare because there is no button to force a sync. You have to connect your phone to power and pray that it will sync. If it doesn't, you have no way to force it. Same thing with AirPods firmware, how do you update it? You don't, it should happen automagically. It didn't? Sucks to suck. You hopefully get the idea by this point :)

2. Yes, easy filterings usually don't need to be broken down/named, but it really depends. At the very least, if the culture is to name intermediary values, you might accidentally get useful information from the variable names even if people weren't diligently writing explanatory why comments.

3. This isn't Kotlin related, it is just that if you do not have a language/codebase with branded types (or some type system property I don't know the name of), the type system might only infer the base primitives of the result, ending up with stuff like the type I mentioned.

For me, the problems with chaining from the point of mostly maintaining existing software are:

1. Harder to impossible to reason about.

As the author alludes to, 1-2 chains are fine, but it starts getting impossible when you get into a territory where you have a longer chain which has a deeper call tree. This happens over time where you start with a smaller chain and people start lengthening it, adding helper functions which grow into large call trees, etc. This makes it so that you have sort of a blackbox pipeline that is, at the very least, annoying and time-consuming to inspect.

2. Harder to debug

Author tries to mention this but he seems to fail/stop short of pointing out what is wrong with the example he provides. For me, I work with Kotlin. In Kotlin, you cannot put a breakpoint in the middle of the chain! As far as I know, you can only put a breakpoint inside of the chained function calls and do step-into/step-over and such, but you cannot put a breakpoint in-between chain function calls. This means that debugger is basically useless if your codebase looks as described in my previous point. The solution is to write a bit more code at the start, naming each variable. This makes it much easier to debug the code/logic (because you can put a breakpoint on the specific variable/step you are interested in) and, more importantly, to understand, because you explain the steps with the variable names and optionally also with comments.

3. Related problem - return chaining

Another issue I have in codebases I inherited is what I would describe as return chaining. It is what happens when you have code which returns a function call and the called function does the same thing and so on and so on. Minimalistic example:

  foo() {
     return x
        .map()
  }


  baz() {
     return foo()
        .map()
  }

  fbaz() {
      return baz()
        .map()
  }

  foo() {
     const helpfulName = x.map()
     
     return helpfulName
  }


  baz() {
     const anotherHelpfulName = foo.map()
     
     return anotherHelpfulName
  }

  fbaz() {
      const superHelpfulName = baz.map()
      
      return superHelpfulName
  }

The journalists credibility is doing quite a bit of lifting here as we have to trust that they put in the effort. One such example is the molesting accusations which the reporters say they heavily looked into and were not able to find any corroborating evidence.

> You never actually get a real picture of the facts. Yes, it is a fundamental impossibility in lots of cases. That's why we trust the reporters that they did as good a job as they could to present all pertinent information.

> That title is an editorial ... I do not perceive it to be editorialised. It states an arguably real possibility that Altman may/does have lots of real power. I am guessing that you believe that the "can he be trusted" is an editorialisation that points towards him being untrustworthy. If that is the case, I think those would be your biases knowing that he is probably not trustworthy. I see it just as an objective question.

Imagine a different situation: you have local elections into your small town. There is a new mayor candidate and during the next term, there will be some money to be given to residents for renovations and such, but not enough for everyone. You don't know this candidate. A local reporter, whom you trust, writes an article "New mayor candidate favoured in polls - will he be fair with the renovation money?". It is a piece trying to shed light on who this candidate is as a person, what was his life before moving into your village, etc. so that voters like you can decide whether to give him your vote. It is not editorialised, as it does not point either way.

Not the author, but PLA has a glass transition temperature of around 60 degrees, which in layman's terms is when it starts to melt. However, depending on the quality of the printing process, layers start separating/the print is pliable significantly lower, at around 35-40 degrees. This means that in countries where you get 30+ degree summers, PLA is not really suitable for anything which experiences any kind of stress. I would hazard a guess that the standing laptop can cause quite a bit of stress when the train starts/stops.

Apple has removed support for font rendering methods which make text on non-integer scaled screens look sharper. As a result, if you want to use your screen without blurry text, you have to use 1080p (1x), 4k (2x 1080p), 5k (2x 1440p) or 6k screens (or any other screens where integer scaling looks ok).

To see the difference, try connecting a Windows/Linux machine to your monitor and comparing how text looks compared to the same screen with a MacOS device.

[0] https://www.pcgamer.com/modders-get-intels-coffee-lake-cpus-....

[0] https://www.youtube.com/watch?v=M6jBXI6CR9s