3 ms·

What amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.

by zionic 7y ago

jshier 7y ago
You're surprised a relatively easy to implement, one off feature with no dependencies and no impact on the rest of the language can be done before a feature that impacts huge areas of the language and requires underlying runtime and compiler support?
- zionic 7y ago
  It's easy enough to say things like "well if you don't like it don't use it". Meanwhile as a primarily swift dev I can't stop others (outside of my team) from using this disastrous syntax. The first time I have to dig into someone's backwards codebase that uses I'm gonna flip. Objects defining named functions allows you to reason about them logically. Car.tireSizeInches() returns an Int type. Any other developer can see that and know whats up, or type "Car." and explore relevant functionality. What the crap does Car() do? Etc. This is a huge backwards step for swift syntax. I hope most of the large open source libs ban it. As for implementation difficulty, see my sibling reply.
wvenable 7y ago
Well callAsFunction is extremely simple to implement and test. Where as async/await is a much bigger and more complex feature. It's not amazing, it's totally logical.
- zionic 7y ago
  I understand the difference in difficulty, my point is any incremental time spent on this is wasted and could have contributed towards something else that's useful.
  - wvenable 7y ago
    That's not how software development works. If I've got a new team member, I'm not going to put him on async/await. I'm going to find him something simpler to work on. Or maybe I've been working on a feature for a few months and I need a break to clear my head so I'll work on a smaller feature for a while. Software development isn't just assembling widgets on an assembly line. It's a creative process. Developers aren't chained to their desks pumping out a non-descript streams of "code" that become different features. Likely incremental time spent on this had almost no real impact on more difficult and useful features.
    - rhysmorgan 7y ago
      > I'm going to find him something simpler to work on. Sure, but why should this non-feature which makes code harder to read and reason about even be built in the first place? All to save `.parse` at the call site of a parser, for example?
      - edflsafoiewq 7y ago
        This syntax already exists in the language. If you want users to be able to use the obj() syntax you can already give them a closure for obj. Allowing it for user-defined types too removes an artificial syntactic distinction.
pixelrevision 7y ago
Async/await might actually help you clean up your codebase. Much better to have more syntactical sugar to keep code reviews lively and add more surprises for future developers!

What amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.

by zionic 7y ago

What amazes me as a huge Swift fan is that crap like callAsFunction gets priority over things like proper async/await.

You're surprised a relatively easy to implement, one off feature with no dependencies and no impact on the rest of the language can be done before a feature that impacts huge areas of the language and requires underlying runtime and compiler support?

zionic 7y ago
It's easy enough to say things like "well if you don't like it don't use it". Meanwhile as a primarily swift dev I can't stop others (outside of my team) from using this disastrous syntax. The first time I have to dig into someone's backwards codebase that uses I'm gonna flip. Objects defining named functions allows you to reason about them logically. Car.tireSizeInches() returns an Int type. Any other developer can see that and know whats up, or type "Car." and explore relevant functionality. What the crap does Car() do? Etc. This is a huge backwards step for swift syntax. I hope most of the large open source libs ban it. As for implementation difficulty, see my sibling reply.

wvenable 7y ago

Well callAsFunction is extremely simple to implement and test. Where as async/await is a much bigger and more complex feature. It's not amazing, it's totally logical.

zionic 7y ago
I understand the difference in difficulty, my point is any incremental time spent on this is wasted and could have contributed towards something else that's useful.
- wvenable 7y ago
  That's not how software development works. If I've got a new team member, I'm not going to put him on async/await. I'm going to find him something simpler to work on. Or maybe I've been working on a feature for a few months and I need a break to clear my head so I'll work on a smaller feature for a while. Software development isn't just assembling widgets on an assembly line. It's a creative process. Developers aren't chained to their desks pumping out a non-descript streams of "code" that become different features. Likely incremental time spent on this had almost no real impact on more difficult and useful features.
  - rhysmorgan 7y ago
    > I'm going to find him something simpler to work on. Sure, but why should this non-feature which makes code harder to read and reason about even be built in the first place? All to save `.parse` at the call site of a parser, for example?
    - edflsafoiewq 7y ago
      This syntax already exists in the language. If you want users to be able to use the obj() syntax you can already give them a closure for obj. Allowing it for user-defined types too removes an artificial syntactic distinction.

pixelrevision 7y ago

Async/await might actually help you clean up your codebase. Much better to have more syntactical sugar to keep code reviews lively and add more surprises for future developers!