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

171–179 of 179 posts

Re: Why you should learn F#

#171

Post by sifoobar »

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…

Definitely.

What could also be taken into account is that I used to be up there preaching the static typing gospel. And then I gradually got fed up with the ceremonies, since they didn't pull their own weight and couldn't keep up.

It's all compromises. The claim is that in return for following rigid rules, they guarantee this and that. Sort of the same deal the state has pushed down our throats since forever. And for a while it seems reasonable, until you pull hard enough to notice the chains around your ankles.

Re: Why you should learn F#

#172

Post by rspeele »

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…

This point of view seems to have a lot to do with programming as craft, and very little to do with programming as engineering.

Nothing wrong with that, but most developers are more concerned with the latter. Writing your own (compression routines|HTML parser|stepper motor driver|user interface controls|game engine) that's fast, cleanly designed, and bug-free is an act of craftsmanship. But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice.

Re: Why you should learn F#

#173

Post by knocte »

atombender wrote: post #149
knocte wrote: post #147

Earlier quoted context omitted.

Mono 2.0 is ancient, nowadays the version is 5.16. That webpage is not worth looking at.

So where should I look? It doesn't seem to be a particularly popular or well-documented topic. The best I've found is this [1]. [1] https://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AO...

FYI a Mono dev removed those old statements about AOT+generics from the page because he agreed with me that they were outdated.

Re: Why you should learn F#

#174

Post by mavelikara »

Dolores12 wrote: post #153
tigershark wrote: post #138

Earlier quoted context omitted.

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#.

> i agree it will take much more time to implement that in c#.

If I am reading the code correctly, here is the Java version (with Lombok [1]):

    @Data class OrderId { final String id; }
    @Data class DeliveryTime { final long time; }
    @Data class DeliveryDetails { final DeliveryTime deliveryTime; }
    @Data class Order { final OrderId id; }
    @Data class DeliveredOrder { 
      final OrderId id; 
      final DeliveryDetails deliveryDetails;
    }
I can imagine C# also having similar expressive powers.

[1] http://jnb.ociweb.com/jnb/jnbJan2010.html. Lombok reduces the drudgery of writing some of the code in Java. Modern JVM languages like Scala and Kotlin have native constructs to express this.

Re: Why you should learn F#

#175

Post by tigershark »

mavelikara wrote: post #174
Dolores12 wrote: post #153

Earlier quoted context omitted.

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

> i agree it will take much more time to implement that in c#. If I am reading the code correctly, here is the Java version (with Lombok [1]): @Data class OrderId { final String id; } @Data class DeliveryTime { final long time; } @Data class DeliveryDetails { final DeliveryTime deliveryTime; } @Data class Order { final OrderId id; } @Data class DeliveredOrder { final OrderId id; final DeliveryDetails deliveryDetails;…

If you are not writing java and you are using lombok then yes, this simple case seems covered well. I still can’t see how Lombok will help with the exhaustive pattern matching in case the order is a union type of several orders types as explained in my other comment or with avoiding mixing up ms and seconds when using a unit of measure in f# for deliveryTime. Also I’m curious how you would change just one field of an immutable object with 10s of properties in Lombok and if the resulting java code is as efficient as F# with its immutable data structures that use the copy on write semantics.

Re: Why you should learn F#

#176

Post by mavelikara »

tigershark wrote: post #175
mavelikara wrote: post #174

Earlier quoted context omitted.

> i agree it will take much more time to implement that in c#. If I am reading the code correctly, here is the Java version (with Lombok [1]): @Data class OrderId { final String id; } @Data class DeliveryTime { final long time; } @Data class DeliveryDetails { final DeliveryTime deliveryTime; } @Data class Order { final OrderId id; } @Data class DeliveredOrder { final OrderId id; final DeliveryDetails deliveryDetails;…

If you are not writing java and you are using lombok then yes, this simple case seems covered well. I still can’t see how Lombok will help with the exhaustive pattern matching in case the order is a union type of several orders types as explained in my other comment or with avoiding mixing up ms and seconds when using a unit of measure in f# for deliveryTime. Also I’m curious how you would change just one field of an…

I agree that exhaustiveness check enforced by compiler is something I will miss in Java.

Persistent data structures have been implemented in Java if that's what you mean by efficient mutations to immutable structures. I can't imagine such structures being hard in any language hosted on the JVM or CLR.

F#, and ML-family languages, surely have their killer features. I am only contesting the claim that the GP made that modeling a domain is a struggle in C# when compared to F#.

Imagine if someone came on this thread and claimed that they struggle to write effectful code in F# which they have been writing in Haskell. Of course, you have counter-evidence of that in all the F# programs you have written so far! I feel the same about the inability-to-domain-modeling claim.

Re: Why you should learn F#

#177

Post by Annatar »

rspeele wrote: post #172
Annatar wrote: post #151

Earlier quoted context omitted.

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…

This point of view seems to have a lot to do with programming as craft, and very little to do with programming as engineering. Nothing wrong with that, but most developers are more concerned with the latter. Writing your own (compression routines|HTML parser|stepper motor driver|user interface controls|game engine) that's fast, cleanly designed, and bug-free is an act of craftsmanship. But if it takes a week and work…

"But if it takes a week and working around the quirks of one off the shelf takes an hour, and the resulting program meets the same requirements either way, it's the wrong engineering choice."

(Un)fortunately, that's not how the world works: it never takes an hour to get the work done even with the off of the shelf solution, and software which gets put together this way usually ends up needing to be babysat and the long term costs to maintaining it are exorbitant. Curiously, the quality of the software ends up being extremely poor not because of using readily available components, but because of the mentality of the people springing for such solutions.

And somehow I have the impression that you and I have different defintions of "engineer": a programmer is not and never had been one. An engineer (which is what I do) gathers requirements, writes a technical specification based on those requirements, designs the software architecture which meets the specifications put forth, proceeds writing said software using scientific theories and principles (the actual process of engineering) and finally writes comprehensive documentation for that software.

Re: Why you should learn F#

#178

Post by atombender »

rkido wrote: post #161
plinkplonk wrote: post #143

Earlier quoted context omitted.

>OCaml actually has excellent tooling — among the best I don't think even the core OCaml devs would claim this. Rust (and Java and Microsoft) toolchains are examples of excellent tooling. OCaml, not so much. That said, the tooling situation today in OCaml is much better than it was a few years ago, which is real progress.

Yes and no. OCaml already has one of the fastest production compilers in the world, acceptable error messages (better than Haskell's, anyway), a great REPL (utop), a high-quality and well-documented build system (dune), a powerful package manager (opam), and a very good language server for IDE integration (merlin). What it's sorely missing right now is higher quality documentation output. Currently, it's hard to navi…

I believe Maven is Java's package manager these days.

Re: Why you should learn F#

#179

Post by konamicode »

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)

There is Mechanic (https://github.com/fsprojects/Mechanic), an OSS project that's meant to take away some of the pain, though I don't have any experience using it and I'm not aware of how useful it is in practice.
Post reply on HN