Monthly Archives: April 2012

Einstein’s Riddle and Closed Questions

April 28, 2012 By in Uncategorized Tags: , 6 Comments

There was a question posted to Stackoverflow about an implementation of the solution of “Einstein’s Riddle” in F#.  Here’s the text of the question, which I include in case the text of the question is later altered:

I’m looking for Einstein’s Riddle solution using F# and I’ve found only Einstein meets F#.

Is F# suitable for this problem and are there any other implementations?

After a bit of discussion and debate, the question was closed.  After a bit more discussion, the question was reopened.  It’s currently well on its way to being closed again. This is nothing that unusual for Stackoverflow.

What I found quite interesting and a little bit troubling was a thread of tweets on Twitter about who closed the question and why it was closed.  Perhaps I misunderstood the tweets in question but it seemed that people thought the question was closed partly because it concerned F#. One person implied that one of the people who voted to close the question had no right to do so because he’s never answered an F# question and therefore can’t know anything about F#.

Now this is solely my opinion, of course, but I think the question should be closed, F# or not.  The reason is the second sentence.  “Is F# suitable for this problem and are there any other implementations?”  If he had stopped after the first question, I would have been fine with the question being left on Stackoverflow.  However, think about that second sentence “Is F# suitable for this problem” – well, I don’t know.  Define suitable and then we’ll talk.  F# is suitable for lots of stuff but if you need to build a solution on the JVM then no it’s probably not suitable.  If you need to interface with lots of native DLL’s on Windows, there may be more suitable approaches.  If you’d like very succinct, short code then probably Prolog is more suitable. This strikes me as a terrific example of an open-ended question.  Without additional context it’s impossible to give a definite answer. And the second part “are there any other implementations?”  Well, yes, I’d be willing to bet there are.  Which language?  Why do you want to see the code—I mean I doubt this is something for work so why do you want to study it?  Again, hard to answer without additional context.

To my mind the second sentence is rather an open-ended question no matter how you interpret it.  And the Stackoverflow FAQ pretty clearly asks people not to ask open-ended questions: “Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page”.  Now the FAQ is not the received word of God but it is a sort of contract that the people paying to run the site ask all of the users to honor.

Frankly I have to say that I’m a little disappointed with my fellow F# developers who seem to think that someone is going through and closing questions solely because they touch on F#.  It takes five votes to close a question—one person with a grudge is only 20% of the way there–and I don’t think implying that someone has a personal grudge against F# is really helpful or productive.

Don’t get me wrong; I have nothing against open-ended discussion questions.  I do have a problem with people posting such questions on Stackoverflow when the people running the site have repeatedly asked members not to do so.

Now some of you reading this will think—fine delete the second sentence.  But that’s not quite the same thing as fixing a typo now is it?  If the original questioner would remove that second sentence I’m sure no one would be voting to close his question.  But that should be his decision.

As I say, I’ve got nothing against open-ended discussions—love them in fact.  But when someone provides a great service to me for free and they ask me to please avoid a certain behavior it seems a bit ungrateful for me not to avoid it.

And please fellow F# developers—dial down the paranoia a bit please?  Hypersensitivity to any whiff of anti-F# feeling isn’t really helping us to get the word out about a great language.

You Might As Well Use Globals

April 22, 2012 By in Software Engineering 7 Comments

I’ve seen a relatively common anti-pattern in Object-Oriented development, although to be fair, I’ve seen something closely akin in non OO languages as well.  The following C# code is a demonstration of the issue:

 

using System;

public class C
{
    private int _m;

    public C(int myInitialValue)
	{
        _m = myInitialValue;
	}

    private void f()
    {
        if (_m > 0)
        {
            _m = 1;
        }
        else if (_m <= 0)
        {
            _m = 0;
        }
    }

}

Can you spot the problem?

The problem is the constructor and the f function using the class variable _m directly.  What could be wrong with that, I hear some of you asking?  A few things:

1.)  Let’s say I need to use the functionality of f somewhere else.  I now need to take _m with the code. Big deal I hear you saying—I need to remember to copy a variable.  Now pretend that f accesses not just one member variable but that it accesses three or four member variables.  To say it in a little more technical way, there’s now a coupling between f and _m (and any other member variables we might use within f).

2.) By referencing _m within f but not passing it in f’s parameter list, I’ve made f a bit less of a black box.  And I’ve modified _m but it’s not obvious outside of the function; I have to look at the contents of f to see that _m is modified. Again, with only one variable this is probably not a big problem, but consider the case where I’m referencing 3 or 4 member variables or maybe even more.

3.) Now consider the case where we need to guard the values put into _m or I need to transform the value in _m when I read it.  No problem, you say, simply add an inspector and mutator to the _m member variable.  And that would be great but it wouldn’t fix the problem in f because f is accessing the member variable directly.

Basically all of the problems that convinced people that using global variables is a bad practice are present in this way of using class level member variables.  The irony is that developers who’ve grown up with the dogma that global variables are a very bad practice which should be avoided at all costs think nothing of writing code like this. 

Now, as I often point out to people, we’re discussing engineering not religion; very few things in engineering are absolutely always right or always wrong.  However I cannot think of many cases where direct access to a member variable in a class is a better approach than either passing the value explicitly as a parameter, returning the new value explicitly or accessing the member variable via an inspector or a mutatator.