 I've hoped you had a great DrupalCon so far already. I've had a great DrupalCon as well. Talked to lots of people. Unfortunately, my voice doesn't take quite as much liking to that as I do, so I hope I'll be clear and understandable to everyone. Welcome to my session about multilingualism makes better programmers. I've been programming for about 15 years. My name is Alexander Farrak. Seven of those years have been spent with Drupal, starting, building sites, creating modules, and I currently work for OpenSocial as a developer. Outside of coding, I love sports and beer, but I've turned my hobby into work, which I say is a good idea, but turns out you work all the time. In this talk, I would like to take a look outside of our comfort zone, so look at what other languages, besides PHP and JavaScript, are doing. One of the initiatives for Drupal 8 was to get off the island. We've done so quite well with adopting a lot of external libraries and components, a lot of things done with Symphony, where we can take it a step farther and see what other language communities are doing. So not everything that other languages can do will be possible in PHP and JavaScript, but I do think that the concepts and the ideas that they have can be applied in your own code as well. So some of the languages that we'll be looking at today will be Ruby, Java, Rust, also some JavaScript, and Perl. First, I would like to shortly look at what's actually in a programming language, because there's a few parts. I think the least interesting is actually the syntax. It's specific to each language, but once you know the general concepts of breaking down a problem and turning it into a solution, then how you write it down is picked up pretty quickly. So it's basically, how do I express what I want to do? Every language also comes with a standard library, which is basically the tools that the language gives you. If you look at assembly, then for example, you get very few tools. If you look at PHP, like the higher level language is like Python, then you get a lot of things for free. There's also the ecosystem. That's also what we are a part of. If you look at the Drupal ecosystem, lots of modules, PHP ecosystem, lots of libraries, JavaScript ecosystem as well, lots of libraries to do the same things. The first language I would like to look at is Ruby, and specifically a bit at their ecosystem. One of the things that I was introduced to when I started working with Ruby about five years ago for a site project is their style guide that's community-driven. You can find it on GitHub at the Rubikup repository. And this is a community-driven effort to standardize the way people write Ruby code. And we can take quite a few things from this style guide and also apply it in our own code. So one of the examples is to keep functions shorter. They say, basically, try to write functions no more than five lines of code. They go as far as to turn the expressions in an if statement into a single function that they call. And this feels a bit weird at first, but once you start doing it, it actually provides really readable code because you're describing what you're checking for instead of how you're checking for it. Yeah, so the summarize give functions a single purpose. Don't try to do too much of it. This reduces mental load because you can see, OK, I know what this function does. And if I need to know how it's done, then you can drill down into the rest. And added benefit, if you're ever presenting something with code, then shorter functions do fit on a slide. And longer functions, unfortunately, do not. But here, as always, do find the right balance and don't go too crazy. An example for this is a function that's in the open social code base. What it does is it tries to load the user's profile to get an image that it displays next to the post box that's at the top of our stream, which is a landing page in open social. But there's actually a lot of checking here. That's not necessarily interesting if I want to know what this does. So a lot of this logic can be extracted into a single function. And this would be a lot more readable because I can see, I get the user image. If I have it, I add it to the post. If I don't have it, then I don't add it. And if I want to know how this happens, then I can drill into the function and see how it's done. Another thing that Ruby style guides shows is the usage of if as a modifier. So what they tell you as an example is to do something if a condition is met. Unfortunately, this is not possible in JavaScript or PHP. But the alternatives that they give you that given some condition, use the end operator or the or operator, do something else, can still be applied. And you've probably used this in your own code. If you look at some sample codes where you've written an if statement, you start with one condition. And then inside the same if statement, you would call a function to check something on this value that you've already verified to check if another condition is true. This can be useful, for example, if you look at the bottom, we have two functions in both PHP and JavaScript. Actually three, sorry, one that returns true, one that returns false, and one that prints a statement. And you can see how you combine the functions that actually only one or both of the functions will be executed depending on how you put them together. So if you add something and the first function returns true, then the second function will also be executed. But if you or something and the first function returns true, then the second function will not be executed. The same when you return false and you add something, then the second function will not even be called. So it's safe to do something in the second function that depends on the result of the first function. Another useful snippet from Ruby that's actually quite applicable to Drupal is that it asks you not to use the method missing method. This is a special method in Ruby that allows you to handle any call to a function that doesn't have a specific implementation. So it's basically a catch all. One of the reasons they say that you shouldn't use this is because it makes it hard to figure out whether you've actually done something wrong. Because even if you've mistyped the method, this method will get called. And you don't know whether the method that you typed actually exists or is doing what you intended. If you look at how this is used within Drupal, we implement some of the PHP's equivalents. For example, get and set on entities. But this does make behavior less predictable. This is the implementation of the entity get function. And what it does is it actually tries to find a value for you either on a field, on an entity property, or in a special values array. And the dangerous thing here is that if it doesn't find a field with the name, it'll just create a new value for you and set it to null. So if you get a property on an entity, you never know if it's actually there or whether you just get this default value. So this makes typos still work and hard to track down. And that's why the Ruby community cautions you to use it, even though it can be useful. You can do similar things in JavaScript. It's not as easy. You use the JavaScript proxy. Would be interesting to give a talk on its own about this. It allows you to do all kinds of things like extent, how functions are called, how properties are accessed. Of course, it doesn't work in Internet Explorer. But yeah, it allows you to do a lot of magic. But this magic comes at a cost of being less transparent. After the examples from the Ruby style guides, we'd like to look at Java. One of the things that we've actually been using quite heavily after adopting symphony that comes from the Java world is annotations. So these are metadata that is added to classes or functions that changes how those objects behave. An example of how this would be done in Java is by writing a simple Minecraft mod. We create a class that will encapsulate our mod. We give it some static properties for an ID and a version. And we create a function that will do something if it's called. However, if we define this, then by default, nothing will happen because our program doesn't yet know how to use this. So that's where annotations can be used. What we do here is we import this mod annotation. And we add it above our class. And this tells the Minecraft extension framework like, hey, this class should be treated as a mod and load it when you have the chance. We give some data that comes from our class that can be used in statistics for the user. Finally, we can use an annotation on the function level as well to make sure that this init method is treated as an event handler. And the framework knows that if it gets an event handler that's registered with this name init, then it'll get the initialized event when the module is initialized. So as an example of how we use this in Drupal, we use it to create field widgets. I think I hope most of you have seen this at some point. One thing you'll notice is that the way this looks is a bit different. In Java, you would just write it next to the class, next to the property, as if it's a language construct. But in PHP, this is actually not built into the language. That's why we write these annotations and comments. The way this actually works is that it uses the annotations library from Doctrine, which uses the PHP reflection class to get information about the class, parse the comments, and then figure out what it has to do. One of the interesting side effects of this is that if you use an optimized runtime of PHP that strips away comments to speed up file loading, then your annotations suddenly no longer work. There is a proposal to move annotations into PHP as a first class citizen, which you can find on the PHP wiki. But there hasn't been much activity yet, so I think for now we're going to be stuck with comments. Annotations are also available in JavaScript, although their behavior is slightly different. They're called decorators, and they are used to modify behavior of a class or its properties. So our annotations are really used to describe classes that are available, for example, to make them available in a plug-in system. In JavaScript, you can go a bit farther and actually modify the behavior. It's not in the core language yet. It's currently a proposal that's in stage two. You can already use it if you're using tools like Babel or TypeScript. And I think we'll see this end up in the language in a few years. As an example of what this looked like, we can create a small counter widget that's a custom HTML element. And one of the first things that we want to do is we want to make this element available in the normal way that we write an HTML element. So we use this define element decorator. And we say, OK, this class should be modified so that we can render it as a normal HTML element. Then we want to add some functionality to actually make the counter work. And for this, we introduce a variable x to keep our count. But we give it the track decorator. And what this does is it modifies this variable so that it intercepts the calls to modifications or whenever it's set. And when this happens, it checks out the class that this variable is a member of. And it calls the render method. And we also use the connected callback to initially render our element. And what you see is that since we're extending the HTML element, we can just put the value of x inside our text content of our element. One of the things that you may have run into, if you've ever worked with classes in JavaScript, is that if you have a method in the class and you pass it as a handler to a callback, that the context of this inside the method when the callback is called is no longer your class instance. But it's actually the instance of the element where the callback was fired on. One way to avoid this is that in the class constructor, you can actually overwrite your function to say, my function is the function but bound to the context of the class. But this is quite cumbersome if you have a lot of functions in your class. So one of the decorators that is shipped by the proposal is the bound decorator, which actually does this for you. So by annotating a function in this way, it's modified to always have the context of the class instance. And finally, to make sure that you can actually click the counter and it updates, we create an onclick handler. And here we use the set decorator to actually set this property as an attribute on the underlying HTML element instead of just as a property on the class. So these are a few examples of how decorators can be used to basically intercept the declaration of classes, properties, and functions, and to modify how they behave and what you can do with them. So one of the languages that's made a huge boom in popularity in the last few years is Rust. I really like it to play with it. It's a systems programming language built by Mozilla. They've used it to rewrite the rendering engine for Firefox. And it's a strongly typed language, which differs quite a bit from PHP and JavaScript. And they take this really far. But this also gives them the ability to make a lot of safety guarantees. So if that's something you're interested in for system programming, definitely check it out. It's really, really cool to play with. So a strongly typed language means that a language has distinct type declarations for all the data that it's passing around. This is different from PHP, where basically if I pass, I give you a string, and you say it's a number, then PHP says, OK, I'll see how I can make this a number. But this leads to a lot of subtle bugs. Thankfully, PHP is moving ever closer to being able to be a strongly typed language. So in 5.0, we already got type hints for interfaces and class names, arrays followed soon after. We got color balls in 5.4, and starting with 7.0, which means we can now use it as Drupal. I believe no longer supports 5.6. We can also do primitive types, and something that I'm really excited about in 7.4 is also type hints for class properties. So you can see, say, that the property in a class should be a certain type. And if you ever assign it a different type, PHP will scream at you, and you know that you've done something wrong. You have to fix something before it's a bug that the client sees. So an example of what will be possible in 7.4 is a little contrived example. We have a property that has called chant that is typed to be a string. We have a setChant that gets a string, so we can assign it to our property. We also have a function that will output this for us. And finally, we just have a function that says, I return a Boolean. However, if we would use this, and then you can see that you can create a new instance of this class, you can set the chant to be a string. Everything is going fine. You can ask it to output this. Then you can set the chant given an integer. It will continue to go, and it will still output this. This may be undesirable, because this is not actually strictly typing, but PHP thinks it's being clever, and it's just converting this number to a string for you. Since I can do this, but this may not be what you want. If you're trying to wire up two things and you know that you should be getting a string on both sides, you may want it to be a little stricter. This is something that we can do by adding declare strict types at the top. So if we were to run this same example again, then at the moment that we want to set the chant to a number, PHP will say, hey, you're trying to use a number here. If you really want to convert this to a string, then you would have to make it explicit, so that there's no subtle behavior here. Seeing how this goes with Drupal, there is some work being done, mostly for array typing. Interfaces have helped a lot, but for this other primitive types than arrays, so your strings, integers, there's still quite a bit of work to do. There's some important issues if you want to look into this. The most of the recent discussion and work is being done in the last two issues. One of the things that we're running into is that we don't want to break backwards compatibility. So if you're suddenly adding a type definition somewhere where before you would say, this can be anything, then someone's code that's inheriting that might break. And that's not what we want to do. Looking at strongly typed JavaScript, JavaScript itself is inherently not strongly typed. There's also no way you can do anything with types. But if you want to do this, then TypeScript is something that you can look at, and it can give you actually build time constraints on what types you're using and tell you if you're making mistakes there. Another interesting feature in Rust that I want to highlight today is pattern matching. It's a syntax where you can take a variable that will have a certain set of values, and you can run logic depending on what kind of value there is. So as an example, say we have a variable that's an integer, and depending on what value this variable has, we want to run certain logic. If it's 1, 2, 3, print the number. If it's anything else, just print anything. This looks a lot like the switch statements that you may be familiar with. But it can do a bit more than the switch statements that we know. One of the examples is that we say we can create a single match for the number 1, 2, 5, and capture that value that it actually is into a new variable so that we can print it. And then for all other instances, we can also just catch the value and still use it in our executing codes. We can also extend this to enumerations. This can be types that can be one value or another. Here you see an optional integer. So it can either be of type value and have an enclosing integer, or it can be of the missing type. And when we create this, we can create a match statement where we either catch the value from this structure if it's greater than 5 in all other cases. We also just print that you have an integer. And if we have no integer value, if it's the type missing, then we run some other codes. So this allows you to really define which cases are possible and create very powerful groupings of those cases. Whereas in a switch, it all has to be the same type. And you can really only add on strong, strictly defined values for the switch statements. So the enum that you saw in the previous example, it's actually quite powerful type. And we have things that try to emulate this in Drupal. An example of this is the language interface, which actually defines values for a text direction. And it says it's either left to right or right to left. And if you implement the language and you create the method get direction, then it should always return one of these values. And this is a promise that's made to you in the comments, but it's actually never enforced by PHP. So one of the things that we can do looking at this interface is to create a gibberish language that when you ask it for a direction, it tells you that its direction is outside in. PHP thinks this is valid. Even if you were to add return types, it would probably say it returns a string. We're still doing this. So PHP wouldn't tell you your code is broken. But if you're trying to render something based on whether something is left to right or right to left and you don't have anything that handles any other case, then your application is probably going to break. With enumerations, you can solve this by saying that we define an enumeration with a language direction. And it's either left to right or right to left, but it can be no other value. So if you then would create this interface and say, this is the return type, then Rust can check at compile time that it's one of these things that you're returning. And if you don't do it, it'll say like, hey, you are supposed to return a language direction which you're actually returning a string. And enumerations can actually hold a lot more kinds of values. So this is an example from the Rust documentation where you're trying to handle a web event. So this can either be page load or page unload, which contains no data. But it can also be a key press where it contains a certain character. Or it can be the paced event that has a string or a click where you even have an entire data structure encapsulated that gives you the coordinates. So unfortunately, PHP doesn't offer this out of the box. And why that's unfortunate, we'll also get to in a moment. There is the SPL types extension, but it's experimental, so I don't know where that's going. One of the takeaways here is to check your return types and see that you're actually getting what you expect and also think about what happens if that's no longer the case. Yeah, JavaScript, this is really something that only works in a strongly typed language. So TypeScript does support it, but JavaScript really doesn't. And you'll really have to be careful with JavaScript to check. Another interesting thing that you encounter when you start working with Rust is that no doesn't exist. And at first, this feels really weird, because what do you do if you don't have a value? In Drupal, you would say, I give you a value, or I give you no. And it's really clear I don't have a value for you. But what if a developer creates this code? I want to load a node. I want to do something with it. It should work fine, right? But if we actually don't have this node, then this will give you quite a bad error in your application, because PHP doesn't know how to continue when you try to call a functional no. So we can try something similar in Rust by creating a small program that opens a file and reads some text for it. Do the same as what we did in the Drupal example. Naively open the file. Read the string into a variable, print the contents. The Rust compiler will actually tell us that this is not possible, because the function that we use to read the string actually doesn't exist on the return type of the file open call. That's because the file open call gives us a result type. And that's how Rust solves this problem. It uses this enumeration type to create a result type that has two possible values. It's either OK, in which it encapsulates some value of type T, or it's an error, in which case it encapsulates an error object of type E. It's pretty simple. This is what it would look like. So OK, one of the ways we can handle this is to use our match. We know we want to open the file. We want to get this file object from the OK function, get the contents, print it out. But Rust won't be satisfied with that, because you're only handling the success case. And that's one of the big powers of Rust, if you start working with it, is that it always forces you to handle the error case. It's basically looking at this match. It knows that the result type has two possible values, so it forces you to create a match that handles all these values. And I think this would be like, if you've done this for a while, at some point you start to look at Drupal code, and you see, hey, we're only checking for success. And if there's an error here, everything breaks down. Even from JavaScript, we can learn some things. There's quite a bit of fun to be had. One of the first things is to look at closures. A closure is when you create a function that encapsulates some data from outside of the function. So in technical terms, it encapsulates the lexical environment. The Mozilla developer network documentation on this is excellent, so we'll borrow some examples here. And if you want to see more, go there. The simplest closure that you can create is we create a function that carries the current value of name. And then we can call display name. And you will see that the name Mozilla will actually be printed, because it's using this variable that's outside of the function and carrying it inside. We can take this a step farther to create a function generator, where we have one function that doesn't execute the function that it creates directly, but will actually return the function so that you can call it at a later time. And you see that when you call it at this later time, it'll still have this name value that's actually outside of the declared function. So even though the function is returned, this name is stored with the function that you created. So what you see here is that it's so just to show you two ways to write function JavaScript to make the next example a bit more succinct, you have the normal function notation and the arrow function notation, but they behave exactly the same. So one of the ways that we can also create closures is to use this arrow function notation when we say, we have a function that's a function generator to make an adder. We initialize this with a certain value, for example, make adder six. Now we have a function that will always add six. And if we create another function that says make adder nine, then this will always add nine. And even though we're using the same function to construct these functions, they will not intertwine with each other. This allows us to create partial functions and to compose these, which leads into a bit of functional programming. Functional programming tries to compose functions in such a way that you don't mutate the variables that you have in between. So for example, if I have a shopping cart, this is in JavaScript, and I want to convert the dollar value to euro, I have some function that has the exchange rate. I iterate over the cart, and I update my prices by calling the function for every price. The downside here is that I have to make sure that I loop through this correctly and that if I want to see the original cart, it's now destroyed. A way to get around this is to use the map function. This will iterate over the entire array for you, so you're also sure to never run out of bounds. And then the items that you return in this function will be collected into a new array. And here, we can still use this dollar-to-euro conversion. We can extend this with the earlier example of creating functions, where we actually create a cart exchanger, where we create different functions for the different currencies that we want to convert to. And then we can use the map function to simply create carts in the different exchange rates that we need. We can actually also do this in PHP, where you would just return an anonymous function if you create a cart exchanger. This looks a bit verbose. The use statement that you see here is where you're actually telling PHP. These are the variables that I want to capture from outside of my functional context and store with the created function, so that if they change later, they remain the same. And then we can use the array map function to iterate over our cart and create a new cart in Euro. Starting in PHP 7.4, we can make this slightly shorter by using the function keyword. And this will automatically capture the variables outside of the function and store it with the created function. Finally, I want to show you how Pearl used this functional programming to solve a problem and the solution to which they've called the Swatchin transform. It's a way to improve the efficiency of sorting items if what you're sorting on is very expensive to calculate. So this can work without intermediate variables, which can sometimes be a pain if you need to say, like, OK, I want to make this temporary variable, assign it to it, move it around. You can do it in PHP. I haven't included on the slide here because it looks like a giant mess. In JavaScript, it actually looks quite nice, so that's what we'll use to demonstrate this. We start out with an unsorted list, and this is basically to demonstrate if you sort this list how often do the values get called into this sort function. So you can see that this is about 22 times that it's handling an element. So if we would implement this the naive way, we would have a transform that takes a second to do some network access or touch the database or disk, and we would call this on each value as we're comparing it. This would take about 22 seconds to execute, which for a sort function is pretty long. We can fix this by transforming our values first and then sorting them. This reduces the runtime to about six seconds, but this gives us a slight problem because we no longer have the values that we were trying to sort. And if we want to display those, then that's an issue. The way that they got around this is to actually transform the value into a new array that contains both the original value and the transformed value, and then sort based on this. You can sort based on one of the properties in this array, so the transformed value. And at the end, you simply map it back to the original value so that you retain your original value array, but in a sorted order. And this is also faster. So this map, sort, map is your swatching and transform. I want to end with a little bit of wisdom from the Ruby style guides, is that no matter what you do, try to be consistent and use your common sense. And that's it. We have about one minute left for questions, so I don't know if there's anyone that wants to ask anything. If not, then I would like to remind you all tomorrow, it's contribution days. You wanna write some codes, apply some of the things here. I'll see you tomorrow for questions. Thank you.