Don Syme's WebLog on F# and Related Topics - All Comments

re: Twelve F# type providers in action

James Moore — Mon, 29 Apr 2013 21:27:22 GMT

FYI, lots of those image links are dead (CSV, XML, JSON...)

[ Don says: thanks! should now be fixed ]

re: "Stati-C/AL Supervision – static analysis for Microsoft Dynamics NAV"

Ryan Riley — Sun, 14 Apr 2013 15:25:01 GMT

You can learn more from the recent C4F# live meeting: http://fpish.net/course/462

re: "Stati-C/AL Supervision – static analysis for Microsoft Dynamics NAV"

Bent Rasmussen — Sun, 14 Apr 2013 14:40:01 GMT

Thanks for the mention Don; we've just come out with another tool, Prism:

stati-cal.com/.../prism

This is a WPF application (using the same libraries we wrote for Supervision, albeit improved and extended). Everything - even the WPF project is written in F# (well, one caveat is that one project with some user controls is written in C#).

re: F# testimonials on fsharp.org

dsyme — Wed, 10 Apr 2013 16:35:49 GMT

Daniel - you just email fsharp@fsharp.org

re: F# testimonials on fsharp.org

Daniel — Wed, 10 Apr 2013 16:30:11 GMT

How do you join F# Foundation?

re: Quote of the Week: "What can C# do that F# cannot?"

Steffen Forkmann — Sun, 07 Apr 2013 12:38:07 GMT

Shameless plug: trigged by this discussion I wrote "A tale of nulls" www.navision-blog.de/.../a-tale-of-nulls

re: Quote of the Week: "What can C# do that F# cannot?"

Marc Sigrist — Thu, 04 Apr 2013 11:46:19 GMT

Over a year ago, I suggested adding non-nullable reference types to C# (see

visualstudio.uservoice.com/.../2320188-add-non-nullable-reference-types-in-c-). The suggestion has since become one of the top voted-for C#-related items.

I have now commented my own suggestion, indicating that a different language design -- forbidding null by default -- would be even better, and that F# sets a good example. Unfortunately, it is not very realistic that such a fundamental design change will be introduced to a long-established mainstream language such as C#.

re: Quote of the Week: "What can C# do that F# cannot?"

Mark Allread — Thu, 28 Mar 2013 10:22:29 GMT

NRE isn't an acronym.

re: Quote of the Week: "What can C# do that F# cannot?"

melnakeeb — Thu, 28 Mar 2013 01:48:10 GMT

A very interesting article.

re: Quote of the Week: "What can C# do that F# cannot?"

JeroMiya — Thu, 28 Mar 2013 01:35:37 GMT

I think it is slightly unfair to group scala in with java and C#, seeing as how an exception was made for F# code calling into C# code. Idiomatic Scala code using Option[T] works similarly to F# code using the Option<T> class in F# - namely using pattern matching and for comprehensions to destructure the Option, making a null reference exception impossible (as long as you always use pattern matching/for comprehensions to extract the value out of the Option).

The last sentence is the problem with both F# and Scala - they don't really go far enough. Option[T] is, in effect, only a rudimentary attempt at including a "code contract" or "design by contract" type system, but only for nullable vs. non-nullable type contracts, and even then it's only if you follow convention.

If you look at languages like Spec#, C#/VB with Microsoft's Code Contracts enabled (I count that as a different language), or the Eiffel programming language those technologies were based on, you'll see that even more is possible. Option[T] and Option<T> don't go far enough because there's nothing stopping you from using them incorrectly, only convention. A language which allows explicit preconditions, postconditions, and invariants, can enforce those at compile time. If you have a function which takes a string and it's marked as only taking non-null strings, you literally cannot pass it a string that could possibly be null under any code path - you'll get an error at compile time.

Design by contract systems have their weaknesses, particularly when interacting with code that is not annotated with contracts, but also in cases where it's impossible for the compiler to prove statically that a contract is being honored - in these cases you have to give the compiler hints sometimes with things like assertions and assumptions which allow you to isolate those issues locally. That is typically cited as the reason these kinds of languages haven't caught on (that and the complexity of implementing a static contract verifier). But by and large, these languages are to F# and Scala what F# and Scala are to C# and Java in terms of the compiler being able to statically verify the absence of a larger class of software bugs.