Code signing should be done though.

You can disagree with Apple’s approach that maintains them as the only signing authority, but, at a fundamental level, code signing is the only way to distribute an executable and have the user be able to trust who authored it (and thus what’s in it).

The SOLID principles are just that principles, not rules.

As someone else said, you should always write your code to be maintainable first and foremost, and extra code is extra maintenance work, so should only really be done when necessary. Don’t write an abstract interface unless multiple things actually need to implement it, and don’t refactor common logic until you’ve repeated it ~3 times.

The DRY principle is probably the most overused one because engineers default to thinking that less code = less work and it’s a fun logic puzzle to figure out common logic and abstract it, but the reality is that many of these abstractions in reality create more coupling and make your code less readable. Dan Abramov (creator of React) has a really good presentation on it that’s worth watching in its entirety.

But I will say that sometimes these irritations are truly just language issues at the end of the day. Java was written in an era where the object oriented paradigm was king, whereas these days functional programming is often described as what OO programming looks like if you actually follow all the SOLID principles and Java still isn’t a first class functional language and probably never will be because it has to maintain backwards compatibility. This is partly why more modern Java compatible languages like Kotlin were created.

A language like C# on the other hand is more flexible since it’s designed to be cross paradigm and support first class functions and objects, and a language like JavaScript is so flexible that it has evolved and changed to suit whatever is needed of it.

Flexibility comes with a bit of a cost, but I think a lot of corporate engineers are over fearful of new things and change and don’t properly value the hidden costs of rigidity. To give it a structural engineering analogy: a rigid tree will snap in the wind, a flexible tree will bend.

Honestly, it’s fucking exhausting.

Cynicism is not cleverness and it is not informedness, it’s just reactionary bullshit that makes you sound edgy online.

Again, no, because that’s not a resolution, that’s a pixel density at a set distance.

While I get your point, this is an article, not a whitepaper.

If someone says something that is obviously not a thing, like ‘the perfect resolution of an analog painting’, then it means the author probably didn’t actually understand what they read and so you shouldn’t trust their interpretation of the underlying news.

That’s not a resolution, that’s a pixel density at a set distance. It’s also arbitrary on Apple’s end, not actually a meaningful universal measurement.

To demonstrate the efficacy of the tiny screen, the researchers reproduced The Kiss, a famous artwork painted by Gustav Klimt. The image was shown in perfect resolution on the screen, which at approximately 1.4 x 1.9 mm was 1/4000th that of a standard smartphone.

This makes me doubt the author of the article’s credibility. What exactly is the “perfect resolution” of a hand painted piece of art?

The underlying paper is published in Nature which adds more credibility to its significance but an article that presents none of the limitations, drawbacks, or broader industry context that might hold something like this back isn’t adding much. What was the colour depth? Refresh rate? Is it thrown if the external light shifts and changes? How many children have to be sacrificed to the machine gods to produce it? Etc. etc.

deleted by creator

+++ I cannot stress this enough.

Programmers tend to get over obsessive about DRY code because it seems like it should be easier to maintain fewer functions and writing less code should be easier right? But it tends to ignore the actual subtle differences between the different consumers of that abstraction, and that leads to massively branching functions that couple unrelated parts of the codebase together. These then become impossible to read and change without worrying about breaking something else.

When I was at Thoughtworks (Martin Fowler’s current company), we were also taught the rule of three for refactoring, and were taught to always optimize your code for readability and maintainability first and foremost. Refactoring and improving easy to read/maintain code is always relatively trivial, by nature of it being clear, concise and decoupled, and that can be done once you have a reason to do so (i.e. performance issue etc), so there’s no point over optimizing for anything else up front.

This talk from Dan Abramov (one of the lead devs of React) does a really really good job explaining some of these issues and is entirely worth the full watch/listen (do it on company time, it’s professional development):

https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebasets

Huh, TIL, I didn’t realize they kept the gateway servers in Python.

I literally do that professionally, and I’m telling you that brackets are inarguably better.

You are used to whitespace; I have literally spent months refactoring and upgrading a react frontend and a python backend and am telling you that brackets are a single character and far more predictable, and then your IDE / Linter / Formatter can reliably use them to fill in the perfect indentation and whitespace.

My first professional language was Python, but I have since tried a half dozen others and would never choose to go back to a whitespace based language unless there was a good reason.

No, it’s not. It was rewritten in Facebook’s version of PHP when they bought them.

Or you know, TypeScript, Go, C#, Java, Swift, etc. etc.

Python isn’t great at anything except for having a lot of data science libraries already written for it.

Lazy is an overly harsh and judgemental way to put it (virtually all programmers start with some high level simplified language), but the sentiment arises because it’s syntax is designed to be easy for people writing code, but at the cost of people maintaining code.

The whitespace delimiters, the lack of type system, the lack of semi-colons … They’re all things that people who haven’t programmed before think make programming easier. In reality they all make in the wild production programs waaay harder to maintain.

There’s a reason that JavaScript has been surpassed by TypeScript for professional developers, and it did so remarkably quickly. All that ‘extra’ information that seems pointless for a new dev to express, in reality constrains your program, makes it more readable and understandable, reduces the amount of tests you have to write, and makes it easier for someone else to come in and make a change to it and be confident they haven’t broken anything.

Python is popular because it’s whitespace based syntax make noobs think it’s easy to read. This and it’s pre-installation on Linux made it popular amongst academics who embraced it for data analysis. This lead to a lot of data scientists embracing it and writing libraries for it which created a virtuous cycle in that arena.

And it’s a damn shame because Python, and it’s whitespace nonsense and lack of type system, is a horribly impractical language for building anything at scale.

Apple is such a piece of shit company.

Learn how to compete without behaving anti competitively or quit your fucking jobs. It’s not complicated.

Why?

1. Lack of Feature Parity

2. Stickiness of library transfer

3. Stickiness of social network effects

4. It’s still better ethically than Apple Music or YouTube Music, which behave anti-competitively

1: I’ve tried out Quobuz, it’s pretty good, but it does not have the Jam / Group Session feature which me and my friends use constantly while gaming remotely. It also does not have an Xbox app which I use while playing games. I find Spotify’s recommendations somewhat underwhelming, but Quobuz has a noticeably worse recommendation engine, at least for my genres and tastes. Those are the features that lack parity that matter to me, but for some others, it’s things like amplifiers having built-in Spotify, or there being a Roku or Playstation app or something.

2: Quobuz uses a third party service to automatically transfer your library, which worked pretty well, but did require jumping through a bunch of hoops and subscribing to a trial subscription that I then had to cancel. It also did not find matches for some songs. Could I make it work if I had enough reason to switch? Yeah, probably, but the lack of feature parity (/roadmap that includes them) is enough to dissuade me from really trying.

3: In addition to friends on Spotify all using Jams, there’s also an inherent niceness to just being able to text people Spotify links, especially since there’s no cross platform linking service that would otherwise make sharing music easy.

4: Supporting Spotify may not be great, but its still better than supporting trillion dollar anti-competitive corporations like Apple and Google.

I assume this suggestion will get me torched for reasons I don’t understand, but why not a multi-paradigm language like JavaScript/Typescript, or C#?

I misread the comment hierarchy, I thought this was a part of a different chain.

No one should be able to do it is the right reaction, but ‘Nintendo deserves no blame or shame for choosing to do it’ is the wrong reaction. Nintendo could have used all the money it spends on IP lawyers to instead lobby the government to change the patent system, but they chose not to.