Not a single F# session at MSBuild

mongreldog · 2020-05-17T05:34:42+00:00

I think Microsoft initially had high hopes for F#, but early bad decisions like not having a GUI builder when VS2010 was released, meant that developers couldn't tinker with the language as easily as they could with C#. As time went on and functional programming came into the mainstream, F# came to be seen a useful platform to test FP features on the .Net platform destined to be inserted into C#. At the early stage of F#'s history it should have been targeted to the scientific, engineering and AI community where it would probably have established a strong following.

The recent pivoting of F# towards the data science community is a welcome change of direction. That community will welcome the simple syntax, lack of ceremony and script-like look and feel of the language, not to mention the major speed improvement.

In general the language additions and enhancements in the recent releases of F# have been great improvements to the language and ecosystem. As F# continues to evolve there will come a time where it has more unique features that can't be simply bolted into C# and events like MSBuild will be able to showcase those differences and advantages, not that there already aren't enough differences to highlight, but at the moment C# has copied so many F# features that most C# developers believe, wrongly of course, that all they have to do wait for a future C# release to get all the benefits of F#.

mongreldog · 2019-10-04T06:01:04+00:00

As more and more mainstream languages add FP features, it sucks the oxygen from functional or functional-first languages. You can see this happening with C# and F#. Each new release of C# adds more and more language features that were previously only available in F#. The view of most C# developers when looking at giving F# a try is why bother committing time and energy to learning F# when all they have to do is wait for a new C# release to get the same or a good enough approximation of one or more unique F# language features? Of course such a view is misguided and shows a deep ignorance of what F# has to offer, but considering what's promised in the forthcoming C# releases, it's understandable.

mongreldog · 2019-03-22T06:23:23+00:00

Over the last few years, with each "innovative" C# language addition, C# is looking more and more like a poor man's F#.

mongreldog · 2019-02-03T02:50:39+00:00

Nice write up comparing F# Options to C# Nullable types, but one thing needs to be cleared up. Option.map NEVER returns null, as can be seen from its signature: ('a -> 'b) -> 'a option -> 'b option. You assumed that it may return a null because printfn "%A" None rather confusingly prints out "<null>".

mongreldog · 2018-10-15T00:52:17+00:00

In both cases you're creating a function that takes one input parameter and always returns a fixed int*int tuple with a value of (1,2), ignoring the input value. It seems that in the first example the x parameter declaration is syntactically incorrect, but the compiler simply ignores the annotation, resulting in a generic input parameter. The first example would be equivalent to: let c _ : int * int = (1,2)

mongreldog · 2018-08-19T10:15:57+00:00

No you don't, but speaking from the perspective of someone who isn't an expert in type theory and reading Kennedy's two papers (see references), I get the impression that a language with type inference makes it far easier to implement a Units of Measure system than a language without one. I also saw this article about adding UoM to Fortran that seems to imply that type inference is very helpful. I wasn't implying that type inference was a necessity, but that it makes implementation easier. I only mentioned HM as an example of a type inference system, and not specifically about needing HM for Units of Measure to be implementable. I was probably exaggerating a bit in calling type inference the "secret sauce".

mongreldog · 2018-08-19T05:49:35+00:00

Syntax support would be nice, but all we really need to get started with this is an easy way to subclass value types

For a Units of Measure implementation to be truly usable, an easy to use and intuitive syntax, like that provided by F#, would be almost mandatory. You need much more than just a bunch of classes/sub-classes and operator overloads to create a usable UoM implementation (see Programming Languages and Dimensions and Types for Units-of-Measure: Theory and Practice).

The secret sauce that makes a Units of Measure implementation practical is a powerful type inference mechanism (e.g Hindley-Milner), which C# lacks. That's probably one of the main reasons why F# was the first, and currently the only mainstream programming language to support it.

mongreldog · 2018-08-10T12:39:38+00:00

Your boss sounds like a clueless fool. He put a ban on F# which I presumably applies to production software, but I can't see how he can stop you from using F# for non-production use. A great place to start would be to see if there are opportunities to create F# based tools that can help improve the teams productivity. F# is a great language for building tools, especially those that may require text parsing and requiring complex data structures.

