3 ms·

There are a bunch of different approaches that other languages that take that make this unnecessary as well. Some functional languages simply don't tend to use

There are a bunch of different approaches that other languages that take that make this unnecessary as well. Some functional languages simply don't tend to use mutable objects with method/property syntax so you can just chain function calls to achieve the same result. (Also some languages have syntactic sugar to do the same thing for method calls) VB.net (unpopular as it is) has "With" statements that allow you to simply avoid repeating the name of the object you are mutating with method calls/property assignments (this looks very similar to a "fluent api" but it's just a serious of normal property assignments with the object name omitted using a with statement): With theCustomer .Name = "Coho Vineyard" .URL = "http://www.cohovineyard.com/" .City = "Redmond" End With

thriftwy 5y ago
Functional programming won't save you from the fact that you don't want to have constructor with dozen unnamed parameters. That's also fragile in the face of code change.
- Smaug123 5y ago
  Well, the situation is a bit better than you make out. Your parameters may be unnamed, but they should at least be typed. Cases like `Directory.Move : IDirectoryInfo -> IDirectoryInfo -> unit` are a bit of a pain to give unambiguous types, but a twelve-parameter method in which every parameter has a different type (`CustomerId`, `BankId`, whatever - tiny types) is orders of magnitude less fragile than one in which everything is a string.
  - thriftwy 5y ago
    It's still not good enough. Java also gives you typing but builders and chained setters are still used.
    - Smaug123 5y ago
      That's because Java, like C#, makes it really painful to define a new type. When it takes huge amounts of boilerplate to define a new type to hold a piece of dumb data, of course nobody does it! In F# it's one line of code, so it's idiomatic to define dozens of tiny types and use them to constrain the semantics of your program.
      - thriftwy 5y ago
        I'm just not sure it will solve the problem in the fact of forward compatibility.

thriftwy 5y ago

Functional programming won't save you from the fact that you don't want to have constructor with dozen unnamed parameters. That's also fragile in the face of code change.

Smaug123 5y ago
Well, the situation is a bit better than you make out. Your parameters may be unnamed, but they should at least be typed. Cases like `Directory.Move : IDirectoryInfo -> IDirectoryInfo -> unit` are a bit of a pain to give unambiguous types, but a twelve-parameter method in which every parameter has a different type (`CustomerId`, `BankId`, whatever - tiny types) is orders of magnitude less fragile than one in which everything is a string.
- thriftwy 5y ago
  It's still not good enough. Java also gives you typing but builders and chained setters are still used.
  - Smaug123 5y ago
    That's because Java, like C#, makes it really painful to define a new type. When it takes huge amounts of boilerplate to define a new type to hold a piece of dumb data, of course nobody does it! In F# it's one line of code, so it's idiomatic to define dozens of tiny types and use them to constrain the semantics of your program.
    - thriftwy 5y ago
      I'm just not sure it will solve the problem in the fact of forward compatibility.