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 “FAIC: CPS Revisited”

Go: Defer, Panic, and Recover

It seems after much resistance to the idea, Go has added exception handling to the language in the form of defer, panic, and recover.

The Go Programming Language Blog: Defer, Panic, and Recover.

Don’t get me wrong, I think the’ve got something here.  Defer gives you the equivalent of C#’s finally/using; or a nice subset of C++’s destructors; or Lisp’s unwind-protect.  Panic = throw / raise.  Recover = catch.

The blog post gives the impression that you can’t programmatically access the value passed to panic — “recover returns nil” — but before judging that behavior I should try to confirm it in the Go documentation.

All in all, I’m giving this design a thumbs up. No element of it is new, but they seem to have brought exception handling in without compromising their mantra of practical and simple.

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 “Trouble with OOP”

Best and Free Programming Ebooks

(updated / switched link to source article on stack overflow)

So, I wrote my list of some unique programming texts. But on the more practical side, there’s this:

Best and Free Programming Ebooks.

Free full texts, covering: Bash, C, C++, C#, Common Lisp, Haskell Java, JavaScript, Lua, Objective-C, Perl, PHP, PowerShell, Prolog, Python, Ruby, SQL, x86 assembly, algorithms, version control, and a couple other topics.  I’ll still be putting together my own preferred lists, but half of what I’ve got is already on this list.