Programming Everything!

Did you know you can use F# type providers to access thousands of statistical packages from R, with auto-complete and documentation? Those of you into data analysis will be aware of the use of the R system by statisticians and other data workers. The F# community and BlueMountain Capital have created a type provider for F#-R interop which embeds all installed R packages directly into F#, with intellisense.  See the  example below. 

Google today launched an "early preview" of Dart, a programming language the company hopes will help Web application programmers overcome shortcomings of JavaScript that Google itself feels acutely.

Scala is a general purpose programming language principally targeting the Java Virtual Machine. Designed to express common programming patterns in a concise, elegant, and type-safe way, it fuses both imperative and functional programming styles. Its key features are: statically typed; advanced type-system with type inference; function types; pattern-matching; implicit parameters and conversions; operator overloading; full interop with Java

cala is a general purpose programming language principally targeting the Java Virtual Machine. Designed to express common programming patterns in a concise, elegant, and type-safe way, it fuses both imperative and functional programming styles. Its key features are: statically typed; advanced type-system with type inference; function types; pattern-matching; implicit parameters and conversions; operator overloading; full interop with Java

Introducing Functional Programming Server-Side Functional Programming Developing Client-Side Applications Numerical Computing Working with Data Visualizing Data with .NET Charts

We consider the problem of specifying combinations of data structures with complex sharing in a manner that is both declarative and results in provably correct code. In our approach, abstract data types are specified using relational algebra and functional dependencies. We describe a language of decompositions that permit the user to specify different concrete representations for relations, and show that operations on concrete representations soundly implement their relational specification. It is easy to incorporate data representations synthesized by our compiler into existing systems, leading to code that is simpler, correct by construction, and comparable in performance to the code it replaces.

F# is ideal for data-rich, concurrent and algorithmic development: "simple code to solve complex problems". F# is a simple and pragmatic programming language combining functional, object-oriented and scripting programming, and supports cross-platform environments including PC, Mac, and Linux. We'll provide the tutorials, resources and tools you’ll need to begin working with F# right away.

Microsoft Technical Fellow and C# creator Anders Hejlsberg explains the new C# and VB.NET asynchronous programming model, available as Async CTP now, which makes async programming much easier for .NET developers.

We had to cover monads eventually, and there are many great monad tutorials out there (see, for example, here: http://www.haskell.org/haskellwiki/Tutorials#Using_monads). In fact, there are web resources concerned solely with organizing the many monad tutorials available in the wild, and developing new monad tutorials seems to be a popular sport in the Haskell community.Today, Ralf Lämmel's lecture goes back to the roots, essentially revisiting Wadler's "The essence of functional programming"—the 1992 paper that discovered monads and popularized their use in functional programming. Ralf Lämmel's lecture and accompanying code distribution show Wadler's seminal insight: those original scenarios and observations still make sense today. Indeed, Simon Marlow (a Haskell/GHC high priest @ MSR Cambridge) recently noted: "it's still the best monad tutorial" (see http://twitter.com/simonmar/status/21397398061).

In this session, Don McCrady discusses how C++ programmers can fully utilize multicore in their applications using the Concurrency Runtime (ConcRT), the Parallel Pattern Library (PPL), and the Asynchronous Agents Library that ship with Visual Studio 2010.

scala> val ONE_DAY = 24 * 60 * 60 * 1000 ONE_DAY: Int = 86400000 scala> var manyDays: Long = ONE_DAY * 10000 manyDays: Long = 711573504 scala> var manyDays: Long = ONE_DAY * 10000L manyDays: Long = 864000000000 scala> ONE_DAY * 10000 res1: Int = 711573504

Dave Megginson (who drove the development of the SAX API that will be familiar to many XML developers who use Java) recently wrote Java is dead. Java stood out as a programming language (though not as a platform) in that Sun had refused to standardize it through an independent and reputable standards organization (a lot of the hard work had been done in one attempt to put it through ECMA and one to put it through ISO, both times Sun pulled out and eventually made their highly unsatisfactory JCP Java Community Process system.) Without the ability to alter Java significantly in ways that might go against their druthers, Java suffered two major forks (Microsoft's J++ then its C#, and IBM's SWT) where significant players disagreed with a major component (the graphics library). Java succeeded in middleware, and but failed to take advantage of the rise of browsers on the deskop: their HTML parser was great for the middle 1990s but was deliberately neglected to the point of being unusable: it is hard not to see this as a deliberate attempt by Sun to leave the browser market to its friends and enemies. I really liked Java, and bet my company on it (in a sense): I would not do that today.

What made me fall of my chair is the methodology/architecture part of this statement. It’s hard enough (but doable) to use RDF to map philosophically similar APIs. It’s a non-starter to use it to bridge architectural and methodological differences. I have spent a fair amount of time looking at Semantic Web technologies in the context of modeling IT systems (see the “semantic tech” category of this blog). While I think they would be a great foundation I don’t see them ever coming anywhere near what Reuven describes.

Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department. Actor based languages such as Erlang are able to achieve high degrees of parallelism by using the Actor model. Under this model the fundamental unit of concurrency is not a thread or fiber, but rather something much smaller. Known as a "process" in Erlang, each unit of concurrency has a base overhead of about 1200 bytes on a 32-bit system. By comparison, a thread on the Windows operating system defaults to 1 MB just for the stack, additional space is also needed for bookkeeping and thread local storage. Because they are so lightweight, an application can spawn literally millions of processes simultaneously.

In short, Joe argues, "Throughout, it became abundantly clear that TM, much like generics, was a systemic and platform-wide technology shift. It didn’t require type theory, but the road ahead sure wasn’t going to be easy." The whole blog post deals with how many implementation challenges platform-wide support for STM would be in .NET, including what options were considered. He does not mention Maurice Herlihy's SXM library approach, but refers to Tim Harris's work several times.

If you need a quick reference guide for the UML notation, check one of the following, IMHO, gret UML cheat sheets (in no particular order):

When a data (typically a variable) can be accessed by several threads, you must synchronize the access to the data to ensure visibility and correctness.

As many long time readers know, I am an enthusiast of the F# programming language.  I make no apologies for the fact that, if you are developing software on the .NET platform, F# is one of the better choices you can make for numerous reasons.  It is one of the reasons I proudly contributed as a co-author to the book, Professional F# 2.0, which is being published by Wrox in October. Some of the oft cited benefits of F# are that, to distill them quickly, it is good at doing intensely mathematical operations, it is built for parallelism, and it is good at helping define domain specific languages.  Those benefits are so often cited by speakers on the F# speaker circuit that they pretty much seem cliche to me at this point (note, yours truly is proud to call himself a member of said circuit, and often gives this talk!)  As great as these features are, there are a couple features, that in my more mundane F# experiences, seem to stand out as things that “save my ass”, for lack of a better phrase, more often than not.

In order to test and run benchmarks on the work I'm doing around creating a managed variant of the JSR-166y ForkJoinPool along with supporting infrastructure for use with Scala Actors, I'm creating a test harness that captures a host of environmental factors about how it was run, and writing sbt actions to make it easy to run the benchmarks and automatically permute the variables.