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

51–60 of 60 posts

Re: On moving code from C# to F#

#51

Post by seabrookmx »

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…

> in terms of tooling, ecosystem

Does F# run on .NET Core yet? Last I checked .NET Core and ASP.NET Core didn't support F#, which is a really big demerit for new projects considering this is the platform Microsoft is pushing for future server side applications (as they should be).

Re: On moving code from C# to F#

#52

Post by snizzitch »

The (potential) terseness of F# seems like a bit of a superficial benefit compared to other features of the language, such as discriminated unions and pattern matching, excellent support for immutable records, structural equality by default, computation expressions, etc.

I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it solely in my own personal time.

However, I'm not certain how much benefit most teams would gain from using F#, after seeing the average (poor) level to which most developers are able to leverage the C# type system to improve the design of their software. Too many developers are forever stuck in a purely imperative paradigm, only knowing how to type one line of code after another, relying exclusively in enums for "extensibility," etc. It seems a bit hopeful to convince the community at large to switch to a language with an improved type system in hope that it will be used to create better software.

Re: On moving code from C# to F#

#53

Post by Retra »

Koshkin wrote: post #41
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.

In many ways code is similar to math, and in math they mostly use one-letter identifiers. And there is a very good reason for that. I have seen texts where authors tried to make formulas more reader-friendly by replacing letters with words, but in that case they might as well have replaced formulas with prose...

Math notation isn't as much concerned with implementation as it is the architecture.

Re: On moving code from C# to F#

#54

Post by snizzitch »

snizzitch wrote: post #52

The (potential) terseness of F# seems like a bit of a superficial benefit compared to other features of the language, such as discriminated unions and pattern matching, excellent support for immutable records, structural equality by default, computation expressions, etc. I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it sole…

I still think it'd be great if the .NET world were to switch over, if only for the sake of us few F# aficionados. :-)

Re: On moving code from C# to F#

#55

Post by MichaelGG »

snizzitch wrote: post #52

The (potential) terseness of F# seems like a bit of a superficial benefit compared to other features of the language, such as discriminated unions and pattern matching, excellent support for immutable records, structural equality by default, computation expressions, etc. I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it sole…

I recall reading that bugs are many times related to the size of the code, across languages. This SO answer has some citations: http://programmers.stackexchange.com/a/185684

But I think somewhere I read that the number of bugs goes up once a function stops fitting on one screen. Or maybe that was Arthur Whitney - J and K seem to do that nicely, and even his C style does so.

Edit: Of course all those other benefits of F# are huge, indeed. But don't underestimate the advantages and pure joy that excellent "programming in the small" provides.

As far as teams being stuck, you're basically saying that mediocre programmers can't handle good things. That's fine, but then the problem is hiring mediocre programmers. I suppose for a lot of basic CRUD/LOB or "enterprisey" stuff, it's important you can take essentially a typist and have them add business rules (like in Wisconsin, if the user is over 50, remove a certain discount). I don't find this type of programming to be particularly interesting though, so who cares what they use?

Re: On moving code from C# to F#

#56

Post by tonyedgecombe »

MichaelGG wrote: post #55
snizzitch wrote: post #52

The (potential) terseness of F# seems like a bit of a superficial benefit compared to other features of the language, such as discriminated unions and pattern matching, excellent support for immutable records, structural equality by default, computation expressions, etc. I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it sole…

I recall reading that bugs are many times related to the size of the code, across languages. This SO answer has some citations: http://programmers.stackexchange.com/a/185684 But I think somewhere I read that the number of bugs goes up once a function stops fitting on one screen. Or maybe that was Arthur Whitney - J and K seem to do that nicely, and even his C style does so. Edit: Of course all those other benefits of…

"I suppose for a lot of basic CRUD/LOB or "enterprisey" stuff, it's important you can take essentially a typist and have them add business rules (like in Wisconsin, if the user is over 50, remove a certain discount)."

Is there really much of that stuff going on? I would have thought they would provide some kind of rules engine to the business rather than hard coding masses of it.

Re: On moving code from C# to F#

#57

Post by dgudkov »

We use both C# and F# in our application, using C# for UI (WPF) and F# for data processing with a lot of calls from C# to F# and vice verse. Using F# was crucial, because it allowed writing heavy processing and complex algorithms (e.g. parallel hash aggregation) in a very clean and concise way with higher-level abstractions which saved us a lot of time. Things like not having to deal with null reference exceptions were also a big time-saver. Without F# it would have taken us one more year to release a production-ready application, or even made it impossible at all given the time & budget constrains that we had. If I ever start another project of that scale I will do it using only F#.

Re: On moving code from C# to F#

#58

Post by greggyb »

tonyedgecombe wrote: post #56
MichaelGG wrote: post #55

Earlier quoted context omitted.

I recall reading that bugs are many times related to the size of the code, across languages. This SO answer has some citations: http://programmers.stackexchange.com/a/185684 But I think somewhere I read that the number of bugs goes up once a function stops fitting on one screen. Or maybe that was Arthur Whitney - J and K seem to do that nicely, and even his C style does so. Edit: Of course all those other benefits of…

"I suppose for a lot of basic CRUD/LOB or "enterprisey" stuff, it's important you can take essentially a typist and have them add business rules (like in Wisconsin, if the user is over 50, remove a certain discount)." Is there really much of that stuff going on? I would have thought they would provide some kind of rules engine to the business rather than hard coding masses of it.

Yes it's going on, and half of it is hacked together in Excel.

Re: On moving code from C# to F#

#59

Post by enricosada »

seabrookmx wrote: post #51
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…

> in terms of tooling, ecosystem Does F# run on .NET Core yet? Last I checked .NET Core and ASP.NET Core didn't support F#, which is a really big demerit for new projects considering this is the platform Microsoft is pushing for future server side applications (as they should be).

yes, using .NET CLI ( http://dotnet.github.io/getting-started/ )

You can check https://github.com/enricosada/fsharp-dotnet-cli-samples/wiki... .

Remember to use last know good version of .NET CLI (see https://github.com/enricosada/fsharp-dotnet-cli-samples/wiki... ), until latest version is fixed

Re: On moving code from C# to F#

#60

Post by carlosnunez »

chadzawistowski wrote: post #38
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?

Yes, Jane Street uses OCaml for their trading systems but we also use(d?) F# for some (very important) odds and ends.
Post reply on HN