Showing posts with label programming trickery. Show all posts
Showing posts with label programming trickery. Show all posts

Thursday, February 7, 2008

Saturday, January 19, 2008

(Haskell) Monads for Imperative Peeps

Warning, since I am still learning Monads, it's quite possible the following is partially or even entirely wrong.

Why Monads


Functional programming languages have the constraint that their functions cannot have any side-effects. A function cannot do anything except produce a return value which is strictly dependent on its input values.

This is done for many good reasons. One such reason is to allow allowing some pretty mean performance optimizations: specifically allowing each individual "pure" function to run on their own processor core, since by definition each function is dependent on its input only, and can run efficiently this way.

However this constraint effectively eliminates entire sub-sets of useful and essential operations. Most notably IO operations such as printing or reading from the console.

A monad is a abstract idea that allows functional languages to stay theoretically coherent by encapsulating side-effect producing operations within themselves. Monadic functions can then be separated from the remaining pure functions when optimizing.

Monads are also extremely useful for encapsulating entire classes of behavior by type. For example a monad for functions that print or read from an OS provided data source is called IO. For functions that print or read strings from the console, the embedded type for IO would be String, and thus their type would be String -> IO String.

What are Monads


In programming languages, monads are meta-types that embed other types.

A monad has 3 parts:
1. A type construction, which defines how to embed a type in the monad
2. A unit function, which explains how to place a value of a type into a value of the monad, "as is"
3. A binding operation, which explains how pull out a value of a type from the monad, apply a pure function to it, and return the result to the monad

As an example we will construct a monad called Maybe that defines a type who's values are either invalid, or from a valid range:

1. data Maybe t = Just t | Nothing

Which says that the monadic type Maybe with parameter type t is a type who's values are of type "Just t" or "Nothing". Nothing is the type of invalid values.

2. return x = Just x

Which defines a function that wraps any value in the identity type Just, and thus embeds it the monad Maybe by our definition in 1.

3. (Just x) >>= f = f x
Nothing >>= f = Nothing

Which says that any function f can be applied to the type Just x as a normal, every-day function call; but any value of the Nothing type always yields Nothing. This means that whenever an invalid value is encountered, all functions from that point on are also invalid.

Saturday, June 16, 2007

On the severely misguided nature of programming tests

Part 2: Intermediate Questions

Question 6:

Consider the following function:

void foo(const char* name)

{

char* Name1 = name; // Statement 1

const char* Name2 = name; // Statement 2

char* const Name3 = name; // Statement 3

char const* Name4 = name; // Statement 4

}

Which of the following is true?

  1. Statement 1 fails to compile.
  2. Statement 1 and 3 fails to compile.
  3. Statement 3 and 4 fails to compile.
  4. Statement 2 fails to compile.
  5. Statement 3 and 4 fails to compile.
  6. If you answered any of the above you have no place being around computer code. A person who programs as a profession needs to first ask them self if they need: a variable pointer to something that is itself constant, a constant pointer to something that is itself variable, or a constant pointer to something that is itself constant, then look up the correct syntax in the book. And if you're still worried, finally test it on the compiler -- THEN NOTE IF IT DOESN'T COMPILE! Anything else is pure nerd dick-waving.
And if I ever catch anyone using such unnecessarily confusing, dusty corners of the C++ standard in my code, or my job interviews, I will consider it an intentional attempt to trick the reader, and toss you out the door for being deceptive and a danger to the code-base. Seriously, what sort of programming job requires you to outwit an adversarial co-worker?!

Because, if programming tests are an accurate reflection of the work you will do as a programmer, then it must follow that the programming test itself is an accurate reflection of the kind of people you will be working with, by virtue of being the kind of people who would pass such a test.

Bonus points for anyone that can translate the following from its current wording to some form that would make me care.

Question 15:

What best describes virtual inheritance?

  1. A derived class which does not implement abstract methods.
  2. A derived class which adds abstract methods to a concrete base class.
  3. A multiply inherited class with multiple copies of its base class.
  4. A multiply inherited class with one copy of its base class.
  5. All of the above
ps. (d)