Posts Tagged ‘Languages’

Newer Entries »
Jan
17
2005

Thinking Better Tech Designs

Where I work, there are programmers of widely varying skill levels all working on a single project. Some pieces tend to get behind, and some finish much more quickly. There are a seemingly endless number of integration problems. I am daily pondering what the differences are in the way people develop, and how I can communicate good ideas in a way that will help people reach that “eureka” moment where they get it.

Generally speaking, I’ve been pretty bad at it. I’ve tried explaining inheritance with stories, shaking people by their collars, etc, nothing really seems to work. The result is that people write code the way they always have: messy, hard to understand, hard to transfer to another owner, hard to change without creating new bugs.

Today this SLAR on System::Console got me thinking. Particularly, this line:

This class is a classic example of “design in reverse.” Before we designed this class we knew what we wanted the Hello World example to look like:

Console.WriteLine ("Hello World");

Well, there it is. That might be my own “eureka moment.” Write an API for yourself as you go. For every task you have to accomplish, ask yourself this:

If I had access to an oracle that could do my task for me, how would I want to use it?

Then start building that oracle. It’ll have steps that seem hard too, but use more oracles and more black boxes.

Another important point is to avoid thinking about code as much as you can.

Now, there are (obviously) a lot of steps between being a programming neophyte and being in the top few percent of software engineers. Most people need to get a lot of bad code out of their system before they’re much good. And this is certainly an oversimplification of thinking like a good developer.

Thinking of the best questions to ask your oracles can be a subjective, soft science too–but hopefully this is a decent starting point.

Tags: , ,
Posted in Programming | No Comments »

Jan
15
2005

Thread Safety in VB-2003 Events

Brad Abrams had a recent post about how the usual way of raising an event in C#:


protected virtual void OnMyEvent(EventArgs e)
{
    if(MyEvent != null)
    {
        MyEvent(this, e);
    }
}

is not threadsafe. Purely out of curiosity, I wondered if VB handles this the correct way:


protected virtual void OnMyEvent(EventArgs e)
{
    EventHandler handler = MyEvent;
    if(handler != null)
    {
        handler(this, e);
    }
}

Since VB abstracts this away with the RaiseEvent keyword. Unfortunately it doesn’t seem to, as this code:


Protected Overridable Sub OnMyEvent(ByVal e As EventArgs)
    RaiseEvent MyEvent(Me, e)
End Sub

Compiles to this:


.method family newslot virtual instance void OnMyEvent([mscorlib]System.EventArgs e) cil managed
{
      // Code Size: 22 byte(s)
      .maxstack 8
      L_0000: ldarg.0
      L_0001: ldfld [mscorlib]System.EventHandler VbConsoleApp.Test::MyEventEvent
      L_0006: brfalse.s L_0015
      L_0008: ldarg.0
      L_0009: ldfld [mscorlib]System.EventHandler VbConsoleApp.Test::MyEventEvent
      L_000e: ldarg.0
      L_000f: ldarg.1
      L_0010: callvirt instance void [mscorlib]System.EventHandler::Invoke(object, [mscorlib]System.EventArgs)
      L_0015: ret
}

Which has a race condition–it should store the delegate in a local. Generally, my answer to all of these questions is “it is fixed in 2005” – so I’m going to just assume that that is the case here.

Tags: , , , ,
Posted in .NET, Microsoft Technology | 1 Comment »

Jan
09
2005

Re: “Best Method Names Ever”

From Brad Abrams.

I would have to say the best function name ever is definitely Function Batman.

But if we’re limiting it to Microsoft products, I guess I’d have to say I’m often surprised by the number of internal framework methods that are labeled “hacks.”

.NET Framework hacks

Tags: , , , ,
Posted in .NET, Microsoft Technology | No Comments »

Jan
09
2005

.NET Math Quiz

I’ve been having a lot of fun with this post on .NET Undocumented.

If x, y, z are ints, …

1. If x < 0, then -x > 0.

False, unchecked(-int.MinValue) == int.MinValue.

2. If x = -x, then x = 0.

False (see 1)

