Computer Science Teacher
Computer Science Teacher - Thoughts and Information from Alfred Thompson

May, 2011

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Why Not C#


    Someone recently passed on same objection to using C# as a first or otherwise early programming language. I hear these sorts of comments all the time and while I have addressed some of  them in the past it seems like this is a good time to readdress them. These are my opinions of course. They are based on my own teaching experience as a high school computer science teacher. And your mileage may vary but these things I believe.

    C# is a proprietary MS clone of the Java language

    Two things in here. One is that C# is proprietary and the other is that it is a clone of Java. Neither of these is completely correct. The C# language borrows heavily from a number of languages including Java, C, C++, Visual Basic and Haskell just to name a few. In more recent years Java has borrowed heavily from C# as well. So while no language develops in a vacuum it is not far to call C# a “Java clone” even though they have many similarities. As for proprietary, C# is a standard language and C# compilers can be (and are being) created without any control or limitation from Microsoft or other vendor. The same can not be said for Java which, while it has a community model in theory, is largely controlled by Oracle who purchased Sun Microsystems. If there is a proprietary language in this mix Java fits the bill closer in my non-legal mind.

    OF course I don’t understand why being “proprietary” rules out using something in school anyway. From what I can tell they use copyrighted books, patented products, and all sorts of proprietary products every day in schools. With programs like MSDN AA for schools and DreamSpark for students getting software very inexpensively or even free for students is not an issue with C# either. There is also C# Express Edition which is a free and easy download.

    If students use Visual Studio, they'll spend all of their time placing buttons and not learning to program

    I’ve wrote about this before but it bares repeating. This is a teaching problem not a tool problem. On one hand you can, if you really want to, limit your students to command line programming. It’s just as easy and just as boring as programming in C, C++ or Java. So if boring is your goal please stay away from Visual Studio. On the other hand if you want students to enjoy the confidence and encouragement they might get from creating real graphical user interface programs that look “real” then maybe Visual Studio is for you. There are ways to keep students focused on the code that you want them to focus on as well. You can supply form templates for example. You can specify exactly what a user interface will look like as another option. OF course if you really want to have students spend more time on the user interface than on useful programs there are far better languages than C# (or Visual Basic) for that. Some languages have these really horrible APIs that you have to hand code every little piece and attribute of objects on a screen. Yuck!

    C/C++ give students a better foundation to learn other languages

    Assembly language is even better for this! But like C or C++ it is a hard way to start. If you are Bill Gates than by all means start with Assembly or even C/C++ but if you are anyone else you may want to think of something a little more easily approached for a first course. There will be time for C/C++ or even Assembly language down the road. I do believe though that this is also a teaching issue, a pedagogy issue, rather than a tool issue. It is a lot about how you teach the concepts that makes the knowledge transferable to new programming languages. And if the complexity of the syntax scares students off or just gets in the way of them progressing than you lose all of the theoretical value of the tool.

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Seven Rules for Beginning Programmers


    Paul Vick posted these Seven Rules for Beginning Programmers earlier this week and I have been thinking about them a lot. They make sense to me. As a professional developer you have to understand that these are the rules for beginners. The last item concludes with “You may go beyond these rules after you have thoroughly understood and mastered them.” It is important to remember that there are few absolutes but at the same time beginners need to exercise some caution while they are mastering the basics. Though honestly, even professionals should “Never use language features whose meaning [they] are not sure of.” Of course there should be fewer of those for experienced professionals than for beginners. Smile Here is Paul’s list.

    1. Do not write long procedures. A procedure should not have more than ten or twelve lines.
    2. Each procedure should have a clear purpose. It should not overlap in purpose with the procedures that went before or come after. A good program is a series of clear, non-overlapping procedures.
    3. Do not use fancy language features. If you’re using something more than variable declarations, procedure calls, control flow statements and arithmetic operators, there is something wrong. The use of simple language features compels you to think about what you are writing. Even difficult algorithms can be broken down into simple language features.
    4. Never use language features whose meaning you are not sure of. If you break this rule you should look for other work.
    5. The beginner should avoid using copy and paste, except when copying code from one program they have written to a new one they are writing. Use as few files as possible.
    6. Avoid the abstract. Always go for the concrete. [Ed. note: This one applies unchanged.]
    7. Every day, for six months at least, practice programming in this way. Short statements; short, clear, concrete procedures. It may be awkward, but it’s training you in the use of a programming language. It may even be getting rid of the bad programming language habits you picked up at the university. You may go beyond these rules after you have thoroughly understood and mastered them.

    I expect some to take exception with something in rule 7 -  “getting rid of the bad programming language habits you picked up at the university” After all isn’t the purpose of a university education to learn “the right way” to do things? Sort of. But the truth is that the types of projects that most complete as part of their education don’t always lead to best practices. The problem is size of the projects and also, in many cases, the artificiality of the projects. They have to be both small and somewhat artificial to fit in the concepts that are being taught. And in some schools software engineering is a dirty word (term) in computer science programs.  That’s not all bad as long as people who become software developers understand that they have things to learn about design and about creating large scale projects.

    Copy and paste is another interesting case and I am glad to see it on the list. There a huge temptation to copy and paste. Sometimes the idea is to use the new code as is in which case one should really think about encapsulating the code in a method, function or subroutine. Or the idea is to copy/paste and then make a little modification. The problem with that is that one invariably misses something in the process. And of course you also have the possibility of copying something that is wrong, buggy or just plain not as close a fit as you thought. Copy/paste means trouble later if far too many cases for beginners to use it as often as they seem to like to do.

    So what do you think of these rules? I see that Garth is planning on posting them in his lab. Would you consider doing the same thing?

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Windows Phone 7 Games in Visual Basic


    I’ve been working all week in C#. Now C# is a wonderful language if you are going to use semi-colons and curly braces. It fixes almost all of the issues I have with C++ and Java. But frankly I have missed the beauty of programming in Visual Basic. So when I saw Sam Stokes’ post (You can now use Visual Basic on Windows Phone 7 to do XNA development-) I knew it was time to take a VB break. So I got the document on Visual Basic Support in XNA Game Studio (Mango) and installed the Windows Phone Developer Tools 7.1 Beta and I went to town. Well actually what I did was to convert my C# Whack Something Game into Visual Basic. Hey I had to start somewhere. I’m going to rewrite it from scratch and do it right soon. Hopefully over the Memorial Day weekend if the “honey do” list is not too long. But for now here is a step by step illustrated with some code (not great code but it works) instruction on creating your first Windows Phone 7 Game in Visual Basic. BTW Pong in VB and XNA for Windows is here.

    Fire Drill Project

    We will be creating a game that causes “flames” to randomly appear on your screen. By touching the flames you will put them out. But beware! More flames will appear.

    Open Visual Studio and select New Project from the File menu. You should get a window that looks something like this:


    Select Windows Phone Game (4.0) and give you project a name such as FireDrill and press the OK button.

    On the Solution Explorer right click on the Content option and either select Add -> Existing Item or press Shift-Alt-a to open the file window. Browse to where the image files are and select x.png and flame.png.



    You can save the flame and X image from here and use them BTW.xflame Just save them with the right file names and extension.

    Now that we have the images we need it is time to start writing some code. We need several variables:

    • · Textures to identify the images
    • · Rectangles to hold the images and help with detection of touches.
    • · Flags to determine what images are being displayed
    • · Some counters to help control how often “fires” pop up.
    • · A random number variable to make things more random

    Our code might look something like this:


    Dim aFire As Texture2D, bFire As Texture2D, xButton As Texture2D
    Dim aRec As Rectangle, bRec As Rectangle, xRec As Rectangle
    Dim aShow As [Boolean], bShow As [Boolean]
    Dim r As Random
    Dim cycleCount As Integer, howOften As Integer

    This lines go in the top of the class right below the lines:


    Private WithEvents graphics As GraphicsDeviceManager
    Private WithEvents spriteBatch As SpriteBatch

    We’ll see how these are used in a minute. But we also have to initialize there variables. We’ll set the Booleans for aShow and bShow to false so that they are not displayed right away when the program loads. We’ll use howOften to determine how many frames to show before deciding to show or not show one of the fires. The default FPS (frames per second) for a Windows Phone is about 33 frames per second so if we wait every 30th frame that will be just about a second. We’ll change that randomly as the program runs to make things less predictable.

    We’ll also set the initial locations of our two flames, the X (for eXit) button and initialize our counters and random number variable. Out code will be in the Initialize method and look something like this:


    aRec = New Rectangle(100, 100, 47, 50)
    bRec = New Rectangle(700, 300, 47, 50)
    aShow = False
    bShow = False
    xRec = New Rectangle(0, 400, 64, 64)
    r = New Random()
    cycleCount = 0
    howOften = 30

    Our images are going into what we call 2D textures and we’ll bring them in from the files in the LoadContent method. Notice that we use the same file for both flames that wiil appear.


    aFire = Me.Content.Load(Of Texture2D)("flame")
    bFire = Me.Content.Load(Of Texture2D)("flame")
    xButton = Me.Content.Load(Of Texture2D)("x")

    We draw these textures in the Draw method – you saw that coming didn’t you? Each frame we will redraw the objects on the screen of our phone using the spriteBatch object. We will first check our Boolean flags (remember aShow and bShow) and if they are set to true they will be drawn. The X button will always be drawn of course.


    If aShow Then
        spriteBatch.Draw(aFire, aRec, Color.AliceBlue)
    End If
    If bShow Then
        spriteBatch.Draw(bFire, bRec, Color.AliceBlue)
    End If
    spriteBatch.Draw(xButton, xRec, Color.AliceBlue)

    Note that we are using the same color for the background of the screen and of the objects we are drawing on it (AliceBlue in this case) to make things look nice. For “interesting” try different colors.

    Now for the real work. What we want to happen is for “flames” to appear in random places on the screen. When we touch them with our finger that will “put them out.” This means that we have to:

    • · Exit the game if the player touches the X button
    • · Make a flame disappear (by setting the show flag to false)
    • · Determine if it is time to show one or more flames
    • · Set the location of one or both flames and display them by setting the show flag to true

    We check for touching the button or flames by checking touch points against the rectangles that define the locations of the objects. The status of the TouchPanel tells us where it was touched.

    Our code may look something like this:


    For Each t As TouchLocation In touches
        Dim touchRec As New Rectangle(CInt(t.Position.X), CInt(t.Position.Y), 1, 1)
        If touchRec.Intersects(xRec) Then
        End If
        If touchRec.Intersects(aRec) AndAlso aShow Then
            aShow = False
        End If
        If touchRec.Intersects(bRec) AndAlso bShow Then
            bShow = False
        End If

    We’ll count the cycles and if enough have passed (according to HowOften) we will select one or both of the flames to appear using a set of if statements. If it is “time” we will use the random number variable to select a location for the flame(s) to appear, set the show flag to true, reset our cycle counter and pick a new random number of cycles before checking again. Our code might look like the following:

    Dim shouldShow As Integer = r.[Next](1, 100)
    cycleCount += 1
    If cycleCount > howOften Then
        If shouldShow < 60 Then
            aShow = True
            aRec.X = r.[Next](100, 700)
            aRec.Y = r.[Next](10, 400)
        End If
        If shouldShow > 50 Then
            bShow = True
            bRec.X = r.[Next](100, 700)
            bRec.Y = r.[Next](10, 400)
        End If
        howOften = r.[Next](33, 100)
        cycleCount = 0
    End If

    If you don’t have a Windows Phone yet make sure the deployment is set for the emulator.


    If everything works you should see something like this:


    The emulator uses mouse clicks to emulate touches unless you have a touch screen on your computer.

    What next?

    Well some things are obvious:

    • · More flames
    • · Score keeping
    • · Losing or winning
    • · Code clean up – shouldn’t there be classes here?

    You get the idea. What can you do from this basic outline?


    Visit the App Hub at for more Windows Phone development resources.

    © 2010 Microsoft Corporation. All rights reserved. This document and its contents are provided AS IS without warranty of any kind, and should not be interpreted as an offer or commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented. The information in this document represents the current view of Microsoft on the content.


Page 1 of 9 (27 items) 12345»