Personally (on desktop) this design strains my eyes. I want to look in the center where there's nothing to grasp, and there's the official statement, black banner, time boxes, time zone titles in highly varying colors/fonts competing with each other. Also I notice the page auto-refreshing in the background.
As a side note, the forums aren't the best place for that; the post could just be unseen by the people that matter. The appropriate channels are through Feedback Assistant and/or a technical support report (https://developer.apple.com/support/technical/) which has bit more visibility.
For things vaguely like this, the places I've worked had contacts within the company helping us to varying degrees. Apply was not one of these companies, and unless there's money or contracts are being signed, getting that contact is a challenge.
Second this, you get two free Technical Support Incident requests per year as a registered developer, and you can purchase additional ones.
We regularly file such requests and have always got timely and helpful responses.
As someone that's written a game "cheating" tool there's good technical / reverse engineering value from modding or cheating games. Plus it's fun to just be able to change a game (I fondly remember the days playing with Game Genie).
It is indeed a bit immoral when one tries to cheat in a way that unfairly puts themselves ahead of other humans.
This website needs to scale text better on mobile (on an iPhone) so it's not hard to read. Especially for a post advocating on using vanilla HTML and how nice and powerful it is.
I don't think I particularly disagree with any of the post, but I found it a little long-winded.
Catering to energy limited, heat dissipation limited, UI size and precision limited, and network limited (random rtt) smart phones is why the web has become as bad as it has.
It's a misconception that layout switchers are relearning to type, especially if they were proficient qwerty touch typists. The better typists in qwerty have a significantly easier time learning a new keyboard layout. Most of the typing skills positively transfer over, even though there's still an initial hurdle.
Furthermore, I think there's significant bias when typists learn a new more ergonomic layout. For example, they may have incidentally fixed their typing posture when learning Colemak, they want to justify their investment, or they overestimate the efficiency/comfort gains in respect to how much they need to type daily. Performing frequent typing tests (something alternative layout typists like to do!) is furthest away from reality for most people. Many switchers also forget how to type in qwerty well; improving typing speed while learning feels "really nice" and it's easy to wrongly associate this with "qwerty is uncomfortable."
They also downplay the importance of living in a qwerty world, having to share a computer with another, or being able to proficiently type in qwerty (which many of them do not retain), or dealing with software not accounting for other layouts.
> That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.
1st tier tooling supported by the platform won't break yearly on every new OS version and you don't have to wait until your 2nd tier tooling developers gets around to fixing it.
The platform developers will do their best to keep 1st tier tooling working and fix it when it breaks.
Likely too much friction. Native environments benefit from using the expected IDE and tooling integration to build UI apps on respective platform. C or C++ is the best common supported language, and they didn't even like that.
Also the UI frameworks are being written in said preferred language these days, eg SwiftUI, and adding one additional language could be perceived as a pain.
Apple ships a C++ compiler but you can't use C++ with Apple's platform SDKs. IF you want to use C++ you need to write Obj-C++ glue code to access most of the system frameworks, including UI code.
I would look at it differently, i.e, obj-c++ is a valid supported language environment, that makes interopt with C++ pleasant at least compared to other interopt choices. Developers may choose to target Obj-C++ even out of preference.
Metal shaders != Metal API. Metal API is Obj-C. Metal shaders are written in MSL (Metal Shading Language). C++ is still not involved, though MSL is admittedly based on C++.
"The Metal programming language is a C++14-based Specification with extensions and
restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21
N4431 Language Specification) for a detailed description of the language grammar.
This section and its subsections describe the modifications and restrictions to the C++14
language supported in Metal."
Also, the MSL and Objective-C compilers are built on top of LLVM, written in C++.
I don't know what point you're trying to make. MSL doesn't link with the rest of your program. No matter what language you use for your program, the shaders are written in MSL. For my program if I use Rust or C++ or Obj-C or Swift or a microscopic magnet and a very careful hand, I write my Metal shaders in MSL.
The fact that Metal itself requires the existence of C++ really has nothing to do with this topic though, which is whether there's any downside to writing your app in a language that Apple doesn't ship a compiler for. The fact that Metal shaders are written in a language based on C++ is irrelevant to this question, because it doesn't matter what language you pick for the rest of your app as Metal shaders don't link with your app. Swift has zero integration with C++ and yet I can write a Metal app using Swift, because the fact that the shaders are written in MSL has no impact on the fact that the app uses Swift.
And the language for writing drivers in is even more irrelevant because we're not talking about writing drivers. You can't write drivers in Swift either.
It depends. When I was writing almost purely functional programming code in Scala I was frequently cursing at type inference. Each explicit type hint helped me more easily understand what each next transform was doing.
More modern languages (Rust, Swift) have also gone and say "well, omitting types from arguments and return values of function signatures is a bad idea, so let's not do that."
I probably think this is true for school, that using laptops is not as productive for taking notes, but I didn't find writing down notes on paper in classes particularly pleasant either.
Past my school life into employment life, the situation is much different. I take digital notes on many tasks, I search through them like in a database when I need to recall something. I don't get distracted for note taking in environments that sitting through long lectures encourage. I still take notes on paper sometimes, but write a lot less down.
I treat playing piano as a creative outlet these days as a small hobby, not profession. Not much different than say, playing video games. I actually have very little interest in becoming better these days, mostly due to forgoing lessons / daily practice long ago.
That said, I’ve created compositions that are really cool on occasional boredom, which is probably something many “accomplished pianists” don’t even do. And that is a lot cooler than performing challenging pieces, if you ask me.
I also don’t think that more challenging pieces actually necessarily sound better / distinct. There are beginner level songs that are surprisingly good.
My music teacher also told me that there’s good and bad practice. If you continuously do bad practice / habits, you get worse, not better.
