An Object Oriented or a Functional Language

Background

In my previous post I came to the conclusion that strong typing should be adopted in EK9.

The next question (before deciding on the types) is to consider the pros-and-cons of Object Oriented programming and Functional programming.

Name Spaces, Scopes and Polymorphism

It is necessary to decide 'where' to locate code when defining an aggregate (structured data) or a function/subroutine. This can assist Polymorphism and has an impact on Coupling/Cohesion.

Some programming languages only have a single global name space in which to define artefacts. This can cause a number of issues, mainly to do with name collisions but also encapsulation of data and function accessibility.

Name Spaces

Languages such as C++, Java and C# have the concept of a 'namespace' or a 'package' from which artefacts can be addressed. This means that it is possible to reduce the collisions of naming. In EK9 this will be called a module. This will allow naming as follows:

postalAddress <- general.postal::Address()
networkAddress <- org.network::Address()

This allows the name Address to be reused, but when this clashes with Address from another module it can be 'fully qualified' to make resolution clear.

Scopes

It is normal in most programming languages to create block scope in functions or member functions (methods on classes). This enables variables to be declared within that block, these variables are typically destroyed/lost when the block scope is complete. There are times when it is desirable to let such variables 'live on' such an idea leads to a closure.

Some languages allow all variables in a scope to be 'closed over'. In EK9 the use of variables in a closure will be explicit.

Both classes and functions also have their own scopes. For functions this scope acts much like a block scope.

For classes the scope contains the member variables and member functions (methods). As discussed in the previous post; polymorphism is highly desirable. While it can be implemented in a number of different ways; use of classes is one of the most natural.

But classes are just one aspect of polymorphism that need to be considered; the concept of a set of method signatures acting as some type of interface or trait can also facilitate polymorphism. These are the main reasons why C morphed from just structs and functions into C++ an Object Oriented language.

Operators

If we were not to provide classes/traits then we'd have to face the issue of whether or not to include operators and operator overloading with developer defined aggregates (data structures).

Are operators desirable? Many languages do include this capability such as C++ and C#; others like Java do not. There are significant benefits in providing this capability; the main one being semantics.

A defined set of operators can also enable the compiler to make a number of assumptions when parsing code (especially when defining 'Generics').

So operators will be included in EK9 and they will be defined in the scope and context of aggregates (such as classes and traits).

Reuse, Inheritance and Delegation

With both classes and traits we can use the traditional inheritance mechanism provided in most Object Oriented languages. In general this feature is overused. In EK9 we will facilitate a mechanism to make delegation just as easy as inheritance. This will be accomplished through the use of member variables and traits.

Delegation/Composition encapsulates data better, facilitates reuse, enables cohesion and makes coupling more flexible. It is currently under used because few programming languages have built in syntax to make delegation/composition as easy as inheritance.

Why bother with functions?

Are functions necessary then? Functions provide a small, stateless and succinct artefact for processing steps. Moreover they are easily reusable and can be made 'pure' (i.e. having no side effects).

In conjunction with the delegation model outlined for classes and traits; functions can also be reused via delegation.

But most importantly there are elements of functionality that do not have a natural 'home' as part of a classes; they stand in there own right within the context of a module.

This is particularly important when the subject of 'streaming pipelines' is addressed. Many languages use/reuse methods on classes to implement what is called a 'fluent' programming interface.

But EK9 will follow the Unix philosophy and use distinct syntax with the pipe | symbol for stream pipelines.

EK9 will also introduce the concept of an abstract function in a similar manner to the C typedef in the previous article.

Conclusion

Functions, Classes and Traits are all required in EK9. They each bring capability and reuse but in different but complementary ways and can be used in combination.

So EK9 will provide syntax and semantics for both Object Oriented Programming and Functional Programming.

The next blog post will cover the basic types that will be provided by EK9 and how higher levels of abstraction for modern concepts should be built into the language from the outset.