The Blogging A-to-Z challenge enters its second week with a note about you, the human.
Last week I discussed several topics that you probably thought were about computers. They weren't. They were about how you interact with computers.
Computers don't need programming languages. This is a perfectly runnable program for the 6502 microprocessor:
0600: a9 01 8d 00 02 a9 05 8d 01 02 a9 08 8d 02 02
The human-readable version looks like this:
$0600 a9 01 LDA #$01
$0602 8d 00 02 STA $0200
$0605 a9 05 LDA #$05
$0607 8d 01 02 STA $0201
$060a a9 08 LDA #$08
$060c 8d 02 02 STA $0202
Imagine looking at that all day and trying to debug it. You'd go insane. I know, because back in the day, I wrote that kind of code for 6502 chips and, well, you have evidence about my sanity in these pages.
This is why we use high-level languages instead of low-level ones. We try to abstract away all the crap. Instead of writing for the machine to read, as you do with assembly language (and even there you have a thin abstraction layer), you write software for a human to read.
And the languages continuously improve. Here, below, is some of the first code I ever plagiarized wrote that lived in a production application. You might understand what it does from reading it:
julian!=INT(365.2422# * year + 30.44 * (month-1) + day + 1)
t1=month - 2 - 12 * (month<3)
t2=year + (month<3)
weekday!=INT(2.61*t1-.2) + day + t2 + INT(t2/4)
weekday! = (weekday! + INT(t3/4) - t3 - t3 + 77) MOD 7 + 1
t4=julian! - 7 * INT(julian!/7)
IF h<0 THEN julian!=julian!-1:_
That language is called QuickBASIC, which Microsoft published from 1985 until 1991, when Visual BASIC took over. It's a subroutine that converts a date into its Julian day number. I developed it because in QuickBASIC there was no way to do simple date calculations, but in astronomy, there was.
Here's the C# version:
public static double ToJulianDayNumber(this DateTimeOffset date)
return date.ToOADate() + 2415018.5;
Forget that this is a naïve implementation, as there are a ton of special cases before the 19th century; and also forget that it uses a magic number that depends on understanding a bit of .NET and Windows internals (like, for example, that JD 2415018.5 is 30 December 1899, which is the epoch date for OLE automation).
The point is, I can abstract away all the calculations and create an extension method which allows me to get any Julian day number just by calling that method on any date-time struct:
var julian = DateTimeOffset.UtcNow.ToJulianDayNumber();
As a human, I'd bet you find that a lot easier to read and understand than the
MDYTOJULIAN subroutine above.
But C# makes it even easier to calculate the difference between two dates, obviating the Julian day entirely, unless you're writing software specifically for astronomers:
var otherDay = new DateTimeOffset(2017, 01, 20, 17, 0, 0, TimeSpan.Zero)
var days = DateTimeOffset.Now.Subtract(otherDay).TotalDays;
Because really, you're trying to get the total days between two dates. The Julian day is a required abstraction when you don't have date arithmetic built in. But when you can just do
date.Subtract(otherDate) to get a
TimeSpan object, the code is a lot easier for humans to read.
Let the compiler worry about the machine. You worry about other humans.