Category Archives: repost

PDC10: Future of C# and Visual Basic

Anders Hejlsberg talking on the new C# and VB features for the version to follow C# 4.0 (timecode 48:10):

[Async methods] allow you to compose asynchronous stuff using normal flow of control and using all of the statements that you know already.

Pretty sweet. The first (longer) portion of the presentation is on the new asynchronous programming features for C# and VB. A hidden gem at the end (starting at timecode 50:40) is the “Compiler as a Service” status report. They’re experimenting with providing compiler front end, back end, and intermediate transformations as a run-time library.

It’s curious that there was no mention of the async transformations (first section) during his discussion of general purpose syntax transformations (second section). It would be interesting to see whether the “Compiler as a Service” libraries provide sufficient support as to be able to extend C# with things like ‘iterator syntax’ or ‘async methods’, without having to wait for a new compiler.

(A nod of course to Lisp’s macros, Scheme’s continuations, and Haskell’s use of monads; for defining new control flow primitives)

FAIC: CPS Revisited

Eric Lippert of Fabulous Adventures In Coding has posted a series on CPS tranformation and different control flow abstractions. Good stuff — recommended reading for translating the crazy stuff I talk about into ‘normal’ code.

Continue reading

Oracle sues Google over Android and Java

Oracle sues Google over Android and Java | CNET News.

Wow. Sun may have open-sourced Java in the past, but at this moment, the JVM seems like a more hostile platform than .Net.

Island/Lake recursion

The Island and Lake Combination.

For those who are curious which is the largest (island in a lake on an)^2 on an island. Because recursion isn’t just for programmers and computers.

Functional Programming, Reductio

Came across a slide deck via Reddit with an excellent point, cutting across the various functional programming diciplines:

Central to the thesis of FP is the notion of referential transparency.

Referential transparency leads to program compositionality.

// #1
X x = function();
R r1 = arbitrary(x);
R r2 = arbitrary(x);

// #2
R r1 = arbitrary(function());
R r2 = arbitrary(function());

If these two programs produce the same outcome then function is referentially transparent.

Well put. Back to the Reddit thread, functional programming and imperative programming are not a true dichotomy, but they one does need to mix carefully.

I find it most useful to build imperative programs on top a functional base, a foundation if you will. Taking the previous example, the function ‘arbitrary’ may not be a true function; it may modify persistent state, the values r1 and r2 being unequal. But building on top of the referentially transparent ‘function’, i can later refactor my program from #1 to #3:

// #3
void part1() {
R r1 = arbitrary(function()); /*...*/
}
void part2() {
R r2 = arbitrary(function()); /*...*/
}

And be able to rely on r1 and r2 being unchanged from their meaning in #1.

Referential transparency can be explained as the property that a function means the same thing every time you call it, no matter where or when you call it. That’s a very useful property to have in understanding and refactoring programs.

GOTOs inconvenient

From “The Discovery of Continuations

The talk actually had one direct and important consequence for computing. Under the inspiration of the notion of the unnecessity of goto’s, Dijkstra spent that evening constructing realistic examples of programs without goto’s, … So while van Wijngaarden said that goto’s were unnecessary … , Dijkstra stretched the point to say that goto’s were inconvenient. The latter lesson stuck. — McIlroy

The continuation passing transformation grew out an attempt to formalize GOTO, and ended up both obsoleting it as well as producing new, better structured control primitives (for example, break).  It’s strange to me that I could have gone as far as I have, as a programmer, without having a good understanding of this concept. We use it implicitly all the time — the call stack of course — but rarely consider all of the ramifications (threading) and certainly not all of the utility (coroutines, exception handling, etc).

Trouble with OOP

Subtyping, Subclassing, and Trouble with OOP.

Excerpt:

What makes this problem more unsettling is that both you and I tried to do everything by the book. We wrote a safe, typechecked code. We eschewed casts. g++ (2.95.2) compiler with flags -W and -Wall issued not a single warning. […] And yet, despite all my efforts to separate interface and implementation, I failed. Should a programming language or the methodology take at least a part of the blame?

A lot of people miss the point with Object Oriented Programming (OOP) – this author gets it.

Continue reading