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

161–170 of 179 posts

Re: Why you should learn F#

#161

Post by rkido »

plinkplonk wrote: post #143
rkido wrote: post #142

Earlier quoted context omitted.

Example of OCaml's object system in use by the creator of OCaml: https://github.com/xavierleroy/cryptokit/blob/master/src/cry... OCaml's object and class systems are excellent; I prefer them to just about anything else. They rarely get used for the simple reason that algebraic types, functors, and first-class modules are better suited to modeling almost any kind of domain logic. Also, I like OCaml's extremely simple…

>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 navigate the generated documentation (e.g., no search bar), it's not held in a centralized online location, and it doesn't do a great job dealing with complex module/functor hierarchies (especially in the presence of destructive substitution).

Unfortunately, much of what I described above doesn't come out of the box. To fix this, the OCaml community is seeking to emulate Rust's cargo tool via the development of the ocaml-platform: http://ocamllabs.io/doc/platform.html

An aside: I didn't know Java had good tooling. I know it recently gained a good REPL. But what is the official package manager, and where is the centralized repository for packages?

Re: Why you should learn F#

#162

Post by cflyingdutchman »

AchieveLife wrote: post #112
cflyingdutchman wrote: post #87

If you want to get paid to learn F#, my team is hiring at Jet/WalmartLabs. If you want to learn more, email me at cole@jet.com.

Has the culture improved since the acquisition? Last time I interviewed there I was treated like dirt.

I'm genuinely sorry that you had a bad interview experience, feel free to email me more details so that I can make sure the feedback is routed to the right people.

Over several years now, I've been very happy with the engineering quality and culture; I feel lucky to work with the people here.

Re: Why you should learn F#

#163

Post by hnbroseph »

tpxl wrote: post #159
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 =…

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

they said "an order cannot ever have DeliveryDetails"

so, if in a nominative subtyping situation like you suggest, a DeliveredOrder is-a Order, and so we can see that some subset of Orders CAN have DeliveryDetails. any method receiving an Order could receive a DeliveredOrder.

Re: Why you should learn F#

#164

Post by contravariant »

hnbroseph wrote: post #163
tpxl wrote: post #159

Earlier quoted context omitted.

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

they said "an order cannot ever have DeliveryDetails" so, if in a nominative subtyping situation like you suggest, a DeliveredOrder is-a Order, and so we can see that some subset of Orders CAN have DeliveryDetails. any method receiving an Order could receive a DeliveredOrder.

> any method receiving an Order could receive a DeliveredOrder.

This seems reasonable, if not outright desirable.

Re: Why you should learn F#

#165

Post by contravariant »

sparkie wrote: post #107
victorNicollet wrote: post #99

Earlier quoted context omitted.

This is what F# does (define multiple classes), but each of these classes only takes one line of code.

Also, it defines them as nested classes, and marks the outer class as `sealed`, as they're closed types, and it prevents the type being extended with new cases. C# can't do this because the compiler rejects putting `abstract` and `sealed` on the same type.

You can kind of solve this by making the constructor of the outer class private and defining all subtypes as nested types.

It's not ideal, but it works.

Re: Why you should learn F#

#166

Post by hnbroseph »

contravariant wrote: post #164
hnbroseph wrote: post #163

Earlier quoted context omitted.

they said "an order cannot ever have DeliveryDetails" so, if in a nominative subtyping situation like you suggest, a DeliveredOrder is-a Order, and so we can see that some subset of Orders CAN have DeliveryDetails. any method receiving an Order could receive a DeliveredOrder.

> any method receiving an Order could receive a DeliveredOrder. This seems reasonable, if not outright desirable.

perhaps, perhaps not. in the abstract there's no way to valuate it. it depends on what it means to be an Order and what it means to be a DeliveredOrder, what assumptions are made by code that receives an Order, etc.

Re: Why you should learn F#

#167

Post by Annatar »

AkosL wrote: post #154
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…

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

You've missed my points. All of them. Sadness ensues.

Re: Why you should learn F#

#168

Post by garfieldnate »

Honestly I was super psyched to get into F# after finishing Dan Grossman's programming languages class, but I abandoned it pretty quickly because setup was so difficult on my Mac.

1) Multiple versions of .Net available (.Net Core, Mono...) and different tutorials and documentation would apply only to one or the other. 2) I went with .Net Core because the community seemed to have decided on that, but there is no easy way to do a cross-platform GUI in F# using .Net Core. 3) I just couldn't find find a simple tutorial taking me from beginner to intermediate using a cross-platform toolchain and development environment. I stumbled around with Visual Studio Code for a while, ran into some compatibility issues with hundreds of lines of errors messages...

I'm sure it would have been fantastic if I had had an F# person help me get set up and started, but the setup curve was too steep to be enjoyable (actually, setting up is never enjoyable. I just want to get to the good part of coding stuff!).

Re: Why you should learn F#

#169

Post by clausok »

sparkie wrote: post #100
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…

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 disliked the module\file order restriction when I started, but have come to appreciate it because every time it felt like a thorn in my side it turned out that the thorn was prodding me towards a better organizational structure.

I've even found that apart from enforcing better design, it can also trigger it. As an illustration, I've had a function 'f' in module 'C' that I decided made more sense in module 'A'. When I moved the function however, module 'A' would no longer compile because 'f' was dependent on a module 'B'. No problem I thought, I'll just move module 'A' below module 'B'. Whoops, now module 'B' won't compile; I didn't realize it was dependent on module 'A'. If I resist the urge to just revert everything and return the function 'f' to module 'C', and I investigate "why does 'f' feel like it belongs in module 'A' and yet placing it there introduces circularity...", often I'll discover a beneficial refactoring that I probably would not have thought of otherwise.

Re: Why you should learn F#

#170

Post by tigershark »

contravariant wrote: post #164
hnbroseph wrote: post #163

Earlier quoted context omitted.

they said "an order cannot ever have DeliveryDetails" so, if in a nominative subtyping situation like you suggest, a DeliveredOrder is-a Order, and so we can see that some subset of Orders CAN have DeliveryDetails. any method receiving an Order could receive a DeliveredOrder.

> any method receiving an Order could receive a DeliveredOrder. This seems reasonable, if not outright desirable.

No, most of the time is wrong. If you have a DeliveredOrder you want to make sure that is not delivered again, so the delivery function should accept only an Order, not a DeliveredOrder. If in some different system you need a domain object that is both an Order and a DeliveredOrder than in F# you simply use an union type:

    type Order = UndeliveredOrder of UndeliveredOrder | DeliveredOrder of DeliveredOrder
And in this way you can write a function that accepts both an UndeliveredOrder and a DeliveredOrder.
Post reply on HN