If you had $100 to improve F#, how would you spend it?

Friday, July 01, 2011 3:19 PM

As a long-term user I have a huge request list for the next release, but if I had $100 to invest into F# improvements, here's how I would vote with the money:

$40 - speed up the existing tools, especially fsc
$40 - offer higher-kinded abstraction (type classes? ML modules?)
$10 - get F# VS project type on par with C#, in particular allow code generation
$10 - everything else (improve quotations, console usability, etc)

The compilation speed is not bad but gains in this area can have a significant impact on everyone's productivity.

Feature-wise, having more abstraction options is very appealing. Ideally, safe abstraction (as functors in OCAML), but perhaps also unsafe abstraction (as camlp4 in OCAML) that is easy to use with existing build tools. I realize the cost of implementing functors or type classes may be prohibitive, but I dream about them nonetheless.

How would you spend your $100?

Anton

Virtual Donation Summary

* TOTAL: $1300 (100%)
** IDE Improvements: $438 (34%) 
*** Debugging: $105
**** Palladinos Nick: $50
**** Edmondo Pentangelo: $30
**** KitEason: $25
*** Refactoring: $120
**** Dmitri Nesteruk: $100
**** Palladinos Nick: $20
*** Other: $213
**** t0yv0: $10
**** Rich Minerich: $50
**** V. Matveev: $50
**** Jack Pappas: $20
**** KitEason: $25
**** Johan Deneux: $33
**** TechNeilogy: $25
** Language Extensions: $360 (28%) 
*** Type Classes: $165
**** t0yv0: $20
**** Ryan Riley: $60
**** Edmondo Pentangelo: $50
**** V. Matveev: $30
**** Da.n Fin.ch: $5
*** Other (ML Modules, Macros, Proof-Carrying Code..): $195
**** t0yv0: $20
**** Palladinos Nick: $30
**** V. Matveev: $20
**** Jack Pappas: $30
**** Da.n Fin.ch: $95
** Tool Quality: $210 (16%) 
*** F# Optimizations: $75
**** KitEason: $50
**** TechNeilogy: $25
*** Other: $135
**** t0yv0: $50
**** Ryan Riley: $40
**** Rich Minerich: $20
**** TechNeilogy: $25
** Documentation: $158 (12%) 
*** F# Source Code: $123
**** Edmondo Pentangelo: $20
**** Rich Minerich: $20
**** Jack Pappas: $50
**** Johan Deneux: $33
*** Other: $35
**** Rich Minerich: $10
**** TechNeilogy: $25
** External Libraries and Tools: $134 (10%) 
*** NOSQL: $100
**** David Grenier: $100
*** Mono: $34
**** Johan Deneux: $34

Edited by Anton Tayanovskyy Saturday, July 02, 2011 9:55 PM
Changed Type Dan Quirk - MSFTMicrosoft Employee, Owner Tuesday, July 12, 2011 9:01 PM

All Replies

Friday, July 01, 2011 3:41 PM

0
I would:
1. Donate the whole $100 to ActiveMesa to finish off FSharper, which is basically the F# support for ReSharper.
Disclosure: I'm the author, so I'm effectively advocating a donation to myself. But at least I can deliver, being on the R# team and all that :)
- Dmitri Nesteruk, MVP C#, Microsoft Partner
- Reply
- Quote
Friday, July 01, 2011 4:58 PM

0

1. 50$ Please improve the VS Debugging experience

2. 20$ Improve VS Tooling (This awful <Note>)

3. 30$ A proper ML Module System

Nick
- Reply
- Quote
Friday, July 01, 2011 5:11 PM

0

I'd put $60 to type classes and $40 to better support for allowing fsi execution against .fsx scripts within F# applications. I'd love to notate my metadata in .fsx files rather than XML, JSON, or other formats.
Ryan Riley @panesofglass
- Reply
- Quote
Friday, July 01, 2011 5:35 PM

0

1. 50$ Type Classes

2. 20$ F# Compiler Source Documentation.

3. 30$ Improved Debugging experience.

Edmondo
- Reply
- Quote
Friday, July 01, 2011 5:47 PM

0

1. $20 on making FSI as easy to embed in an existing program as DLR language engines

