Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

On the one hand I like this idea because I'm tired of Intel's lousy security and lousy energy budget. On the other hand I dread it because Apple will not fully document the ISA of their new CPU (just like with their current mobile lineup) which means it will become impossible to develop one's own programs for the Mac, write code in whatever language you wish, or distribute programs for the Mac outside the Apple-controlled walled garden. You'll use Swift and Xcode and you'll distribute your programs via the App Store with Apple's approval, and you'll like it. Or you won't develop for the Mac.

View on HN

I write code in c++ (using Emacs), compile it with the latest (non-Apple) llvm, and link it with some UI code I developed with Xcode. I can even compile from within Emacs by calling xcodebuild (though these days I just have cmake do that).

Or compile it all in Xcode. Not terrible, I just happen not to like guis.

I think it's incorrect assumption. If you want to develop a compiler for this new ISA, you'll develop a compiler into Clang's IL (intermediate language, that's probably incorrect name, I'm not a specialist in compilers) and then Apple's Clang will do the rest. Or may be even Apple will develop that part of Clang and make it open source then this is your documentation effectively.

I stopped supporting Mac versions of software when they kept breaking compatibility for no real reason.

Did you stop developing software altogether? What doesn’t break compatibility from time to time?

The linux kernel is userspace abi compatible back to year minus one.

Windows...

This is an important lesson. I am personally not a fan of the Windows programming model* and I despair the number of security holes over the years, but I am quite aware that a large part of it stems from Microsoft's commitment to extreme backwards compatibility (which I also recognize has sometimes taken heroic measures).

I'm actually surprised how long Apple takes to obsolete APIs (carbon lingered forever) and how far back they are willing to support old hardware. They project an insouciance towards old APIs but tend to give a lot of advanced warning (e.g. the obsolescence of 32-bit applications was announced at least five years ago). They seem to be far less conservative towards UI, and prefer to rewrite rather than update which leads to a bunch of new bugs. That might be what gives people the impression that they junk APIs quickly.

* that's a matter of personal taste, not meant to start a flame session.

LLVM will almost certainly get a back-end for it; Apple uses the latter extensively already. And virtually all new, native language projects already target LLVM. So I don't see this being a problem at all.

Reply on news.ycombinator.com