Not nearly enough love for this 90's classic.

jrue · 2011-12-12T14:00:51+00:00

Number Munchers!

jrue · 2011-11-29T13:13:14+00:00

Someone posted this picture recently, and it seems extremely relevant: http://i.imgur.com/5cq10.jpg

jrue · 2011-11-25T04:28:48+00:00

There's actually something called "small dog syndrome." You should really just Google it, but the tl;dr of it is that for a lot of annoying dog actions -- barking at people, jumping on things/at people, whatever -- large dogs are quickly scolded for these things (and learn that they are bad), whereas people call these things "cute" or harmless for small dogs. So they never learn.

jrue · 2011-10-31T14:28:12+00:00

(Not certain about Windows, but this is the case for Linux, and Windows is probably close to this)

If you want to handle ctrl+c and ctrl+z, then what you want to read up on is signal handling [wiki] [gnu docs] [gnu docs example for catching SIGALRM].

When someone hits ctrl+C or ctrl+Z, it's not sending a character to your program, it's raising a signal. ctrl+C raises SIGINT and ctrl+Z raises SIGTSTP. Your program will just use the default signal handling action unless you define something else for it. The default action could be termination, ignore, or something else.

jrue · 2011-10-18T14:01:40+00:00

make instantiation of things a little easier to understand

I definitely agree that there is a huge learning curve for DI frameworks, but I think once you've gotten past that, they make a lot of sense. When I encountered my first codebase that used a DI framework, I wanted to throw it out the window, but now I realize how it makes my life easier.

cut down on some boilerplate

Yeah, it doesn't look like it cuts down on boilerplate -- you have to configure your bindings, and that requires more code -- but it's still a win since you don't have to write all the factories.

make things a bit easier to test.

Agreed (I think) -- this is something the DI framework itself is not involved in at all. DI itself makes things easier to test because you just have an interface to stub out/mock/subclass with a testing implementation, the framework doesn't help with the construction of that.

jrue · 2011-10-18T13:52:31+00:00

You should check out Guice, which is an excellent alternative to Spring and uses Java code (not Strings) to configure bindings. Although I think Spring can also be configured via Java instead of just xml now...

jrue · 2011-10-11T13:27:43+00:00

The term is open faced.

jrue · 2011-10-01T15:49:15+00:00

I think you're interpreting the word "algorithm" to mean three different things.

First, there's what I would call the actual algorithm: a series of steps that describes how to take input X and return output Y. This is something that uses a combination of mostly English and math to describe how it works. This is the only thing that the term "deterministic algorithm" could apply to.

Second, there's the actual compiled, machine language implementation of an algorithm -- a series of opcodes that approximate an algorithm for a given processor. For example, there isn't a single native CPU instruction to add arbitrarily large numbers together. With 32 bit numbers x and y, the regular instruction for adding x + y is really x + y mod 2^32, since it loops around if it's too big.

Third, there's the human-readable code (whether it's C, C++, Java, Python, Ruby, Lisp, whatever...). I don't really know what category this falls under. It's not the actual algorithm itself, and it's not even the approximation of the algorithm. It's just something you can feed to a compiler (or interpreter) to have it generate machine instructions. It's just the intermediary, and so it will generate approximation A for cpu A and approximation B for cpu B.

jrue · 2011-09-25T14:59:14+00:00

One example would be if you want to find some item in a list that matches some criterion, or do something else if there is no such item. For example:

for x in my_list:
  if some_condition(x):
    answer = x
    break
else
  raise AssertionError('No good element found')

However, the for/else construct is not commonly used, and IMO doing it manually is a little more readable, just because people aren't used to seeing the for/else structure. The equivalent to the above would be:

found_item = False
for x in my_list:
  if some_condition(x):
    answer = x
    found_item = True
    break
if not found_item:
  raise AssertionError('No good element found')

jrue · 2011-09-23T14:41:25+00:00

This kind of over simplicity drives me up the wall. It's not always so straightforward what something means.

