Ask HN: If learning to develop for iOS- start with Obj C or Swift?

Care to elaborate? I get that an ObjC method potentionally returning nil would result in an optional on the swift side, but I don't really get how the compiler doesn't warn you the same way it would with anything else with Optional semantics. (ie. it's nullable.)

0) easily very cross-platform (but you will have to pay), mainstream in mobile games via Unity3D;

1) not locked to one company: .NET by Microsoft, Mono by Xamarin;

2) open-source and welcoming feedback;

3) modern and innovative (not like Swift, but for real - introducing stuff like async/await, mixed dynamic/static typing etc.);

4) allows building mobile, web, desktop, butt software today;

5) first-class IDE, that will get an extensible compiler-as-a-service in 2015;

6) best in class automated refactoring via ReSharper.

So I'd agree that a reset is a good idea. However, Swift pretty much represents the grafting-on approach. Even now, at the start, Swift is already more complex, with more special cases, than even grafted-upon-grafted Objective-C, let alone Objective-C as it started out.

That doesn't mean that there aren't a few things that are handled nicely, but overall it's a bit of a mess already, because of the insistence of stuffing everything into the language and compiler and having everything checked statically (except that it only pretends...).

"If you focus on just messaging - and realize that a good metasystem can late bind the various 2nd level architectures used in objects - then much of the language-, UI-, and OS based discussions on this thread are really quite moot."

-- Alan Kay (http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...)

This is not to say that it's correct because "Alan Kay", but to show a very different approach to language design that is, IMHO, much more powerful and durable than special-casing all the language-fads-du-jour into the compiler.

If you go back a bit and see where Objective-C came from, it was the desire to have Smalltalk, but with better performance and better C interoperability. So an obvious reboot of Objective-C would have been Smalltalk based, with C interop moved out of the base and better support for architectural interconnect. A real "Objective-C without the C", unlike Swift, which is more "Objective-C without the Objective-".

This is such an obvious thing to do that there have been several community projects, including, but not limited to StepTalk, FScript, Pragmatic Smalltalk and my own Objective-Smalltalk (http://objective.st).

In fact, Objective-Smalltalk was in part inspired by Alan Kay's work as expressed in that message: focus on the big things, get the right meta-system in-place, the rest will take care of itself. (here's my response: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-... ) As such, it Objective-Smalltalk isn't trying to be yet another Smalltalk implementation, but rather a new approach in the spirit of Smalltalk: identify the next bigger thing to handle (we now have the Web, for example) and then scale that down so it can handle everything else as well. I think I'm on a good road of achieving this, Higher Order Messaging and Polymorphic Identifiers in combination already handle a lot of what you need, in a user-extensible, late-bound fashion, governed by a very simple and powerful metasystem.

Starting with any of these Smalltalks (or a separate development along similar lines) would have been an easy road towards the goals that Swift aspires to, even considered by itself. When you add interop with the current class libraries, which are simply at odds with the Swift approach, it becomes a no-brainer.

I also find it pretty easy to convert Objective C code (from tutorials/StackOverflow) to swift, in particular with the help of auto-completion. So in my opinion (from someone who just started, so take with a grain of salt), I would definitely suggest Swift