The cruelty is the point. It's consistent with the rest of their policy decisions.

God Bless Murica. They need it.

That is my current approach as well. A steamdeck/switch/none + FW13 while traveling.

While there are issues with Window's WDM (badly writen drivers abound), it really should be looked as a model.

_but_ that would require a stable ABI. Which is specifically called out as not desired here https://www.kernel.org/doc/html/next/process/stable-api-nons...

There are valid concerns, but the analysis doesn't lay out the issues with the current design either making it a one sided review.

Could you tell more about the WDM advantages ?

I don't disagree with the point, but I question if that person is an aviation analyst, considering commercial airframes will go up to 30 years. As others in this thread have mentioned, it's about maintenance.

Except maintenance of software looks more like continuous architectural review and operation of an electrical grid. Calling it maintenance is a little narrow.

That is general take as well. A lot of small apps/simulators are in python. Ops scripts tend to be python. Java for the core/data. Refactoring/tooling is easier in Java when you are dealing with a 100k codebase imo. Typescript always.

Seen plenty of coding horrors in both ecosystems...

Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python. Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.

That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like

  class IWantToBeABean:
    def init(self, arg1: int, arg2: str, arg4: str) -> None:
      self._field1: int = arg1
      self._field2: str = arg2
      self._field3: str = arg3

    def get_field1(self) -> int:
      return self._field1

    def set_field1(self, value: int) -> None:
      self._field1 = value
    
    def get_field2(self) -> str:
      return self._field2

    def set_field2(self, value: str) -> None:
      self._field2 = value

    def get_field3(self) -> str:
      return self._field3

    def set_field3(self, value: str) -> None:
      self._field3 = value

when it could have just been:

  @dataclass
  class IDontWantToBeABean:
    field1: int
    field2: str
    field3: str

The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades.

The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.

Hey, you forgot useless comments for each method:

    get_field1(self) -> int:
      """
         Gets Field1.

         @rtype: int
         @return: the field1
      """
      self._field1

And use double underscores for private fields, because, you know, encapsulation.

Seriously though, in Java you don't need get*() either. Typically you either:

1. use `record` types (since Java14, 2020), or

2. use Lombok that auto-generates them [1], or

3. use Kotlin `data class`, or

4. just raw field access. I don't buy the encapsulation thing if my code is not a library for wide internet to use.

[1] https://projectlombok.org/features/GetterSetter

Try Kotlin then.

I wouldn't call it a new language, for me it's just a syntactic sugar over Java, but for any problem you would google "how to do X in Java", not "how to do X in Kotlin".

But there you can do way simpler syntax, like:

    0..100 meters with -45..45 deg within 3 seconds

Because "0..100 meters ..." is equivalent to "(0..100).meters(...)"

(0..100) is a built-in IntRange type, that you can extend:

    data class MyDistanceRange(val meters: ClosedRange<Double>)

    val IntRange.meters: MyDistanceRange
        get() = MyDistanceRange(first.toDouble()..last.toDouble())

and

IMO Kotlin has some features that take it way beyond just being syntactic sugar over Java. Like, I know you could probably use some eye-watering gang-of-four pattern to achieve the same effect as extension methods. But it's going to be such a PITA to maintain that calling the Kotlin feature syntactic sugar for the same thing is about as useful as saying that function definitions are just syntactic sugar over assembly language calling conventions.

I've played with it for a bit but it doesn't excite me enough to spend time learning it properly. I also don't care about Python beyond using it for learning algorithms and maybe some smaller Pyside UIs. However, together with Mojo it might become more interesting again.

Apple should commit to a support life cycle on the front end then. You are being sold this product with support for a minimum of 'x' time frame. You are not 'buying' this.

Ideally what Stop Killing Games would like is game preservation, but at minimum we need honesty/transparency about product market places. I finally know what my minimum OS lifecycle is for my Pixel phone, and I can make a comfortable purchase decision based on that.

Even Steam isn't immune to this, it simply has an good track record relative compared to most other platforms.

Apple took a ~30% cut of the sale of the product. That should calculate into it's servicing of the product. To Ross Scott's points (and many others), if you have a perpetual service but a onetime/lifetime payment, the business model will eventually not net out.

Ditto. I have several games in my backlog that I got on deep discount, but need serious time commitment to play. It's going to take me a little bit to play Witcher 3, Disco Elysium, or the entire Mass Effect trilogy. Also there is a certain time horizon on steam that play time wasn't tracked. I am pretty sure I played Half Life 2, since that's why I have a steam account in the first place.

Edit: You may not want to know if your steam account is old enough to drink...

Yup. Each peasant after say the first 4 give me a DC check that gets harder to catch/pass the projectile down the line. If you need to be a 3rd level monk to potentially catch the missile, and not even rethrow the missile unless you get the damage to zero, this isn't getting up to any dangerous speed before hurting someone in the line. At least under my ad-hoc ruling.

I have learned over my career that I can't dictate culture. If I attempt to, I will go insane from the stress, because it always comes top down. I try, I give feedback, I do what I can, but these choices are systemic. You can shelter yourself, peers, and team from some rain, but not the ocean.

XAVC HS 4k 10Bit HEVC 4:2:2 on Windows.

Plex and ffmpeg, perfectly fine. VLC is not a fan.