Wednesday, December 25, 2013

Why the web is losing ground to app stores

Any platform has to balance the needs of consumers against the needs of creators, because it needs to attract both. It's possible to favor consumers too much at the expense of creators, by making content too easy to copy and too hard to monetize. The web might be losing ground to app stores for precisely this reason.

It's pointless to pine for the old web and complain about the greed of creators who choose to make apps instead of websites. Greed is a part of what we are. A more interesting question is how to make a system that will leverage that greed for the good of everyone. App stores may be part of the answer, but maybe something else will come along.

Tuesday, December 17, 2013

Science and marketing

Science is similar to inter-species competition, while marketing is similar to intra-species competition. In science we try to get better at manipulating the universe. In marketing we try to get better at manipulating each other, and waste resources that could've been used to get a bigger share of the universe.

Thursday, November 21, 2013

On code that is fun to write

If your code was fun to write, maybe you were borrowing fun from the future people who will need to read and modify it.

Tuesday, November 19, 2013

"Lexical typing" and "static scope"

In "lexical scope", the correspondence between names in code and variables in memory depends on the lexical structure of the code (which parts enclose which). In "dynamic scope", it depends on the dynamic structure of the running program (which parts are calling which)

In "static typing", the correspondence between variable names and variable types depends on the lexical structure of the code. In "dynamic typing", it depends on the dynamic structure of the program.

"Static" and "lexical" seem to be synonyms. You might as well rename static typing to "lexical typing", or lexical scope to "static scope".

Tuesday, September 24, 2013

The land of good programming

When programmers die, they go to the land of good programming.

Everyone imagines that land in their own way. For some it's a land of Haskell, for others a land of C++. Everyone goes to a different land.

Unfortunately, the more time you spend in your land, the more you realize that it was not intended as an unconditional reward. As your ideas about good programming materialize, you learn to see their drawbacks and blind spots, the things that others pointed out before but you wouldn't listen. In this way, depending on your virtue as a programmer, your land will become either heaven or hell for you.

Sunday, August 18, 2013

Calling a function with no arguments

Q: I don't understand what it means to call a function with no arguments.

A: Come again?

Q: You see, in mathematics a function is a subset of the Cartesian product of domain and range. If the domain is empty, there's no place to stash the return value. But programmers seem to use such functions just fine. What's going on?

A: Well, the thing that programmers call a "function with no arguments" is never really a function with an empty domain.

Q: What is it, then?

A: There can be different interpretations...

Q: Can you give an example? What happens when I call a C function with no arguments:

f();

A: This part of C doesn't reflect the underlying math very well. Let's look at Haskell instead. Functions in Haskell are curried, here's the type of a function with two arguments:

a -> b -> c

And with one argument:

a -> b

If we follow that pattern, the type of a "function with no arguments" will look like this:

a

As you can see, that's just a value, not a function at all.

Q: Neat! I remember reading something about constants as "nullary functions". But it's still a little unsatisfying. Can you explain what's going on in a language where functions aren't curried?

A: Haskell also has non-curried functions. They look like this:

f (a,b)

If we follow that pattern, a non-curried "function with no arguments" will look like this:

f ()

Note that () is the empty tuple, aka "unit". The function's domain is a one-element set, not the empty set.

Q: Okay, that's a nice interpretation, and it's closer to the original question I had in mind. But when I call a C function with no arguments, it doesn't seem to pass the empty tuple, it passes nothing at all. Why does that work?

A: If you want to specify an element of a one-element set, zero bits of information is enough.

Q: That makes it clear. Thanks!

Monday, July 22, 2013

Throwing an exception to the dog

Q: Where's my terminal?

A: It's gone. Throw a dog ate my terminal exception.

Q: Throw a dog?

A: No, throw the exception to the dog. Then it will catch it and finally bring it back to you.

Q: Dogs don't usually do that.

A: That's the whole point. Dogs don't usually do that, but there are exceptions.

Wednesday, July 17, 2013

Printing an int in C++

Q: How do you print an integer to standard output in C++?

A: Like this!

printf("%d", x);

Q: Please use C++ facilities.

A: Sure.

std::cout << x;

Q: But what if someone switched the stream to hex mode before calling your code?

std::cout << std::hex;

Then your code will print "a" instead of "10", which is not what you want.

A: Okay, I'll switch the stream to decimal mode, just to be sure:

std::cout << std::dec << x;

Q: Now your code has an unintended side effect, it might change the state of the stream for the next caller.

A: Hmm. So I need to restore the stream to its previous state, whatever it was? Hang on, I'll check the internet...

(a minute later)

Wow. There's a Boost library to do that.

Q: Seriously?

A: You know what, I'd like to go back to my first answer with printf.