Almost too much to keep up with this week.  Most notably, Roger Castillo gave a fantastic talk on F#’s Language Oriented Programming features.  Also interesting, the Microsoft Research F7 project, Symbolic Differentiation, and tail call optimized corecursion.

 

Roger Castillo’s Language Oriented Programming in F#

Roger will present one approach to Language Oriented Programming in F#, a technique in which software designers borrow techniques from language design to organize software architectures.

The most advanced F# talk I’ve seen to date.  In this talk, Roger examines some of F#’s LOP features and discusses a methodology for leveraging said features to build DSLs.

 

F7: Refinement Types for F#

F7 is an enhanced typechecker for the F# programming language. F7 supports static checking of properties expressed with refinement types. Our motivation is to check various security properties of F# implementation code by typing.

A very exciting Microsoft Research project.  Static checking of cryptographic protocols and access control mechanisms could do much for safety if used generally.

 

Symbolic Differentiation in C#/F#

[A] simple C#/F# library for Symbolic Differentiation and whatever else comes to mind.

Some features, such as parallel computation of expressions, are only supported in F#.

 

Jomo Fisher’s Adventures in F# – Corecursion

Mutual recursion is a useful feature and I was sure F# must have a way to support it. I searched around quite a bit, but I didn't know the right question to ask the search engines. Eventually, I got some help from my friend  Luke Hoban.

I was interested to find out that tail recursion optimization works with corecursion as well.

 

F# Cheat Sheet

This sheet glances over some of the common syntax of the F# language. It is designed to be kept close for those times when you need to jog your memory on something like loops or object expressions.

Very useful to have on hand when teaching F#.

Michael Feathers, author of the excellent book Working Effectively with Legacy Code, recently tweeted about a paper written by Peter Van Roy entitled Programming Paradigms for Dummies: What Every Programmer Should Know.   I thoroughly enjoyed the paper, despite being initially put off by its title.  It’s written in very accessible language and the vast majority of programmers would benefit greatly from giving it a read. 

Understandably, most won’t take the time to read a 50-odd page academic paper unprompted.   We are all busy professionals with full lives.  With this in mind, I would like to share the core of the ideas contained therein.  Perhaps this short summary might intrigue in so far as to incite the printing of said paper for placement by the bed side, or in the bathroom, for future perusal.

 

What Every Programmer Should Know

What exactly constitutes a paradigm? In this paper Peter Van Roy provides the following definition:

“A programming paradigm is an approach to programming a computer based on a mathematical theory or a coherent set of principles.”

This concept along with Imperative, Object Oriented and even Functional programming are spoken of in many software development circles.  However, little known to the every day software engineer is the family tree of paradigms which has continuously been evolving since the advent of computing.  Each paradigm having been invented to reduce the complexity of solving a particular computational problem.

The basic idea of this paper is that, as Software Engineers, we should take the time to learn paradigms outside the scope of those had in mind by our language’s designers.  Because most languages directly support only one or two paradigms, problems are frequently solved in needlessly computationally expensive, convoluted and difficult to maintain ways. 

Therefore, the best approach language community leaders can take is to learn, retrofit our existing languages and promote knowledge of these paradigms.  In this way we can enjoy many of their benefits and start solving problems in the most manageable way available.

 

Additional Thoughts on The Ideal Multi-Paradigm Language

In the ideal case, a language would directly support all known paradigms well.  However, even given the realization of this currently unrealistic language, it would take a long time to see widespread adoption.  As time passed and the language was adopted, surely new paradigms would be invented and the language would be no longer “paradigm complete”.  Thus the process would likely have to be repeated ad infinitum.

This is not to say the trying to build such a language would not be worthwhile.  Perhaps even some kind of paradigm meta layer could be made to enhance extensibility.  However, I do believe that with any language it would only be a matter of time before a paradigm was invented that violated an underlying assumption of the system, and the processes would need to be restarted from scratch.