2. $50 on improving the VS2010 experience.
- Better intellisense (especially when it comes to comments),
- Better automatic indentation/autoformatting (especially with do and multi-line lambdas)
- Automatic importing of dependencies into FSI on alt-enter
- A reasonable story for F# Signature file generation (let us keep it all in one file and add it to the project automatically)
- Working "go to definition" across assemblies (and especially from C#)

3. $20 on releasing compiler tests and better documenting the compiler
- This could be an investment in the future, I know a few ICFP guys who want to play with extending F#.
- I personally want to play with it, but right now the code is pretty intimidating to change.

4. $10 on better documentation
- more examples would be great for new users
- Reply
- Quote
Friday, July 01, 2011 5:51 PM

1

50$ - for enhancements in VS support

30$ - type classes

20$ - hygienic macros
- Reply
- Quote
Friday, July 01, 2011 7:48 PM

0

$50 - Better documentation of the F# compiler's source code. Specifically, it'd be *extremely* helpful to my day-to-day work if I could add a few small features/extensions to the F# compiler where I'm currently having to resort to some really messy (and relatively slow) code due to some F# language limitations. Most of the features I'd like to add are pretty small, and I could easily add them if I understood the internals of the compiler better.

$30 - Support for Code Contracts and/or writing proof-carrying code a la F*/Coq/HOL. Either one would be helpful, but a synergy between them would be even better.

$20 - Support for F#-based MSTest / unit-testing projects within Visual Studio.
- Reply
- Quote
Friday, July 01, 2011 8:23 PM

0

$50 - Optimisation of code, esp for code which uses higher-order functions

$25 - Debugger improvements: more 'step-ability' and better visibility of variables/objects

$25 - VS integration, especially UI design
- Reply
- Quote
Saturday, July 02, 2011 7:06 AM

0
I would probably use $33 to bribe someone and get the source code of the Visual Studio F# IDE, the part that handles syntax highlighting.

There are a couple simple extensions to the language I might want to develop, and although modifying the compiler is in theory possible, Visual Studio would flag my extensions as errors. IIRC Tomas Petricek has hit this obstacle with his experimental compiler with joinads.

For the curious, here is one of the extensions I'm considering:
```
type ISomething =
 abstract member Do : unit -> unit

type Something() =
 interface ISomething with
 member this.Do() = ()

type InheritanceForCodeReuse() =
 inherit Something()
```
```
type CodeReuseWithoutInheritance() =
```
```
 let impl = new Something() :> ISomething
 interface ISomething with impl
```
The last line is not currently valid F#.

I would donate $33 to an open source project that combines some of the popular improvements to VS: line colouring (depending on the indentation level), F# refactoring and the documentation header generation Brian has demonstrated but that nobody has taken over (AFAIK).

The two first don't work well together, the line colouring plugin "paints" over the highlighting of F# refactoring. It also seems a bit wasteful to have a number of plugins all parse the F# code once each.

I would donate the remaining $34 to the mono project to iron out whatever issues there might be left. I'm not sure what's the current status, but I would like to avoid surprises with garbage collection, tail call optimization and execution speed. I'm not too interested in the high-level APIs, it's mostly the CLR I'm aiming at. If mono can reach that status, I think we could in principle replace most of our use of Python by F# at my work.

To summarize:

$33 on openness / documentation to enable me to make my own extensions

$33 on the IDE

$34 on cross-platform support
- Reply
- Quote
Saturday, July 02, 2011 2:48 PM

0

$25 Integrating F# with existing design tools for WPF, etc.

$25 Improving efficiency of existing features and code optimization.

$25 Improving and extending FSLex and FSYacc and other DSL tools.

$25 Adding various features to make F# a good teaching tool for pre-college computer students. (For example, Logo-like features and game programming extensions.)

-Neil
- Reply
- Quote
Saturday, July 02, 2011 6:22 PM

0

100$ on an NoSQL database that embraces F# immutable nature... any solutions on top of RDBMS' starting to feel like stone age.

edit:

I'd like to change my mind on 35$ on better intellisense built-in as C#'s much more powerful.

35$ on NoSQL.

And another 30$ on F# web projects so that I could use Websharper with the Integrated Shell + F# distro without having to install the whole shabang.
- Reply
- Quote
Saturday, July 02, 2011 8:04 PM

0

$95 on compiler extensibility as a language feature, like Boo & Nemerle's syntactic macros.

$5 on type classes ;)
- Reply
- Quote
Monday, July 04, 2011 2:02 AM

