2017-02-26 - Computer Engineering is Weird

Computer engineering is weird compared to other engineering disciplines. Engineers mainly work on the design part of a project. They come up with specifications that get approved by the client and then sealed by the engineer to indicate that they are ready to be used. Then the plans are given to other people who construct the project under the supervision of the engineer. In computer engineering there is rarely a separate build time or a complete specification. This is largely because programming is both harder and easier than other disciplines.

Building a program is a fair bit easier than building other things. Maybe not in terms of complexity but at least in terms of resources and personnel. You need carpenters, electricians, plumbers, painters and many other trades people  along with wood, wiring, piping, and heavy equipment to build a house. In contrast you just need programmers and computers to build a program. Programming teams also tend to be a lot smaller compared to construction crews.

On the other hand designing a program can be quite complicated. There tends to be a large number of distinct parts of a program which can interact with each other in a variety of ways. These parts can also be created and destroyed many times throughout the life-cycle of the application. Modeling these details in a simple way can be almost impossible. There's also the problem that the design and implementation of a program can be very similar. A specification is a set of instructions that describes how something should be built but a program is also a set of instructions. So it becomes difficult to write a specification that is detailed enough to be useful but not too detailed that it's basically the program written in another language.

Because of the ease of building a program and the comparable difficulty of designing teams will often skip the formal specification in favour of just building the program and the program becomes its own specification. Since the main focus is on building the project there's no need for a separate design group or a formal approval processes. Specifications are going to be created and used by the same people and change as the program is developed and details get fleshed out.

Now likely computer engineering would benefit from having more formal specification and approval processes but it requires tools specificity designed to make it practical to do so.

2017-02-04 - Parts of Speech: Nouns

We are going to start our investigation of the parts of speech with nouns. Nouns are said to name things. They are used to refer to entities, things, ideas, people, or places. Nouns can have multiple forms on inflections depending on how they are being used. These inflections are important to us because they can change the spelling of the word and can impact the spelling and word choice of the words used in association with the noun.

Proper nouns refer to specific entities while common nouns refer to general things. Proper nouns are capitalized while common nouns are not. For Example "General Petre Dumitrescu" is capitalized because it refers to a specific person while "an admiral" isn't because it refers to an non-specific person. Although these technically aren't inflections I am including them because they do change the word.

One of the main ways nouns are inflected is to show number. You can have singular nouns such as "An Apple" and plural nouns such as "Apples". In English plurals are commonly formed from singular nouns by adding s or es but some words have irregular plurals such as "Children". Uncountable nouns refer to things which can't be referred to in the singular such as "Apple Juice". You can't take a single bit of apple juice out of a glass. This often depends on how the word is being used for example you can ask for "an apple juice" or "five apple juices" in which case you mean a glass or glasses of apple juice.

Another way nouns are inflected is to show possession. For example "the cat's" or "the building's". Possession is usually expressed using an 's and sometimes just an ' if the noun ends in s. Possession doesn't necessarily express ownership.

Although not common in English some languages also inflect nouns for gender. For example "chat" is French for a male cat while "chatte" is French for a female cat. In these languages most nouns have a gender but not all of them can be inflected to express a different gender. For example "livre" is French for book and is a masculine noun but there is no feminine form of book.

Next time we will look at a subclass of nouns called pronouns.

2017-01-07 - In IL: Grade Analyser (switch)

Last time we looked at the IL switch instruction. Today we are going to look at the switch statement in C# and see how it uses the IL switch instruction.

We are going to use a program that tests a student's grade and prints out a message.

Now if we compile the above program we get.

Looking at the IL we can clearly see the code writing text to the console, setting the needToImprove variable, and then doing some branching for each of the cases. This is all stuff we've seen before but what's going on before that?

The program starts by loading the value 66 into the grade variable. 66 is the Unicode value for the capital B letter. We then set the needToImprove variable to 0 which represents false. Then we push the grade variable onto the stack and subtract 65 from it. Why does it do that?

65 is the Unicode value for A. Since Unicode letters are in alphabetical order subtracting 65 from the grade variable converts the character value into an offset from A. So A becomes 0, B becomes 1, C becomes 2 and so on. As you will recall from last time switch instructions are 0 based so having the first option be 0 and subsequent options incrementing from there simplifies the switch instruction. Otherwise we would need to specify branching targets for 0 to 64 that all point to the default case.

So now let's look at the switch instruction. The following table shows the switch instruction branch index, the branch target, and the corresponding case statement.

If you look at the instructions at each of the branch targets you can see they line up with the case statements perfectly.

There's only one thing left, the default case. Recall that if the value on the stack doesn't correspond to a target of the switch instruction then nothing happens and executions continues at the next instruction. Thus if the grade value isn't A, B, C, or D, execution will move on to the unconditional branch to IL_0058. This is our default case.

Next time we will try and bust the switch statement.

2016-12-17 - Programs aren't Permanent

After a certain age people begin to understand that objects still exist when you put them away. If you put a hammer on a shelf today it will likely still be there in a week and still be the same hammer. Programs on the other hand don't keep when you stop using them, at least not in the same way.

This is because programs don't contain components the way we would normally think of them. A hammer is made up of pieces of metal and plastic. The hammer is a hammer because of the specific shape of those pieces and how they are put together. A program isn't made up of stuff, it is made up of instructions.

When a program is launched it starts executing the instructions stored within it. These instructions generally start by building up data structures in memory that store a program's state. When a program is closed those data structures are destroyed. The information stored within them may be persisted into another form but the exact data structures the program was using to run no longer exist.

Imagine having to rebuild the hammer every time you needed to use it. The hammer would change each time based on the current circumstances. Maybe there wasn't a lot of free plastic one time so you ended up with a very short hammer, or there was an issue getting the metal so you ended up with just a handle.

Because a program is just instructions it is very dependant on the results of those instructions. If the results can change from one run to another then the program's behaviour can change. Some times it launches fine and other time it crashes immediately. It's all up to the circumstances in which the program is being launched.

This is why restarting a program can make it run better.

12 13 14 15 16