العربية
Facebook Twitter

Nowadays any programmer needs to learn many languages. There is a different programming language for each different purpose. Worse than that, a programmer often needs to use multiple languages in a single project. And every few years new technologies emerge, and with them new programming languages. Forcing all programmers to constantly spend valuable time and resources learning new languages that share the bigger part of their features with other languages anyway, making much of that learning effort technically redundant knowledge. Alusus solves this problem by making language features hot-pluggable. This saves a lot of valuable time and resources for both technology producers and users. Technology producers won't need to develop entire languages from scratch, instead they only need to develop the specific features their technology needs. And users will only need to learn those specific features rather than learning an entire language with its rich set of standard libraries, most of which do the very same thing their counterparts do in other languages.

Advantages

There are many reasons why a single language for every programming need is not only useful, but necessary: In addition to the benefits mentioned above, Alusus is designed to make the following possible:

Concept

To understand Alusus's concept more, think of it as the opposite of frameworks like LLVM, JVM, or .NET. With LLVM for example, you have one code generation backend into which you can plug many language front ends. Alusus is the opposite: it's one language front end into which you can plug many code generation backends.

Extending the language isn't limited to adding new code generation backends. Extensions can also manipulate or add to existing code generation backends as shown in the following graph:

Alusus provides dynamic and modularized syntax into which users can plug new constructs either by writing the code directly in their project or by loading a library that does that. New syntax constructs are accompanied by code generation components that have full access to the compiler's data structures enabling it to manipulate the compilation process. The user can also override existing syntax or code generation components. All of this happens on the fly upon loading of a library or parsing of new syntax definitions, allowing each individual project to pick and choose the extra language features it needs without affecting other projects. The difference between mainstream languages and Alusus is like the difference between gaming consoles and Linux.

How about Conflicts?

With a language as flexible as Alusus, one can only expect conflicts to happen between different code generation libraries developed by different teams. This is as true as is the case with conflicting packages in an operating system like Linux. There are packages that you technically can't use together, nor do they make a valid use case to be used together. For example, you cannot, and shouldn't need to, run Gnome and KDE at the same time; it's either Gnome or KDE, but you can choose between the two what suites you best and choose between init systems what suites you best and so on. The situation will be similar in Alusus where some packages can conflict with others. However, unlike Linux, the target audience for Alusus are programmers who won't have issues understanding and dealing with those technical details. Despite that, Alusus tries to reduce the possibilities of conflicts by allowing language syntax to be modularized, i.e. allowing a syntax addition to be limited to a certain area within the syntax. For example, you can define a 'function' command that can appear only inside a 'namespace' body, and define another 'function' command with a different code generation handler and limit that inside the body of a 'db' command. In this case these two commands won't conflict even if both are loaded at the same time and used together in the same project.

But Can't We Already Extend Existing Languages?

One might say that we can already extend existing languages since most of them are open source anyways. While this is true, there are three important differences between the two approaches:

Doesn't This Make it a Difficult Language?

One might think that with the above mentioned, it looks like the language will be quite difficult to learn. This is not quite true, because the language will come with a standard set of libraries that provides common functionalities like object oriented programming. This won't be more difficult to learn than any other object-oriented language. The difficulty will come with the additional user-generated features, but those will still be far easier to learn than learning an entirely new language. In addition to that, having the extra language features, if done correctly, can save you having to learn how to bridge the two languages and having to spend the time writing that bridging code which will also add an extra source of bugs. Using only one language in a project, even if it's a harder to learn language, will overall result in less to learn, less to test, less bugs, and more reusability.

Hypothetical Examples

The following hypothetical example shows how a client-server system can be developed as a single application:
import "System";
import "http://alusus.net/lib/networking";

def server : System.load_config("server_config");

@host[server] def getDate : function ()=>(System.Date)
{
  return System.Date.today
};

def main : function
{
  def d : getDate();
  d = convertToCurrentTimezone(d);
  print(d);
  return 0
}
The upper example illustrates how Alusus can be expanded to deal with web applications without the user needing to write the server code in a different file using a different language. This ability is added in the second line that imports the 'networking' library which adds the @host modifier and adds whatever is required to the compilation process in order to automatically build the program into two pieces, one for the client and one for the server, and automatically links the two pieces. All this without needing to rebuild the compiler or update the development environment. It's also possible to load more than one library to choose all the features needed for our program. For example, if someone develops a chained_execution library that makes it easier to link statements like a chain (or assembly line) then we'll be able to simplify the upper program into:
import "System";
import "http://alusus.net/lib/networking";
import "http://example.net/lib/chained_execution";

def server : System.loadConfig("server_config");

@host[server] def getDate : function ()=>(System.Date)
{
  return System.Date.today
};

def main : function
{
  getDate() => convertToCurrentTimezone => print;
  return 0
}
There are no limits to what Alusus extensions can achieve as the compiler's internal components and data are available to those libraries. For example, a library can modify the way executable code is generated to enable programming of GPUs. The following hypothetical example shows one possible way to extend the language to support shader programming through a library called gpu_programming. A function is marked to be compiled into a GPU shader by adding the @gpu modifier:
import "http://graphics.com/gpu_programming";

def matrix : Matrix;
def factor : Float;

def draw_lines : function (filename:String)
{
  set_transformation_matrix(matrix~ptr);
  def file : File(filename);
  while !!file.eof() draw_line(file.read[Point](), file.read[Point]())
};

def draw_line : @gpu function(p1:Point, p2:Point)
{
  def pp1 = p1 * matrix;
  def pp2 = p2 * matrix;
  line pp1, pp2, draw_pixel
};

def draw_pixel : @gpu function (p:Point)
{
  def c = color * (1 – (p-center).length()/factor);
  pixel p, c
}
In general, Alusus considers the method of execution or compilation or storage of a program not to be part of the language itself and not part of the program's design. Therefore, the language aims at allowing the program to be designed primarily based on its features and functional specifications rather than the execution environment. For example, Alusus doesn't require special files to manage projects and doesn't need to partition the source code based on the compilation results. Instead, it allows this to be specified in the program itself and using Alusus syntax as in the following example which generates an executable library and a dynamic library from one source code file:
import "System";

def MyLib : namespace
{
  def MyClass : class
  {
    …
  }
};

def MyApp : namespace
{
  def main : function
  {
    def a : MyClass;
    …
  }
};

@ct output format:dynamic_lib, include:MyLib,
           filename:"mylib";

@ct output format:executable, include:MyApp,
           filename:"myapp";
There are no limits to what Alusus libraries can achieve and no limits to the number or types of libraries loaded simultaneously. Alusus is designed to allow adding an unspecified number of grammar definitions and designed in a way to reduce the possibility of conflict between those definitions and guarantees their consistency. Please refer to the language's design document in the Documentation page for more information.

Alusus reimagines software development by eliminating more boundaries and putting more power in the hands of programmers. Have you ever wished if your favourite programming language has a support for some feature you saw in a different language? With Alusus you can easily turn your wishes into reality. Unleash your imagination and contact us to participate in making Alusus a solution to many of the problems that face programmers today.

Copyright © 2018 Alusus Software Ltd