Concise - marked by brevity of expression or statement: free from all elaboration and superfluous detail
Over the 4 months I have been developing an F# data visualization project for one of my clients. I found F# development extremely enjoyable experience. I have been trying to fully quantify why it has been so much fun versus other experiences I have had programming. One of the key benefits of F# is conciseness. Robert Pickering, the author of the “Foundation of F#” has discussed this aspect of F# and I agree with his observation regarding F#’s conciseness.
Developing in F# reminds of Peter Siebel's Practical Common Lisp talk in which Peter Siebel describes Peter Naur's theory of the programming in the context of Lisp programming to explain the expressive power of Lisp.
I looked up Peter Naur’s original text and found the following passages:
"..programming should be regarded as an activity by which programmers form or achieve a certain kind of insight of the matters at hand: a theory (...and not only the production of a program text)...
"Programming shall denote the whole activity of both design and implementation of solutions. "
To paraphrase Naur and Siebel, programming conciseness is the extent to which your program expresses this theory with least elaboration. One of F#'s biggest strengths is the conciseness of expression. F# incorporates many language capabilities to create a very expressive language, which leads to this conciseness. Here is a short, incomplete list of F# features, which promote code conciseness.
1. Type Inference
The F# compiler deduces at compile-time what types you are using based on the eventual evaluation of the expressions in your program.
Example:
// C#
String myString = new String ("I like the clicking of keys");
Double myNumber = new Double(4.0);
// F#
let myString = "I crave silence"
let myNumber = 4.
String myString = new String ("I like the clicking of keys");
Double myNumber = new Double(4.0);
// F#
let myString = "I crave silence"
let myNumber = 4.
The compiler types both myString and MyNumber as type String and Float (F# equivalent of Double) because the right side of the let expression has a type that can be inferred.
In C#/Java case you have to tell the compiler that you are declaring and creating an instance String assigned to the identifier myString and and you are declaring an identifier myNumber of type Double assigned a new instance of Double. If you take a step back, the code has enough information to determine the types, so why should you have to type the type names?
In F#, the compiler infers the type from the expression. As you are typing your program into the Visual Studio F# editor, the compiler is constantly running in the background compiling and type checking. It creates this really interesting dialog between you and the compiler as you are developing your program. It took me a bit to get used to but overtime the compilers feedback made me more aware of types in my program and the overall semantics those types were trying to capture.
At first type inference feels a bit like Python's duck-typing, however the key difference is that type inference is statically checked and as a result you have a lot fewer type-error surprises at run-time. Type-inference eliminates the over-elaboration of type information within a program. F# type inference is not perfect. However, type ambiguities are treated as the exception and identifiers can be type-annotated, when the compiler cannot make a type determination based on the your programs expressions.
2. Significant White Space
F# handling of significant white space is Pythonic. At the top of an F# code file, you can specify a #light syntax directive, which enables significant white space for subsequent F-Sharp module. The #light syntax directive in F# is much like Python. Programming blocks are defined by the indentation of the programming statements in the file.
Significant white space is definitely a taste issue. Some developers hate significant white space, because it dictates a certain code aesthetic. I personally, like significant white space, as it eliminates line-noise in code created by the tyranny of the curly-brace.
Example:
void Foo
{
if (something == true)
{
// this is a block
}
else
{
// this is another block
}
}
//F#
#light
let foo()=
if something then
// here is block
else
// here is another block
3. Everything does not need to be an object.
I started my career, while object-oriented development was starting to take the industry by storm. I was one of the early zealots who believed OOP was going to save the world. Moving to objects wasn’t easy for the industry. Developers were extremely wary of "object stuff". A common refrain was that it would slow programs down. In the early days it probably did. Presently, all the major languages (by popularity of use) have object support and developers don't think twice about using objects for everything.
In C# and Java, all functionality is encapsulated through objects. C# one-upped Java by making all types derive ultimately from Object. The industry’s embrace of OOP, seems to be an over-correct. More recently C# has introduced closures, which allow functions to be defined independent of objects. Java 7 very nearly introduced a notation for closures, but unfortunately it didn’t make the cut for the next release. There are many instances where closures provide a better notation than standard object encapsulation.
F# straddles object functional programming models, which provides great expressiveness and the opportunity to use object when you needed and functions where better suited.
Example:
class FooClassHolder
{
public static void foo()
{
// I can do some stuff
}
}
let foo() =
// I do some stuff
// call some foo
FooClassHolder.foo()
foo()
This is just a trivial example, but it illustrates how you can define a function without having to define a wrapping object class.
Conciseness De-clutters the Programming Mind
Developers say “big-deal” less typing…I type really fast and my fancy IDE types-ahead for me! Even so, I find that concise code allows me to better hold the concepts in my head. IDE have become really smart in large part to the typing challenge created by large bodies of code text. F#’s focus on conciseness in many ways obviates these intelligent IDE features. Don’t get me wrong, I really love Intellisense. I couldn't live without it and IDE’s provide a ton of value to developers. However, I find working with less code freeing mentally. I find myself having more mental bandwidth because I can more easily scan a smaller amount of code. Smaller amounts of code allows me to focus more on the intent of program, rather than pushing text around.
