Programming Everything!

Starting from Visual Studio 2010 F# is full member of .NET Framework languages family. It is functional language with syntax specific to functional languages but I think it is time for us also notice and study functional languages. In this posting I will show you some examples about cool things other people have done using F#.

When Sven Groot was in town a while ago we dropped by Erik Meijer's world and got a look at what he and team have been and still are working on (thus there is no out-of-date property of this fun and insightful interview that is off-the-cuff as it gets: deep Channel 9 ). It's great that we were able to put a real live Niner into fire in one of Erik's team meetings. There is a great deal to learn here. Thank you, Sven, for being a real sport! Great stuff in here. Tune in!

Today I'm excited to share the project a small team of amazing people and I have been working on for the past two years; HipHop for PHP. With HipHop we've reduced the CPU usage on our Web servers on average by about fifty percent, depending on the page. Less CPU means fewer servers, which means less overhead. This project has had a tremendous impact on Facebook. We feel the Web at large can benefit from HipHop, so we are releasing it as open source this evening in hope that it brings a new focus toward scaling large complex websites with PHP. While HipHop has shown us incredible results, it's certainly not complete and you should be comfortable with beta software before trying it out. HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP's runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations.

F# is Microsoft's first functional programming language to be included as one of Visual Studio's official set of languages. F# is a succinct, efficient, expressive functional/object-oriented programming language under joint development by Microsoft Developer Division and Microsoft Research. During the course of Erik Meijer's fantastic lecture series on functional programming fundamentals several of you asked for examples of specific topics in F#. Well, we listened. Dr. Don Syme is a principal researcher in MSR Cambridge. He has a rich history in programming language research, design, and implementation (C# generics being one of his most recognized implementations), and is the principle creator of F#. Who better to lecture on the topic than Don? This three part series will serve as an introduction to F#, including insights into the rationale behind the history and creation of Microsoft's newest language.

OpenGL 3.1 introduced two new sources from where shaders can retrieve their data, namely uniform buffers and texture buffers. These can be used to accelerate rendering when heavy usage of application provided data happens like in case of skeletal animation, especially when combined with geometry instancing. However, even if the functionality is in the core specification for about a year now, there are few demos out there to show their usage, as so, there is a big confusion around when to use them and which one is more suitable for a particular use case. Both AMD and NVIDIA have updated their GPU programming guides to present the latest facilities provided by both OpenGL and DirectX, however I still see that people don’t really understand how they work and that prevents them from effectively taking advantage of these features. Once, at some online forum, I found somebody arguing why is this whole confusion introduced by the Khronos Group and why there is no general buffer type to use instead and the decision whether to use uniform or texture buffers should be a decision made by the driver. This particular post motivated me to write this article.

For my latest project, WeatherBar, I had to pick a weather API. Basically, I needed to get the weather conditions for a specific location, as well as a short forecast. The choices I had were Yahoo Weather API, WeatherBug API and Google Weather API (yes,there is no mistake here – it is a direct API call, since Google doesn’t have an official page for this API). Probably there are more services offering a public weather API out there, but these caught my attention.

Running languages on .NET is ultra-powerful. Using managed COBOL (from Micro Focus), it is possible to use F# code to work with COBOL code. Imagine a Cloud based F# map reduce system consuming legacy COBOL - yes, that really is on the horizon.

One of the common discussions that I've had with several colleagues when we're making use of some of the higher order functions that can be applied on collections is whether to use the LINQ style syntax or to chain the different methods together. I tend to prefer the latter approach although when asked the question after my talk at Developer Developer Developer I didn't really have a good answer other than to suggest that it seemed to just be a personal preference thing. Damian Marshall suggested that he preferred the method chaining approach because it more clearly describes the idea of passing a collection through a pipeline where we can apply different operations to that collection.

In this interview made by InfoQ’s Sadek Drobi, Don Syme, a Senior Researcher at Microsoft Research, answers questions mostly on F#, but also on functional programming, C# generics, type classes in Haskell, similarities between F# and Scala.

In functional programming, monadic characterizations of computational effects are normally understood denotationally: they describe how an effectful program can be systematically expanded or translated into a larger, pure program, which can then be evaluated according to an effect-free semantics. Any effect-specific operations expressible in the monad are also given purely functional definitions, but these definitions are only directly executable in the context of an already translated program. This approach thus takes an inherently Church-style view of effects: the nominal meaning of every effectful term in the program depends crucially on its type. We present here a complementary, operational view of monadic effects, in which an effect definition directly induces an imperative behavior of the new operations expressible in the monad. This behavior is formalized as additional operational rules for only the new constructs; it does not require any structural changes to the evaluation judgment. Specifically, we give a small-step operational semantics of a prototypical functional language supporting programmer-definable, layered effects, and show how this semantics naturally supports reasoning by familiar syntactic techniques, such as showing soundness of a Curry-style effect-type system by the progress+preservation method.