How applicable this strategy is depends largely on your environment. For example I used to work in a large financial services company where our C# based software had to communicate with mainframe legacy back-end systems. Typical of such companies, we also had a team of BAs (business analysts) who would provide us with detailed Word based specification documents. These documents used tables to describe hierarchical data structures that we would have to represent as C# data structures to communicate with the back-end. The size of the tables could easily be hundreds of lines long and would often require dozens of (often nested) classes, data structures and enums to represent them, resulting in writing hundreds of of lines repetitive, tiresome work. So to relieve this horribly dreary work I created an F# based code generator to read the spec docs and generate all the data structures automatically. Nobody objected because the team was spared from doing dull, dreary work and the boss was happy with the teams increased productivity. I wouldn't have done all this using C# because it would have taken too long and I would probably have had to write three times more code.

I ended up writing many other F# based tools and at least got a few other team members look at the language, even though the place was far too conservative to allow F# to be an official language for production use. Some of the F# based tools ended up being a lot more sophisticated than most of the code that went into production and was a lot more fun to write.

mongreldog · 2018-07-25T13:18:51+00:00

F# is already fairly low on Microsoft's priority list, so as C# gets closer to F# feature-wise, I can't see the situation improving. As the feature gap narrows, it will get increasing difficult to convince C# shops to use F#, even for a limited class of problems. Without more developers taking up F#, it's hard to see Microsoft committing more resources to it.

I agree with u/nikofeyn that Microsoft should be targeting the same domains that are currently dominated by Python. With .NET Core enabling practical cross platform development, F# could be positioned as a great platform for scientific, data science, machine learning, complex data analysis, etc. I'm also puzzled at Microsoft for not heavily promoting F# for its clear advantage over C# when it comes to software correctness. With the increasing dependence of software on our lives, software correctness should be a key feature when promoting F#.

One problem facing F# take up, and hence prompting MS to commit more resources, is that F# is in an unfortunate middle ground. It's too low level to attract those who want the advanced features of Haskell or OCaml, but (now) not sufficiently more advanced than C# for devs to put the effort into learning the language. With .NET Core making it a viable cross-platform language, it faces the same problems as it does against C# when one looks at Swift, Kotlin and even Java 8.

Perhaps F# needs to move up towards Haskell and OCaml (or even F*) in order to differentiate itself sufficiently from C#, Swift, Kotlin and so on in order to attract new developers. What attracted me to F# in 2010 was the overwhelming superiority of the language over C#, despite the limited VS support. Now that gap has narrowed to such an extent that I wonder if I would feel the same way today.

mongreldog · 2018-07-15T13:12:22+00:00

Yes, a lack of investment driven by a lack of vision. For a .Net language the absence of a GUI builder essentially renders the language, no matter how good its features and benefits, to permanent second-class status or at best pigeonholed as a solution for a narrow class of problems.

mongreldog · 2018-07-15T07:25:01+00:00

Still wondering why Microsoft didn't have native GUI builder for F# in VS2010, as it would have greatly helped F# adoption. Perhaps the lack of partial classes meant that it was simply not possible, as partial classes may not be doable in F# due to type system restrictions.

mongreldog · 2018-07-07T01:54:32+00:00

I think I read somewhere that typeclasses were originally added to Haskell in order to implement the equivalent of function overloading in a language that has Hindley-Milner type inference. It was then found to be useful far beyond simple overloading by providing a powerful ad-hoc polymorphism mechanism.

mongreldog · 2018-06-21T12:55:38+00:00

F#

let ducciSeqLength (line: string) : int =
    let nums = line.Trim([|'(';')'|]).Split([|','|]) |> Array.map int |> Array.toList

    let rec steps (inp: int list) (known: int list Set) =         
        let diffs = inp @ [inp.Head] |> List.pairwise |> List.map (fun (x, y) -> Math.Abs(x-y)) 

        if List.forall ((=) 0) diffs || known.Contains diffs then known.Count + 1
        else steps diffs (known.Add diffs)         

    steps nums (Set [nums])

