6 ms·

Swift and Dynamism

86 points by dchest 10y ago

jawngee 10y ago
He skipped over KVO, KVC and related reflection capabilities of Objective-C that make it so flexible. I like and use swift, but I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this".
- adamnemecek 10y ago
  > I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this". You don't feel more productive in swift? Like a lot more?
  - mpweiher 10y ago
    No. EDIT: Just the compile times alone drive me batshit. That doesn't mean that there aren't nice aspects, certainly some of the syntax has been simplified by unifying two disparate syntaxes...but they could have done so much better, even there.
- mikeash 10y ago
  KVO is horrendous. KVC is occasionally nice but often greatly overused. I certainly wouldn't miss either one.
  - mpweiher 10y ago
    "The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way." http://blog.metaobject.com/2016/05/what-missing-in-discussion-about.html http://blog.metaobject.com/2016/05/what-missing-in-discussio... See also: The Siren Call of KVO and Cocoa Bindings http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...
    - chillacy 10y ago
      Yea, I think KVO could be done better. As I recall, Ember properties were pretty neat, and had a nice way of specifying dependencies. A lot less awkward than a bunch of + (NSSet )keyPathsForValuesAffectingValueForKey:(NSString )key methods. I'd also want more strongly typed keys, less strings everywhere. I do use NSStringFromSelector as much as I can, but strings are unavoidable in IB. Also the handling of one-to-many dependencies could be made a lot more intuitive as well.
matt4077 10y ago
My heart skipped a beat today when refreshing my RSS-feeds. It was like a reunion with your first love. The best of new excitement & old familiarity: Wil Shipley is writing again!
ktRolster 10y ago
nevermind, I figured it out.
- simscitizen 10y ago
  He's saying that the same team that developed LLVM, clang, and ARC (which most people think are good things for the Apple ecosystem) is also bringing you Swift. So you should feel good that the language is being developed by a team with a good track record that will probably find a solution for this particular issue.
bjt 10y ago
This is a very strong endorsement: > I am better Swift programmer after a year and a half in Swift than I was in Objective-C after 26 years.
patrickg_zill 10y ago
I must not be 100% up on my acronyms: what is ARC? it's not "Arc" as in "Lisp like language written by Paul Graham et al" of course.
- austinz 10y ago
  Automatic Reference Counting: https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting
adamnemecek 10y ago
I doubt you have written much Swift as you are like one of the most die hard Obj-C fanboys there is. Also I have read your blog before and you fundamentally misunderstand type theory, so I wouldn't really expect any other answer from you :-).
- mpweiher 10y ago
  "However, many of these dynamic features are definitely hacks, with various issues, some of which I talk about in The Siren Call of KVO and (Cocoa) Bindings." "Note that Objective-C's metasystem...is a bad design." You have a funny definition of "fanboy", but suit yourself. And if you've read my blog and think I write about type theory, then you are utterly confused.
  - adamnemecek 10y ago
    > And if you've read my blog and think I write about type theory, then you are utterly confused. http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...
    - mpweiher 10y ago
      You have a funny definition of "type theory". That article just documents that the safety benefits of static typing are, empirically, rather minuscule, especially compared to the claims for the benefits, which are vastly overblown. That said: I still like to be able to statically type my programs. I just don't expect it to yield a significant safety benefit (documentation benefit is more important). Here is another: https://labs.ig.com/static-typing-promise https://labs.ig.com/static-typing-promise
      - adamnemecek 10y ago
        > That article just documents that the safety benefits of static typing are, empirically, rather minuscule, especially compared to the claims for the benefits, which are vastly overblown. Right, which is why I said that you fundamentally misunderstand type theory. > https://labs.ig.com/static-typing-promise https://labs.ig.com/static-typing-promise This article is laughable. There is like billion confounding factors.
stevedekorte 10y ago
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.
mpweiher 10y ago
From the guy who wrote that frameworks are bullshit, and made his money leaning heavily on some of the most well-designed frameworks in the industry.
- dchest 10y ago
  You are misrepresenting his argument about frameworks. Re-read the first paragraph of his post: "Apple's shared frameworks are very useful for sharing executable code and its associated resources among multiple applications, but were historically not designed to be created by authors of consumer applications. I discourage developers from creating frameworks as a method of sharing code, because they encourage code bloat, increase launch times, complicate the developer's fix/compile/link/debug cycle, and require extra effort in setting up correct and useful developer and deployment builds." and the last one: "Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project." http://blog.wilshipley.com/2005/11/frameworks-are-teh-suck-err.html http://blog.wilshipley.com/2005/11/frameworks-are-teh-suck-e... (Note: framework here refers to a specific way of organizing compiled code in OS X for sharing: .framework bundles)
  - mpweiher 10y ago
    And none of his claims about the problems with frameworks are true. Frameworks are trivial to create and use. In fact, with most of my apps, the app itself is just a simple wrapper around a bunch of frameworks. Which, by the way, is also how Xcode is set up. Have you looked how large the actual binary is? On my system, it's 35K. -rwxr-xr-x 1 root wheel 35K May 1 22:12 Xcode* Holy compression, Batman! No, actually, they just moved all of the actual code out into frameworks. Just like the clang and llvm teams put all their code into libraries, which gives us tools like the static analyser and Xcode-integrated syntax tools. So even if I don't have plans to share the code yet, I still just put it in a framework target that's in the same project as the app itself, which takes around 30 seconds, and afterwards is no extra effort. And the idea that only Apple can create software that is worthy of reuse...well fanboys be fanboys, but it actually isn't true.
coldcode 10y ago
It's nice to hear from someone that's been using Objective-C even longer than me who feels the same about Swift. Only 19 years here.

