Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On moving code from C# to F#

felienne.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: On moving code from C# to F#

#31

Post by UnoriginalGuy »

bunderbunder wrote: post #17
UnoriginalGuy wrote: post #11

Earlier quoted context omitted.

That's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).

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.

Re: On moving code from C# to F#

#32

Post by superuser2 »

xeromal wrote: post #12
iuyoynp wrote: post #2

please dont override default scrolling behaviour, the site is unusable

For someone uninformed, what did they change? I'm able to scroll using the keyboard keys, scroll bar, and arrow keys on my keyboard. Is mobile scrolling what's broken?

They added a TON of "inertia." Flick the trackpad a tiny little bit and it keeps moving long after I take my fingers off, giving an entirely different screenful.

Your users know better than you how fast they intend to scroll. Always.

Re: On moving code from C# to F#

#33

Post by edgyswingset »

platz wrote: post #30
conceit wrote: post #29

Earlier quoted context omitted.

> short, generic function names fit the length of the functions. Long names might be indicative of some deeper problem with coding style.

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 res = getResult input
Granted there's some exception, such as defining your own operators. F# does this itself, where "|>" is "let (|>) f g = g f". I don't think you gain much from adding verbosity to that.

Re: On moving code from C# to F#

#34

Post by MichaelGG »

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.

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. But for programming "in the small" it's just needless noise.

It's not just the hassle of typing long names out; a good editor can help there. It's the visual overhead of having so many extra pixels lit as you read things.

Short functions are good for local functions:

  var sb = new StringBuilder()
  sb.AppendLine bla
  ...
  sb.AppendLine foo // And another 5 places in the following 10 lines of code.
It's nicer to instead have: let al = sb.AppendLine al bla ...

This is especially true then the local code pattern is 2, 3, or more lines or when it contains branches.

Re: On moving code from C# to F#

#35

Post by conceit »

platz wrote: post #30
conceit wrote: post #29

Earlier quoted context omitted.

> short, generic function names fit the length of the functions. Long names might be indicative of some deeper problem with coding style.

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.

Well, if you need to scroll to read the whole name, that's indicative of some deeper problems, alright. That's kind of what I was getting at, just that the code also needs to fit in my head. Use of verbose identifiers might be linked to verbose code and that might or might not be harder to follow. There is a sweet spot.

I am just defending that I don't know what car means mainly because I don't know LISP and I refuse to read documentation, but out of lazyness mind you.

On a related note, I often discover that trying to shorten text, sentences become a lot clearer when they are less verbose. Compare that to: On a related note, I often notice shorter sentences are clearer. Compare that to the overly terse Short Sentence Clarity!

Re: On moving code from C# to F#

#36

Post by carlosnunez »

I LOVE F#. I wish I could use it more often. I haven't used it since I worked at Jane Street three years ago, and Jet.com is the only other place that's using it seriously at the moment.

It is such an expressive and clear language to write code in. That is until you start needing to use imperative .NET types :)

Re: On moving code from C# to F#

#37

Post by rspeele »

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.

Most likely they're referring to the C# part being written for Microsoft's "ASP.Net Web API" framework, rather than just being a web API in general.

That framework is designed for C# programmers and most of the resources (tutorials/stackoverflow answers/etc) around it will assume you are writing C#. So it makes some sense to use C# for that part of your application even if most of the underlying business logic is implemented in separate F# libraries.

That's probably why they specified it - to explain why they're using both C# and F#. I can see how it could be confusing, especially if you're not familiar with that rather generically named framework.

Re: On moving code from C# to F#

#38

Post by chadzawistowski »

carlosnunez wrote: post #36

I LOVE F#. I wish I could use it more often. I haven't used it since I worked at Jane Street three years ago, and Jet.com is the only other place that's using it seriously at the moment. It is such an expressive and clear language to write code in. That is until you start needing to use imperative .NET types :)

I thought Jane Street used OCaml! (I know the two are similar.) Why did they need to target the CLR?

Re: On moving code from C# to F#

#39

Post by was_boring »

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…

I perfer the verbosity because it helps with eliminating ambiguity when the code changes hands or goes into "maintenance". This is especially true in weakly, or duck, typed languages.

Both have merits though.

Re: On moving code from C# to F#

#40

Post by mintplant »

jaegerpicker wrote: post #28
iuyoynp wrote: post #2

please dont override default scrolling behaviour, the site is unusable

Not sure what issues you are seeing but I'm able to scroll completely normally.

There's a "smoothscroll.js" loaded by the page. Looks like it only targets Chrome users.

http://www.felienne.com/wp-content/themes/zerif-lite/js/smoo...

Post reply on HN