Functional programming, immutability and the World.

In C++  if you write a cooking_meat() function it returns NOT a new piece of meat, but one with a changed state.

In Clojure we have:

• immutability - so we get here a NEW piece of meat

In real life it'd be not a wholly new piece of meat!

• world -> constantly changing state, we cannot understand all of the Change
• thus -> functional programming - our unability to cope with Change, to understand the world we are living in?

The symbol-pointer equivalence.

Recently, I realized an interesting little fact when comparing LISP-type and C-type languages. It may seem that, by their design and philosophy, they cannot be more distant from each other, but well, it all boils down to memory locations and addresses.

Let's take the a LISP symbol a, and a C++ object obj. If you take a for itself, it resolves to its value, if you don't want that, you have to quote it. On the other side, of you take a pointer to the C++ obj, you have to dereference it directly if you want the underlying value:

  'a <=> &obj
   a <=> obj

and

   a <=> *obj_ptr
  'a <=> obj_ptr

I think it's cool. Think of symbols as pointers.

Birthday paradox, Lotto and learning

Warning: this post is about how we learn but in reality we don't.

You may know the "birthday paradox" - it's a cute little story in probability theory, and as it happens it might be useful to know in a programming interview. So many of us learn about it and might even be able to derive the probability bound and to reason about it. But do we really learn? Or do we just memorize some story which will be called out in the "technical interview"?

Let us apply it to the case of lottery gambling. ...

The hard question here is - which numbers should I choose to win the jackpot. Well, the answer is, we don't know. The not so hard question is - which numbers NOT to choose. Here we can definitely offer some responses. We shouldn't choose the numbers most people would choose. Can you sense the application here? Well, most people will use their birthday date in some form (as it's the number they are most accustomed to). And the birthday paradox teaches us that... we ourselves shouldn't use it!

Would you see that? Possibly not. No party, no room, no people talking to each other as in the classic setting of the story. That's sad. That's not what I like about maths (and programming). But isn't it like that in the real life? If you'll be interviewed you have to reproduce the known answer first. If you're good at it, some deeper questions will follow, most of them with a known answer. And we learn that stuff to be used in an interview... But is that learning?


PS: admittedly, this isn't any direct application of the paradox, but rather a "reverse" one, nevertheless I see it as cool math giving hints in seemingly unrelated problem. And when we learn about it, we don't play enough with ideas, we just want to "pack it in" and have it ready for that interview.