Live data from Hacker News

On moving code from C# to F#

felienne.com

21–30 of 60 posts

Re: On moving code from C# to F#

#21
post #12
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?

also seems to work fine on my end. scroll wheel, middle mouse button work too. seems normal.

Re: On moving code from C# to F#

#22
post #4

Is it possible to call F# code easily from C#? Or vice versa?

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

Have they fixed the intellisense yet? Last time I tried to call c# from f# it compiled but autocompletion in vs didn't work.

Re: On moving code from C# to F#

#23

Earlier quoted context omitted.

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

Yes, I agree, but you need to be really careful about tail call recursion optimisation when calling f# code from c#. In F# it is always guaranteed, in c# only on 64 bit 4 and above runtime if I remember correctly, so you can't really rely on it for production code.

Unless it's changed, F# doesn't emit "tail." prefixes for tailcall. Nor is it guaranteed. The F# compiler will, in some cases, manually turn your tailcall-OK code into a loop. But it doesn't do it in all cases (nor could it).

The F# compiler used to emit "tail." prefixes in every case that was eligible. But not only does the CLR have lots of restrictions, it was slower to request tailcalls.

Maybe that changed in the last version or two.

Edit: OK I found the email where I had asked fsbugs why tailcalls were no longer generated. But that was in 2009 so I'm more out of date than I remember.

In the release notes[1] for the May 2009 release, there's this section:

Optimizations for Tailcalls

On some implementations of the CLI, normal calls can be more efficient than tailcalls. An optimization is now applied to determine if a function is “closed” in the sense that it never takes any tailcalls outside a finite non-recursive callgraph. If so, the use of tailcalls is suppressed.

1: http://blogs.msdn.com/dsyme/archive/2009/05/20/detailed-rele...

Re: On moving code from C# to F#

#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 verbosity with readability and get scared.)

I tried porting a small demo program, a few hundred lines, directly from C# to F#. It required only 1/20th of the type annotations. I've written web APIs in F# and many took about half the lines of code.

I particularly like the ease in which I can define local functions to reduce redundancy. In, say, C#, there's so much overhead involved that it's just not worth it.

Going back to F# I've written years ago hasn't been hard either. Since the code is so compact, it's not difficult to figure things out.

F# should be MS's flagship. While F# isn't perfect (could use more inference, traits or typeclasses, and macros), in terms of tooling, ecosystem, language features it come out near the top.

Re: On moving code from C# to F#

#25
post #12
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?

I'm using Chrome on Mac OS and I can't scroll left and right in any of the code examples. This is particularly bad because the OS hides scroll bars by default under the assumption that you'll be able to scroll left and right with the trackpad.

Also, it's hard to describe exactly what the problem is, but scrolling up and down definitely feels weird and frustrating. For example, a light push that normally goes down a few lines of text on any other page seems to go down a full page. It also seems "stickier", like any scrolling takes a split second to "kick in". As a more contrived example, if I hold two fingers down on the trackpad and scroll up and down in place, any other page will scroll up and down following my fingers, but this page seems to jump around in an inconsistent way.

Something on the page is trying to intercept scroll events and do something smart, but at least on a trackpad on Mac OS in Chrome it makes scrolling feel much worse and less predictable. It looks like Chrome, Firefox, and Safari all behave differently here, with Chrome behaving the worst.

Re: On moving code from C# to F#

#26
post #22

Earlier quoted context omitted.

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

Have they fixed the intellisense yet? Last time I tried to call c# from f# it compiled but autocompletion in vs didn't work.

Yeah, the intellisense is a lot better than it was in earlier versions.

That said, it doesn't attempt to read your mind, so the intellisense only kicks in when the type you're interacting with is unambiguous. So, for example, you'll need to explicitly state a function parameter's type before intellisense will help you figure out what methods you can call on it.

Re: On moving code from C# to F#

#27

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.

Re: On moving code from C# to F#

#29
post #27

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.

> short, generic function names

fit the length of the functions. Long names might be indicative of some deeper problem with coding style.

Re: On moving code from C# to F#

#30
post #29
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.

> 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.
Post reply on HN