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

Why you should learn F#

dusted.codes

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Why you should learn F#

#151

Post by Annatar »

nickpeterson wrote: post #85
Annatar wrote: post #70

Earlier quoted context omitted.

It's slow and bloated. For someone who grew up coding intros and cracking protections in machine code on C=64 and the Amiga, such bloat simply won't fly. It's an abomination. I hate wasting my life away waiting for slow software.

If it makes you feel better, the JVM and dotnet communities agree and have been working on strategies to reduce the bloat a lot. They also offer a ton of other resources to help tune things to your liking. I'm sure you can hand write a piece of C or Common Lisp that is very fast. But I'm sure you would also acknowledge that people that are good at JVM/Dotnet could probably write a pretty fast piece of code in them as…

I had a semester of Java and AWT programming at the university. The professor was really good. My final project got a good grade. But after it was over, I knew I'd never touch Java again: any language where I needed to instantiate three different objects just to output a single message to the screen is crap.

Available libraries or lack thereof were never criteria by which I judge a language. Chalk that one up to competing against other coders on the scene. If someone disasembled one's intro code and found that one were using pieces of someone else's code, one instantaneously lost face and would never be able to live it down. It was plagiarism. 35 years later those same people still get derided and laughed at. It's considered extremely lame, because it means one wasn't capable of writing one's own routines. This is elitist in the extreme and those are the stakes for making it to the elite programming circle that is the scene. I'm perfectly fine with that, under the motto "it's lonely at the top". And that's as it should be. IT doesn't need more programmers producing so much bloated garbage; it needs the best programmers producing small, light and fast software that's a joy to use to its users.

So for me, having been tempered by such an elitist, competitive environment, library availability is never important. I understand that open source is different and I understand the advantage of not duplicating code, so if it's already been written and if it is good, clean code I'll use it, but I've no qualms about rolling my own.

I would never allow for library availability to influence my choice of a programming language: the language must stand on its own, including how easy it is for the system administrator to install and upgrade my application during its software managent lifecycle.

As programmers we should never make it easy or convenient for ourselves at the expense of complicating users' life or wasting their time. Never ever is that excusable.

Re: Why you should learn F#

#152

Post by pjmlp »

algorithmsRcool wrote: post #135
knocte wrote: post #129

Earlier quoted context omitted.

AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).

In dotnet land generics are JITted on demand at runtime when you first execute a specific instance of that generic type. So List doesn't necessarily get JItted even though List has been. This poses a bit of a problem for AOT compilation. You would essentially have to either A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it…

Note that since Windows 8, .NET Store apps are fully AOT to native code, there is no JIT.

Window 8.x used the cloud compiler with MDIL deployments (based on Bartok MDIL from Singularity), doing on-device linking.

Windows 10 makes use of .NET Native toolchain.

The only restriction is reflection, all classes that are accessed via reflection need to be explicitly mentioned on a rd.xml file, otherwise the linker might prune them.

Re: Why you should learn F#

#153

Post by Dolores12 »

tigershark wrote: post #138
mavelikara wrote: post #109

Earlier quoted context omitted.

Why do you struggle with this in C#, especially given that you are familiar with the F# style? I don't know C#, but in Java I'd write this as: public class Order { final Optional delivery; public Order(Optional delivery) { this.delivery = delivery; } } public class DeliveryDetails { final long deliveryTimeMs; ... public DeliveryDetails (long deliveryTimeMs,...) { this.deliveryTimeMs = deliveryTimeMs; ... } } My IDE w…

The ide maybe will write a small part of it, but you’ll have to keep reading it forever. And obviously it is modelled wrong because it is possible to have a Delivered order without delivery details, there is nothing that enforces it. Compare it with how I would write it in f#: type OrderId = OrderId of string type DeliveryTime = DeliveryTime of long type DeliveryDetails = { deliveryTime: DeliveryTime...} type Order =…

very elegant solution. i agree it will take much more time to implement that in c#.

Re: Why you should learn F#

#154

Post by AkosL »

Annatar wrote: post #151
nickpeterson wrote: post #85

Earlier quoted context omitted.

If it makes you feel better, the JVM and dotnet communities agree and have been working on strategies to reduce the bloat a lot. They also offer a ton of other resources to help tune things to your liking. I'm sure you can hand write a piece of C or Common Lisp that is very fast. But I'm sure you would also acknowledge that people that are good at JVM/Dotnet could probably write a pretty fast piece of code in them as…

I had a semester of Java and AWT programming at the university. The professor was really good. My final project got a good grade. But after it was over, I knew I'd never touch Java again: any language where I needed to instantiate three different objects just to output a single message to the screen is crap. Available libraries or lack thereof were never criteria by which I judge a language. Chalk that one up to comp…

Luckily, you can just do

  printfn "Hello World from F#!"
4 lines (you can squash it into a single line, but meh), and you have a complete console app

  []
  let main _ =
      printfn "Hello World from F#!"
      0

Re: Why you should learn F#

