5 ms·

I always thought that introducing keys in function parameters was a mistake.

• frizlab 3y ago
  I disagree. It makes the code readable.
  • makeitdouble 3y ago
    It's still a tradeoff: in a previous team switching languages it openned the door to function with 5+ parameters, when that was highly throwned upon otherwise. It's a tool to help better manage complexity, and that naturally invites more complexity as well.
    • bigyikes 3y ago
      is that an issue of the language or of the team? adding additional names does not add additional complexity. complexity arises in interactions between components.
      • makeitdouble 3y ago
        I see it as mostly influenced by the language and tooling. From there, some people will be more attracted by one side or the other, but when moving stack you tend to follow the stack's natural incline. For instance ruby helps to have shorter, less verbose code, but with more hidden components. Rails rose from there, tooling tends to support that style. I've seen java devs moving to ruby and naturally writing less verbose code. In contract Java tooling makes it a lot more manageable to write 40 character long classes, deeper dependency trees and injections and potentially auto-generate half of the needed methods. The cost is low, and there's less incentive to fight that trend when tools help you abstract part of it.
        • bigyikes 3y ago
          i agree but you discuss verbosity and not complexity
          • makeitdouble 3y ago
            Fair point. You're right that total complexity across the system fundamentally doesn't change (it's up to the devs and the problems at hand). Local complexity in each part of the system can vary, but the whole will probably always be least as complex as it needs to be.
• seanalltogether 3y ago
  I disagree, I think the more self documenting the code is, the better. It's also nice with code completion because when I start typing a function, I'm given a list of all the overloads for that function, and when I pick one I get all the arguments sitting there ready for me to fill in.
  • msie 3y ago
    You still get that with traditional languages that don’t use keywords like java. With Swift you have to read a lot more to get the right function since many vary in the number and type of parameters.
• yen223 3y ago
  Not having keys in function parameters is a mistake. Swift does have an unconventional approach to function keys though, wherein you can specify an "external" label and an "internal" label: func greeting(for person: String) -> String { "Hello, " + person + "!" // the argument is "person" inside the function body... } print(greeting(for: "Dave")) // ... but it's "for" when calling the function I'm not sure if I like it or hate it, but it is cool.
  • jwells89 3y ago
    I love the internal/external labeling. With a little thought it can make for code that reads more nicely than is possible otherwise.
    • dorianmariefr 3y ago
      JavaScript has that with: const hello = ({ for: person }) => `Hello ${person}` hello({ for: "Dorian" }) 'Hello Dorian'
      • yen223 3y ago
        Javascript's one is a little bit different in that you are renaming the destructured variable - it's not a function-specific thing - whereas Swift's version is a property of the function. e.g. const user = {id: "123"}; const { id } = user; // This extracts the `id` field const { id: userId } = user; // This also extracts the `id` field, but renames it to userId console.log(userId)
      • jahewson 3y ago
        It does indeed, but the cost is an object allocation for every function call.
    • airstrike 3y ago
      it's one of those small things that are also brilliant in hindsight
• astrange 3y ago
  The best function calling syntax I've ever used is the video scripting language AVISynth, which is mostly key based. It's basically Swift but more flexible and informal. http://avisynth.nl/index.php/Grammar#Functions.2C_Filters_and_Arguments http://avisynth.nl/index.php/Grammar#Functions.2C_Filters_an...