11 ms·

I don't really get this complaint: > The already weird-ish addition of Smalltalk/Objective-C keywords inside the f(x) syntax: f(arg:x) I'm a huge fan of named

• choeger 6y ago
  Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward. Think: f(fst:x, snd:y), what is the type of f(snd:4)? I think this can be implemented, but then f(3, fst:5) is either an error or counter-intuitive.
  • skohan 6y ago
    Swift's approach to this is pretty good. Arguments have a fixed order, and whether or not they are named at the call-site is explicitly decided by the author of the function signature. In practice the order and identity of the arguments is quite clear in Swift.
    • codetrotter 6y ago
      As someone who kind of jumped into Swift coming from other languages, I still find this kind of stuff confusing. Is there a good intro to Swift that goes through only what is unique/peculiar about Swift and explains that in a good way to someone that already knows how to program?
      • bluk 6y ago
        I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.
  • tomp 6y ago
    I generally dislike this kind of _implicit_ partial application anyways. I prefer Scala-like way of partial application with `_`: f(fst = _, snd = y)
  • andrenth 6y ago
    OCaml supports this: # let f ~fst ~snd = fst + snd;; val f : fst:int -> snd:int -> int = <fun> # f ~snd:4;; - : fst:int -> int = <fun>
  • Spivak 6y ago
    I don’t think named arguments are as much a problem as function overloading and optional parameters for this. Without overloading you could define the answer as g(x) { f(fst:x, snd:y) } always which would make partial application somewhat ergonomic but makes allowing fst without snd horribly ugly when you have to pass in some spiritual null or _ to. I think these ideas are fundamentally opposed and so I don’t think there’s a good way to have a nice syntax for both.
  • marcosdumay 6y ago
    Yes, this can be implemented. And languages can trust the developers to not write stuff like f(3, fst:5). This is not a large scale pattern where people need help to refactor. The one largest obstacle for partial application (at least of the Haskell style) is optional arguments. You just can not have both.
    • sukilot 6y ago
      I'd bet 4:1 odds that Haskell supports optional arguments with partial application using something like typeclass magic.
      • marcosdumay 6y ago
        If you want optional arguments and partial application, you need some way to declare that the optional arguments are left blank. Haskell-style syntax has no such way. But yeah, functors are all about building stuff like that. So there are similar things, just with a different syntax.
  • deleted 6y ago
    [deleted]
• kiawe_fire 6y ago
  Maybe it's shallow of me, but named/keyword arguments are now at the top of my list of things I want in a programming language. For all the attention given to static typing and unit testing for increasing developer confidence, I think named arguments belong up there as well. Makes reading code so much easier, especially the way they are implemented and encouraged in Swift. As someone stuck doing PHP for my day job, they could buy an awful lot of goodwill from me by implementing something like this in PHP (well, that, and separating arrays from dictionaries, but that seems far less likely to happen).
  • MrBuddyCasino 6y ago
    Automatically generated builders are also nice, not sure yet which I prefer.
    • oefrha 6y ago
      Builders are nice when you actually need to build something with tons of optional arguments. The vast majority of cases where named arguments shine are function/method calls where builders just don’t make sense. Also, named arguments complement/augment the builder pattern.
      • MrBuddyCasino 6y ago
        Good point. Also, named arguments can be compiler checked for mandatory values, with builders the error happens at runtime.
        • swsieber 6y ago
          You can actually have type safe buildrs in rust where trying to call the method that consumes the builder fails to compile if not all the arguments are set correctly. https://github.com/idanarye/rust-typed-builder/blob/master/README.md#rust-typed-builder https://github.com/idanarye/rust-typed-builder/blob/master/R...
          • 6y ago
• jasondclinton 6y ago
  It's really weird to me that this is (currently) the top-voted comment on this article. This little quip is not what the article is about nor does it represent the author's views. Do you have any feedback on that article's thesis that the closure syntax could have been handled better?
  • dsabanin 6y ago
    Hindsight is 20/20. Every programming language changes as it evolves and matures and people understand how to use it best or its domain changes significantly. Unfortunately, this always means accumulating these syntactic and semantical warts. Personally, I think Swift manages to keep a good balance, and it's a very powerful language, with lots of users and compatibility requirements, so it's much harder for them than for many others. Alternative is constant redesign of syntax and behavior that just keeps making users unhappy with every release, breaking their code, libraries and obsoleting the docs. If, to mitigate that, you try to make big changes to the language in big releases, once in a long while, you can easily get into the Python 3, Scala 3, Perl 6 fiasco and that can simply kill the language adoption. It's a hard problem.
    • lizmat 6y ago
      Indeed. In the Perl 6 case, this has been solved by renaming the language to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).
    • aduitsis 6y ago
      Very good point, thank you. As regards Perl 6, a recent development was to rename it to Raku, which (in hindsight) seems like a perfectly sensible decision. The overloading of the name Perl for a language that proved to be something different from Perl 5 caused trouble both ways. Perl 5 was widely considered to be a version that was to be eventually be replaced, whereas Perl 6 was considered a language that was a close and direct iteration of Perl 5. So we basically got the worst of both worlds. Perl 5 is very much in use today, still being actively maintained and is getting new features regularly, while Raku/Perl 6 is a beautiful new different language with interesting ideas being worked on by many brilliant folks, and the notion of trying to be in any way compatible with Perl 5 seems utterly irrelevant today.
