Language Spectrum

(Note: Opinion piece by Josh - An attempt at being objective)

I'd like to try this - Lets draw an analogy between the political left/right spectrum, and the spectrum of programming languages that are available to us. This might sound a bit weird, but I think it might be an interesting way to classify modern programming languages, and better understand the underlying design decisions.

Overview

The big question: Should we give users more freedom, but greater risk, or should we reduce risk by force users into doing what we think is right for them?

The cost of taking a 'Liberal' approach is that novice programmers/designers are armed with tools to shoot themselves in the foot. A typical example here is multiple inheritance, a terribly misunderstood concept that more frequently does damage then good.

The cost of taking the alternative 'Conservative' approach is that we reduce the power of the programmer to solve particular problems in an effective way. An example here is operator overloading, a tool that can be valuable when using objects than can be manipulated mathematically.

Issues in the Spectrum

When looking at these issues, it's a matter of weighing up the potential danger/damage rating of a feature, versus the utility of it. Like with the political spectrum, the majority of us are probably pretty centrist and will take a little from either column.

Operator Overloading

Most languages allow you to write expressions using operators such as + (plus), / (divide), % (modulus), or [] (index). These operators work on some types by default, for example integers can be added, arrays can be indexed, and pointers can be dereferenced. Operator overloading allows you to specify a custom behavior, for when an operator is used with your class. See the below example.

 //Operator Overloading example in C++
 //CrazyInt overload the != operator.
 class CrazyInt {
   private:
     int value;
   public:
     CrazyInt(int value) : value(value) {}
     bool operator!=(const CrazyInt &other) const {
       return this->value == other.value;
     }
 }

Advantages, Disadvantages & Language Implementations

Operator overloading can be very useful when writing classes that can be manipulated mathematically. A common example is a Vector class, which corresponds to n values (for an n-dimensional vector), and can be added, subtracted, dotted, normalised etc. Forcing users to use method calls in this case can cause clumsy code, which does not read like prose, and causes the user to convert expressions from prefix to infix order in their head.

The ugly side of operator overloading is that you can essentially change the behaviour of a mechanism the client of your class is used to, without them knowing. For example, in C++ you can overload the new operator, which could allocate an object in a different way, without overloading the delete operator, causing asymmetric behavior. You could be prone to breaking identities such as (A + B) - B == A, or worse.

C++ lets you overload everything, from + and -, to new, dereference, and indexing. Java has no support whatsoever. C# improves on C++ operator overloading, by providing more intuitive syntax.

Implications for OO

I believe that Operator overloading is something that some objects just scream out for. Why should you not be allowed to add vectors in the same way as numbers? Surely if someone overloads the + operator to actually subtract, then they should not be allowed near a compiler ever again.

I guess if we're 'modelling the real world', concepts such as 'trees' and 'students' can't be 'added', but when the domain is mathematical, OO should give us the tools to model both the Objects and operations.

Encapsulation

In the context of computer science, this term means the logical separation of a concept from another. In OO, encapsulation most commonly refers to restricting visibility to objects or classes. In regards to programming language design, there are two issues: the visibility options available, and the default visibility (as this certainly affects code and design). Then of course, there's the whole issue of Encapsulation boundary, which I won't touch on here.

Advantages, Disadvantages & Language Implementations

Having a weak encapsulation standard, such as default public visibility, is no doubt faster for prototyping. The trade-off is that as a program gets larger, weak encapsulation opens your private workings up to the world, often causing a coupled, buggy, mess. Some argue that not encapsulating will cause an increase in the programmers cognitive load, although Python programmers might argue that the API documentation provides the limited/simplified 'view' that the clients of the code can use.

This is important to our language spectrum for the following reason: Weak encapsulation may not be inherently evil, but if we allow it we must expect hideous coupled code to emerge. Do we force private visibility, such that the programmer must then write boilerplate getters and setters?

Languages like Java, C# and C++ have taken a pretty liberal approach by giving the programmer many different visibility & access modifiers (public, private, protected, internal, friend, const). Python doesn't really seem to care, and pretty much makes everything public by default. Smalltalk is strict, enforcing private object-encapsulated attributes. One interesting compromise is in C#. Implicit properties can be defined (pretty much free-for-all fields), which can then be transitioned to an explicit property, backed by a field, correctly encapsulating data:

 //C# encapsulation with properties
 public String Name {get; private set;} //Implicit property
 public String Name2 {
   get { return _name; }
   set { _name = value; }
 }

Implications for OO

Encapsulation is a critical issue in Object-Oriented programming. Providing a more liberal default visibility, or a wider range of visibility modifiers may be useful, but almost certainly encourage bad OO design. The visibility modifiers in current languages are perhaps unwieldy encapsulation tools

Explicit Pointers/Pointer Arithmetic

Pointers are used in languages such as C and C++ to store the memory address of an object, value, array or function. In these languages, pointers are the standard way to refer to objects by reference (instead of copying the entire object as a value-type). Pointer arithmetic allows users to perform math operations (such as addition) on pointers, in effect giving them uncontrolled access to any memory.

 //Pointer arithmetic - C
 Cat *c;
 c->weight = 14; // Where is c pointing ?!
 delete c; // Delete what?
 Dog *d = (Dog *) (c[4] - 4); //WTF?
 
 //Implicit references - Java
 Cat c = new Cat();
 c[3] + 2 //Doesn't compile, and so it shouldn't.

Advantages, Disadvantages & Language Implementations

Pointers can be incredibly dangerous. As variables are not initialized in C, a pointer can be pointing to an arbitrary place in memory. Also, the memory containing an object can potentially be freed while a pointer to it still exists. If a pointer is dereferenced in either of these cases, it can be an absolute nightmare at runtime.

Pointers have actually been made redundant in most modern languages, as memory must no longer be manually managed. Languages such as Java and C# maintain object 'references', which allow the referencing of object instances without exposing memory details. The objects are transparently created on the heap, and then freed when they're no longer used.

Likely due to these changes, the designers of Java must have seen it is a feature more damaging than useful. The designers of C# chose a compromise, some pointer arithmetic is allowed (mostly for inter-op purposes), but it must be inside a declared 'unsafe' function.

Implications for OO

The absence of explicit pointers fits in well with the OO paradigm - they are an artifact of the underlying model (computer memory), and not a concept that exists in the real world.

Multiple Inheritance

Multiple Inheritance

Strong Typing

blah blah blah

Static Typing

blah blah blah

Language Classification

A rough spectrum of popular languages that I came up with. Feel free to argue/re-arrange etc:

Left To Right

Lisp

Python

C

Smalltalk

C++

C#

Java