5 ms·

Idk if I agree that objective-c is simpler to learn. I have been working as a full-time ios developer for almost 2 years now and I still have to consult fucking

Idk if I agree that objective-c is simpler to learn. I have been working as a full-time ios developer for almost 2 years now and I still have to consult fuckingblocksyntax.com on a weekly basis. And fully understanding objective-c's "message passing" idea is hard because it's so radically different from other languages. And sure you can whip together a simple app using all the documentation and tutorials out there for objective-c. But objective-c has a lot of gotchas that make it easy to do bad things as you start to build a larger app. Like retaining self implicitly because of an ivar in a block... Can't tell you how many times that is bitten us. That being said, have you tried to use Swift with the core foundation framework? Yikes. I spent hours yesterday trying to understand how to simply pass a pointer to a function. The type was something like CMutablePointer<Unmanaged<SecKey>?>. Hopefully it'll get easier as the documentation improves though :)

potatolicious 12y ago
Yeah, this is one of the reasons why Swift exists. The base Obj-C that we started with was pretty simple and reasonably elegant, but over the years we've been grafted pieces onto it in decidedly inelegant ways. Block syntax, a ludicrous proliferation of __keywords and @keywords, the verbosity of GCD calls, all of it makes modern, complex Obj-C apps harder and harder to write. In a lot of ways Swift is a reset. It offers a lot of the things we want from Obj-C/Cocoa (e.g., more block-based everything) in a clean syntax that was designed from the get-go to support it. One of the complex bits of Swift right now is that the APIs haven't been ported. UIButton still expects targets and selectors (ugh), and an innumerable number of API calls still rely on the only C-style way of passing error pointers into calls to see if they get filled (and necessitating the idiotic NSErrorPointer class). A lot of the complexity of building in Swift right now is shoehorning Obj-C style APIs into Swift code.
- mpweiher 12y ago
  Yes, definitely. Objective-C was a lot more elegant before the odd grafting started, with everything hard-baked into the compiler and special cases added on top of special cases after the first special cases were found to be too special. 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-October/017019.html 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 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-October/004106.html 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.

potatolicious 12y ago

Yeah, this is one of the reasons why Swift exists. The base Obj-C that we started with was pretty simple and reasonably elegant, but over the years we've been grafted pieces onto it in decidedly inelegant ways. Block syntax, a ludicrous proliferation of __keywords and @keywords, the verbosity of GCD calls, all of it makes modern, complex Obj-C apps harder and harder to write. In a lot of ways Swift is a reset. It offers a lot of the things we want from Obj-C/Cocoa (e.g., more block-based everything) in a clean syntax that was designed from the get-go to support it. One of the complex bits of Swift right now is that the APIs haven't been ported. UIButton still expects targets and selectors (ugh), and an innumerable number of API calls still rely on the only C-style way of passing error pointers into calls to see if they get filled (and necessitating the idiotic NSErrorPointer class). A lot of the complexity of building in Swift right now is shoehorning Obj-C style APIs into Swift code.

mpweiher 12y ago
Yes, definitely. Objective-C was a lot more elegant before the odd grafting started, with everything hard-baked into the compiler and special cases added on top of special cases after the first special cases were found to be too special. 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-October/017019.html 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 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-October/004106.html 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.