Wednesday, February 27, 2013

Dates on a computer

Dates are one of those things in Computer Science that keep finding new and more entertaining ways to behave really badly. So here. Read this XKCD comic, and then everyone, please just follow the ISO standard. Hell, if everyone follows the ISO standard, everyone can keep doing that annoying thing where they store a date in an integer. That'll work okay until well after my lifetime is over. Note that other habits for storing time as a single integer don't sort as well ( the ISO standard, take out the dashes, sorts perfectly fine using the standard integer comparators ), or they have edge cases that'll behave oddly.

For example, if you stored dates as month-day-year, and you need to store January first, 2001, let's first convert that to its numerical equivalent in month-day-year: 01-01-2001. To get your integer, remove the dashes.

That leading zero gets lost. If you're using -three- ints to store the date ( a distressingly common thing I see ), -two- leading zeroes get lost in conversion to a single integer, and we wind up with 112001. Which I don't know what that is when your custom date format object gets passed to my code.

What I'm asking for, is if you're going to be sloppy about your date formats, store them in a single int, in the ISO format.

Though what I -really- want is for your date formats to actually be a robust first-class object in your system, but I understand that's a pain to code for.

If you decided to store dates as the number of seconds on your system, well, okay, that's fine, I can work with that. Please don't ignore things like the 2038 problem. ( Hint: If you're going to count seconds, use a bigger integer )

Wait, what's the 2038 problem?

Okay. Well, assuming a single 32 bit block of data is storing time information, and assuming you're working on an architecture that assumes the beginning of time is 1970-01-01 at 00:00:00 UTC, ( so, pretty much all Unix-based systems ), AND you're storing time as the number of seconds since this beginning of time, the last date that can be recorded correctly is 2038-01-19, at 03:14:07 UTC. At that point, the integer will overflow, and it'll be 1970 again for everyone.


Note to actual professionals reading this blog: I'm still a college student. These are problems I deal with. Somebody tell me better in the comments.

Trivia point: if we're counting the number of years since 'the beginning of time', last year was year 42. I hope everyone remembered their towels.

Tuesday, February 19, 2013

Late

Update will be late. I'll post something about my workflow later this week. Also, an announcement that's only exciting to me, but is really exciting for all that.

Tuesday, February 12, 2013

Technical Debt

This post is not about money.

Any serious programmer who has been programming for any reasonable period of time, whether as a hobbyist amateur or making big money at the big company, will eventually have to make this decision:

Accomplish your task doing something dirty -now- and fix it later, or do it the correct way ( whatever your idea of the correct way may be ), taking longer, possibly even taking up time that is unavailable. And in almost every situation, the temptation to do it dirty and do it now is overwhelming.

Doing it dirty and doing it now has the advantage of instant gratification. You can see the results of your work sooner, get immediate benefits, and spend time on something more interesting or less vexing. Of course, you’ll fix it proper later. Maybe during a maintenance cycle or during code review or in the next patch or when you revisit this program. Whenever it is, it is usually in the indeterminate and unplanned future but we as programmers are -certain- we’ll fix it.

Of course, we never fix it. We’ll forget how we programmed our quick and dirty fix in a week, forget the problem domain in a month, and just plain forget the whole program in a year. Either we will move on to another project, or the demands of this project will always stay high enough that we are never able to quite get back to fixing our quick and dirty code.

And in a high entropy environment, one quick and dirty fix becomes two becomes many. And we never get back to create those proper solutions we’ve always dreamed of. This is the technical debt. Taking out a loan in time now, and then never paying it back. The debt is incurred typically in code understanding or maintenance, and the quick and dirty fix can wind up costing us far more time than creating the proper solution in the first place.

It’s important to try to remember this. The technical debt for most projects will be incurred, sooner or later. It’s hard to keep in mind during crunch time or during finals or when you -just want to draw a box on the screen, dammit-, but that technical debt will tend to come back. Pay it now, and pay it forward. Don’t fall into the trap.

As a final note, though, moderation must be exercised here. While a quick and dirty fix now is almost never worth the end cost, a good solution now is often better than a perfect diamond solution, depending on what you are working on. Good judgement that comes with experience will help a lot here, but given the choice, I would recommend most programmers try for perfection rather than settle for quick and dirty.

Wednesday, February 6, 2013

Programming Paradigms

This is a placeholder for some terminology.

There are some ‘big’ programming paradigms that I’m familiar with. Procedural, functional, and object oriented are ones I have hands-on experience with. There’s also imperative versus declarative, and the idea of reflection, and macros, and... well. Programming languages tend to support one or more of these paradigms, and that, in turn, will affect the way in which a coder will code. Since production languages tend to be Turing complete, you can technically force any language into any paradigm. Having said that, programming languages are tools, and just like real tools, while you can force them into tasks they weren’t designed for, it’s probably better to just change tools.

Real fast, for those who aren’t programmers, Turing completeness describes a machine that can perform any calculation. You can imagine a machine that can read symbols that are printed on an infinite ribbon, and can interpret those symbols to carry out an arbitrary number of instructions, as well as modify those symbols. For practical purposes, if a programming language has an IF construct, and can read from, write to, and modify memory, it’s Turing complete.

IMPERATIVE programs are programs that can be described as a series of orders. Imperatives, if you will. PRINT a number, GOTO a line number, do this, do that. You can think of it as marching orders for the machine. Procedural and object oriented programming tends to fall in this category.

DECLARATIVE programs just describe what the program should do, but not a thing about how it should go about doing it. Functional and logical programming languages tend to enter this paradigm, as well as database languages such as SQL.


PROCEDURAL programs are the ones I am most familiar with. They have a list of commands to be followed, and procedures which can be called. C and BASIC are procedural programs, with the procedures that can be called being known as ‘functions’ in C, and ‘subroutines’ in BASIC. I think BASIC also has functions, but it’s been so long since I used it, I don’t really recall.

FUNCTIONAL programs are called that because they can be thought of as running a series of mathematically provable functions as programs. Haskell is an example here. They are noted for their lack of side effects, which is a way of saying that they don’t modify states like procedural/imperative languages do.

OBJECT ORIENTED programs have, well, objects. These objects tend to have a number of characteristics, such as encapsulation, and message passing. An object will tend to have a public interface, which is a way of passing commands to the object. This object will then have an implementation, which code outside the object doesn’t need to concern itself with. Objects often can also pass messages to each other, and act on these messages. C++ and Java are object oriented languages.

Hopefully this is clearer than the relevant Wiki pages.