# Constructs - do we need more? ## Background In my [previous post](https://blog.ek9.io/immutability-why-is-it-hard) I covered immutability and touched on the first *construct*; the [constant](https://www.ek9.io/constants.html). EK9 also has [functions](https://www.ek9.io/functions.html), [dynamic functions](https://www.ek9.io/dynamicFunctions.html), [classes](https://www.ek9.io/classes.html), [dynamic classes](https://www.ek9.io/dynamicClasses.html) and [interfaces/traits](https://www.ek9.io/traits.html). These are all unsurprising as they are presented in most languages. But in EK9 **functions** and **classes** are equal *constructs* much like they are in **C++**. But are **constants, functions** and **classes** enough? ## APIs - Frameworks - Pre-processors Let's take a quick look at what developers actually use more widely beyond just the programming language of choice. It's pretty obvious what an *API* or *library* is. It is some form of prebuilt functionality that you as the developer decide to call. The developer is in the driving seat -- so to speak. The *framework* is also fairly easy to understand. In this case the developer creates some piece of functionality and *registers* it via some existing software through an *API*, *library* or configuration file. But here is the twist, the *framework* does the actual calling of the developers code. So the *framework* is in the driving seat of making the call (yes the developer did configure when to make the call - but the framework does the calling). So what about *pre-processors* like those for *sass*, *svelte*, etc. Indeed what about *post-processors* for slimming down the final sets of artefacts, packaging etc. Now these *processors* take code to output in one format and transform it, in some cases they are a quite *simple* but in others they are more like a *compiler*. But in general they all push the final use/checks/assembly to *runtime*. ### Front-end While most (but not all) back-end development has long had *compile and packaging* technology in various forms (*dll, so, lib, jar* etc), the front-end has generally made the most of its agility. By this I mean just straight forward text files that a browser engine uses (HTML, Javascript and CSS). Simple, clean (without too much complexity in the tool chain). For many years this was the way to deliver an application via the internet to clients/customers (for some; it still is). But now the front-end has almost moved into being *compiled*. Initially through the use of *pre-processors*, but now more frameworks are adding in specifics that require *pre-processing*. More importantly the resulting artefacts require (*post-processing* and *packaging*). **Why?** Evolution; the fact that the delivery mechanism of *HTML, Javascript and CSS* is being treated more like assembly code. Web App developers are looking for more of a *component model* rather than a *page layout model*. Developers want to make reusable components they can compose on to a page. But importantly they want to componentise not just the dynamic visual content, but the behaviour and the presentation. They want *Object Orientation*; but more than just pulling/merging/copying a number of separate files together. Web Applications are becoming more like **thick clients** of old, it is just that the browser is the deployment mechanism. Newer Web Applications are tending to *thin out* the back-end and put more and more logic in the front-end. Will this trend end? There was a reason the **N-tier** architecture evolved. Thicker client solutions come with a range of benefits but also a range of drawbacks. With more of a component model; **CSS** becomes an issue, because it was designed to work with a *page layout model* not really a *component model*. This is designed right into **CSS** it has a very strong mechanism to be able to address elements via the structure of a page. It also has the **.class** mechanism to short cut all that. This then causes alternate **CSS** approaches to be adopted (like *tailwind* for example). When you think about it; it is the whole *page* the user sees. So there are some aspects of styling that could be at a component level; but there is a significant amount that should be at the whole page/site level. It's quite obvious that moving from just pure **HTML** with [unobtrusive Javascript](https://en.wikipedia.org/wiki/Unobtrusive_JavaScript) and **CSS** with a page layout focus; to a *component model*, that is primarily driven through Javascript frameworks; is a very big shift in approach! Why have I discussed these different approaches? The main reason is to highlight evolution and the constant struggle to find a viable solution to specific problems. Will the Javascript framework pull more and more into the browser; is this desirable? What are the implications/benefits/drawbacks? The most interesting thing here for me is the adoption of an *Object Oriented Approach* to UI delivery to the browser. But several of these new frameworks have lost the *separation of concerns* when it comes to mixing object structure, markup and *CSS* presentation. So while gaining some *componentisation* functionality, the separation between the *HTML* markup and code and the further separation of **look** via **CSS** has been sacrificed to some extent. It is interesting to note that [Apache Wicket](https://wicket.apache.org/start/quickstart.html) (which dates back to 2005) has a sort of *OO* approach with a separation between *HTML* and *Java* but is server side rendering (with Ajax hooks). ### Back-end Evolution is not restricted to the front-end; the back-end has also undergone some change. If we focus on *Java* and *Spring* for a moment; it becomes quite clear that a sort of 'meta-language' of **Component, Service, Config, etc** has; in effect, created another language. This is in stark contradiction to what *Spring* set out to do. Originally its aim was to be unobtrusive and *wire* together Objects through configuration files. But I digress, the main point of *Spring* and any IOC/DI framework is to add capability that is missing from the programming language itself. You can make the argument **that's what Annotations are for**, but you are building a framework and additional syntax/semantics that are not really compile time safe. It is only at runtime you actually find out if your *wiring* was right or not. Those **Annotations** are also very specific to the API/Framework. You see this same sort of **Annotation** driven approach in frameworks like *Spring WebServices*. ## Different Roles What appears to have happened since the 1960's that different sorts of *patterns/constructs* have just naturally evolved out of different programming languages when they have been applied to specific problems. During the late 1980's the new construct of the *class* emerged. Further innovations occur in the 1990's with *markup* (specifically HTML). This is followed quite quickly by the pattern of *separation of concerns* with respect to *markup* and how/where that *marked up content* is presented (**CSS**). We also see a move to *virtual machines* with Java (though the [USDC p-system](https://en.wikipedia.org/wiki/UCSD_Pascal) and others pre-dates this). Innovation continues with *markup* in the form of *JSON* and the *Semantic Web*. In general we can see languages like **Smalltalk**, **Haskell**, **Erlang**, **Lisp** for example have some following in certain domains; but remain somewhat niche. But concepts and ideas from those languages *leak out* and get incorporated into *design patterns* or other languages over time. ### Summary You may think that the above *history* and summaries of front-end and back-end are just ramblings. But there is a common theme in all of them; the choice of programming language has not allowed a developer to solve a problem without significant additional APIs, Frameworks and Processors. In some cases the *constructs* are constraints of simple types but in others they are *Aggregates* used in conjunction with a *design pattern* or *role*. Additionally; certain technologies such as Browsers, Java and C# have provided mechanisms that enable developers to mitigate omissions of *constructs* in programming languages. I'll give some examples to try and make this a little clearer. ### Enumerations An [enumerated](https://en.wikipedia.org/wiki/Enumerated_type) type is normally based on some simple primitive type (an Integer for example). But this construct was not always **baked in**. The original K&R **C** language did not have enumerations. They sort of evolved out over time, most languages (but not all) now support **Enumerations**. But why are they needed? What purpose to they perform? Won't just a finite set of *ints* just do the job just as well? No, not really; if you want **strong typing**. This is really what an enumeration is giving you; **strong typing**. It's noticeable that languages like Javascript and Python are a little late to the *enumeration game* -- these languages don't tend to be associated with **strong typing**. [EK9 has enumerations](https://www.ek9.io/enumerations.html). ### Simple Constraints So really an enumeration boils down to some sort of *constraint* on a primitive type when it comes to delivering **Enumerations**. [ADA](https://www.adaic.org/resources/add_content/docs/craft/html/ch05.htm) has the idea of subtypes/derived types. This again is a form of **strong typing**. Why would these be useful in a program? They could be used to represent minimum and maximum values for a person age for example. Defining a *constraint* on Integer to be greater than 16 and less than 91 for some business reason. The main benefit of this is type safety, but also it is possible to have an **operator** of **++** on a variable and accidentally transition over a boundary. When this boundary is transited an exception could be thrown or the value could just become undefined. EK9 has [constrained types](https://www.ek9.io/components.html); specifically look at ** EmployeeId** and **Name** in the example code. These provide **strong typing**. The *Tag Cloud* shown on the link above also highlights the value of strong typing. It helps to quickly convey meaning. ### Classes Classes sort of evolved out of *structs* with *function pointers* attached to them, then became a solution for *reuse* through inheritance. ### Interfaces/traits These programming concepts evolved out of *abstract classes* and enabled developers to create different polymorphic views of the same object but in a type safe way. ### DTO's In general quite a few programs are written using *data transfer objects*, in **C/C++/C#** these would be called *structs*. Other languages call them **records**. EK9 uses the term [record](https://www.ek9.io/records.html). In EK9 these have constructors, public fields and optional **operators**. Their main purpose is to be a *data transfer object*. The Java programming language has now also evolved to include *records*. So this is another concrete example of how languages move and evolve different *constructs* over time. But this is also quite significant and many Object Oriented theorists would decry these *records* as **anaemic classes**. Again this is an example of how patterns/trends and accepted ways of working change over time (I'll skip the **Singleton** debacle). ### Internationalisation Most languages provide APIs for internationalisation and managing of localisation of messages for the end user. But EK9 takes this important area one step further by providing a [text](https://www.ek9.io/textProperties.html) *construct* explicitly designed to deal with internationalisation and localisation. It does also provide API calls in the form of a [Locale](https://www.ek9.io/builtInTypes.html#locale). But the [text](https://www.ek9.io/textProperties.html) *construct* has been designed to: - Deal with small or large amounts of text - Be component driven - Be parametrisable with strong typing - Provide compiler support for missing messages - Be flexible in the number and size of files that contain application text You may consider this a little excessive, but if you have ever developed a large component based application for multiple spoken languages you'll immediately see the value and need for this *construct*. ### IOC and DI Inversion of Control and Dependency Injection are two mechanism used widely in development. But in general they are provided through some form of *meta language* or *external configuration* mechanism. [Spring](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) is an example of this. EK9 is no where near as comprehensive as *Spring* it has been designed **not to be**. It bakes IOC and DI right into the language; through the use of [Applications/Components](https://www.ek9.io/components.html) and [Dependency Injection](https://www.ek9.io/dependencyInjection.html). Both IOC and DI can be very useful, but can also lead to massive complexity. EK9 looks to cut through the excesses and provide a minimal but valuable *construct* to support this design technique. But what should we apply IOC/DI and Aspect to? In EK9 you can **only** apply them to [components](https://www.ek9.io/components.html). **Why** Because that is the most appropriate *level* to apply them. If you can apply them to *Classes* then IOC/DI is abused and the code base becomes too interlinked through excessive injection. In short it's just too easy. By ensuring only *components* can be injected, it is possible to ensure a more appropriate layering of code. ### Aspects Through the use of IOC and DI EK9 also includes a minimal *aspect oriented mechanism* for cross cutting concerns. Many theorists now avoid *aspect oriented programming* stating that it is **brittle**, buggy or limits refactoring. EK9 has deliberately *limited* the excesses of *AOP*, in EK9 there is no matching methods by name or anything like that. It's an all or nothing thing on a *component*. ### Streaming While not strictly a *construct* in the traditional sense; EK9 pulls away from the object oriented approach of streaming and pipelining through *fluent interfaces* or *method chaining*. It firmly moves in the direction of *functional programming* and provides [Pipelines](https://www.ek9.io/streamsAndPipelines.html). If you are familiar with Unix pipes and pipeline processing then this is for you; but in a programming language. You may ask; why create more syntax and *constructs* for something that can be delivered via **Classes/Objects**? The main reasons are simple syntax, semantics and consistency. The concept of streaming *objects/data/functions* through a processing pipeline is significant and compelling. The only reason languages such as Java/C# employ objects and a fluent interface is because that's all they have available. [EK9 Pipelines](https://www.ek9.io/streamsAndPipelines.html) provide and very clear, concise and elegant natural *construct* for developers. ### Web Services As mentioned previously *Spring WebServices* employs **Annotations** for implementation of web services. Many other languages have frameworks that support web services. But [EK9 Web services](https://www.ek9.io/webServices.html) bake this essential *construct* right into the language. This **service** *construct* dovetails with the **text** *construct*. Like **TCP**; the **HTTP** protocol is here to stay. It is now very unlikely it will be replaced by anything else. It may evolve and change but unlike some technologies (*RMI* and *CORBA* for example), **HTTP** is here to stay in the mainstream. As such EK9 builds it right into the language as a powerful *construct*. ### Packaging The last *construct* EK9 introduces is [packaging](https://www.ek9.io/packaging.html). You may think that final packaging, versioning and releasing of software should be external to the language. After all most languages don't include packaging but depend on tools like **npm, ant, ivy, maven, cradle, make, imake, cmake, pip** etc, etc). Here lies the problem if we're honest. Why so many package managers and why does each language tend to add at least one new one? In general it's because each language has features/limits/constraints that require a different approach. Unfortunately all these package managers then invent their own specific package syntax and file format! So let's just accept that as a new language EK9 will probably need some type of package manager mechanism and rather than use an external format - just build it into the language itself. Tools like *make* start off simple, but building software is now so much more than simple steps from taking source -> object -> binaries. Dependency management, packaging, publishing and version management are now critical aspects in software development. The [EK9 command line tool](https://www.ek9.io/commandline.html) has a very wide range of options and lots of functionality to be able to support: - Dependency Resolution - Package Management - Compilation - Versioning - Packaging - Publishing - Execution ## Summary EK9 has gone from a couple of simple *constructs* and included a wide range of additional ideas. You may consider this is going too far; take a look at the [example](https://www.ek9.io/index.html#examples), you might see the ideas fit quite well together. These conclusions I'm drawing here may well be **wrong**. But I have to wonder why we have some many different *frameworks*, *APIs* and *build tools* if our programming languages are complete. When I look at most new *programming languages* such as **Golang, Rust, Dart, Kotlin, Swift, etc**; I see improvements here and there; but no real radical shift or innovation. I don't intend this to be a criticism, they each address the target issues they are attempting to resolve. I'm attempting to resolve the target issue I think exist (maybe only I think these are real issues to be addressed). Importantly, when getting started with EK9 you only really need to use a handful of these different *constructs*, but you can employ more of them as you progress. There are quite a few [examples](https://www.ek9.io/index.html#examples) for you to look at to get a feel of the language. These range from very simple to complete applications. ### A different approach In the next post I'll cover the syntax of EK9 and why it was adopted. Superficially EK9 syntax looks very similar to Python rather than C, C++, C#, Java, Dart, Kotlin, Go, Rust or Swift. This is not due to my Python background (my background is C, C++ and Java). But my aversion to *punctuation* and slight dyslexia make it much easier for me to read a sort of Python syntax. Why not just use Python then? There are some flaws in its approach and its lack of **strong typing** means I find it useful for small utilities, but not for full large scale application development. So I have attempted to merge aspects of many languages into one I like. You may consider this egocentric. I can understand you might think that. When creating something you like yourself; it maybe that **only** you like it; that's fine by me. But I'm hoping a few other people will see value and utility in this new language. So next post is all about syntax. It will probably look quite strange to you at first. But I've looked at quite a few theoretical papers on how humans comprehend text via layout. I have attempted to fold some of those ideas into the layout and structure.