It used to be that rockets and research were two words that went together. Now, rockets aren’t quite as cool.
For example the ESTES curriculum material has out of date software, naturally the algorithms still work, but the software uses old software and expects older video cards. As Cay Horstmann pointed out at the CCSTC held at the National University on April 3 and April 4, 2009, old software and data is often hard or impossible to read. Cay also made some other good points about the lack of students actually reading code and mostly writing code. Cay is definitely a good guy and apparently a prolific writer, so make sure you take a look at his excellent blog on Java and his journeys. I can only aspire to do as good a job with F# as Cay has done with his work on Java, he certainly has made an impression on many students.
Ok, back to Research, F#, Rocketry and everything, the ESTES curriculum material with respect to Windows is badly out of date, of course the physics remains the same. Again, we hit the problem with computer aided training that someone must own the material and maintain it in a manner that keeps it functional. There are parts of the material that won’t run in Win 95 compatibility mode, apparently because the video drivers on my Vista machine are not the ones expected. Hardware has changed, and some of the code used the video drivers directly. I am going to test the Physics of Model Rocketry in a VPC later in the week, I don’t have one built that supports Win95, but that shouldn’t take long to build.
As to the other insight that Cay Horstmann pointed out in his keynote: Students aren’t motivated to read code. Let’s combine the two problems by reviewing some excellent code written by Chris Smith.
Well, to answer this, let’s read some code, Chris Smith put together an interesting example that applies to my blog “focus” that is: Using F# to solve real life problems.
The code is lifted from http://blogs.msdn.com/chrsmith/archive/2008/09/04/simple-f-game-using-wpf.aspx
Chris Smith uses a simple ballistic problem to illustrate the use of Units of Measurement in F#, which is cool and in previous blogs I discussed the problem with not using the correct units of measurements caused the crash of the Martian Climate Orbiter in 1999. Our goal is to examine the code by Chris Smith’s code to solve a ballistic problem, rather than focusing on the units of measurements:
Using F# Chris sets up the UnitsOfMeasurement.fs class, and he discusses this in the link above. What else is going on?
The keyword: module is a simple way to encapsulate code while doing rapid prototyping without the need to spend the
time to design a strict object-oriented type hierarchy. So elsewhere in the F# part of the project you can use GameEnvironment with intellisense that allows you to use the default setting for time steps, wind force, and so forth.
The keyword: “open” is an import declaration that is used in module definition and signatures as well as Namespace fragments and their signatures. Open is used to to access existing objects that for example are contained in one of the following:
- Project classes (in the case of BurnedLandGame.Math)
- Provided by a dll you have imported by adding a reference
- Provided by a dll that was added to the project by the default template
The keyword: “let” bindings in modules introduces named variables and functions
In this module the units are shown by the nomenclature <s> for example as the unit <s>, if it is used in a calculation that doesn’t work out dimensionally, then a context error line (the red squiggly underline will show up in the IDE.
Here is a little quiz:
What are some examples of files that you use with the “open” statement?
Is the “let” keyword only used for values?
Is the “let” keyword only used for functions?
If I write the line of code: let TimeBump = 1.0<ft>*3.0<m>, will I get a context error indication?
Well that is it for today, keep an eye for more, this is going to lead into ballistics calculations eventually.