When coding with F# its very natural to highlight some code in the editor and just evaluate it interactively.

Specific cases, corner conditions can be easily checked right there as you write the code (you still have to write the tests manually).

There is definitely a feeling of being close to your code and data.

Often times large snippets of code are developed interactively using the REPL and then placed in the main program. This (and the fact F# does not have nulls) means F# programs have much lower error rates (also see http://www.simontylercousins.net/journal/2013/3/7/why-bugs-dont-like-f.html)

posted by fwaris

The concept of Type Providers is truly a major innovation in language / IDE design.

Even though I have been using F# for a while, I am still learning quite a bit from tryfsharp.org, especially about the applications of F# in the various domains.

posted by fwaris

Yes its possible with F# and WebSharper.

Check out a live mobile sample here: http://mins.apphb.com .

Source code on codeplex http://ahmobe.codeplex.com

posted by fwaris

Secondly, as someone who has done a fair bit of Smalltalk, C#, Java and F#, I and can contribute from my experience.

Smalltalk certainly has the cleanest syntax that  I have seen. It is a pleasure to work in that language (unfortunately it was all but wiped out by Java). It think it is the most stress free language that I can think of.

Now I work mostly work in F# and I believe that I am better off than when I was working in either Smalltalk (or C# or Java).

F# (or OCaml) has strong *type inference* so most of the time it does not *feel* that you are working in a strongly typed language. If you make a change, the types automatically propagate through. If there is a type conflict, the error gets flagged and you can fix it.

While nothing is perfect, F# strikes a good balance between the extremes of Smalltalk and Haskell.

posted by fwaris

I think instead of a 'language' standard, we should have a VM standard for browsers. If we have a VM standard then we could use any language we want. There will be constraints that all languages will have to adhere to, for interoperability but it's doable. Note both the CLR and JVM have evolved to support a large variety of languages so its technically feasible.

I don't see any standardization effort in regards to a browser VM. Clearly it is needed because javascript can only be taken so far.

posted by fwaris

Aptly, I just wrote an HTML parser using F# "Active Patterns". The parser/serializer is less than 140 lines of code! (I am claiming it to be the world's smallest HMTL parser until proven wrong).

Please see: http://fshtml.codeplex.com/

posted by fwaris

Anyone interested in a good monad tutorial can check this out http://www.infoq.com/presentations/Why-is-a-Monad-Like-a-Writing-Desk.

posted by fwaris

Also, one of the useful F# features  is metaprogramming using computation expressions that provides language extensibility (this is like C++ or LISP macros but not exactly). Donna talks about that at around the 45 minute mark. One of the products that leverages it well is WebSharper (http://websharper.com) for generating client side javascript from F# code.

posted by fwaris

http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

Their language of choice is Standard ML.

posted by fwaris

http://fsviterbi.codeplex.com

See F# source here: http://fsviterbi.codeplex.com/SourceControl/changeset/view/64363#1117175

Test script: http://fsviterbi.codeplex.com/SourceControl/changeset/view/64363#1117178

Some differences:

Actual code (excluding comments) is slighly shorter due to F#'s better type inference and buit-in tuple support.

Path copying is avoided due to 'structural sharing' of F# collections (list in this case)

The double loop calculation is parallelized using TPL wapper "PSeq"  but can be easily serialized. This could be useful for very large state sets on multi-core machines.

posted by fwaris

posted by fwaris

The model's input data comes in multiple Excel files.

F# came in really handy for the complex data manipulation that was required to take the source data and feed it to the solver foundation model.

Data manipulation is one of the areas where functional languages do exceptionally well. Such processing would have been untenable with Java (and even C# despite LINQ).

Suffice is to say that the PoC is very well received and has already saved the company mega bucks.

posted by fwaris

I could use the 'show' and 'freebase' samples for some internal demos coming up next month.

Will these be posted anywhere?

posted by fwaris

F# has a DSL for monads called Computation Expressions so monads 'look' different in F#. Also, I think that once you have a monad implementation, the DSL makes it easier to use the implementation in your code.

So F# provides some extra language support for monads.

However, unlike Scala, F# does not have higher-kinded types so you cannot compose two monad implementations together (as easily).

I struggled with monads at first but then I realized that monads are really about function composition. Here is blog post that emphasizes this aspect of monads that may help with the understanding:

http://fwaris.wordpress.com/2011/07/30/understanding-monads/

posted by fwaris

For now though, I am enjoying the succinctness of F# without losing anything. I have to admit learing F# was harder than I thought as I did not have a funcitonal programming background.

My question is more appropriate for the CLR team but I will ask anyway. It seems that OO-based platform (such as CLR and JVM) are not super optimized for symbolic computing (I learned while reading "F# for Scientists" by John Harrop). Are there any plans for supporting symbolic computing more efficiently? To be honest I don't even know what that even means in terms of CLR changes. I suspect it has to do with creation and garbage collection of extra objects that perhaps can be avoided if the CLR is further optimized for functional languages.

Considering that both CLR and JVM have added special support for dynamic languages (so that dynamic method dispatch is optimized) can something similar be done for F# and other functional languages (Scala and Clojure)?

posted by fwaris

I suppose in future we will have to contend with quantum algorithms (as in quantum computing).

Here is an interesting talk on a quantum algorithm that is supposedly faster than its classical equivalent.

http://www.youtube.com/watch?v=gKA1k3VJDq8

posted by fwaris

Two comments:

a) I think it would help to have a touch screen or something so that when the presenter 'points' to the screen, the pointer can be recorded in the screen capture as well.

b) Greg looks like he has been working way too hard. My suggestion is the have him in check into the nearest day spa for a full day of pamering. Go ahead Greg you have our permission.

posted by fwaris

I think Greg's lectures are a wonderful education for us. Thanks to Greg and Charles. Please keep them coming!

posted by fwaris

The major issue with Scala is that the JVM does not support tailcall optimization (the CLR does).

Not having tailcall optimization is a serious limitation for functional languages. Scala does create loops out of simple recursive calls but in complex composition it can still run into stack overflow issues.

For an illustration of complex compostion involving tailcalls, see the monad implementation example in F# 2.0 language spec (http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/spec.pdf) page 60, definition of "catch".

Scala can't be a serious contender unless the JVM gets tailcalls - or it is ported to .Net.

posted by fwaris

The F# workflow syntactic sugar makes writing async code almost like synchronous code.

posted by fwaris

I am  using F# Agents (mailbox processors) and Async processing in Azure worker roles. The code ends up being much shorter, cleaner and more understandable.

F# may appear difficult at first but stick with it and I can assure you that your effort will pay off handsomely.

posted by fwaris