I will begin our blog on Java Tutorial with an incredibly important aspect of java development:  memory management.  The importance of this topic should not be minimized as an application's performance and footprint size are at stake.

From the outset, the Java Virtual Machine (JVM) manages memory via a mechanism known as Garbage Collection (GC).  The Garbage collector

• Manages the heap memory.   All obects are stored on the heap; therefore, all objects are managed.  The keyword, new, allocates the requisite memory to instantiate an object and places the newly allocated memory on the heap.  This object is marked as live until it is no longer being reference.
• Deallocates or reclaims those objects that are no longer being referened. 
• Traditionally, employs a Mark and Sweep algorithm.  In the mark phase, the collector identifies which objects are still alive.  The sweep phase identifies objects that are no longer alive.
• Deallocates the memory of objects that are not marked as live.
• Is automatically run by the JVM and not explicitely called by the Java developer.  Unlike languages such as C++, the Java developer has no explict control over memory management.
• Does not manage the stack.  Local primitive types and local object references are not managed by the GC.

So if the Java developer has no control over memory management, why even worry about the GC?  It turns out that memory management is an integral part of an application's performance, all things being equal.  The more memory that is required for the application to run, the greater the likelihood that computational efficiency suffers. To that end, the developer has to take into account the amount of memory being allocated when writing code.  This translates into the amount of heap memory being consumed.

Memory is split into two types:  stack and heap.  Stack memory is memory set aside for a thread of execution e.g. a function.  When a function is called, a block of memory is reserved for those variables local to the function, provided that they are either a type of Java primitive or an object reference.  Upon runtime completion of the function call, the reserved memory block is now available for the next thread of execution.  Heap memory, on the otherhand, is dynamically allocated.  That is, there is no set pattern for allocating or deallocating this memory.  Therefore, keeping track or managing this type of memory is a complicated process. In Java, such memory is allocated when instantiating an object:

String s = new String();  // new operator being employed
String m = "A String";    /* object instantiated by the JVM and then being set to a value.  The JVM
calls the new operator */

The iconic software company that is based in King County Washington has been getting almost universally slammed from it's recent Los Angeles press announcement about its entry into the hardware business with the convertible laptop/tablet known as Surface.

Certainly I can see the point that it is now competing with its hardware vendors/partners. Intel has done a good job in the arena creating 'reference designs' without competing with its partners.

There is another viewpoint which seems to be ignored. The cold facts are Microsoft is a public company. This puts Microsoft in a legal position of doing the most it can to return value to its shareholders. Failure to do so means somebody is going to jail.

Microsoft has a vision, which at the end of the day is, a certain way to get enough people to see enough value to hand over their money, to fulfill their fiduciary duty.

When making a strategic cloud decision, organizations can follow either one of two ideologies: open or closed.

In the past, major software technologies have been widely accepted because an emerging market leader simplified the initial adoption.  After a technology comes of age, the industry spawns open alternatives that provide choice and flexibility, and the result is an open alternative that quickly gains traction and most often outstrips the capabilities of its proprietary predecessor.

After an organization invests significantly in a technology, the complexity and effort required steering a given workload onto a new system or platform is, in most cases, significant. Switching outlays, shifting to updated or new software/hardware platforms, and the accompanying risks may lead to the ubiquitousness of large, monolithic and complex ERP systems – reason not being that they offer the best value for an organization, but rather because shifting to anything else is simply – unthinkable.

There’s no denying that these are critical considerations today since a substantial number of organizations are making their first jump into the cloud and making preparations for the upsetting shift in how IT is delivered to both internal and external clientele. Early adopters are aware of the fact that the innovation brought about by open technologies can bring dramatic change, and hence are realizing how crucial it is to be able to chart their own destiny.

It is said that spoken languages shape thoughts by their inclusion and exclusion of concepts, and by structuring them in different ways. Similarly, programming languages shape solutions by making some tasks easier and others less aesthetic. Using F# instead of C# reshapes software projects in ways that prefer certain development styles and outcomes, changing what is possible and how it is achieved.

F# is a functional language from Microsoft's research division. While once relegated to the land of impractical academia, the principles espoused by functional programming are beginning to garner mainstream appeal.

As its name implies, functions are first-class citizens in functional programming. Blocks of code can be stored in variables, passed to other functions, and infinitely composed into higher-order functions, encouraging cleaner abstractions and easier testing. While it has long been possible to store and pass code, F#'s clean syntax for higher-order functions encourages them as a solution to any problem seeking an abstraction.

F# also encourages immutability. Instead of maintaining state in variables, functional programming with F# models programs as a series of functions converting inputs to outputs. While this introduces complications for those used to imperative styles, the benefits of immutability mesh well with many current developments best practices.

For instance, if functions are pure, handling only immutable data and exhibiting no side effects, then testing is vastly simplified. It is very easy to test that a specific block of code always returns the same value given the same inputs, and by modeling code as a series of immutable functions, it becomes possible to gain a deep and highly precise set of guarantees that software will behave exactly as written.

Further, if execution flow is exclusively a matter of routing function inputs to outputs, then concurrency is vastly simplified. By shifting away from mutable state to immutable functions, the need for locks and semaphores is vastly reduced if not entirely eliminated, and multi-processor development is almost effortless in many cases.

Type inference is another powerful feature of many functional languages. It is often unnecessary to specify argument and return types, since any modern compiler can infer them automatically. F# brings this feature to most areas of the language, making F# feel less like a statically-typed language and more like Ruby or Python. F# also eliminates noise like braces, explicit returns, and other bits of ceremony that make languages feel cumbersome.

Functional programming with F# makes it possible to write concise, easily testable code that is simpler to parallelize and reason about. However, strict functional styles often require imperative developers to learn new ways of thinking that are not as intuitive. Fortunately, F# makes it possible to incrementally change habits over time. Thanks to its hybrid object-oriented and functional nature, and its clean interoperability with the .net platform, F# developers can gradually shift to a more functional mindset while still using the algorithms and libraries with which they are most familiar.

Related F# Resources:

F# Programming Essentials Training