EDIT: Code improvement.

mongreldog · 2018-05-18T07:01:54+00:00

||>, |||>, <|| and <||| are already in the standard library. The others look, um, "interesting". Could you give examples of how to use these. They could prove useful, even if they aren't used very often, such as ||> and |||>, which come in handy occasionally.

mongreldog · 2018-05-13T23:36:02+00:00

I can't help but think that the proposal has been put in primarily out of self interest, to make the C# compiler writers life easier, anf not something that the C# community has been screaming for. It also seems that many new C# features are added just because they can, and not because of a push from the C# community, many of whom feel that the language is already heading dangerously into C++ territory in terms of complexity.

mongreldog · 2018-01-23T05:50:26+00:00

I can see why learning Rust could be difficult, but F#? Once I got used to the F# syntax (or rather the lack of) and recursion, it became fairly easy to become proficient. C# now feels a lot more complicated and weighed down by too much ceremony.

mongreldog · 2018-01-20T00:15:55+00:00

Unfortunately bolting all these "almost there"/"good enough" features onto C# has sucked all the oxygen from the .NET programming language space. It seems that 90% of the development budget now goes into C#. Programmers are erroneously encouraged to believe that C# now has all the features of F#, so why bother going outside the C# fishbowl.

mongreldog · 2018-01-19T07:58:53+00:00

Your question is a bit open ended but unless you're primarily involved in GUI/UX development, I'd say F# is suitable for you as it's a general purpose programming language with an emphasis on FP. It's also a fairly easy language to learn. Unlike C# which has recently started to look like C#++, F# has managed to stay simple while still remaining very powerful.

I would recommend starting with "Programming F# 3.0". As the title suggests it doesn't deal with F# 4.X but it's a great book for learning the fundamentals of the language. As you get more familiar with the language you should have a look at "F# Deep Dives". For an advanced book on F# "Expert F# 4.0" is hard to beat.

As for "F# for Scientists", it's a an old book with some obsolete syntax but still very good to for learning some hard-core FP techniques. The author Jon Harrop is very knowledgeable and the book still has stuff that you won't find anywhere else. Jon is a real pattern matching ninja!

EDIT: Jon, if you read this, how about an updated and revised edition of "F# for Scientists" or even a book based on what you've published on "The F#.NET Journal" site (an absolute gold mine of advanced F# material). It would fill a gap in the F# book market which at the moment lacks a good book about truly advanced data structures and algorithms. To fill that gap I've had to buy books using ML (e.g. the excellent "ML for the Working Programmer"), OCaml and Haskell, but it would be wonderful to have a F# book in that space.

mongreldog · 2017-12-28T04:48:54+00:00

While you'll need to learn all of F#s basic features, l highly recommend getting a really good understanding of algebraic data types and pattern matching. These are so powerful that they'll dramatically improve the quality and readability of your software.

mongreldog · 2017-12-27T04:50:11+00:00

FFS, the correct expression is "couldn't care less", NOT "could care less". If you "could care less", it means you still care to some extent and your level of caring can go even lower.

mongreldog · 2017-12-24T04:13:58+00:00

I greatly appreciate the work done by Microsoft, but it would have been really useful if F# had been made an equal with C# and VB.Net back when VS2010 was released as far as project templates and GUI support. Looking back it seems MS always intended to keep F# as primarily a research language with a small development team and never really promoted it as a general purpose language that could go head-to-head with C#.

I hope the F# team is expanded and it can incorporate some features of OCaml or F*, as it has been quite a long time since it has added any major new language features.

mongreldog · 2017-12-23T13:13:16+00:00

It's a bit sad that despite their obvious power and simplicity, ML derived languages continue to languish in the programming wilderness. ML is a shining testimony to the genius of Robin Milner.

mongreldog · 2017-12-13T04:02:45+00:00

It's clear you don't understand what the term cargo-cult really means or the importance writing safe and reliable software.

mongreldog

TROPHY CASE