Coding standards and type inference

With type inference you avoid “finger-typing” on both sides of an assignment:

Foo myFoo = new Foo()
var myFoo = new Foo() //Type-inference (no "win" here, but with parameterized types...)

Type inference also works with functions, allowing you to write:

def bar() : Foo = { ...etc... }
def bat(foo : Foo) = { ...etc... }

var myFoo = bar(); //Type-inference works fine

But I’m wondering if a coding standard that specified a type on the LHS of such assignments would be clearer:

Foo myFoo = bar();

Pro arguments:

  1. If you think type signatures are important for reasoning (which you presumably do if you’re using a type-inferred language), it follows that the explicitness is helpful; and
  2. If you change bar()s signature, the compiler’s going to complain about the call to bat (“Foo expected, found SomeNewType”) and that’s a little misleading.

Con arguments:

  1. Complaining about what’s passed to bat() is only “misleading” in the sense that people aren’t used to it; and
  2. Putting types on the LHS is an insult to referential transparency, since it is making explicit a difference in assignment use-cases

I am tending towards the “Con” arguments, but I think there’s merit to the “Pro” arguments. Anyone care to make the case that the “Pro” coding standard is superior?

Review: “A Dance with Dragons” by George R.R. Martin

A Dance With Dragons (A Song of Ice and Fire, #5)A Dance With Dragons by George R.R. Martin

My rating: 3 of 5 stars

Definitely a step up from “A Feast for Crows” (my review: “What a slog…”) in that it is primarily told from the viewpoint of major characters, but the plot is still disturbingly bogged down: after five books in a seven-book series, the pieces ought to be staged for the climax, but it’s very difficult to believe that’s the case. My only thought is that a bold stroke would be to start the next book 5 years later, with the important viewpoint characters having walked the paths they’re currently on and near the final crisis. It took the author 5 books to get us through Fall, there’s no way that he can satisfactorily get through Winter and end with the first signs of Spring unless he changes something about his strategy.

View all my reviews

Review: Kraken by China Miéville

KrakenKraken by China Miéville

My rating: 4 of 5 stars

Perhaps the most successful “modern gods and magic” book I’ve read (although actually I experienced it as an audiobook). This is the quality that I thought “American Gods” was going to achieve (when in fact I thought that book was quite over-rated). Miéville does an exceptional job establishing the relative power of the various players and, although the climax involves universe-altering forces, there’s the strong sense that the author got to that point in a fair way. There’s a good deal of absurdity (that Star Trek is worshipped leads to some key capabilities) but in general the author plays it straight, with the protagonists trying to forestall the apocalypse, and appropriately dreadful antagonists menacing them. The narrator of the audiobook, John Lee, does a great job with a text that’s filled with neologisms, parentheticals, and interrupted dialog.

View all my reviews

Half my life ago, today

On July 3, 1988, I moved to San Francisco from San Diego (more specifically, I moved to Sausalito from Pacific Beach) to take a job as Product Review Editor on Computer Language and AI Expert magazines. I remember riding the Marin Airporter (for the first, but certainly not last, time) over the Golden Gate Bridge and taking in the view of the Bay and thinking “Wow, I live here.”

Tina stayed in San Diego for a couple weeks, packing up and saying good-bye to daily swims at La Jolla Cove.

Struggling with the benefits of the Reader monad

Still struggling with the benefits of the Reader monad… In the well-liked answer on StackOverflow, mergeconflict says

I can explain how Reader works easily: it’s a function, and it takes an argument.

OK, so I think the structure of the technique seems clear: instead of being dependent on some configurable value, it’s preferred to return a function that takes an argument.

This seems to be asserting that :

def foo : Configuration => Unit = { config : Configuration => bar(config) }

is markedly superior to :

def foo(config : Configuration) : Unit = { bar(config) }

? I’m afraid I don’t see the benefit.

The Reader monad is held out as superior to, in particular, DI frameworks, but it seems that :

In contrast, how does Spring (for example) work? …… “we still have to choose” – Sure. In either approach, you have to choose which environment you want to use. That aspect is not magic either way

This seems like begging the question: the “magic” (or at least Reflection) in Spring is a way to deal with the “you have to choose which environment you want to use,” (choosing a type and setting values) aspect not a way to deal with using that environment (acting on those configured values).

If I understand correctly (and it’s clear that something isn’t clicking with me), the Reader monad doesn’t provide a solution to the “choose which environment” task. I think I’d have to write, in source code, something like

val connectionString = System.getenv(“connection_string”)
val connectionString = args[0]
val connectionString = loadFromPropertiesFile(System.getenv(“properties_file”))
…etc any of a million ways, of which @Resource annotations might well be considered the most reasonable

I’m really not willfully trying to drag my feet here. I’ve got a real problem where I have 10KLoC of pretty dense code that has hard-coded throughout it some lists that need to be configurable. I really want to do the technique that has the highest quality.