Month: September 2010

Posted on

Digital photography is not rocket science. It just seems that way.

Here’s a TV advert for a camera touting the benefits of film cameras over digital cameras. I’m almost inclined to wonder if this advert is a parody, but even so, it has a point.

Let’s watch…

Photography for technophobes.

I’m reminded of when I was lending my digital camera to a friend some time ago. She knew how to use a film camera, but the technological revolution had, alas, left her behind.

She had no problem with the LCD display on the back. This was why she wanted to borrow my camera in the first place after she saw me using it. Taking a picture while holding the camera at arms length is a lot easier than holding it up to the eye.

Showing her how to browse old pictures took a bit of teaching but she soon picked it up. It helped a lot that this camera had a big switch with only two settings; taking-pictures or looking-at-pictures.

The big stumbling point was when I showed her how to use memory cards. I tried to explain how it stores pictures, but I got a lot of blank looks. I finally said “This card is like the film.” There was a sudden look of understanding on her face.

The analogy to traditional film cameras worked perfectly. I told her that the photo shops will develop (print) her pictures, produce negatives (make a CD copy) and clean the film off to be reused again. If she needed more film, she could buy some by asking for a “128 MB SD” at the shops (which might tell you when this story took place).

Embrace the metaphor!

Film cameras are devices that direct photon particles in order to induce chemical reactions in silver halide particles mounted on sheets of cellulose acetate.

Somehow, the camera industry managed to sell us cameras without having to give us chemistry lessons first. And yet, we all need computer science lessons to use digital cameras. People never really cared about the chemical processes of film photography and we shouldn’t have to care about bits, megabytes and other pieces of jargon that can be abstracted away.

So, here are my suggestions for the digital camera industry.

1. Standardise!
Why are there so many memory card formats? As far as I can tell, they’re all flash memory chips contained in differently shaped blobs of plastic. The industry needs to pick one shape of blob and stick with it. No inventing new blobs unless there’s a really good reason to.

2. Call memory cards, ‘digital film’.
Embrace all the metaphors. If the world already has a name for something, don’t come up with a different name for it.

3. Tell me how many pictures it can store, not how many gigabytes.
This one will be tricky, as the size of a picture depends on the number of pixels. So while I don’t think we could realistically get rid of the “GB”, cameras need to help the user by telling us how many pictures are in a “GB” at that particular time.

4. Cameras should come with a reasonably sized card as standard.
How would you feel if you bought a camera, but later found the lens was extra? Digital film (getting used to the phrase yet?) is reusable and will probably last as long as the camera itself. So why not bundle it with the camera and save your customers the hassle.

5. Photo printing shops to provide archival DVDs as a standard part of the service.
People using film cameras expected their negatives as part of the service. Copying a few gigabytes full of pictures to a DVD should be cheap enough that it could be offered free to anyone who wants to print a vacation’s worth of snaps.

Hang on, did that advert just say two cameras for ten dollars? Forget everything I just wrote, that’s a bargain!

Picture credits:
‘Film and SD card’ by ‘sparkieblues’ of flickr
‘Leica’ by ‘AMERICANVIRUS’ of flickr

Posted on

reddit’d (Followup to ‘Construct Something Else’)

Fame at last! Fame at last!

My last piece, “Construct something else!” got a bit of attention when someone posted it on reddit.That was unexpected.

Remember the rule; If you publish something that’s a bad idea in hindsight, post a “clarification” article claiming you’ve been misunderstood and that you never thought it was a good idea in the first place. Then hide in the shower.

You see, I think I’ve been misunderstood. I was reading stackoverflow and I found the question asking about c# constructors. There was the comment from Eric Lippert, talking about the possibility of implementing this feature, but they were lacking a good reason to undertake the effort. Then I remembered I had exactly what he was looking for, a real-world use case! So I wrote up my experiences in a blog post and left a comment on the stack overflow question.

I thought I was rather clear that I was just providing Mr Lippert with a use case, rather than actually advocating it. Nonetheless, some people mistakenly took my post as advocacy and responded as such. Now if you’ll excuse me, I’m going to go have a shower.

šŸ™‚

But seriously, I remain of the opinion that implementing pseudo-constructors would be a good thing, but probably not worth the time for Microsoft to implement. But first, a quick aside to clarify (there’s that word again) how it could work. Just so we’re all clear (!) on what it is I’m advocating.

A pseudo-constructor would essentially be a static factory function. Call it, and it returns an instance of the class, perhaps using a private real-constructor inside. The only difference being that it can be called using the new operator. The compiler sees that the parameters match the pseudo-constructor signature and it generates code to call that static function instead. From a MSIL/CIL view, it’s just like a normal static function.