0

See this

Windows MVP, paid Remote Assistance is available for XP, Vista and Windows 7.

My page on Video Card Problems is now my most popular landing page. See my gaming site for game reviews etc.

Developer | Windows IT | Chess | Economics | Hardcore Games | Vegan Advocate | PC Reviews
- Reply
- Quote
Monday, July 04, 2011 5:26 AM

0

set my 100 bucks on Typeclasses
- Reply
- Quote
Monday, July 04, 2011 8:40 AM

1

$50 - Improve support for writing generic code - More powerful module system (Functors) or Typeclasses

$30 - Improve compilation speed

$19 - Tooling and VS integration, debugging, code refactoring, FSI (i find it especially painful having to explictly include DLLs with #r )

$1 - Improve standard libraries and switch to .NET naming conventions

Joel
- Reply
- Quote
Monday, July 04, 2011 1:52 PM

0

$50 - type classes

$40 - VS tools for F#

$10 - for bribing MS developer division execs to promote F# more
- Reply
- Quote
Tuesday, July 05, 2011 2:40 AM

0
I'm new to F# so forgive me if I request something that already exists in F#, but I would like to see built in programming by contract support that doesn't require a separate download of http://research.microsoft.com/en-us/projects/contracts/ More specifically, I would like to see "static" checks of violations of contract.

Instead of code like this:
```
(* Example of runtime contract enforcement without using MS 
	Code Contracts Add On *) 
let getCircleArea r = 
	(* Unfortunately, this is a runtime check and I would rather it 
		be a compile time check *) 
	System.Diagnostics.Debug.Assert(r > 0.0)
	r * r * System.Math.PI
```
I would like to be able to write code like this:
```
(* Hypothetical example of compile time contract enforcement using 
  the idea of Real Number subranges *)  
let getCircleArea (r : PositiveReal) =   
	r * r * System.Math.PI
```
I understand that one could probably accomplish my stated goal with the MS Code Contract Addon, but I think the only issue with that library is that anyone wishing to use the add on would have to convince all of his fellow team members to also install and use the add on. In some cases, convincing other team members of the need could be difficult.

With Respect,

Shawn
- Reply
- Quote
Tuesday, July 05, 2011 11:03 PM

1

Hi, as a not-so-gifted programmer struggling with F# I would put the entire $100 towards documentation and samples.
- Reply
- Quote
Thursday, July 07, 2011 1:44 PM

1

Speaking as an old Lisp programmer who breathed an enormous sigh of relief when he first saw F#, I would blow the lot on a proper implementation of run-time compilation so that we can use some of those wonderful techniques for writing programmes that extend themselves dynamically. I know that there are a variety of ways of achieving it, but they are all too clunky for my liking. We should just be able to assign a string representation of a function into a string, have it compiled transparently and be able to execute it!
- Reply
- Quote
Thursday, July 07, 2011 7:34 PM

0
$100 - Improving efficiency of existing features and code optimization.

Specifically:
- Compiler-generated state machines for sequence expressions are far less than optimal, especially recursive sequence expressions -- so many unnecessary allocations.
- Reduce the number of allocations in built-in higher-order functions. I can't count the number of times I've had to replace e.g. a `.tryPick' call with an imperative loop because the number of `Option' instances allocated for a long sequence causes considerable GC churn. (I realize that it's probably too late to change fundamental types such as `Option' to structs, but it would be very nice if an allocationless alternative was built-in...)
- Make the `printf' family of functions at least as efficient as `String.Format'.
- Reply
- Quote
Friday, July 08, 2011 11:40 AM

0

Compiler Extensibility 50$

Higher Types 50$

_________________

Huw
- Reply
- Quote
Friday, July 08, 2011 9:33 PM

0

I'm going to throw all my $100 at FSharper as well.

Have fun

Finn
- Reply
- Quote
Sunday, July 10, 2011 2:14 PM

0

1. $50 Type classes + higher-order type operators ("higher-kinded types")

2. $30 Macro system and/or improved quotation support

3. $20 Enhanced tool support (esp. IntelliSense)
- Reply
- Quote
Monday, July 11, 2011 6:32 AM

1

$25 - Anonymous types, as per C#. Would make ASP.NET MVC easier

$25 - Folders in the VS project structure

$25 - Debugging in fsi, in VS

$25 - Enable REPL evaluation with .fs files, including modules and namespaces
- Reply
- Quote
Monday, July 11, 2011 8:09 AM

0

Sadly, I've already spent my $100, but I whole-heartedly second debugging code executing in fsi.
- Reply
- Quote
Thursday, July 14, 2011 8:46 PM

0

$30 : IDE/tooling (Stepping through |> and seeing intermediate values, etc...)
Most IDE extensions should include source and use IDE-embedded DLR language.

$30 : F# could be a better DSL language. Runtime/meta-progragamming/extensions (incl. user-def operator syntax a la prolog "op $$ xfy 200" and default printer/reader support) -- or support for a parse-block that looks like computation expression but dispatches to a user-defined parser (found using MEF in current or other program) and return resultant F# code.

$20 : basic refactoring suuport (w/o needing resharper)

$10 : Auto-properties

$10 : typeclass (like) support
MBR
- Reply
- Quote
Thursday, July 21, 2011 4:12 AM

0

I'm surprised to see so many who want better debugging. As it stands I rarely use the debugger in F#. I find with a combination of well defined types, F# Interactive and TDD with xUnit/TestDriven.net it's rarely necessary to set a breakpoint.
- Reply
- Quote
Monday, August 01, 2011 4:29 AM

0

While I am tempted to go on about language stuff like good macros, mixins, other type enhancements and so on, the best investment is to put all $100 into Visual Studio usability. After having some other people try out F# for regular business applications (database and web work), I've seen that the difference in ease-of-use between C# and F# is great. From drag-n-drop LINQ-to-SQL, to automatic properties, to lack of mstest support, to basic IntelliSense functionality: F# may be a better language, but it can end up being very frustrating if you're used to or want to use the "VS ecosystem".

If F# had true first class support, so that we could build, say, a little ASP.NET MVC app just as easily as C#, then F# would be able to take over much more marketshare. And then, for the next version, instead of asking how to spend $100, the question would be how to spend $10,000.
- Reply
- Quote
Tuesday, August 02, 2011 9:56 AM

1

1 $ 30 type class

2 $ 30 nested data parallel

3 $ 40 scientific & numeric computation support (e.g. linear algebra library, special functions, gamma function psi function etc.)
- Reply
- Quote
Monday, August 22, 2011 3:53 PM

0

Full Visual Studio support.

MSTest, at least.
- Reply
- Quote
Thursday, April 18, 2013 6:37 AM

4

To resurrect an old thread...

I'd put all $100 on Microsoft communicating that they are as committed to F# for the LONG haul as they are C#.

I am in the process of deciding whether or not F# is a good decision for building our mission critical enterprise applications. From my perspective, nothing mentioned in this thread so far is as important to the future of F# as is people like me having 100% confidence that we can count on F# to be around and fully supported for the long term.

When asked, I'm sure Microsoft would say that they are committed to F#, but then you see things like Scott Guthrie's blog announcing Visual Studio 2012.2. It mentions C#, it mentions VB -- heck, it even mentions CoffeeScript, but there isn't a word about F#.

What are the CTOs and CIOs of the world to think about Microsoft's commitment to F#? Is Microsoft committed to it? Or just Microsoft's Don Syme? The messaging is just passive enough to make us worry.

Until we can figure that out, many organizations are going to "wait and see" if F# succeeds, thus becoming the main reason it might not, even though we truly wish it would so we can use it.
- Reply
- Quote
Thursday, April 18, 2013 7:31 PM

0

$80 for long term support, but as I'm greedy, I'd also like a side of continuous improvement like --

$10 for higher-kinded types/type classes

$4 for better tooling : both static IL analysis that understands the idiosyncrasies of the F# code generator, and a StyleCop-like tool for automating coding standards

$3 for Spec#-like annotations ([<Pure>] and similar) to complement those extra tools

$2 for syntactic conveniences that Scala manages on the JVM, like traits (mixins) and implicits

$1 for frivolities like re-instating unicode symbols as valid operator characters
- Reply
- Quote