4 ms·
I've been enjoying using it for both some personal and commercial projects. Points I've noted myself that aren't really discussed so much in the usual analysis
by rlmw 16y ago
I've been enjoying using it for both some personal and commercial projects. Points I've noted myself that aren't really discussed so much in the usual analysis, or maybe they're the 'small print':
1. Active Patterns are incredibly useful. Active Patterns are the f# equivalent of 'View Patterns' in Haskell. In other words they allow you write a function that converts something into a pattern matchable form. The first example I saw of this in Haskell was the ability to write a function of the form:
dec (n + 1) = n
which performs the same function as:
dec n = n - 1
Whilst that 'cool' I didn't really see the applicability. Now you're in the f# world and trying to interact with .net libraries its suddenly amazingly powerful! Suppose you have a DOM api or something like that, that the idiomatic functional approach would involve heavy pattern matching. Hey presto - one simple function and you've wrapped up an imperative .net library and you can think of it like a discriminated union.
2. Multiple collections libraries are annoying. There's some functionally oriented stuff in the f# libraries, but sometimes its a pain to get it to interact with existing c# code - you might need to do some conversions. The Seq module works over sequences - which are instances of IEnumerable - but you find yourself looking at the LINQ extension methods, and the legacy c# functions and then the f# ones and thinking 'its one platform - why are there 4 ways of doing something?'
3. The f# compiler takes a while to generate code under Mono. I've not tried mono 2.8 yet, but as of 2.6 it takes a significant amount of time to compile projects. If you're compiling code in order to try and get a few errors, a common thing to do if you're used to using your compiler to find bugs in your code, then this becomes a bit of a productivity drag.
4. Intellisense is still useful for functional programmers. I've noted a propensity among advocates of self-described expressive languages to claim that an IDE is a crutch for weaker programmers, or perhaps produce some other ill conceived but dismissive response towards IDEs. In the past I've considered the notion that the support something like Eclipse or IDEA gives to Java programmers or Visual Studio gives to C# is something unnecessary in the functional world. My mind on this matter has been changed by two things - one being the Visual Studio support for f#. Its not as good as c#, but its at a pretty young stage and is already highly useful. I feel a lot more productive in visual studio than vim for example. The other aspect was my efforts in teaching beginners to program haskell about a year ago. I was expecting a lot of people to get stuck on Monads and combinators etc. What I didn't expect was them to become confused on basic programming issues - things an IDE would help them find solutions to more easily in a language like Java. So I'm inclined to think from these experiences that IDEs are useful, even in a succint language like f# and more importantly both to beginners and experts alike. (Assuming I can consider myself an expert.)
There's already a tool that provides the intellisense support in an out-of-ide environment, and I hope that it will mature soon enough that I'll be able to use it within vim.
I have a few more minor points - but I think thats all of interest for now.
- ezyang 16y agoSlight bit of pedantry (not to detract from the overall content of your post): dec (n + 1) is not a view pattern, it's an n+k pattern, and Haskellers have mostly decided that they were a bad idea. However, you've gotten the point of real view patterns (foo (someFunc -> x)) spot on: they encourage better data abstraction, which is helpful if you've got an imperative .net library that you want to interface with.
- rlmw 16y agoThanks for the correction. I admit I've not fiddled with Haskell's equivalents to Active Patterns to any great extent - as since I mention in the original comment I didn't hugely see the motivation in that context. I really only mentioned them since I assumed more people would be familiar with haskell.
- jdh30 16y agoHaskell 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.