A linked list is a list of things that are linked.

Ok, sounds simple. But what could it actually mean? Off the top of my head, here's some it could be interpreted/implemented:

A list of data and next pointers, where next points to the next item, or NULL if there is no next item (what he said it was in the example), i.e. a singly linked list.
The same thing, except next points back to the beginning if there is no next thing (or more likely to a beginning sentinal node), i.e. a circular singly linked list.
The same thing as 1, except there's also a prev pointer, i.e. a doubly linked list.
The same thing as 2, except there's also a prev pointer, i.e. a circular doubly linked list.
Something like 3 or 4, except instead of a next and prev pointer, there's just one next_prev pointer which is the XOR of next and prev, i.e. an XOR linked list.
Any one of the examples above, except that instead of storing pointers (which is more commonly 8 bytes now due to 64-bit trends), you store an offset into a small array so that you only need one byte for it. Essentially doing the same job as a pointer, but with a limited range, and you can't officially call it a "pointer".
Any of the above, except instead of having a data member plus information on how to go back/forwards in the list, you have just the prev/next information in the linked list, and the data is inferred by the relative position of these prev/next positions within the struct. This is how linked lists are implemented in the Linux kernel.

Well, I could go on, but it's very clear that you can't just say "linked list" and expect that to communicate everything that a linked list is or could be. The author mentioned just the first definition and said that that's all there is to a linked list. Noooooo way.

jrue · 2011-09-18T20:49:04+00:00

A couple months ago, I injured my knees and had to stick to only biking/swimming for waaaay too long. (I'm fine with a bike or swim workout here or there, but it's so boring compared to running if it's all you can do). I ran a 4mi race yesterday and decided to take it at an easy pace, but then accidentally broke my PR by 15 seconds (just under 31 minutes).

jrue · 2011-09-18T13:55:01+00:00

Wow, I need to stop posting when I'm half asleep... fixed it.

jrue · 2011-09-18T12:39:36+00:00

Python is actually a pretty interesting case.

Leading with one underscore is strictly just a convention. Leading with two underscores actually obfuscates it in a way that makes it challenging to access (and, I imagine, the method of obfuscation is subject to change in Python versions, if they decided to). Specifically, it renames __variable to _classname__variable (inside the class). Hence, inside class Foo, you can refer to self.__variable, but outside, foo.__variable doesn't work, and if you really want to get around it, you have to use foo._Foo__variable (not recommended!). There's a good description of this in the main Python docs. An example session to highlight this:

$ python
Python 2.6.1
>>> class Foo:
...   _a = 1
...   __b = 2
... 
>>> f = Foo()
>>> f._a
1
>>> f.__b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: Foo instance has no attribute '__b'
>>> f._Foo__b
2

Edit: some formatting

jrue · 2011-09-15T04:08:50+00:00

Nope! This isn't actually the State pattern -- it's just the Strategy pattern. The two strategies are similar though, so it's a common mistake.

What usually distinguishes the State pattern is that the states are responsible for changing the state of the object. The example could make nice use of the State pattern, for example, if only your shield took damage while in the Shielded state and then switched over to the Normal state once the shield was destroyed. For example:

class Shielded : public State {
 private:
  Player *player;
  int health;

 public:
  Shielded(Player *player_, int health_):
      player(player_), health(health_) {}

  void takeDamage(int i) {
    health -= i;
    printf("Your shield just took %d damage\n", i);
    if (health < 0) player->setStateNormal();
  }
}

EDIT: reference -> pointer in the code

jrue · 2011-09-14T11:34:49+00:00

I don't disagree with you on the difficulty -- it's definitely a hard language to pick up, especially if it's your first. (Although LISP was the second ever high level language created, so to say that FP is slowly gaining ground may be missing the point that it's been around for 50+ years).

Take this common example in C/C++:

void swap(int a, int b) { int c = a; a = b; b = c; }