3. If x - y > 0, then x > y.

False, unchecked(int.MinValue - int.MaxValue) == 1

4. If x and y are positive, then x + y > x.

False, unchecked(int.MaxValue + 1) < int.MaxValue

5. If x and y are positive, then (double)x * (double)y = (long)x * (long)y.

True – I don’t think this can’t be broken over the range of the integers. Not so over the longs, though.

6. If x - y > 0 and y - z > 0, then x - z > 0.

False, use

int x = int.MaxValue-1;

int y = -1;

int z = int.MinValue;

This gives you x - y == int.MaxValue, y - z == int.MaxValue, and x - z == -1.


If x, y, z are doubles, …

1. x = x.

False. double.NaN != double.NaN.

2. If x > y is false, then x < = y is true.

False – use double.NaN for both.

3. If x > 0, then x - x = 0.

False. double.PositiveInfinity - double.PositiveInfinity == double.NaN

4. If x and y are positive integers, then x + y > x.

This is true because at the boundary condition, double.MaxValue + double.MaxValue == double.PositiveInfinity.

Note that this is different from the behavior of longs or ints. It is only true for integer doubles, though, because x + double.Epsilon == x.

5. If x and y are integers and x > 0, then the statement “x + y = x for all y” is false for all x.

True.

6. If x <= 0 is false, then x > 0.

Both statements are false for double.NaN.

7. If x and y are longs, then (double)(x + y) = (long)(x + y).

This is true because of the order of operations, but it does not hold for (double)x + (double)y.

8. if x.Equals(y), then x = y.

This is false for double.NaN.

9. If x.Equals(-x), then x = 0.

This is false for double.NaN.

10. if x.ComparesTo(y) < 0, then x < y.

This is false where x is double.NaN.

Note: You don’t need to use the unchecked keyword for the counterexamples using it to be valid; it is easy enough to come up with examples that will pass as long as runtime checks are off. I just used it so that my answers would be brief and would compile.

Tags: , ,
Posted in .NET, Microsoft Technology | No Comments »

Jan
08
2005

Moore’s Law and the Free Lunch

This article was brought to my attention from a few sources. The general theme here is, “concurrency is going to be really important as processors begin to hit physical limits, and these kinds of programs are harder to write.” I thought I would give my spin on it. Here is another one-sentence summary of that article, childishly represented using Windows Paint.

Your friend Jack Albertson

At the admitted risk of sounding too much like a doomsday prophet, my prediction can be summed up as follows: despite attempts at tool and language support (for instance, CΩ), this is going to be painful for a large percentage of developers. Software cycles will probably take a big turn for the worse, so you might be better off working on the quantum computers in your garages now.

My reasoning is heavily influenced by the alleged “object revolution.” The fact is, you can’t claim to be doing object-oriented development just by virtue of using a language that has object-oriented features. And you can’t reap the benefits of doing object-oriented development in that case, either. In this day and age, I still see a ton (scores… hundreds.. maybe thousands) of methods that are 200 lines long and take twelve arguments. Now you can put a “virtual” in front of a method like that, but there’s obviously still a problem.

I like this quote from Object Thinking:

Both software engineering and object orientation have achieved a strange status - everyone claims to be doing them without really doing so.

The thesis of that book is that OOP and traditional programming take drastically different mindsets. Changes in mindsets can be really difficult to accomplish. Tools help you but they don’t automatically make you good at the task at hand. We’ve got great OOP tools now, but I think a lot of people still work on teams where deadlines are missed, integrating code written by different people is hard, and any number of shortcuts leads to a mess of spaghetti. We get away with it to an extent, mostly because it is accepted that software projects are late and contain bugs. We work way too hard in the process, though.

And as accurate as I think that is for the “object revolution”, it is only more accurate for the upcoming “concurrency revolution.” Writing a multithreaded app is a lot different than writing a single threaded app.

It could be good news for the highly motivated / educated, but as in any field that is the minority. I’m looking forward to the challenge, but purely for selfish reasons.

Tags: , , ,
Posted in Programming | 2 Comments »

Newer Entries »