• jakear 6y ago
  I like the standard TS/JS approach to this. All arguments are positional and not named at call site, but you can instead pass around object literals.
  • dmitriid 6y ago
    You can't. Unless the function has extra code destructuring those objects. Passing around objects is precisely the workaround people use for lack of named arguments.
    • jakear 6y ago
      Yes, the function definition must opt-in to accepting named arguments. To me that’s not a big deal, and if it means the same object/array spread syntax can be used everywhere for the same effect, it’s miles better than introducing new syntax for named arguments. In my opinion, languages should be simple and small, relating on composition of core syntax features over introducing new syntax for each and every new stylistic fad happens to be popular this year.
      • dmitriid 6y ago
        > if it means the same object/array spread syntax can be used everywhere for the same effect It cannot. Because, as you yourself said it: the function must know how to deal with object-as-parameters. > relating on composition of core syntax features over introducing new syntax This doesn't work for named arguments. They either exist in a language, and you can use them everywhere, or they don't, and you're left with inconsistently implemented workarounds.
        • jakear 6y ago
          It can - you pass objects to functions declared with named parameters, and you pass lists to functions declared with positional parameters. It is true that the function must be written one way one or the other a. priori (it could theoretically detect, but that’s not ideal). And what I’m saying is that if they don’t exist in a language and you can instead using other more core things in the language to implement them rather than adding new syntax (complexity) to the language itself, that’s (in my opinion) a better language and the one I’d rather work in.
• mpweiher 6y ago
  > fan of named arguments in Swift Keyword parameters are great. The way they are done in x.f() syntax languages is sub-optimal, and Swift is particularly weird. > code becomes almost self-documenting Yes, exactly! Dan Ingalls explains this wonderfully in his Object Oriented Programming talk. Highly recommended: https://youtu.be/P2mh92d-T3Y?t=515 https://youtu.be/P2mh92d-T3Y?t=515 The problem is that there is the Smalltalk/Objective-C style keyword syntax or the Pascal/C/C++ etc. function syntax. Both are consistent and complete ways of handling this, though I obviously think the Smalltalk way is better. But it's either/or. When you jam them together, you get a weird mess of special cases and workarounds. I would agree that the benefits of labels outweigh the messiness, even for the x.f() + labels case. So if you're coming from the x.f() side of things, I can fully understand and sympathize the view that they are a pure benefit without drawbacks. But once you have keyword messages, you no longer need the x.f() part of the syntax, because the syntax is completely self-sufficient. And then all the extra messiness of integrating the two makes no sense whatsoever. As an example, the colon and the whitespace are sufficient to separate parameters. So is the comma. So we have...both? There is also the issue that, please correct me if I got this wrong, the label that's in the signature becomes the name of the parameter inside the function. And as far as I can tell it cannot be changed/mapped. That's a horrible coupling of inside and outside. Because of this, you actually need labels in your function declaration even for parameters that are unlabeled. Wut? And because of this, you need another special bit of syntax that says "despite the fact that I am now about to give a label, this is unlabeled". It also means that a name that is actually purely internal to the function is part of the signature. Wat? And sometimes you get partial labels that just kind of sit there. It's really weird when you look at things closely. I guess an analogy would be like a gasoline engine, a hybrid and a fully electric. Yes, the hybrid seems like an obvious improvement to the pure gasoline engine, if at some cost in complexity. But the pure electric car (let's assume a few more years improvement in battery tech) does away with all that extra complexity. Hmm not entirely sure that analogy is all that good.
  • saurik 6y ago
    > There is also the issue that, please correct me if I got this wrong, the label that's in the signature becomes the name of the parameter inside the function. And as far as I can tell it cannot be changed/mapped. That's a horrible coupling of inside and outside. You can in fact provide names for both, and there at least used to be (I think they might have removed this?) some ludicrous special case on the behavior of the first parameter.
• CyberDildonics 6y ago
  I think an IDE that would show the argument names and types when you mouse over a function would give a lot of the benefits of named arguments without putting the responsibility on the language to support them. I think named arguments is an example of trying to solve issues at the language level, when the real problem is the information that is hidden from you while programming.