On moving code from C# to F#

Post by Koshkin » Sun, Mar 20, 2016, 1:07 AM UTC

douche wrote: post #27

MichaelGG wrote: post #24

I've been using F# for a while and it's been excellent. It's just so less frustrating than writing C# in all its verbosity. There's really no reason to not use F# other than legacy or poor management. (Some folks just don't "get it". Perhaps the same kind of people that use a 20 char variable name when 3 would do. Or that are cautious about using local type inference. I don't know. But too many people conflate verbos…

> use a 20 char variable name when 3 would do. I generally think functional programming is a smart idea, but knock it off with the short, generic function names. We're not writing Fortran on an 80-char terminal any more. Name shit what it is, it's going to auto-complete anyway after you type 3-4 characters, so you might as well give it a name that you won't have to puzzle about later.

Post by smt88 » Sun, Mar 20, 2016, 1:15 AM UTC

MichaelGG wrote: post #34

douche wrote: post #27

Earlier quoted context omitted.

> use a 20 char variable name when 3 would do. I generally think functional programming is a smart idea, but knock it off with the short, generic function names. We're not writing Fortran on an 80-char terminal any more. Name shit what it is, it's going to auto-complete anyway after you type 3-4 characters, so you might as well give it a name that you won't have to puzzle about later.

I'm talking more like locals. Consider: var newCustomers = getNewCustomers() foreach(var newCustomer in newCustomers) { newCustomer.this .that etc. } Depending on the length of the surrounding function, you're better off using "xs" and "x". Or "cs" and "c". I think people trick themselves into thinking that long names somehow provide more context. At a high level, this is correct: modules, exported functions, etc. Bu…

  var newCustomers = getNewCustomers()
  
  foreach(var newCustomer in newCustomers)
  {
     newCustomer.this .that etc.
  }

Post by bunderbunder » Sun, Mar 20, 2016, 3:52 AM UTC

UnoriginalGuy wrote: post #31

bunderbunder wrote: post #17

Earlier quoted context omitted.

I'm guessing the poster means an ASP.NET WebAPI controller that relies on an assembly written in F#, not a process making web API calls.

Why does it being WebAPI-exposed interface matter at all then? It is an extremely confusing way of phasing it. It literally doesn't matter, and even reading back if that IS what they meant then it is still a really circular way of wording it.

Post by nv-vn » Sun, Mar 20, 2016, 4:18 AM UTC

edgyswingset wrote: post #33

platz wrote: post #30

Earlier quoted context omitted.

I think the reason functional programmers like short, terse names is because they need to see the structure of the code more than the individual identifiers. More verbosity makes it hard to get a picture of whats going on locally. Pattern Matching and Recursion creates structures that are easier to understand if it fits on the screen.

There's a happy middle ground there. At the call site is where it matters a lot more. If you have a function that's basically nothing but a pattern matching expression, the name of a parameter matters a lot less than the name of the input when you call that function. Same goes for what you name the result. If you do this: let r = f x Then you might be a fucker. But most good F# code I've seen is more reasonable: let…

    let r = getResult input
    let s = "abc" + r
    let t = doSomethingWith s
    printfn "%d" t

  "abc" + getResult input |> doSomethingWith |> printfn "%d"

Post by recursive » Sun, Mar 20, 2016, 5:07 AM UTC

lerax wrote: post #9

Easy, only up 3 tones.