> of course it is not possible to write a Swift compiler in Swift before the language exists
No, but you can do a self-hosting port after you have a first rudimentary compiler. Many compilers have been built like this. Some did it early in language development with a purpouse built one-off bootstrapping compiler, some did it after the language was somewhat stable (eg Go).
Some people I know previously asked this question to one of the Swift developers. I believe the reasoning was along the lines of (very liberally paraphrased/interpreted): Even aside from the problem of bootstrapping the compiler's compilation to start, performant compilation on C++ is a very mature and well-explored problem space. C++ already compiles on a ton of systems, and maintaining a C++-to-Swift(bootstrap compiler)-to-Swift(final compiler) compilation process is added complexity and invites repeated work.
From a language design point of view, the things needed to get a language to the point where it could successfully and efficiently compile itself would skew or re-order priorities in a much different fashion than if they were to focus on building and iterating on an applications and systems language.
tl;dr: LLVM and Clang and their assorted toolsets do quite a bit of valuable work; reinventing that to serve the language they're building is a feedback loop is a downside that also removes some upside from the equation, too.
I believe I saw Lattner once describe a self-hosting compiler for Swift as an anti-goal, at least before the design had stabilized.
Aside from the value of maintaining LLVM as a shared codebase, the concern was that writing a compiler in Swift could bias early language design tradeoffs towards decisions that would make it easier to write a compiler at the expense of the larger universe of potential applications.
Objective-C bridges to and from Swift easily, so it would be easily to incrementally replace Objective-C code with Swift code. Since C++ doesn't interact with Swift at all, it would either have to be wrapped in C/Objective-C, or the entire compiler would need to be rewritten at once.
That being said, C++ is probably a better choice, because dynamic dispatch sucks and there's better platform support.
3. App Store search results that are actually relevant
4. Ability to respond to negative reviews
5. Mac App Store sand boxing that doesn't suck
Of course, there are many more issues but the primary problem is that Apple has addressed exactly zero of these issues and the App Store itself is virtually unchanged after 5+ years.
Right, Swift had one very specific and timely request for a new product. That's not comparable to, "There's a bunch of stuff that's needed fixing for years."
That's not entirely true - it only uses monosyllabic words for IPv6 addresses because there's no other way to fit enough bits into the right number of syllables.
For IPv4 addresses, there's loads of space, so I can afford to use some longer words.
Depending on one's interpretation of common carrier, it's the same as the difference between "delivering email from user a to user b" and "conspiring with terrorists"
This is a common but completely unfair criticism of Apple. Plenty of people complained when iOS 7 was made available for the iPhone 4 (because the hardware was too slow to run it properly). And Apple still sells and supports relatively ancient hardware (the iPad mini) as a result of their current strategy of selling last year's model as the second-best option.
The reason people complain is because iOS updates are a horrible kind of bait and switch. You update the OS because you think its awesome, but are unable to downgrade when you find that in reality, its slow and bloated.
The most infuriating thing in all of this is that my iPhone 4S is STILL a fast device. The CPU hasn't shrunk since the time I bought it. Apple has decided that I am unworthy of restoring my phone to the state it was when I purchased it.
Yup. I had 1 iPhone, my first and last Apple product.
My mom just got an iPad mini, was infuriated when she discovered she can't buy Kindle books from the Kindle app like she could on Android.
The artificial restrictions Apple places on developers and users are ridiculous. And Android 5 is the first release where I can say that Android is unequivocally a nicer experience than iOS...
Say what now? I just opened my Kindle app and the store hasn't gone anywhere.
Are you maybe thinking of Google blocking Amazon from including the Amazon Appstore in the Amazon shopping app? That's a different issue and,
more importantly, that doesn't really affect what's possible on Android, just how convenient it is. After all, anyone who wants to can download the store Google blocked from Amazon directly.
Just like how if anyone wants to purchase a Kindle book on the iPad, they can do it via Safari (they could make it more convenient by pinning it to the home screen as well)
Actually, no. Being able to purchase a book over a web browser and installing a native application store on your device are very different things.
I think you can argue that a browser itself is an app store (you download and execute (web-)apps with it). But Apple does not allow the installation of different browser engines, so you can still not install an app store on your device.
I understand what you're saying, technically they are different things.
But not to my mother.
I would guess (and only guess, I haven't tried to look for any numbers) that the percentage of people who go out and install an alternative app store, let alone Amazon's, is quite small (especially once you take out the HN audience)
Most of the criticisms of brand-new OS updates being "slow and bloated" are from extremely impatient users (or professional clickbait critics) who don't even have the good sense to wait a few hours or a day or two for the processes that can make major upgrades a bit sluggish on ALL devices to complete, such as rebuilding databases, the fact that OS updates often result in dozens or even hundreds of app updates that have to download and install and in some cases update their own databases, etc.
Certainly, they do not wait for the first x.0.1 release, or for the release that usually closely follows the initial release and which is specifically intended to optimize performance on the oldest devices that can still support the latest OS. This was seen for iOS 7 and once again for iOS 8.
I don't think it's a valid comment, or a comment made in good faith, to say that iOS updates are a "bait and switch". That's just silliness and flies in the face of all the facts. The facts say, very loudly, that Apple supports its older devices MUCH better and for much longer than any competitor. It's not even close.
Now, if you are unable to acknowledge reality, and expect that a brand-new OS, designed to take advantage of devices that are about 10x as fast as three-year-old or four-year-old devices, isn't going to be quite as snappy on older devices, then in my opinion, that is on you as a user. Blaming Apple for trying to give more features to users on new hardware is ludicrous. Apple expends considerable engineering effort keeping those devices working as well as possible. The iPhone has been out for seven years. There's now more than enough history out there for users to know that if you install major iOS updates, you cannot easily downgrade. (It's not impossible, it's just a huge pain.)
I'm sorry but this is simply untrue. Every time I have hardware 1-1.5 generations behind (which is not always, I've done it both ways) the OS upgrade makes it somewhere between noticeably slower and painfully slow. I've recently used an identical model side-by-side that was not upgraded and it is vastly snappier. this has nothing to do with waiting for x.0.1 or app updates. In this case we are talking about iOS 7 on 4S, I'm refusing the iOS 8 upgrade for obvious reasons. I've seen others have similar problems in previous iterations whilst my newer hardware was fine.
People are fond of overstating Apple problems and I'm grateful that the opportunity to upgrade exists at all. However it is a fact that it often destroys the performance so the ability to revert seems very reasonable. I also find the extent of the degradation puzzling.
>There's now more than enough history out there for users to know that if you install major iOS updates, you cannot easily downgrade.
Certainly, that is your version of reality. Only a small minority of users have any clue about downgrading.
>I don't think it's a valid comment, or a comment made in good faith, to say that iOS updates are a "bait and switch".
>that Apple supports its older devices MUCH better and for much longer than any competitor.
Well, it depends on your viewpoint. How can you 'support' a device by incrementally making it slower with each passing release? If all they were releasing was bug fixes and patches, and features which didn't adversely impact performance then YES I would agree with you. Or hell, I'd even agree with you with the current situation if Apple allowed downgrades.
Seriously, I mean don't you think its totally messed up that Apple has to give its permission before you're able to downgrade the OS to speed it up when its their own update that slowed it down ? Its ridiculous and should not be accepted as the norm.
> you cannot easily downgrade. (It's not impossible, it's just a huge pain.)
Cool, please point the entire world to a working bootrom exploit for the 4s. We've been waiting for a while :)
It's not a choice between no software updates for old hardware, and bad software updates for no hardware. At least in theory, Apple could have made an iOS 7 update for the iPhone 4 that actually worked well on that hardware. It's not "unfair" to complain that Apple does a bad job of supporting hardware after only a couple of years, when your counter is that they release OS updates that don't work well on them.
I wouldn't say it's completely unfair. Using proprietary data/charging cables and changing the design every so often, obsoleting whole generations of products seems like behavior consistent with my criticism.
Apple introduced the Dock connector on the iPod in 2001. The same connector was used for over ten years, before it was replaced with the lightning connector in 2012.
The MagSafe connector was replaced after 6 years by the MagSafe 2 connector, also in 2012.
Both of these connectors where replaced for good reasons. The Dock connector was not reversible, prone to break, and was easily clogged with dust. It was also too big for smaller form factors. The MagSafe connector was often confused with USB and also too thick for thinner devices, and it used a low charging voltage (less efficient).
Switching to a new design is often inconvenient, but also often necessary. To ease the transition, Apple even provided adaptors for compatibility with older chargers.
When it comes right down to it, people hate change. "It still works, so why change it!?" is a popular saying among most users.
You're right, though. In this case, there definitely had to be an update to Apple's charging cables. Now that we're 3 generations into the new Lightning Connector, it's less of an issue for most people.
Apple has a huge majority of users who are basically into fashion. I usually buy the newest things and give away the old stuff, even if its just charging cables or an extra monitor.
The connector for iPods, iPads, and iPhones has only changed once. And the old 30-pin dock connector was in use for 11 years. 11 years now counts as “every so often”?
As for macs, the original MagSafe connector was in production for 6 years, before it was replaced by MagSafe 2 in 2012…
There have only been two apple charging interfaces for iPods, iPhones and iPads (excluding the shuffle), and the new one was necessary (if I understood correctly) to take advantage of faster USB3 data transfer rates.
Lightning doesn't currently support USB3, unfortunately. It did get rid of a lot of obsolete old interfaces that were present in the 30-pin dock connector pinout, though, and opened up possibilities for new devices (like the HDMI adapter).
I think you are splitting hairs. What would be the point of "legally" allowing you to build an app that could not be submitted to the App Store? The only way to distribute it would be to "illegally" jailbroken devices.
> What would be the point of "legally" allowing you to build an app that could not be submitted to the App Store?
Simple, you can use it personally, or for example submit it to Cydia or any other place without Apple's censorship. Just post it as a download after all. There is nothing illegal in distributing for jailbroken devices.
But that's really irrelevant. The license here doesn't even get to that part - it forbids you to build the browser, regardless of any of your further plans how to use or distribute it. It's completely sick.
And of course it is not possible to write a Swift compiler in Swift before the language exists.
So no, not odd at all. Quite logical actually.