You may have heard people saying that in some language or another that functions were first class objects, or have come across the term first class function. What does it mean? And why is it so good?

What Programmers Know

Contents

1. The Computer - What's The Big Idea?*
2. The Memory Principle - Computer Memory and Pigeonholes*
3. Principles of Execution - The CPU
4. Assemblers and assembly language*
5. The Essence Of Programming
6. Variables - Scope, Lifetime And More*
7. Binary Arithmetic
8. Hexadecimal*
9. Binary - Negative Numbers*
10. Floating Point Numbers*
11. Inside the Computer - Addressing
12. The Mod Function
13. Recursion
14. The Lost Art Of The Storage Mapping Function *
15. Hashing - The Greatest Idea In Programming
16. Advanced Hashing
17. XOR - The Magic Swap*
18. Programmer's Introduction to XML
19. From Data To Objects*
20. What Exactly Is A First Class Function - And Why You Should Care*
21. Stacks And Trees*
22. The LIFO Stack - A Gentle Guide*
23. Data Structures - Trees
24. Inside Random Numbers
25. The Monte Carlo Method
26. Cache Memory And The Caching Principle
27. Data Compression The Dictionary Way
28. Dates Are Difficult*
29. Sequential Storage*
30. Magic of Merging*
31. Power of Operators
32. The Heart Of A Compiler*
33. The Fundamentals of Pointers
34. Functional And Dysfunctional Programming*

* Recently revised

Object-oriented programming is the standard paradigm, no matter what programmers of other persuasions may say. It is the one we use - the others we simply try out as an alternative. However, as well as exploring other ways of doing the job, it is important that at least now and again we look at how we approach objects. 

If you are a committed functional programmer you think about functions in a different way and the issue discussed here isn't as important. In this article we focus on object and their relationship to functions.

The big problem is that object-oriented programming was introduced with procedural modular programming as the dominant approach and this has colored the facilities we use to build objects. So too has the need to make our languages efficient. In particular, this has resulted in moving away from the simple principle "everything is an object".

When the object-oriented idea entered programming - about the time Simula was introduced - the key ideas used to construct a program were variables and functions (or procedures or subroutines they all mean the same sort of thing). What you did was you wrote functions that called other functions that called other functions and so on until you got down to a small enough task for which you could actually write some lines of code that got things done. Programs were structured using decomposition into modules comprised of functions. 

When the idea of organizing things into objects came along it was natural to keep the variables and the functions. So objects had properties and the properties could be variables - i.e. data properties - or they could be functions - i.e. code properties or methods. The idea that an object is comprised of properties and methods is a very old one and something that many programmers don't even think much about. If they do then it is more likely that they would reject the idea of data properties than code properties. For example, Java programmers don't think you should use data properties or fields. Instead every property should be a function and data properties are simply represented by getter and setter methods - or accessor methods. 

The problem with this approach to objects is that it complicates things by having three basic entities in its programming model - objects, variables and functions. 

A much simpler approach is to try to stick as closely as possible to the "everything is an object" idea. 

This is harder than it looks for a programmer brought up on a diet of primitive data types and functions.

For example, what does:

var a=1;

mean? Most programmers would say something like:

"store the value 1 in the variable a"

However with just a little re-orientation you can just as easily tell the story as:

set a to reference the object 1

Once you start telling this story you have to stick to it and sometimes this can be hard. For example, what does:

var b=a+1;

mean?

Again most programmers would say:

"take the contents of a, add one to it and store the result back in b".

A different story that fits in with the "everything is an object idea is:

"the binary operator + takes references to two number objects and returns a reference to a number object as its result.  In this case it acts on the object 1 and another number object referenced by a the two number objects are used to create a new number object that is the result of a+1. The variable b is set to reference the new number object."

Okay, you get the idea. 

Notice that this is just a different way of telling the same story but in many languages numbers are objects and can have properties. For example in JavaScript you can write:

1.toString();

where toString() is a method of the 1 object. In this case the "everything is an object" way of explaining things is more appropriate.