jdh30

I just noticed your post (https://news.ycombinator.com/item?id=18050422) about courses but cannot comment on it because it is too old. I am an employer with strong opinions. If you'd like to hear them please e-mail me here: https://www.idtechex.com/contact/team/dr_jon_harrop.asp

There are 182 articles in the F# Journal.

The F# News blog has had many applications on it:

http://fsharpnews.blogspot.co.uk/2010/12/most-popular-f-samp...

So has Phil Trelford's blog:

http://trelford.com/blog/

And many others.

I have written thousands of pages of example applications in articles for the F# Journal.

F# Journal articles walk through the design and implementation of dozens of different example applications including both client GUI and server with sockets and so on.

> Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

I just watched it. Great to see somebody else trying but this is no more advanced than OC4MC and they are using Fibonacci as an example when I already used a complete parallel ray tracer with shared memory when benchmarking parallelised HLVM code:

http://flyingfrogblog.blogspot.co.uk/2010/01/naive-paralleli...

They've got a lot of catching up to do before they can overtake and I'm concerned that retrofitting a modern GC on a 20th century VM will never work because OCaml has such poor locality of reference due to massive unnecessary boxing.

> TBH I don't miss multithreading in OCaml,

I said multicore, not multithreading. I dot lots of concurrency and parallelism in F# without having to worry about multithreading.

> if you write applications which expose some sort of API over a socket that will scale to clusters not just multicore.

You're proposing deep copying all of your data structures when multicore programming is all about sharing data between cores using shared caches. If you copy then your identical copies of the data compete for space in a shared cache.

> And you can program those kinds of applications quite nicely with Lwt or Async already.

Lwt and Async are for concurrent programming. In particular, they are extremely slow.

> Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.

Ctypes looks great. Didn't exist when I last used OCaml.

> Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.

Has anyone tried to write anything much using it?

> Wow, ML syntax is actually better than OCaml. It's a shame the former was used as a base for F#.

I prefer this:

http://www.ffconsultancy.com/languages/ray_tracer/code/1/ray...

to this:

http://www.ffconsultancy.com/languages/ray_tracer/code/1/ray...

> One thing I think F# got right is that it removed some of the "flexibility" in OCaml's syntax. For example, it uses significant whitespace to define scoping, which removed (in nearly all cases) the need for the 'in' keyword and lots of parentheses and semicolons. That may not sound like a huge deal, but it does greatly improve the readability of F# code (all other things being equal).

I must disagree. I once translated a significant (15kLOC) commercial OCaml code base into F# and took the opportunity to quantify the syntactic benefits as <3% by volume of code. The flipside is that F# misinterprets code pasted from the web, rendering most code on the web useless. That is a crippling deficiency of F# in my eyes and a major reason to go back to the superior OCaml solution.

OCaml will give you compiler warnings on the incomplete and redundant match cases. F# will silently execute a semantically different version of your code. I prefer OCaml. Indentation sensitivity was one of F#'s design flaws.

> SML has stagnated for almost 20 years

I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.

Classic Dunning-Kruger effect.

Demand for OCaml and F# people here is insane right now. I just turned down a £390k job offer.

> The language was developed by a team in Microsoft Research, not by a product team. If a product team thought there was a good product strategy for the language, they would have taken it over.

Luke Hoban's F# product team in Redmond develop F# with the research team in Cambridge UK continuing to evolve it.

> Some of the reasons given for F# are not a direct customer benefit. Example: show that CLR can support languages other than C#.

F# was not the second language after C# to run on the CLR.

> Given the question here on HN, it's not obvious to some people why Microsoft invested so much in the language.

The investment is tiny for Microsoft and has already paid off by drawing people into the Windows platform who then buy Visual Studio 2010 in order to use F#.

> Since pure functional languages are easier to parallelize.

Purely functional programs have a lot of problems with parallelism. If you want to parallelize your F# code effectively, you write Cilk-style code with heavy use of mutation and not Haskell-style code with purely functional data structures.

Read this: http://flyingfrogblog.blogspot.com/2010/06/regular-shape-pol...

You can nest a recursive function inside a non-recursive one and inline that.

I love it!

Multicore is one obvious huge advantage over OCaml. Associating basic functions (like comparison) with types is a major advantage. Equality types are a huge advantage. Overloading and associated benefits like support for the full range of primitive types is another important advantage.

Also, F# executables tend to be orders of magnitude smaller than OCaml executables but, of course, the F# ones need a CLR installed to run them.

F# was just released under to OSI-approved Apache open source license.

Haskell doesn't have active patterns. Although they were originally proposed for Haskell by Wadler, they don't make so much sense with non-strict evaluation because you can just write code to compute the result and match over it safe in the knowledge that it will be computed on-demand only as far as required.

I'm Jon Harrop. HLVM is a hobby project that I work on when I can find the time. If I could commercialize it then I would but there is no short-term way to make decent money from a VM/language that I can see.

I suggest you think carefully about when HLVM's fat references are a disadvantage compared to the alternatives and why. The real reasons are not at all what you're thinking (or what I thought for a long time).