 My name is Emiliano Firmino. I am a software developer from Brazil and I will present here one extension that we have developed that brings to Erlang support for object oriented programming. We have created a very thin extension, so you can continue to program in Erlang, but using this extension we can using objects just like you can do in C++, Java and other object oriented programming languages. So... Okay, so who I am? Well, now I'm currently maintaining of Erlang. It's an extension of Erlang. And I work as a software developer at INDT. INDT is a company in Brazil that helps Microsoft to develop applications and research related to mobile phones. And also, I am a master's student at the University of Pernambuco, Federal University of Pernambuco. And I have a degree in computer engineering by the State University of Amazonas. The Erlang is the only functional programming language that I have some experience. I have tried before F sharp, high-skill, but I didn't dedicate enough time. So I only Erlang that I have some experience. And in my daily base, I work with C++ and C sharp, but I have some experience with Java and JavaScript. Because of this project, I have some experience with programming languages, distributed systems, and because my company works with mobile phones, I have some experience with Android and Windows Phone platforms. And multimedia, mainly in audio and video streaming. But where am I from? Well, I'm from Manaus. Manaus is a city in the heart of the Amazon jungle. It's there. There are many industries there because the initiatives of Brazil governments. So there are the Honda, Panasonic, Microsoft, and many other companies that produce electronics. And but since last year, I live in Recife. Recife is the city that have a strong IT industry. Well, how I got there? I got there. Well, those two cities are apart by just 1800 miles. So if I want to see my parents, I have to take a plane of six hours. But how I got there? Well, 10 years ago, my previous university, my current university, have created a partnership to improve the formation of their professors because, in my state, the university is very young. It has less than 15 years. So they create a partnership, an inter-university doctoral program that helps to create more PhDs and masters in the area. And one of these projects of this program was the this one, Orilland. That was a PhD test for my former supervisor. I'm not the only one that had worked in this project. We have helped from two supervisors from FPE. One of them is my current supervisor, Professor Rafael Lins and the other Professor Francisco Junior. One PhD student at the time, that was my former supervisor, Professor Jusma Junior, and three undergraduate students. That was me and two friends, Daniela Aquino and Rodrigo Bernadino. In this presentation, first I will talk a little background, why we think that it was important to bring object-oriented programming to Orilland. Our approach, how we implemented the language, short crash course here, showing how to get the source, install, create a basic class, inheritance, interface, using the language and comparing with Java and C++. I will talk a little about the internals of the language, how we implemented the objects and translated from our metaprogramming language, Orilland to Orilland. A short citation about some previous work that we have done with the language and some ideas that we have for our future work. And when we finish this presentation, I can answer some questions. Well, that might be a shocking fact, but OOP is very popular. It's many probably all of you have some knowledge or experience with OOP, object-oriented programming. We can see this by looking some ranks. If you see that Taiobi rank from this month, we see that the top ten language, only one that not supports oriented object programming that they see. The Java, C++, Object C, C sharp, and all these languages have some kind of support to object-oriented programming. Using AutoRank, Red Monk rank, the top ten only two that doesn't support object-oriented programming that they see in CSS. But CSS is not my programming language. And another one, PyPL, the top ten, just like only see that doesn't support OOP. So most programmers have some experience with object-oriented programming. They work with some popular languages like C++, Java, Python, Ruby. And so they have some experience with exception of C. But C you have the option to use C++ or Object C to have support to object-oriented programming. And OOP is widely used in the industry. So many APIs that are provided for the vendors are created for you to access object-oriented programming. Some kind of object-oriented organization. And it's part of many curriculums of computer science and computer engineering undergraduate course. That's not why a functional programming language is still not widely adopted. But these have some flaws. One mainly flaw that I can't see here. It is the reason why functional programs have returned to popularity is because of multi-core processes. Since our process could get more faster by just speed up the frequency, the industry have changed from a mono-core architecture, mono-core process to architecture based on many cores. So now we have our machine, our phones have four cores, eight cores, 16 cores. God knows how many cores in the future. So multi-core programming is very hard compared to traditional programming language, traditional serial languages. And the communication between the process is hard. And in many OOP languages it's very, very prone. So it's very easy to make some mistake. You're writing some parallel code or concurrent code in Java C++. That would be in Haskell or Erlang. But not in Erlang. Erlang have some nice premises that can help you to extract all the processing power of these new architectures. In Erlang everything is a process. So the language itself has native support to creation, destruction and communication of process. Process are shipped to create. You can easily spot one process in Erlang. You just have to know one function, the function name for example. Process share nothing. So there's no risk from a race condition or some kind of interaction between many threads that corrupt your data. And the communication is always explicit. If you want to send a message to a process, there is a explicit operating the language that helps you to send a message. But how much ship is the creator of this process? Running a simple code that just creates a thread, a power thread, and measure how much time it takes to create a thread and join it. I could measure how much time it takes to create a process. For example in Java it takes 200 microseconds while in Erlang just 50 microseconds. And in Erlang process are managed by the virtual machine. So it's not the operating system that should handle this. And they are much more less memory expensive when it created. But Erlang is not very popular. In Tyobi index its number is 36 and the last measurements they have declined. And Erlang uses a prologue-like syntax. For many people it's not very familiar when you confirm the languages that are more C-like. And it's not very well known in the OOP community. So what do you think? What have you thought? How we can help? We have so many developers that have spent many time studying, programming, have a large knowledge of OOP programming to start using Erlang. How we can help to lower the bar to they start using the language? So we thought why we don't help them to apply the knowledge and tools from OOP in Erlang by adding support to OOP in the language. They can still use models in Erlang, all the features of the Erlang. But now there's an option that they can use object-oriented programming in the language. And that's our approach. We have created an extension for the language. This is the site of the language. It has some time that we didn't update it. But the proposal of this is that we have an extension for the language that provides object-oriented programming with a syntax that would be more familiar for Java programmers. Our approach is a lightweight extension that's very thin over Erlang. It should be fully backward compatible with the language, but using this extension can create objects. You can use inheritance, you can use interface, and use a design partner for object-oriented programming, and many other features that have been developed for OOP. To do that, we have to support three pillars that any OOP language must support. That is abstract data types, that's just class. In object-oriented programming, class objects are just a bunch of data and methods that operate together. Inheritance, that we can declare an object, declare a class, and define a more specialized one that provides some nice new features and can enable reuse of code of the parent, for example. In dynamic call, when we have a static type of language where you have a car, if you use a specialized type of car, when you call a function of a car, they have to solve the specialized one, not the parent one. So you have to know when running that this object is not the parent by the children. The first step to start using our extensions is to get the code. The code is available at github.com.org and it's very simple to start using it. You just have to clone the repository and make it. I can show here, after you clone the repository, you have our source code. It's just a LAN code and you can make this code using just make. It will generate a being folder. If our file is compiled and the next step you have to do is to create an environment variable that will be used by the tools, the compiler and the helper that we use to execute a method. They could be a program called OAHome. If you add this environment variable to the path, you can easily compile and run some OAHome code. There are two tools that we basically use to compile and execute objective LAN code. That is our compiler, OOEC, that receives one or more source files. We use an extension dot CERL, that means class Erlang. Just like in C and Java, if you declare a static main function, you can easily run your program using the OOE command line. I can show here a basic hello world, so you can get the feeling about the language. Basically, we define a hello dot CERL, you can see. Basically, we have a class declaring Erlang that is called hello. We define a class method to adjust some methods that are associated with the class, not the object. It's just like a static type. Here, we are using IO format to just print a message. We can compile this code using hello dot CERL. This compiler can run using hello. What we do here, when we call the compiler, we create an equivalent of this code in Erlang that creates an object we are not using here. It's mapped this defined function to just map this class method function to an Erlang function. Now, how do we define a class? A class is just a bunch of data and methods associated. Here, we have a class called person that has a first name, last name and age. We have a constructor called new that received the first name, last name and age. And a method called print that prints this data in STD out. If we would do this in Java, you would have something like this. We can break this declaration in three parts. The first one is there are some definitions. We are saying here that this is a class, we are defining a class called person. And we can have, for example, the package that this class are from or which classes we are using. We have some dependencies. The second part is the attributes. Here, we have first name, last name and age. And finally, we have some methods. We have the constructor and a print method. If we would describe this function using C++, they follow the same idea. We have three parts. The first one, we have some definition. Here, we are defined as a class and it depends on your string and string. We have some attributes. And finally, we have some methods. Or Erlang is the same thing. Uses like different syntax that we would be using just Erlang. But we follow the same structure. We have some definition here. Here, we are defined a class that have a constructor called new that received three params. And export print. The second part, we have some attributes because Erlang is not a static type of language. We don't have to define the type. Here, we could optionally initialize these values. And finally, we have some methods. We have a constructor and a print. I can execute the same code that I show you here. First, the Java. Just the same thing that was defined there. The only difference that we have here is static main point and entry point. So, we can run this code in show. It's running. So, the result here. We have the same code for C++. The same code that I show in this slide. The only difference here is that we have entry point. And we can compile using C++. And finally, we can do the same thing for our class or Erlang. The same class. The only difference here is that we have entry point just like in Java in C++. The second pillar of object oriented programming inheritance. We are a simple inheritance. We have a car that's a parent class. And that child that is a hybrid car. In the parent car, we have some methods. We can start the car engine. We can stop the car engine. And we can honk. And the hybrid car. He changed the implementation of start and stop. But he used the honk implementation from this parent class. If you would declare this in Java, it would be something like this. In Java, car is just a trivial class. But in the child one, we have to use a special notation. We have to say that's hybrid car extends car. And we implemented this method, the method start and stop. And optionally, we can call this the parent using super.start or super.stop to reuse some code from the parent class. In C++, you would be something like this. Because C++ is a little different. In the parent class, you have to say that these methods can be override. So you have to declare that these methods are virtual. And in the child class, you say that the public car, the hybrid car, extend public car, use this notation. And when you want to call a parent method, you have to explicitly say the name of the parent. For example, here car. Or along, we follow something similar to Java. So you don't have to change anything in your parent class. But in the child class, you have to say that this class extends for the parent. In this case, this is hybrid car, hybrid car, extend from car. And we can explicitly call a method from the parent using super, just like in C++ in Java. You can show here. We have a car and a hybrid car. We just activate our class and hybrid car. And we have here our main class that adjusts our app for our main function. What this maze does is it creates a car and creates a hybrid car, C1 and C2. We call the C1 and C2 both are defined as car. We first call start from C1, honk from C1, and stop from C1. And following, we do the same thing for car two. Start, honk, and stop. Honk is not defined in the hybrid car. But because hybrid car inheritance from car, they can use the parent code. You can compile here and run. So here we have that car one have started main engine, honk, and stop the main engine. While car two that is a specialized type of car, first we have to initialize the electric engine. And after that, we call the parent method main engine using super. Car two have not defined honk, but because it's inheritance from car, they have this method. And after that, we stop the main engine and stop the electric engine. In C++, we have some very similar C++. We do the same thing here that we does in the Java main. We create a car, create a hybrid car, and we call start, start, honk, and stop. The same thing we do for car two. C++ equals C++11. So here you get the same output that we saw in Java. Honk is not defined in car two. So he used the implementation from car one. And we do the same thing here in our example using our run. We have not defined honk here, but we use the parent class. So we see there are some ones we cannot use, but it's not important here. And we can call main. But just before that, this, I can show you our main. Basically, we do the same thing that we did in Java in C++. We create a car and call the method start, honk, and stop. And we have the same output. So we have now the last example. We have interface that has special kind of inheritance where in the interface, we don't define no, we have no implementation in the interface. Just a contract that the charge class must implement. So here we have a shape that implements a method called calculate area. And because square, circle, and triangle implement this method, they must implement the calculate area. In Java, it's a special kind of keyword that you say to the compiler. We say public interface shape. So all the methods in the interface must be abstract. They have no implementation. In C++, we don't have an interface keyword, but you can get the same behavior by creating a pure abstract class where all the methods are virtual and not in our virtual and not have implementation. We follow the same syntax, same idea here in our learn. We say that we replace class by interface. So shape is a type of interface that is part of the method calculate area. One moment, please. And this method don't have implementation. When we implement this in Java, we say that, for example, square. We have square implement shape using these syntax. And because of that, they must implement the method calculate area. C++, follow the same syntax that we saw for inheritance. But if you don't implement the calculator area, there will be a compiler error. And in our learn, we follow the same syntax from Java. We have additional definition that we say class square implement shape or one or more interfaces. You can see here our classes. We can compile the Java system. And the method run, method may, just an entry point. Here we define a shape, three shapes, a shape circle, shape square, and shape triangle. With circle, we create a circle, create a square and a triangle. And because of these objects, our shapes, we can call calculate area. Here we can run Java main. So we have the error for each of these objects. We can do the same thing for C++. We have a main function, a main entry point. That does the same thing that we did in Java. We have three kinds of shape, a circle, square, and triangle. And we assess this method calculate area. You get the same results. And the object oriented along with the same thing. We have our classes here. We have a main entry point. That does the same thing that we did in Java and C++. We create a circle. We create a square. We create a triangle. And we invoke the math calculator for each one. So we get the same behavior that we saw in Java and C++. But how we implement the language? Now you'll talk about how internally we map object Erlang to Erlang. Basically, we map with objects, a dictionary process. When you create an object, they map to Erlang in a tuple that has the class name and instance name. I can show here. Use the same code that we just executed. I can use the Erlang terminal. I can here create a circle. New. Five. In Erlang, objects are mapped to a tuple. The first element is the class name. The second one is a process. We use this process to simulate the behavior of an object that can change states. When you change the state of an object, we send this information for this process. One moment. The objects are just tuples that have a class and an instance. This class is just an atom. That is the model of this object. And instance is a process ID that maps all the attributes that we define to enter a process to map those attributes to our entries in the procs dictionary. And when we call a method from an object that follows the syntax object, double-colon method, we translate this to a class called function if the instance are just the first parameter. I can show here. We have implemented in the circle the method calculated area. So we can, for example, first we have a class and an instance of circle. We have stack this. This class is just an atom. And instance is a process ID. And we can call class, calculate area, instance, to get the same result that we saw in the command line. But because we are creating process, we have some problems that we have solved in the future. Let's say more about that. So what our compiler does, we have some steps to implement this behavior. Our compiler translates all along in seven steps. The first step, I can demonstrate this using the compiler. We have some additional options that we can say that we want to get the tokens, the AST, abstract syntax tree. So the first our compiler, he reads the file, he extracts the tokens, they pass the tokens to create abstract syntax tree. We translate this abstract syntax tree from our Erlang to Erlang. After that, we format the code, write to our file in compiler using Erlang. So I can show some tokens here, use the, for example, I can open this shape. I can say, oh, see, get me the tokens of this class, this interface. And when you probably pass this command, oh, see, token shape, he prints all the tokens that compose that file. And after that, we can go to the next phase that is passed to create the abstract syntax tree that represent that data. O A S T, shape dot zero, or circle, or square. And with this abstract syntax tree, we can translate this, we can analyze, we can identify where are defined those objects and convert from Erlang to Erlang to Erlang. I could show here using A S T, but that is a bug. So it's crashing. I have to solve this later. And I can show here the result from the compilation. Square don't count because the interface, interface don't generate code, but I can see, for example, I square, oops, square. He maps square, that's a class, to a module in Erlang. And this model implement the metacalculated area. Here, calculated area receive the object ID that I showed you, that just an instance, and communicate with the dictionary object to get the values. And because we have the code in Erlang, we can just compile using Erlang. I'll compile organizing some models. I will say, I will brief tell about each one. We have A S T that basically can manipulate the syntax tree. We have a core that is a compiler main engine. We have used this library called O O E. Probably you have to see here that we use this in runtime to communicate with the dictionary object. And initially, we are using our modified version of the parser from Erlang. But they have some issues and they don't support macros definition, the fines. So now we are using a modified version of Aleppo. Aleppo is a syntax analyzer that for Erlang that can handle the loading of headers. If you include a header in your Erlang file, the Aleppo parser will support. You can use macros and other features that are not available in the O O E parser. And there are some other models, some other models, like O O S that we are using to extract these tokens. At runtime, there are two main APIs. We have O O E that I have saw you. O O E compiler. We can compile the same code that I'll show you here using this API. For example, one moment. I forgot the name of the classes. We can say here O O C compile, shape, square, for example. And we compile the square function, the square. And there is this O O U 2 that you can get the tokens in the abstracts directory for Erlang and O O Erlang. And we use the language to implement the 23 parsers from Gengar 4. These are available at our site, our repository. And we have used it to implement a benchmark. We have implemented Intel and paid benchmark to compile Java, Scala, Erlang, O Erlang, Python, and Ruby in the communicate-intensive patterns, message patterns that define this MPI. This is available too in our repository. And finally, there are many things to do yet. We have to provide a better integrated development environment using for example Eclipse or other environment. We have, I would say before, we are creating dictionaries to keep the object states. We have to implement some kind of garbage collector. So when all the reference for these objects are gone, we can destroy these objects. Now we have to explicitly call a some kind of standard object library that we will provide some additional functionalities that are provided by Erlang. But based on objects, some kind of interactive terminal so we can use the syntax to create, destroy, and call methods from an object. Before they need to translate, they call conventions from Erlang to Erlang. And there are some bug fixes to do. Thank you very much.