In case you haven’t realized it, the new trend in computer chip technology is multi-core. This is where most of the speed improvements moving forward will come from on our computers. To take full advantage of this however it is necessary to design your applications using Parallel Programming practices, also known as "parallelism". In today’s episode, we will meet with Stephen Toub, who will share with us some of the overarching concepts associated with parallelism, and some of the ways we are trying to empower developers to develop applications to take advantage of it.

The past couple of years have seen some extended debates on whether Scala is a functional language. On the one hand, Scala offers essentially all programming constructs typically associated with functional programming and a lot of Scala code is purely functional. On the other hand quite a few people disagree that Scala is a functional language. For instance, Robert Fischer writes that Scala is Not a Functional Programming Language and Daniel Spiewak summarizes some of the arguments asking Is Scala Not Functional Enough?

In ASP.NET development, F# also offers productivity advantages over VB and C#.  F# is different because it is statically checked and type-safe.  It addresses weaknesses in ASP.NET development like untyped values, complex form construction, and using strings for IDs and method names that connect markup with code-behind (class-files).  Writing a web application in F# on the WebSharper platform can be less-time consuming if a developer is not great at writing web apps in JavaScript.  Through WebSharper, developers can write a web app using a large subset of F# and .NET core libraries and then just let WebSharper map the code to JavaScript.  WebSharper can integrate with ASP.NET applications, but it is different from the standard approach because it builds applications from miniature web pages called "pagelets".  The pagelets correspond to functions on the client-side and they are automatically translated into JavaScript.   WebSharper supports a wide range of JavaScript libraries, making it easy for developers to optimize their code in whatever way they choose.  jQuery, qooxdoo, Flapjax, and Yahoo UI are all supported by WebSharper.  The leap from F# to JavaScript is manageable because both are functional languages that support lambda expressions and closures.  Another unique part of WebSharper is a "formlet".  A formlet is a special pagelet that provides form functionality.  Formlets in Web Sharper run and validate on the client, submitting their result to a either a client- or a server-side callback.

Jeffrey Richter has completed CLR via C#, Third Edition and the book is at the printer! We’ll post chapter excerpts when the book is available in a couple of weeks. Here is Jeffrey describing the book in his Introduction:

TenAsys Corporation, a provider of real-time OS and virtualization software, has announced that all of its embedded virtualization software products, including the INtime real-time OS for Windows, provide full support for new 2010 Intel Core processors and companion chipsets for the embedded market.

From Nic:   We're piloting a new show idea on Wednesday called Help Desk where we put together a group of Windows trouble shooting gurus and get them to answer your Windows PC issues live on the air...   Any Niners out there have Windows PC issues/questions they need some help with?   Send to ch9live(AT)microsoft(DOT)com or tweet us @ch9live and make sure to watch the show live or check out the broadcast afterwards on demand.

The first textbook of its kind, Programming Massively Parallel Processors: A Hands-on Approach launches today, authored by Dr. David B. Kirk, NVIDIA Fellow and former chief scientist, and Dr. Wen-mei Hwu, who serves at the University of Illinois at Urbana-Champaign as Chair of Electrical and Computer Engineering in the Coordinated Science Laboratory, co-director of the Universal Parallel Computing Research Center and principal investigator of the CUDA Center of Excellence. The textbook, which is 256 pages, is the first aimed at teaching advanced students and professionals the basic concepts of parallel programming and GPU architectures. Published by Morgan Kaufmann, it explores various techniques for constructing parallel programs and reviews numerous case studies. With conventional CPU-based computing no longer scaling in performance and the world’s computational challenges increasing in complexity, the need for massively parallel processing has never been greater. GPUs have hundreds of cores capable of delivering transformative performance increases across a wide range of computational challenges. The rise of these multi-core architectures has raised the need to teach advanced programmers a new and essential skill: how to program massively parallel processors.

Verification of algorithm-intensive systems is a long, costly process. Studies show that the majority of flaws in embedded systems are introduced at the specification stage, but are not detected until late in the development process. These flaws are the dominant cause of project delays and a major contributor to engineering costs. For algorithm-intensive systems —including systems with communications, audio, video, imaging, and navigation functions— these delays and costs are exploding as system complexity increases. It doesn't have to be this way. Many designers of algorithm-intensive systems already have the tools they need to get verification under control. Engineers can use these same tools to build system models that help them find and correct problems earlier in the development process. This can not only reduce verification time, but also improves the performance of their designs. In this article, we'll explain three practical approaches to early verification that make this possible. First, let's examine why the current algorithm verification process is inefficient and error-prone. In a typical workflow, designs start with algorithm developers, who pass the design to hardware and software teams using specification documents.