(people have complained about it approximately since it was released)
Desktop iTunes is a dumpster fire, but their iOS software is what I was specifically referring to.
and I ain't gonna stop complaining until I find a suitable music player to replace it!
Most of iOS is still great. The problem is all the cruft that has developed since around 7.0. It just seems like an endless march of features at all expense.
I think it's programming practices themselves that have fallen off a cliff, at least in the non-FLOSS world, and nothing specific to Apple. You can even see this in the dumpster-fire that's popularly known as "Windows 10", as well as in the latest versions of Mac OS X which are a lot slower and less user-friendly than their predecessors.
Sure, that could be argued. But with Objective-C, you still had exposure to the "metal". You had to understand what a pointer is, and why you would want to use it. You had to understand memory management, even though ARC does the job (mostly). It was firmly entrenched in the world of memory efficient embedded programming that mobile started out as, but now that developers coming from Javascript/Python land see a familiar syntax they've brought their patterns with them as well.
Yes. But it has nothing to do with pointers specifically, just the mindset and training of the average developer who has had experience with them, vs. the average developer who has not.
There's an entire generation of developers now graduating from CS programs, hiring into Apple, and getting dumped on these application teams with zero real world experience and their only language being Python or Swift. The result is you have tons of brilliant people who can quickly whip up a DFS algorithm, but don't understand that using 4MB of RAM for a JPEG is unnacceptable, or that whatever dynamic thing they are asking the runtime to do might not always work as intended. That's why we get these massive feature lists nobody asked for with every iOS release, and zero emphasis on performance.
I’m not sure where you’re getting this anecdote from, because I have not found it to be at all true in practice.
It’s a nightmare for security and performance - the number of obvious, blatant security issues I’ve spotted and fixed just through luck alone is horrifying.
But coming back to your point, there have always been new engineers with weak skills, just like there have always been smart engineers as well. I don't think the choice of programming language changes this fact significantly, although certain languages may have a slightly higher proportion of inexperienced programmers than others.
As programming gets easier to learn, people spend less time learning programming. This has a number of negative knock-on effects, eg less understanding & focus on correctness, performance, security, etc. Obviously there’s lots of wider benefits too - but I suspect that the average person writing objective-c today spent more time studying programming than the average person writing swift today.
It sounds like we generally agree on that - but my claim is that this effect size is big enough to dominate almost all other considerations. I suspect the average C program is more secure than the average JavaScript web app, despite how the absurd difficulty in writing correct C, just because of the ratio of new and old programmers in both communities.
There are going to be engineers that have to deal with driver-level code that know full well the limitations of memory constraints, thread overhead, etc.
No doubt you're describing the other half — the app engineers that use the API/SPI's. It might even be argued though that, given a well defined API, they should not have to worry about how much memory a JPEG requires ... the API decompressing the image only when rendering to the destination or what-have-you. Pointers, memory management should be managed by the low-level parts of the language or OS/kernel.
I happen to like the bit-banging, pointer walking, free-wheeling world of straight C but I don't begrudge higher level languages that are designed to tackle the more modern pressures of concurrency and "asynchronicity".