3 ms·

Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for fol

Also my answer to your question is: I think both. If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software. I’d also argue that apple did not do the former in regards to memory safety, rust did.

mpweiher 3y ago
Demonstrably false. It is easy to write fast software in Objective-C. Harder in Swift, for example.
- zer0zzz 3y ago
  What part are you responding to? I in no way made any claims about objc versus swift performance. I said the way they have tried to address memory safety assumes more compiler optimization and less burden to the programmer than rust.
  - mpweiher 3y ago
    "If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software." The compiler people don't need to optimise for the common case.
    - zer0zzz 3y ago
      That’s literally all compiler people do.. if we see a pattern people are using 80 percent of the time we find a way to make it better. There are ways to make ObjC better optimized at the compiler and runtime level but no one is exactly asking for patches for doing so for objc for very obvious reasons (which I am not going to discuss on a public forum).
      - mpweiher 3y ago
        > That’s literally all compiler people do. I know. My point is that in lots of cases it is unnecessary and in fact unhelpful. > make it better Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".
        zer0zzz 3y ago
        > Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better". I think that depends on if said dynamism is being intentionally used. Far too often it is not, and it gets even worse when that is paired with tools that do automated source code generation like the kinds Meta and Google use (or misuse depending on your definition).
- coopierez 3y ago
  Can you give some examples? "Easy" and "hard" are subjective.
  - mpweiher 3y ago
    1. Swift tends to be about on par with Java in the language shootout. 2. Java tends to at least around 2x slower than C. 3. For my book[1], I wrote a chapter on Swift and did quite a bit of benchmarking. Just how bad Swift was actually surprised me, and I wasn't expecting it to be particularly good. 4. Case study: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Even the worst Objective-C implementation I could think of (really comically bad) was 3.8x the speed of Swift's compiler-supported super-duper-sophisticated implementation. With a bit of work I took that to around 20x. [1] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321842847&linkCode=as2&tag=metaobject-20&linkId=4f7c355096938fece9d7c880e6916ce8 https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

mpweiher 3y ago

Demonstrably false. It is easy to write fast software in Objective-C. Harder in Swift, for example.

zer0zzz 3y ago
What part are you responding to? I in no way made any claims about objc versus swift performance. I said the way they have tried to address memory safety assumes more compiler optimization and less burden to the programmer than rust.
- mpweiher 3y ago
  "If it’s generally too hard for compiler people to optimize for the common case then it will be harder for folks to build great software." The compiler people don't need to optimise for the common case.
  - zer0zzz 3y ago
    That’s literally all compiler people do.. if we see a pattern people are using 80 percent of the time we find a way to make it better. There are ways to make ObjC better optimized at the compiler and runtime level but no one is exactly asking for patches for doing so for objc for very obvious reasons (which I am not going to discuss on a public forum).
    - mpweiher 3y ago
      > That’s literally all compiler people do. I know. My point is that in lots of cases it is unnecessary and in fact unhelpful. > make it better Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better".
      - zer0zzz 3y ago
        > Well, you first need to get agreement from your language users on what constitutes "better". Removing the dynamism from a dynamic language does not make it "better". I think that depends on if said dynamism is being intentionally used. Far too often it is not, and it gets even worse when that is paired with tools that do automated source code generation like the kinds Meta and Google use (or misuse depending on your definition).
coopierez 3y ago
Can you give some examples? "Easy" and "hard" are subjective.
- mpweiher 3y ago
  1. Swift tends to be about on par with Java in the language shootout. 2. Java tends to at least around 2x slower than C. 3. For my book[1], I wrote a chapter on Swift and did quite a bit of benchmarking. Just how bad Swift was actually surprised me, and I wasn't expecting it to be particularly good. 4. Case study: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Even the worst Objective-C implementation I could think of (really comically bad) was 3.8x the speed of Swift's compiler-supported super-duper-sophisticated implementation. With a bit of work I took that to around 20x. [1] https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321842847&linkCode=as2&tag=metaobject-20&linkId=4f7c355096938fece9d7c880e6916ce8 https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...