86 points by dchest 10y ago

He skipped over KVO, KVC and related reflection capabilities of Objective-C that make it so flexible. I like and use swift, but I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this".

adamnemecek 10y ago
> I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this". You don't feel more productive in swift? Like a lot more?
- mpweiher 10y ago
  No. EDIT: Just the compile times alone drive me batshit. That doesn't mean that there aren't nice aspects, certainly some of the syntax has been simplified by unifying two disparate syntaxes...but they could have done so much better, even there.
mikeash 10y ago
KVO is horrendous. KVC is occasionally nice but often greatly overused. I certainly wouldn't miss either one.
- mpweiher 10y ago
  "The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way." http://blog.metaobject.com/2016/05/what-missing-in-discussion-about.html http://blog.metaobject.com/2016/05/what-missing-in-discussio... See also: The Siren Call of KVO and Cocoa Bindings http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa-bindings.html http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...
  - chillacy 10y ago
    Yea, I think KVO could be done better. As I recall, Ember properties were pretty neat, and had a nice way of specifying dependencies. A lot less awkward than a bunch of + (NSSet )keyPathsForValuesAffectingValueForKey:(NSString )key methods. I'd also want more strongly typed keys, less strings everywhere. I do use NSStringFromSelector as much as I can, but strings are unavoidable in IB. Also the handling of one-to-many dependencies could be made a lot more intuitive as well.

matt4077 10y ago

My heart skipped a beat today when refreshing my RSS-feeds. It was like a reunion with your first love. The best of new excitement & old familiarity: Wil Shipley is writing again!

ktRolster 10y ago

nevermind, I figured it out.

simscitizen 10y ago
He's saying that the same team that developed LLVM, clang, and ARC (which most people think are good things for the Apple ecosystem) is also bringing you Swift. So you should feel good that the language is being developed by a team with a good track record that will probably find a solution for this particular issue.

bjt 10y ago

This is a very strong endorsement: > I am better Swift programmer after a year and a half in Swift than I was in Objective-C after 26 years.

patrickg_zill 10y ago

I must not be 100% up on my acronyms: what is ARC? it's not "Arc" as in "Lisp like language written by Paul Graham et al" of course.

austinz 10y ago
Automatic Reference Counting: https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting

adamnemecek 10y ago

I doubt you have written much Swift as you are like one of the most die hard Obj-C fanboys there is. Also I have read your blog before and you fundamentally misunderstand type theory, so I wouldn't really expect any other answer from you :-).

mpweiher 10y ago
"However, many of these dynamic features are definitely hacks, with various issues, some of which I talk about in The Siren Call of KVO and (Cocoa) Bindings." "Note that Objective-C's metasystem...is a bad design." You have a funny definition of "fanboy", but suit yourself. And if you've read my blog and think I write about type theory, then you are utterly confused.
- adamnemecek 10y ago
  > And if you've read my blog and think I write about type theory, then you are utterly confused. http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...
  - mpweiher 10y ago
    You have a funny definition of "type theory". That article just documents that the safety benefits of static typing are, empirically, rather minuscule, especially compared to the claims for the benefits, which are vastly overblown. That said: I still like to be able to statically type my programs. I just don't expect it to yield a significant safety benefit (documentation benefit is more important). Here is another: https://labs.ig.com/static-typing-promise https://labs.ig.com/static-typing-promise
    - adamnemecek 10y ago
      > That article just documents that the safety benefits of static typing are, empirically, rather minuscule, especially compared to the claims for the benefits, which are vastly overblown. Right, which is why I said that you fundamentally misunderstand type theory. > https://labs.ig.com/static-typing-promise https://labs.ig.com/static-typing-promise This article is laughable. There is like billion confounding factors.

stevedekorte 10y ago

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.

mpweiher 10y ago

From the guy who wrote that frameworks are bullshit, and made his money leaning heavily on some of the most well-designed frameworks in the industry.

dchest 10y ago
You are misrepresenting his argument about frameworks. Re-read the first paragraph of his post: "Apple's shared frameworks are very useful for sharing executable code and its associated resources among multiple applications, but were historically not designed to be created by authors of consumer applications. I discourage developers from creating frameworks as a method of sharing code, because they encourage code bloat, increase launch times, complicate the developer's fix/compile/link/debug cycle, and require extra effort in setting up correct and useful developer and deployment builds." and the last one: "Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project." http://blog.wilshipley.com/2005/11/frameworks-are-teh-suck-err.html http://blog.wilshipley.com/2005/11/frameworks-are-teh-suck-e... (Note: framework here refers to a specific way of organizing compiled code in OS X for sharing: .framework bundles)
- mpweiher 10y ago
  And none of his claims about the problems with frameworks are true. Frameworks are trivial to create and use. In fact, with most of my apps, the app itself is just a simple wrapper around a bunch of frameworks. Which, by the way, is also how Xcode is set up. Have you looked how large the actual binary is? On my system, it's 35K. -rwxr-xr-x 1 root wheel 35K May 1 22:12 Xcode* Holy compression, Batman! No, actually, they just moved all of the actual code out into frameworks. Just like the clang and llvm teams put all their code into libraries, which gives us tools like the static analyser and Xcode-integrated syntax tools. So even if I don't have plans to share the code yet, I still just put it in a framework target that's in the same project as the app itself, which takes around 30 seconds, and afterwards is no extra effort. And the idea that only Apple can create software that is worthy of reuse...well fanboys be fanboys, but it actually isn't true.

coldcode 10y ago

It's nice to hear from someone that's been using Objective-C even longer than me who feels the same about Swift. Only 19 years here.