So why would this be a good thing?

Changing the interface without changing caller code.

This is the reason I raised in my original post. If version 1 of a DLL has a real-constructor, version 2 can use a pseudo-constructor in it’s place. The caller code would have to be recompiled, but the C# code would not need to be modified.

Intellisenseā„¢ simplification.

How many times have you needed an instance of particular class, typed new ClassName, only for Intellisenseā„¢ to show that no constructors are available. You slap your forehead and remember that this class uses static factory functions instead. If these could be called with a new operator, they would all appear in the same list.

(I suspect this was the original motivation for considering the feature in the first place.)

That’s it?

There’s a few good reasons not to make this change, which I’ll briefly discuss. Enjoy.

They won’t be real constructors.
(Thanks to reddit user “grauenwolf”.)

Sometimes, only a real constructor will do. When writing a subclass constructor, you can call the base class’s constructor just before the first opening brace using the base keyword. This would have to be a real constructor call, as you can’t just decide which base class to use at run-time.

Adding pseudo constructors doesn’t take away real constructors, but it might lead to confusion when people see that a base classes constructors have gone missing.

You don’t need it.
(Thanks to “Anthony” for commenting on the original post.)

You can do all this by making a class full of delegate instances. The constructor can select what functions to fill into those delegates at run-time. Add some [Obsolete] attributes so anyone writing new code will code against the new preferred objects.

So I don’t think this new feature would break anything, except it would be taking up the time of the clever people at Microsoft. Nice to have, but we don’t need it.

If you’re in the mood for discussing future directions of the C# language, please take at look at my earlier piece on destructors for structs. I’m interested in any thoughts on the subject or any reasons why it wouldn’t work.

I hope I’ve gained a little bit of an readership from this experience. If you’re reading this, please leave a comment. Without comments, we’re just bumping around in a closed system and tending towards entropy. Here’s some nice charts for a bit of insight on the reddit people.


Picture credit:
“The Walk of Fame” by flickr user Storm Crypt.
Readership charts by blogger.

Posted on

Construct something else! (C#)

Please read my follow-up post after reading this one.

Quoth rjw on stackoverflow…

Given the following client code:

Ā Ā Ā Ā var obj = new Class1();

Is there any way to modify the constructor of Class1 so that it will actually return a subclass (or some other alternate implementation) instead?

C# compiler guru, Eric Lippert commented…

We are considering adding a feature “extension new” which would essentially allow you to make a static factory method that would be called when the “new” operator is used, much as extension methods are called when the “.” operator is used. It would be a nice syntactic sugar for the factory. If you have a really awesome scenario where this sort of pattern would be useful, I’d love to see an example.

I have one!

Version one of our DLL had a class that wrapped a connection to a remote server.

Ā Ā Ā Ā using (var connect = new ExampleConnection("service.example.com"))
Ā Ā Ā Ā {
Ā Ā Ā Ā Ā Ā Ā Ā connect.DoStuff(42);
Ā Ā Ā  }

It worked great. Our customers were very happy with it and developed lots of code to use our little DLL. Life was good.

Time passes and our customers ask us to add support for a different type of server that does a similar job but with a very different protocol. No problem, we develop a new class called DifferentConnection and just to be helpful, both ExampleConnection and DifferentConnection implement a common interface object.

We’re about to release version two to our customers, but a common response comes back;

“This is good, but we were hoping your library would automatically detect which variety of server it’s talking to. Also, we really don’t want to change our code. We want to just drop your updated DLL into the install folder, but we’ll recompile our EXE if we really have to.”

With these new requirements, ExampleConnection had to become a class that supported both varieties of remote server. The constructor has to perform the auto-detect, and all of the public functions now all begin with an if statement, selecting for which variety of remote server is in use.

If we had a bit more foresight, we should have supplied a static Connect function that wrapped a private constructor. That way, version two of this function could have returned a subclass object instead. But we didn’t. There are costs to writing code that way, so you wouldn’t do it unless there was a clear point to it. If a normal constructor could return a subclass instead, there would be no problem.

Mr Lippert, I hope this provides the justification you need to add this to .NET 5, but I’d much rather have destructors on structs instead. I also want a pony.

Picture credit: ‘LEGO Mini Construction Site’ by flickr user ‘bucklava’.
(I don’t really want a pony.)

UPDATE: Someone submitted this to reddit. Lots of discussion there.
UPDATE(2): Follow-up post.