Hacker News Reader

Comment by lindig | Hacker News Reader

While technically impressive, I wonder how much economical sense does it make for an iOS developer to go this route. For a small install base you open up a support front and now your code needs to work against the UIKit implementation of Windows Phone that by all likelihood will have its own bugs and limitations. You also might have planned to use Swift on iOS and this isn't possible when you want to compile your code for Windows Phone.

Edit: I meant to talk about Swift, not Swipe.

View on HN

Is there any likely technical reason Microsoft won't be able to do the same with Swift in the future? As I understand (not an Apple developer) doesn't it use the same frameworks, so they can reuse that? Its syntax also looks way more similar to c# than obj c does from a quick look.

It seems to be in the works as during the Build talk there was a "suit" that kept saying "no comments" when asked about Swift.

The technical reason is probably that Obj-C has multiple stable implementations (which agree almost entirely), the GNU or Clang frontends, which makes it easy to write your own implementation because you can study what those two do (in the worst case; the Obj-C part they could just do by compiling either of those two compilers).

With Swift, the compiler is closed source, so you either have to examine the code it produces or the programmers manual, which is legitimately more difficult technically.

Then there's the fact that the lawyers will have to be all over any Swift implementation, and it gets even harder.

None of this would have happened if Clang didn't exist :P The whole reason that Microsoft can do this project now is because Clang didn't exist when Apple/NeXT started development on Obj-C.

> None of this would have happened if Clang didn't exist :P The whole reason that Microsoft can do this project now is because Clang didn't exist when Apple/NeXT started development on Obj-C.

This paragraph is a few kinds of incorrect. I built objc code on Linux with GCC before clang existed. (gobjc is the name of the package.) Clang therefore was not the only free software objc frontend at the time of introduction. GNUstep even ran on Windows using that. There is no reason Microsoft could not have also based its efforts on GCC's objc frontend, without clang.

I believe also NeXT used GCC back in the day - I read somewhere that even then they were displeased with the fact that GPL forced them to contribute back. Also objc existed before NeXT, the were just the only notable player using it and de facto took it over.

In 1996 I ported a large bunch of code from NEXTSTEP to Windows using the GNU runtime. That was all pre-OpenStep (OK, it wasn't, but the code didn't use Foundation, had no UI, etc, so it didn't depend on any class libraries beyond the runtime itself). But it has been possible for at least twenty years! (And there was always GNUstep.)

Another interesting thing is Apportable's Foundation implementation, it's really nice and is LGPL'd. I wonder if MS licensed that.

That's my entire point; if Clang did not exist then Apple would have had to contribute the Swift frontend back with the GPL or write an entire compiler backend, as they did for Obj-C.

Now, Clang is competitive and they can keep the frontend under wraps.

Had Clang existed when Apple were implementing Obj-C, they'd have used that, there'd be no open source Obj-C frontend Microsoft wouldn't be able to do this without considerably more work.

> Had Clang existed when Apple were implementing Obj-C, they'd have used that, there'd be no open source Obj-C frontend Microsoft wouldn't be able to do this without considerably more work.

Ah, OK... So you mean if NeXT hadn't based their 1980s effort on GCC, i.e. if there had been a decent BSD-licensed C compiler back then.

It's worth mentioning that this was a long time ago, before a fair number of HN readers were born, and also at a time when GPL vs. BSD licensing likely wasn't as much of a topic as today. Comparing GCC with Clang when we're talking about things that happened in 1988[1] just doesn't seem to make any sense to me.

[1] Per Wikipedia's article on Objective-C, the year that NeXT's GCC changes happened.

They probably will do so with Swift in the future, but at present it is much more difficult.

I did a quick summary of the talk, which had a bit more detail, here: https://news.ycombinator.com/item?id=9471204

In short, they used one of the available open-source frontends (clang, the other being gcc). In addition, Objective-C is almost completely trivial to implement if you have a C compiler. Heck, a 17 year old kid with nothing but a C compiler, access to the Brad Cox book and no formal training in CompSci in general or compilers in particular managed to pull it off back in 1986 or so.

Swift is closed-source, so unless or until that changes, it is a reverse-engineering effort. It is also a vastly more complicated language to implement. It is hard to even begin to describe the difference. It leans on the compiler and optimizer by what I consider to be an insane amount, just the rules for initializers and named keyword arguments are bigger than the entire Smalltalk language spec (which is the part Objective-C adds to C). The optimizer is required if you want performance greater than Ruby interpreting a Python program. etc.

On the other hand, it is in many ways similar to C#, so probably not that hard a feat for MS to pull off.

And it's possible Apple will open source it - although if they do I imagine it will be more work to integrate with a foreign runtime (if indeed that is what MS has done) than to use Apple's own.

Since microsoft remake the UIKit, theoriticaly it still support swipe. Well at least you can swipe on ui table view.

It is my understanding that Microsoft approaches the makers of popular software titles and offers them money to put their software in the Windows store. In the past I think a lot of companies turned them down. If the barrier to entry is lower, maybe those companies will take the offer.

Reply on news.ycombinator.com