Re:Native GUI library for Go
by grey-area on Friday June 06, 2014 @07:27AM
(#7857231)
Objective-C doesn't have generics either and is/was the blessed API language on your chosen OS. The horror!
[ Parent
| on HN ]
Obj-C is 31 years old. I don't think it's unreasonable to expect new languages/frameworks to have progressed in that time.
Isn't it normal to expect old languages to evolve too, especially when they are pushed forward by companies as huge as Apple? Look at C++ (the same age as Objective-C): C++11 was approved in 2011.
Swift, Apple's days-old intended replacement for Objective-C, does have generics.
Isn't it about time? I mean, they don't really have to make a brand new language to add generics.
As mentioned elsewhere, Objective-C is mostly dynamically typed, and you can just silently cast id to things, so it doesn't need generics as much as a language like Go, although they certainly could be useful. On the other hand, the dynamic typing makes it slow with generics or not, and if you want to put numbers in collections, you have to go through a very cumbersome boxing process - two of the many things only a new language could resolve.
Re:Native GUI library for Go
by matthewmacleod on Friday June 06, 2014 @09:21AM
(#7857674)
It's also not statically typed - that's one of the things that generics can really help with.
Surprisingly, people have different expectations between a language from the 80s and a language less than a decade old.
Re:Native GUI library for Go
by Alphasite_ on Friday June 06, 2014 @08:45AM
(#7857520)
And Objective-C isn't really strongly typed either, so you can send anything any message.
FWIW this is specifically why Objective-C has been able to get by without generics for a while. You don't get solid type-checking like you do with generics in other languages (except C++), but that has never really been an issue because the above statement works even with [...] statements (sure, the compiler will warn you, but).
The only real issue is that the things you shove into Objective-C containers must themselves be Objective-C types, which means using NSNumber and NSValue everywhere for raw C types. The new Objective-C @literal and @(expression) syntax, however, should make such code cleaner in the future...