#155

Post by tatoalo »

algorithmsRcool wrote: post #14

F# is 3 big things to me: Safer threading with immutability Safer programming with null-safety Safer logic with precise domain modeling The precise domain modeling is the real paradigm shift. The whole point of static typing is to inform the compiler about your intent so that it can provide guarantees about correctness. F# makes it easy to define lots of small types that precisely model state so that you can give mor…

I’ve also really liked FsCheck, if well configured of course.

Just a shame that the university exam I took this summer was to implement binary trees and a parser...

Re: Why you should learn F#

#156

Post by piaste »

algorithmsRcool wrote: post #124
sparkie wrote: post #100

Earlier quoted context omitted.

One of the features that makes F# great for organization is the sequential ordering of compilation units which makes it easier to understand code dependencies, and makes it awkward to create mutually recursive types (requiring them to be in the same code file separated by `and`, or defined in signature files in advanced). This might sound like an unwanted restriction, but 9 times out of 10, having mutually recursive…

I mostly agree about mutually recursive types, but I really hate having to keep my files ordered in the project honestly. It might be my least favorite thing about F# (Except that Option is a class not a struct)

> Except that Option is a class not a struct

There is ValueOption now.

It's a mouthful and you'll still have to deal with all the standard library, or other third-party libraries, which produces and consumes Option, but you can address that with some aliases and conversion operators if you want to go all-in:

   type 't voption = ValueOption
   type VOption = ValueOption

   let inline (!) opt = 
     if System.Object.ReferenceEquals(opt, null) then ValueNone else 
     match opt with None -> ValueNone | Some x -> ValueSome x

   let inline (?) vopt = 
     match vopt with ValueNone -> None | ValueSome x -> Some x;;

   // usage
   let x = !(List.tryFind (fun x -> x = 0) [1]);;
   // [] val x : int voption = ValueNone

Re: Why you should learn F#

#157

Post by Tarean »

weavie wrote: post #103
sifoobar wrote: post #83

Earlier quoted context omitted.

For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort. There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now. Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.

I think a lot of it could be personality based. With C, Lisp and Forth you bash out code and run it, see if it works and then make changes. You get much faster visual feedback. With Haskell, you need to put in a lot more up front thought. Then stuff doesn't compile and you spend ages working out why.. You can go for hours without having anything running. The cause of the errors can be quite abstract and obtuse and ma…

Ghc haskell has a bunch of features to make type errors into runtime errors and a really good repl. You can do interactive development pretty well this way.

The way I write php isn't that different from how I write haskell, especially with phan running on save. Php actually requires a bit more thinking in advance because I can't refactor it quite as easily.

Re: Why you should learn F#

#158

Post by piaste »

knocte wrote: post #148
algorithmsRcool wrote: post #135

Earlier quoted context omitted.

In dotnet land generics are JITted on demand at runtime when you first execute a specific instance of that generic type. So List doesn't necessarily get JItted even though List has been. This poses a bit of a problem for AOT compilation. You would essentially have to either A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it…

> So List doesn't necessarily get JItted It does, if the AOT compiler is advanced enough to examine all code and determine that `int` is a possible type being used with List . Mono has had a lot of advancements on these techniques over the years, as it's the only way for them to let Xamarin devs deploy apps on the iPhone.

In regular .NET you can instantiate generic types with a type parameter provided at runtime.

Of course it's not something you should ever do in regular code, but it can be useful for deserialization and stuff like that, so you can create e.g. a list of arbitrary types received over the wire.

Does the AOT compiler just crash if asked to compile a project that uses reflection?

Re: Why you should learn F#

#159

Post by tpxl »

tigershark wrote: post #138
mavelikara wrote: post #109

Earlier quoted context omitted.

Why do you struggle with this in C#, especially given that you are familiar with the F# style? I don't know C#, but in Java I'd write this as: public class Order { final Optional delivery; public Order(Optional delivery) { this.delivery = delivery; } } public class DeliveryDetails { final long deliveryTimeMs; ... public DeliveryDetails (long deliveryTimeMs,...) { this.deliveryTimeMs = deliveryTimeMs; ... } } My IDE w…

The ide maybe will write a small part of it, but you’ll have to keep reading it forever. And obviously it is modelled wrong because it is possible to have a Delivered order without delivery details, there is nothing that enforces it. Compare it with how I would write it in f#: type OrderId = OrderId of string type DeliveryTime = DeliveryTime of long type DeliveryDetails = { deliveryTime: DeliveryTime...} type Order =…

What's the difference between this and having an Order class and a DeliveredOrder extends Order class in C#?

Re: Why you should learn F#

#160

Post by akoeplinger »

atombender wrote: post #134
knocte wrote: post #129

Earlier quoted context omitted.

AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).

"As of Mono 2.0, AOT compilation is only supported for non-generic methods. support for generics is currently under development."

This was outdated info on the website, I've updated the page. Generics are supported with FullAOT nowadays.
Post reply on HN