3 ms·

People that don't use a feature (whether it's introspection, dynamic message passing, classes, FP, actors, GC, type systems, etc) saying they won't miss it, tel

People that don't use a feature (whether it's introspection, dynamic message passing, classes, FP, actors, GC, type systems, etc) saying they won't miss it, tells us something about the person but not necessarily anything about the feature.

mpweiher 10y ago
Especially if, as was the thrust of many of the articles, they actually are using those features, and quite heavily at that. They just don't see them directly. Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket)
- deleted 10y ago
  [deleted]
- coldtea 10y ago
  >Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket) Sounds like a hoax slogan (possible from anti-anti-nuclearists). The one I remember was "Atomkraft, Nein Danke!" by itself.
cageface 10y ago
Or perhaps they know what they are doing and have decided they don't need that feature?
- threatofrain 10y ago
  Yes, and that they aren't giving enough discussion to the universe of situations and whether given that universe, the trade off of feature inclusion or exclusion is worth it. There may be a fitter initial frame of discussion for language policy than focusing on your situation. At the very least, if you argue broadly, then you should give a clue about why you think your case is a sufficient proxy for the general case.
- coldtea 10y ago
  That is totally orthogonal to what the parent said. They could know what they are doing, or they could be blathering idiots. Or, possibly, their use cases might be different than another person's. Whatever the case, by just saying that they "won't miss feature X", they still tells us something about them but nothing about the feature. To do the latter, they'd have to up their argumentation.
chvid 10y ago
Personally I don't understand why strong reflection support has been left out of Swift. I can understand that there is probably a problem related to ARC and garbage collection. But missing this set of features means that there are lot of things that simply cannot be implemented in Swift and thus having remain in Objective-C (Core Data, other ORMs, IoC-frameworks etc.). That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future.
- coldtea 10y ago
  >I can understand that there is probably a problem related to ARC and garbage collection. I don't think so, since Objective-C also uses ARC and is very dynamic. I'd say the typesystem/runtime of Swift might have more to do with it.
  - mpweiher 10y ago
    While there are almost certainly other considerations as well, ARC definitely makes Objective-C much less dynamic. The Objective-C compiler gets significantly more strict with ARC turned on, for example sending unknown messages is an error instead of a warning. Various runtime functions that used to be quite safe also become dangerous, for example it used to be OK to send performSelector: style messages with non-object returning messages (void) and simply ignore the result. That now becomes a crash as ARC tries to retain the return value. So in order the be compatible with ARC, the "cheap and cheerful" reflection that ObjC has isn't really sufficient. ARC is predicated on the compiler having essentially a statically checkable call-chain.
- fit2rule 10y ago
  >That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future. iOS/OSX has been split into multiple languages for a long time, anyway. The C/C++-based framework subsystem has produced many others..

mpweiher 10y ago

Especially if, as was the thrust of many of the articles, they actually are using those features, and quite heavily at that. They just don't see them directly. Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket)

deleted 10y ago
[deleted]
coldtea 10y ago
>Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket) Sounds like a hoax slogan (possible from anti-anti-nuclearists). The one I remember was "Atomkraft, Nein Danke!" by itself.

cageface 10y ago

Or perhaps they know what they are doing and have decided they don't need that feature?

threatofrain 10y ago
Yes, and that they aren't giving enough discussion to the universe of situations and whether given that universe, the trade off of feature inclusion or exclusion is worth it. There may be a fitter initial frame of discussion for language policy than focusing on your situation. At the very least, if you argue broadly, then you should give a clue about why you think your case is a sufficient proxy for the general case.
coldtea 10y ago
That is totally orthogonal to what the parent said. They could know what they are doing, or they could be blathering idiots. Or, possibly, their use cases might be different than another person's. Whatever the case, by just saying that they "won't miss feature X", they still tells us something about them but nothing about the feature. To do the latter, they'd have to up their argumentation.

chvid 10y ago

Personally I don't understand why strong reflection support has been left out of Swift. I can understand that there is probably a problem related to ARC and garbage collection. But missing this set of features means that there are lot of things that simply cannot be implemented in Swift and thus having remain in Objective-C (Core Data, other ORMs, IoC-frameworks etc.). That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future.

coldtea 10y ago
>I can understand that there is probably a problem related to ARC and garbage collection. I don't think so, since Objective-C also uses ARC and is very dynamic. I'd say the typesystem/runtime of Swift might have more to do with it.
- mpweiher 10y ago
  While there are almost certainly other considerations as well, ARC definitely makes Objective-C much less dynamic. The Objective-C compiler gets significantly more strict with ARC turned on, for example sending unknown messages is an error instead of a warning. Various runtime functions that used to be quite safe also become dangerous, for example it used to be OK to send performSelector: style messages with non-object returning messages (void) and simply ignore the result. That now becomes a crash as ARC tries to retain the return value. So in order the be compatible with ARC, the "cheap and cheerful" reflection that ObjC has isn't really sufficient. ARC is predicated on the compiler having essentially a statically checkable call-chain.
fit2rule 10y ago
>That means the iOS/OSX-platform will continue to be split in two programming languages and object-models for the foreseeable future. iOS/OSX has been split into multiple languages for a long time, anyway. The C/C++-based framework subsystem has produced many others..