Hacker News Reader

Comment by jnbiche | Hacker News Reader

Amazing architecture; I remember reading about it and colorforth several years ago when I was researching parallel architectures. I almost want to buy a chip and mount it on a schmartboard, but I've got so much going on right now that I know it would probably sit there after that.

The real reason for my comment, however, is a question: is that idiomatic F#? If so, I like it! It's got a lot of Haskell's succinctness, power, and functional goodness without becoming a tangled mess of indecipherable symbols. Yes, you can write Haskell this way, but in my experience, almost no one does. If this is typical for F#, it deserves a (very close) look.

Add to that the fact that I was impressed with the readability and power of a bit of C# code the other day. I really got to give these MS languages another chance. It's too bad I can't stand the OS (and yes, I've tried Windows 8 -- even worse). How's Mono these days?

View on HN

Mono's actually really solid, and I'm looking to bring it more heavily into use at work. Some of the most active F# contributors are Mono-first, too, so it's a well-supported target.

Well F# is basically ML.net so why not check out OCaml? Same language, and no windows required.

F# runs perfectly fine on Mono. No Windows required there, either.

F# is an ML implementation for .NET; being an ML-based lanaguage, it shares many similarities with OCaml, but as I pointed out yesterday, it is definitely not the same thing as OCaml:

https://news.ycombinator.com/item?id=6660947

Basically, yes.

But in detail, "F# is basicall ML.net" is about as useful a language summary as "Objective-C is basically C++.mac". Despite the common heritage, the two feel quite different once you sit down and spend some time with them.

And seriously, this "the Common Language Runtime is only available on Windows" trope needs to die. Mono's been around for. . . what, a decade now? Something like that.

I agree that the underlying runtime and ecosystem affect the "feel" of programming in a given language a lot, but the comment above was specifically referring to the snippet of F# in the blog post, which could be trivially translated into OCaml.

AFAIK the main differences around the runtime are that the CLR has true concurrency and access to more libraries without using FFI, while OCaml is able to produce very tiny executables (~200kb) if you use the native compiler.

Sounds like the differences go rather farther than you know:

The object model's really quite very different - F# uses CLR objects instead of OCaml-style ones.

F# has computation expressions, which are a rather nice riff on monads.

F# doesn't have functors. Since it uses CLR objects it does have .NET generics, but it's just not the same

Active patterns and type providers are neat, too. Though I believe there are Caml macros that implement both.

From my research, it looks like F# does not have structural typing (since it uses the .net type system). Does this mean you can't use constraints on types, like make a type with a range (0.0-1.0) or a type from an enum (man|woman|child)?

These kinds of type constraints are one of my favorite things about Haskell, and one of the reasons I'm really interested (in another language category) in Ada -- you can actually model real-life things using the type system.

F# uses nominal typing - that's another difference between it and Caml.

That said, F# will let you do the things you listed - one can be handled with traditional OOP techniques, and the other is handled by discriminated unions. Structural typing is a bit different from what you're describing - it's more a kind of compile-time duck typing.

I actually think F#'s switch to nominative typing is a big improvement over its Caml roots. When I'm trying to build out a type system that's meant to use type checks to enforce sanity, I want to have explicit control over when and where types are considered to be equivalent. Just because the types foo and bar implement members with similar signatures does not mean that they carry the same semantics.

Therefore, IMO having the language try to be clever and jump to the conclusion that anything that looks like a duck must be a duck is a hindrance to type safety. It's also a bit of a maintainability hassle: Having a formal type definition for each equivalence class makes it easier to find which types need to be modified accordingly when an equivalence class's definition changes.

What are your main issues with working on Windows 7?

Probably because it's probably Windows. :)

I use Windows at my day job and get paid well to develop and admin for it. I also have a few personal applications that require a Windows VM at home.

But my personal machines run Linux, which I find is more pleasing for development, exploring, security, tinkering and such. Plus you can tailor your environment to suit your needs (from embedded to supercomputing), not that of a marketing manager.

Reply on news.ycombinator.com