Dysfunctional Programming

Oracle sues Google over Android and Java

aaron — Fri, 13 Aug 2010 03:11:37 +0000

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

aaron — Mon, 09 Aug 2010 17:23:15 +0000

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.

Go: Defer, Panic, and Recover

aaron — Thu, 05 Aug 2010 05:50:41 +0000

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

aaron — Thu, 01 Jul 2010 23:29:03 +0000

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.

Wicked cool — mandlebulb fly-through

aaron — Fri, 25 Jun 2010 18:54:21 +0000

Please, PLEASE watch this in HD full screen.

Wow. Math can be breathtakingly beautiful.

via YouTube – Mandelbox trip.

GOTOs inconvenient

aaron — Fri, 25 Jun 2010 15:03:12 +0000

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

aaron — Sun, 20 Jun 2010 18:37:05 +0000

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.

Painfully few programmers are aware of the Liskov Substitution Principle (LSP), and its violations incur the wrath of some distant cousin of the the side effect monster, the violated invariant monster. LSP is incredibly tricky to apply – generally, the object metaphor actually gets in the way of verifying LSP properties. The general guidance of OO spends far too little time on these implications. Inevitably, a programmer does something totally reasonable but everything breaks anyway.

I try to follow the LSP when designing green-field. This rarely permits me to use inheritance of implementation. Rather, composition dominates my designs.

For the curious, the author’s program strengthened a precondition – the derived class CSet required the element be unique for insert to ‘succeed’, where CBag required nothing. As such, LSP predicts that CSets cannot be transparently substituted where CBags are predicted; if they are, different behavior may (and did) result.

Best and Free Programming Ebooks

aaron — Sat, 19 Jun 2010 20:53:40 +0000

(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.

Hacker News | “it was designed to restrict the kind of trouble programmers can get themselves …

aaron — Thu, 17 Jun 2010 06:25:10 +0000

Great one liner on PL design:

Every programming language is designed to restrict trouble programmers can get into. The key is that they all have different ideas of trouble.

via Hacker News

Yeah, Toast

aaron — Fri, 04 Jun 2010 06:53:19 +0000

So, for those not familiar, I go by toast` on the programming language IRC channels. So when I saw this video come up on youtube, with Mr. Engineer (my preferred TF2 class), I had a feeling of a certain kind of awesome. Like it was meant for me, or something.

Yeah, Toast!!