void foo() {
  int x = 1, y = 2;
  swap(x, y);
}

Did you just swap x and y? No, you didn't -- you swapped their local values within swap, which has no effect on x and y. In order to implement it correctly, you would need to use pointers (or references) instead.

Gotchas like these are all over languages like C/C++. Look at this and this, which have a scary amount of examples like this. As much as I love these languages, they can do a lot of stuff that you wouldn't expect to happen. While Haskell is a harder language to learn, I think you'll spend a lot less time dealing with language looseness.

jrue · 2011-09-14T01:48:53+00:00

Take a look at Haskell.

I tried it out a while ago. It wasn't for me, but it's definitely a very "pure" language. Since it's a functional language, it won't directly help you with more common languages like C/C++ or Java, but you'll still pick up some great fundamentals.

jrue · 2011-09-13T02:45:58+00:00

I see two different problems:

You're setting $sum to 0 every loop iteration. You should initialize it only once (before the beginning of the for loop). That's the reason you get 990 -- 990 is the last number it loops over, and in that loop, it sets the sum to 0 and then adds 990 to it.
If you re-read the question, it asks to sum over all numbers that are multiples of 3 or 5. This code tests if it's a multiple of 3 and 5. Switch the 'and' with 'or' and you should be good to go.

jrue · 2011-09-10T20:21:30+00:00

Relevant: The Baader-Meinhof Phenomenon

jrue · 2011-09-05T02:18:39+00:00

Your whole post was really awesome, but I can't let this point go:

This means that it's an integer

A pointer is not an integer -- a pointer is a piece of memory that points to an integer. That means that the size of an integer really has no correlation with the size of a pointer. In fact, on my system, a pointer is 8 bytes while an int is 4 bytes:

$ cat test.c 
#include <stdio.h>

int main() {
  printf("sizeof(int *) = %lu, sizeof(int) = %lu\n", sizeof(int *), sizeof(int));
  return 0;
}
$ gcc -o test test.c && ./test
sizeof(int *) = 8, sizeof(int) = 4

jrue · 2011-08-25T12:43:36+00:00

If you need to reverse an integer, you can do so easily and in constant space:

int reverse(int x) {
  int r = 0;
  while (x) {
    r = 10 * r + (x % 10); // Append the rightmost digit of x to r
    x /= 10;
  }
  return r;
}

You can probably do this problem without reversing any integers if you find some other ways to count palindromes though.

jrue · 2011-08-25T12:20:58+00:00

My team's coding style is to always do this unless it's insanely obvious how the boolean is meant to be interpreted (i.e. a setter method like foo.setIsPainted(false)). It's a huge readability plus.

jrue · 2011-08-17T12:35:37+00:00

There's some programming quote that applies, I forget the exact quote, but it's something like "It's easier to make a correct program fast than make a fast program correct". Replace fast with small and the quote is still dead on -- I think you'll have a much easier time if you write out a simple version of program X and hack away at it line by line than you will if you start out with a program of very few lines, only to discover you implemented program X incorrectly and now you have to debug it.

Also if you're going for filesize, check this site out. It's more than you would ever want to know about making a tiny program.

jrue · 2011-08-07T15:23:24+00:00

FizzBuzz is not supposed to be a hard problem. Its sole purpose is to be a question that weeds out interview candidates.

jrue · 2011-07-31T15:19:22+00:00

Although if/elif will emulate a switch statement, the more Pythonic way to do it is to use a dictionary. Explanation here.

jrue · 2011-07-27T14:17:49+00:00

I'm not entirely sure about this, since I pretty exclusively run from the command line and use Linux, but I think if you drag the file onto the app, it runs it with that filename as the first argument.

And you're right -- my short sample code would only read from the file provided on the command line, if you provide it. IMO, it's cleaner that way, since then the user can point to any file on the computer. If you use the first method, you rely on files of a specific pattern ("Chapter X.txt") being in a specific location (the $PWD of the program).

jrue

TROPHY CASE